My coding "methodology" with the programming languages I use (C/C++/Perl/Lisp) is well established over the years. I code small pieces at a time, thoroughly testing each. The way software works is mostly linear - this happens, and then that happens, either automatically or caused by some user event. Coding it a small piece at a time is pretty simple and ends with relatively few errors.

In the past few weeks I've written thousands of LOCs of complex VHDL - to be synthesized in a FPGA. And I get the impression that coding a HDL (hardware description language) is a whole different world. Beyond the very trivial logic, things start to get complicated very quickly. State machines are densely intertwined, each one depending on another, sometimes in a circular manner.

So, it's far from simple to follow the software methodology - one piece at a time. Each piece depends (not in terms of I/O, but during its runtime) on others, and it all has to be built together.

I still haven't found a really good systematic way to do it, but I'm making progress. Stubs seem to help. That's when I have a FSM X and FSM Y, each of which depends on the other in its transitions. I can code only X, but then I have to provide a simple stub for Y that keeps certain signals at certain levels and allows me to simulate X. Then the other way. Then, combine them.

I guess it can be paralleled in the software development world. Probably to a massively multi-threaded program, where each thread depends on the other, and they use shared variables to communicate. I haven't done this kind of coding (I did write threaded code, but not anything overly complex), but I guess now I have a good preparation for it.


comments powered by Disqus