I have recently started seriously coding in Verilog HDL. Although I am still to get a grip of FPGAs and CPLDs, I am curious about the levels of abstractions used in these codes. I understand I have 3 options right now, Behavioral, Register Transfer and Gate level modeling. But I cannot decide which is the most suited for good synthesis. For example, when making smaller circuits I dabbled in Gate level modeling, but later on when I moved to describing my own ALUs I used behavioral level modeling. But Behavioral modeling feels like just concurrent programming and not exactly hardware description. So what is the best way to write code which will ensure proper synthesis?
-
1\$\begingroup\$ I think there is no best way; one is better suited for fitting the behavior, while one is closer to the HW implementation, so will map more directly the real configuration \$\endgroup\$– clabacchioCommented Apr 13, 2012 at 13:31
-
\$\begingroup\$ As far as I can tell, the only way to ensure your HDL is synthesizable is to follow known patterns. There are supposedly a few good books you might look for. I lurked on the comp.arch.fpga and comp.lang.vhdl groups for a long time absorbing information. IMHO, gate level is ridiculous for anything complex. I would suggest that you embrace the higher level modeling, just learn a few good patterns (all synchronous unless you have a very good reason not to, careful attention to clock domains, a good state machine model you use consistently, etc) \$\endgroup\$– darronCommented Apr 13, 2012 at 15:06
2 Answers
You should completely ignore the terms "behavioral", "Register Transfer", and "Gate level". I think these terms were invented by professors or people writing text books and have little or no relevance to "actually getting work done". It's like scientists and professors inventing Latin names just for the sake of making them sound smart.
Write your code (Verilog, VHDL, or whatever) so that you get the results you want and your code is readable and understandable. After you have done this a while you will settle into a style that works for you.
I should mention that the only way this can happen is if you learn everything about Verilog (or whatever). Often there are features of the language that are not covered very well by books or professors but really help you efficiently write code that is easy to read.
-
1\$\begingroup\$ This is exactly what I had to do in order to "grok" VHDL. The second I stopped reading the books and instead started reading code and speaking to people who actually did the work I found out a) how much bad code there is out there, b) how bad most of the books are and c) that there is absolutely no substitute for talking to someone about a block of code you're trying to make work. \$\endgroup\$ Commented Apr 14, 2012 at 18:50
-
\$\begingroup\$ @AndrewKohlsmith I think that a lot of the bad code (and there is a LOT of it) comes from people with very little software background. There is a huge difference between writing 1k lines of code and writing 500k lines, and the software guys generally know how to write 500k while the HW guys don't. Most of that difference is in managing the logistics of writing 500k lines and still be sane at the end. I actually started doing SW and switched to HW, so writing huge chunks of VHDL is not a big deal to me. \$\endgroup\$– user3624Commented Apr 14, 2012 at 20:49
-
\$\begingroup\$ same here -- almost two decades of C programming but under 3 in HDL. Most of the bad HDL I see seems to have a common source problem where the writer has no real understanding what the tools will create given the code, but the second most common source issue is the lack of understanding regarding synchronous logic. What's left after that is just plain old bad code. :-) \$\endgroup\$ Commented Apr 15, 2012 at 16:34
No one should write at "gate level". There isn't any need for that outside of learning. It's just too low-level to be productive.
The most common level is Register Transfer level. However when you are inferring an adder, for example, that is "behavioral" in that you aren't telling the tools how to do it.