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

[Jan C. <jan...@mu...>]

On 06/05/12 06:35, Tom Dillon wrote:

> "Experienced python developer", what is that? I am not sure what
> that has to do with anything.
True. An "Experienced python developer" is most likely someone who 
has gained some control over a machine at a very high level of 
abstraction. They may know little or nothing about the 
progressively differing layers of software beneath, supporting 
their code.  Likely, the further layers of hardware concepts 
expressed below are completely out of sight.

> There is nothing unnatural about MyHDL. Again, trying to draw
> somebody into a meaningless discussion.
I think he's angling to get a fish, a big one.  A person wanting to 
learn to fish would need to be interested in understanding and 
clearly distinguishing the names of the tools, behaviour of fish, 
affects of tides, etc.  Asking why angling is not an iPhone app 
that can be run, sat on a bench in the park while watching bowls is 
pointless.

> MyHDL works fine. I fail to see a conflict at all.
I'm struggling, but much too inexperienced with Python to suggest 
changing any of MyHDL.

My hardware experience started with borrowing my mums breadboard 
and dressmaking pins, and using surplus germanium diodes and 
transistors.  I still like to know the details of the fabric I'm 
using.

Today I still have questions, for example: Do clockless gate arrays 
use standard SRAM blocks in an async wrapper, or are they async to 
a much lower level than this.  It may seem pointless to ask, but it 
would help me to estimate the reliability of tools which translate 
RTL designs to use a clockless fabric. [1]

But this extremely low-level interest might hinder my progress in 
using MyHDL in a similar way to having an insufficiently deep 
understanding of electronics.  I'll need to work to get the balance 
right.

It has been a hard struggle for me to get started with MyHDL, 
hopefully we can work out why, and make it easier for others in the 
future.

Jan Coombs
-- 
[1] www.achronix.com