Re: [myhdl-list] blocking and non-blocking assignments in toVerilog code.
Brought to you by:
jandecaluwe
From: Christopher L. F. <cf...@uc...> - 2008-06-17 12:58:27
|
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! |