Refactoring revisited

Every now and then I evaluate some tools just to see if I'm missing any tooling goodness. I've mentioned it in the past, and I'll mention it here again. One of the things I really really miss in HDL tools is refactoring support. Even if it is something trivial as renaming a module. You know how it goes. You produce some code, but it's one of those days where you are not very creative in coming up with proper descriptive names. Or you change things slightly, such that a somewhat modified name would now be more descriptive. Now if this were a regular programming language, in any modern tool I can just select the module/class/function/whatever ... press refactor, review changes, and done.

ISE/Vivado of course do not come even close to supporting this but that is no surprise. AFAIK Altera tools are not much better in this regard.

Maybe I am just too used to mature refactoring support in imperative programming country. Maybe if all you know is HDL related tools then you don't mind because you don't know what you are missing. But I find it to be a real pain in the donkey when I want to re-use an old design, or pimp an old design to improve it's re-use. Translation: polish a collection of older modules so they are easier to use in the future, where essentially future == now.

So I was wondering what you people use when refactoring.
- refactor? wut? We don't do that. We rewrite everything from scratch because it's hip and we have plenty of time.
- refactor? wut? We don't do that. We rewrite everything from scratch, which is a pain because we always run out of time. AAARGH the pressure!
- refactor? Yeah, we use a shitload of perl regex's, do a diff which we then inspect and manually edit where needed.
- refactor? Hah! We use Magic Tool XYZ!
- refawuzzawah?

In related news for those using System Verilog, SVEditor is slowly but surely getting there. Compared to the offerings by xilinx/altera it's pretty sweet. It even plays nice with UVM out of the box. The best part IMO is the fast code navigation. Well that and code completion & easy to configure templates. MINUS THE BLEEDING HAVING TO ... ahem.... Minus the having to restart eclipse when you edit templates in a funny way. But oh well, you don't edit templates that often.

Oh and View Class Diagram is really nice. Put cursor on SV class name in your code, CTRL-SHIFT-D and tadaaa nice and readable overview of all related classes.

Is this not just search and replace?

The rename module/class/whatever part of it is just search & replace if you like pain, yes. ;-) Add/remove ports, parameters etc not so much. The nice thing about proper refactoring tools is that it changes what needs to be changed, doesn't change things that do not need to be changed.

Real simple example where straight forward search replace break is having several modules. Lets say modules A, B, C.

Module A uses an instantiation of B. C has nothing to do with A or B, but is used elsewhere in the design. A, B and C all have a port named lets_break_things. You start refactoring module A, and want to rename the lets_break_things port to something_else. The correct behavior would be refactoring tool checks the entire netlist and sees that it also needs to change that port in module B. But NOT in module C. A straightforward search/replace would happily change every lets_break_things occurance to something_else, and in doing so breaking module C. And that's just one simple example.

And of course a proper tool has to intelligently handle the name of that port in comments as well. Because it could be just another word, but it could also be a description of what that signal does, and that word over there really is the name of the signal and needs to be replaced. In that case you want a side by side preview and the option to say "yes, please do change that occurrence of the string, but not that one." Stuff like that. You can do everything by hand with the aid of sed/perl scripts, but wtf, it's 2014.

Im of the "Never had it - dont miss it camp" . Always from a firmware background.
I guess the tools vendors put most of their time /effort into the synth and routing, rather than the editing tools. Most of the problems I know we feedback/get help with are to do with actually getting a design to fit or meeting timing.

Refactoring has never had a second thought (and given the state of the auto-generated code by the system generator tools, I dont want them touching my code!)

I guessed as much already. ;-) Well, I don't want s*** tools touching my code either. I do want tools that actually make my task easier and don't fsck things up in the process to touch my code however.

And it's not as if refactoring in HDL context is a crazy idea. It's just that tool vendors are lagging behind the software world in that regard. The likes of Intel & nvidia etc all use it to improve re-use of their IP. But they have 1) larger problems and 2) larger budgets. They license parsers from the likes of verific and build their own custom refactoring tools on that. And of course you can get by the old way. I mean it's not as if search/replace didn't work in software country many many moons ago. But if you have proper tool that actually work, then that makes the task so much easier.

In the grand scheme of things I also much rather see these same vendors spend their time on implementing a standardized subset of system verilog. If they do that, screw refactoring. By the time they get around to having that in order in say 4 years, there's bound to be a few free editors with refactoring. There's already sigasi, but that's VHDL only. And there's DVTEclipse, but that's using an XML refactor script + it's commercial only.

The whole reason there aren't refactoring tools available for Verilog/VHDL because the majority of ASIC/FPGA designers aren't software engineers with tons of software projects under their belts.

When you have a gazilion software engineers working on tools to help them write code of course they are going to add stuff that makes it easier for them to do things (like refactoring). But unless some group of hardware types (a.k.a. ASIC/FPGA engineers) fork over a wad of cash and ask those same SW engineers to add xyz to some editor they aren't going to be all that inclined to do anything for us.

I for one don't have the time or inclination to become a software engineer and make those changes in my favorite editor. Besides my favorite editor isn't even one of those fancy project based editors that does everything including the dishes. I use VIM (primarily because using a mouse makes my arm hurt). Now if one of those fancy editors actually had a good implementation of a VIM clone mode then I might consider trying it out....

The software/hardware people & lack of crossover probably has a lot to do with it yes. Although at some level I really don't quite get it. The commercial tools are quite expensive, and people buy that. So a little budget for developing this sort of functionality does not seem totally strange. Even if you are totally paranoid about refactoring your RTL code, it also helps in polishing your verification IP.

As for VIM key bindings, SVEditor comes with the vrapper VIM plugin. See this list for implemented VIM-like features: http://vrapper.sourceforge.net/features/

There's a few more plugins like it, that provide vim key bindings. Haven't really tried them myself because :q!.