Re: [myhdl-list] [newb] modelling question

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

Neal Becker wrote:
> Simple question.  Model an accumulator.  The accumulator has state 
> (call it 'sum').
> 
> Most examples are an RTL style.  My imitation of this style might be:
> 
> 
> 
> def accum (x, result, _sum, count, clock, n): @always (clock.posedge)
>  def accum_logic(x): _sum.next += x if count == n-1: result.next = 
> _sum _sum.next = 0
> 
> return accum_logic
> 
> _sum is an internal variable.  Does it need to be one of the 
> parameters passed to accum, as I showed above?

No. (Also, it is more precise to qualify _sum as an internal signal).

> Perhaps this could be: def accum (x, result, count, clock, n):
> 
> _sum = Signal (0)
> 
> @always (clock.posedge) def accum_logic(x): _sum.next += x if count 
> == n-1: result.next = _sum _sum.next = 0
> 
> return accum_logic

Yes.

> What if I prefer object oriented style?  The manual mentions this 
> (the fifo examples).  I wonder if this style will work properly with 
> the rest of myhdl? For example, there are some functions that 'infer'
>  inputs and outputs.  Does this work if I use this object-oriented 
> style?  There must be some constraints.

Ok. Like with any HDL, the first question is: what is the code intended
for? Pure modeling or synthesis? And in the case of MyHDL, a further
one: even if not for synthesis, should it be convertible to Verilog
or VHDL?

For pure modeling, MyHDL is intended to be fully general. You can create
generators and signals in any way you want, including object-oriented
styles. Just give the Simulation object a set of generators and it
should work as expected.

For convertibility (which encompasses synthesizability) the situation
is completely different and the constraints are significant. However, I
believe the convertible subset is well documented:
http://www.myhdl.org/doc/0.6/manual/conversion.html#the-convertible-subset

Finally, a word about the decorators instance, always and always_comb.
They are just convenient ways to create generators.  Although I haven't
tried it, the first two are fairly generic and I expect they can be
used in a variety of styles. The one that extracts inputs and outputs
that you refer to is always_comb. This one is more specialized
and assumes plain signal names to be visible in the code.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a hardware description language:
     http://www.myhdl.org