[myhdl-list] Re: Johnson counter page
Brought to you by:
jandecaluwe
From: Jan D. <ja...@ja...> - 2006-01-11 10:06:58
|
George Pantazopoulos wrote: > Thanks for the example of the Johnson Counter. Someone on comp.lang.fpga suggested to add side-by-side comparisons of MyHDL code versus other solutions. I liked that idea, but I thought a "cookbook" would be even better. Over time, I hope to add widely used and well-known examples, so that people can learn by example. > http://myhdl.jandecaluwe.com/doku.php/cookbook:jc2 > > Could you have used an @always block if you pulled the state variables > out of the logic() function and put them in the enclosing scope, as > illustrated below? No. When you assign them inside a function, they are local variables that have nothing to do with the ones in the enclosing scope. In particular, this means they can't keep state over multiple function invocations. > I noticed that the state variables are not manipulated by the .next > operator, but instead directly assigned (combinatorially, as you say). I > didn't know this was possible with variables that would end up in the > verilog output! > > Please tell us more about your preferred coding style and why you > recommend it! The point I want to make is that there is no good reason to avoid using variables (blocking assignments in Verilog), if you can use them to write elegant code. However, avoiding them would be the implication if you believe the Verilog gurus who tell you not to mix blocking and non-blocking assignments in a sequential always block. When you simply use variables to hold intermediate results, my observation should be obvious. However, you can even use them to use state (and still use them combinatorially also), and this is also no problem for (decent) synthesis tools. Sometimes it's easier to concentrate on the behavior of code instead of "thinking hardware". Synthesis tools can deal with this coding style perfectly fine. (However, it seems that there are also lame tools that refer to crazy rules like the one above to reject such input code. Don't know about Xilinx ISE.) Caveat: just when I wanted to announce the page (you beat me to it), I noticed an inconsistency between the Verilog and VHDL in the original code from the Xilinx ISE. Again related to blocking vs non-blocking (signal) assignments :-) (Who understands these matters actually??) I based myself on the Verilog, but I believe the VHDL is really what's intended. In that case, all state variables are signals anyway and the code could use an always decorator. In other words, the example is subject to significant changes. Perhaps I'll keep the current code as an "advanced" variant. Regards, Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |