myhdl-list

[myhdl-list] Johnson counter page

[George P. <ge...@ga...>]

Thanks for the example of the Johnson Counter.

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?

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!

Thanks,
George


from myhdl import *
 
ACTIVE = 0
DirType = enum('RIGHT', 'LEFT')

def jc2(left,right,stop,clk,q):
     ...
     ...
     ...
     dir = Signal(DirType.LEFT)
     run = Signal(bool(False))

     @always(clk.posedge)
     def logic():
          if right == ACTIVE:
               dir = DirType.RIGHT
               run = True
          ...
          ...
          ...
     return instances()

[myhdl-list] Re: Johnson counter page

[Jan D. <ja...@ja...>]

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