myhdl-list

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

[Günter D. <dan...@we...>]

Maybe I am not up to date and this got actually already fixed. I justed 
noticed that in the Verilog generated code of the stopwatch example:

   http://myhdl.jandecaluwe.com/doku.php/cookbook:stopwatch

there are blocking and non-blocking assignments in the same always block.

Is that intended or would it be better to have only non-blocking 
assignments used?

Guenter

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

[Christopher L. F. <cf...@uc...>]

On Jun 16, 2008, at 12:20 PM, Jan Decaluwe wrote:

> Günter Dannoritzer wrote:
>> Jan Decaluwe wrote:
>
>>> This is in fact also one of my career-long battles :-) Basically,  
>>> I insist that
>>> HDL designers need both "variable" and "signal" semantics, also in  
>>> clocked
>>> processes. I agree that with languages like VHDL and MyHDL, this  
>>> is easier
>>> to understand, because those HDLs make a difference between  
>>> "variable" and
>>> "signal" objects.
>>
>> Have you considered writing a book about that? I feel like there is a
>> lot that could be taught, not available through books yet and it  
>> would
>> be a good publicity for MyHDL.
>
> Yes, I have, about this and related issues. Almost 15 years ago.
> I'm serious!
> Title: 'Efficient HDL synthesis'
> Subtitle: 'Avoiding the pitfalls of "thinking hardware"'
>
> I never started writing because I always thought that such a book
> would be obsolete by the time it would be published. I have never
> been more wrong.
>
> However (before you start to pity me) I have done something with
> those ideas which is probably more satisfactory: I co-founded
> a company, Easics, in which I'm still a director. I'm quite proud
> on Easics, because we have a history of design successes, even when
> our methodology is not exactly mainstream.
>
> Also, over the years I have posted about these matters on
> comp.lang.verilog/vhdl, trying everything from arguments,
> over irony and sarcasm, to gross insults :-)
> Without much success though.
>

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?

Good stuff, thanks for all the information!

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