Re: [myhdl-list] blocking and non-blocking assignments in toVerilog code.

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

Christopher L. Felton wrote:

> Why do you believe there has been a persistence not to adopt a higher  
> level synthesis approach?  Why do so many still want to only "think  
> hardware"?  A general tendency to avoid change?  Momentum, course  
> work, etc is wrapped around, "thinking hardware"?  Obviously there are  
> scenarios where "thinking hardware" can get you into trouble.  Are  
> there scenarios when not "thinking hardware" can be detrimental?

Certainly: thinking hardware is often suboptimal and inefficient,
but not thinking hardware may get you into trouble. This shows
that "thinking hardware" is useless as a paradigm for HDL design.

I think that HDL design is a special kind of software development,
and that a synthesis tool is a compiler. So for a better paradigm,
I look to the software world. You want to be as productive as possible,
and therefore raise the abstraction level, without being inefficient.
The paradigm to achieve that is: "Understand your compiler".
I think that's what the best software designers do. You have to
understand what you can leave to your compiler to solve, and what
you should worry about yourself.

For example, take the case of "mixing blocking and non-blocking
assignments". Of course I want to use variable semantics to
describe complex behavior if that's possible.  So the remaining
question is: can a synthesis tool handle this efficiently? It may
take you some thinking time and experiments to understand it fully,
but the answer is yes. So I want to use it. And I certainly
don't accept any constraints from people who did less thinking
and less experiments on the matter than I did myself.

To me, the above is obvious and even trivial, but as you point
out, it's not "mainstream" in the hardware design community, and
you ask why. Here are some hypotheses that I use to understand
why my own projections have been so wrong :-) :

* perhaps hardware design (and its efficiency) are not *that*
important in the overall process of building systems;

* perhaps the software-oriented talent that might make a difference
is attracted by "more exciting" industries;

* perhaps most of us remain schematic-entry designers, that only use
HDL synthesis because its benefits are enormous even when used
inefficiently. The code we write is a reflection of the schematic
that we are drawing in our head.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com