Re: [myhdl-list] When to use @always, @instance and @always_comb

[Christopher L. <loz...@fr...>]

On 5/2/12 3:58 PM, Christopher Felton wrote:
> On 5/2/2012 1:52 PM, Uri Nix wrote:
>> IMHO it /is/ confusing, since the previous topics in the chapter are
>> synthesis oriented.
> The manual under "Modeling techniques" currently progresses; structural, 
> RTL, High-level.  Do you think a top-down versus bottom-up order would 
> be better?  Someone *without* a HW design background may find; 
> High-level, RTL, structural order less confusing?  Or, in your opinion, 
> do you think it needs to be a completely separate chapter?
It is still all not clear to me.  I am not sure about top down or bottom
up.  There are two different target markets, the experienced hardware
designers, and the experienced software developers.  I can only speak
for the later.

I would love to see it structured more as a tutorial on hardware design
than as a class on MyHDL.  Start with a flip flop, maybe that is a
structural example progress to a more complex digital circuit, say a
clock, maybe that is RTL, and then onto High Level.    In particular I
would love to see a hardware example of when you use @always, @instance
and @always_comb.  Why are there only 3 decorators???? I think I
understand it, but I keep getting it wrong.  And then at a certain
point, say okay here is more stuff you can model, but that you cannot
synthesize.  Better yet, say this is more stuff you can model, but
cannot use to create an FPGA.  And I would love to add my section on
what you cannot synthesize to the docs.  In fact I would love to move
all or part of my wiki onto MyDHL.org

I guess words like structural, RTL, and High level make sense to the
chip designers, but for me I am not quite sure of the differences. 
Specific examples would be much more helpful.

The point is, if you are targeting python developers, then the
documentation needs to be written in ways that are mindful of their
mindset.  They understand python, but not chip design, so explain the
later to them. 

In contrast, the hardware guys are probably quite happy with the current
manual structure, although I cannot speak for them.

I hope that helps.