I'd rather switch than fight!
in [FPGA]
|
From: Patrick Maupin on 23 Apr 2010 23:55 On Apr 23, 10:43 pm, Muzaffer Kal <k...(a)dspia.com> wrote: > I think you're being overly harsh about this issue. The paper in > question is almost 10 years old and synthesis tools came along way > since then. Also one has to take the guideline within the context it > has been defined. FWIW, the latest rev of the paper (1.3) was September of last year. Regards, Pat
From: Jan Decaluwe on 26 Apr 2010 03:56 On Apr 24, 3:26 am, Patrick Maupin <pmau...(a)gmail.com> wrote: > Well, it's hard for me to know what you are looking for in "raising > the abstraction level" when you showed the code this way. In my > opinion, coding run/stop and direction separately unnecessarily lowers > the abstraction level. 'run' and 'dir' come from the original Xilinx examples, and play the crucial role in the story. In particular, the mismatch between the Xilinx VHDL and verilog versions is due to different assignment types to these variables. You will understand that I treat them as a given in my article that tries to shed a light on the issues. > Note that this violates my preference not to use 'next_xxx' on the rhs > in one instance (but doesn't violate any of the underlying rules laid > out by Cliff Cummings), but given the choice between an extra variable > and this minor infraction (where it can be easily seen that next_state > is never used until all potential assignments to it have occurred), I > would probably code it as I have shown. Thanks for your coding efforts. These are the kind of considerations that I'm trying to put on the agenda, translated to your closer-to-hardware coding style. I note that you conclude, quite appropriately, that the best option here is to depart from your preferred style. In effect, what you are doing is making more effective use of variable semantics as offered by the HDL. Jan
From: Martin Thompson on 26 Apr 2010 08:27 Chris Higgs <chiggs.99(a)googlemail.com> writes: > You can only use sequential processes and make it impossible to infer > a latch but lose the ability to use a combinatorially derived signal. > Alternatively you can use a two-process technique which allows > intermediate/derived signals to be used but accept the risk that bad > code will introduce latches. Or you can use a single sequential process with variables to infer both combinatorial logic and flip-flops, which both avoids latches and allows the ability to use a combinatorially derived "signal" (in the non-VHDL sense of the word). Cheers, Martin -- martin.j.thompson(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
From: Andy on 26 Apr 2010 20:15 Cliff's paper is about avoiding race conditions. However, in vhdl "blocking assignements" (to unshared variables) are limited to local process/subprogram scope anyway, so you never have problems with race conditions with them. That is why it is safe and even beneficial to use blocking assignments (to unshared variables) in VHDL clocked processes. Combine that with the flexibility afforded in describing both combinatorial and sequential logic in the same process, and it makes for an extremely powerful, yet safe concept. While some may struggle with identifying where the registers are located in relation to the combinatorial logic, understanding the cycle-based behavior is more intuitive, since the code "reads and executes like SW". Given the increasing use of retiming optimizations, knowing where registers are located in your RTL is rapidly becoming useless anyway. For the remaining < 1% of the time when I need an in-to-out combinatorial logic path through a module/entity, I'll go ahead and use a combinatorial process (implied by a concurrent assignment or otherwise). That doesn't mean I'm going to throw away the benefits of using only clocked processes for the other > 99%, just for purity's sake. Andy
From: Patrick Maupin on 26 Apr 2010 21:26
On Apr 26, 7:15 pm, Andy <jonesa...(a)comcast.net> wrote: > Cliff's paper is about avoiding race conditions. However, in vhdl > "blocking assignements" (to unshared variables) are limited to local > process/subprogram scope anyway, so you never have problems with race > conditions with them. That is why it is safe and even beneficial to > use blocking assignments (to unshared variables) in VHDL clocked > processes. Combine that with the flexibility afforded in describing > both combinatorial and sequential logic in the same process, and it > makes for an extremely powerful, yet safe concept. While some may > struggle with identifying where the registers are located in relation > to the combinatorial logic, understanding the cycle-based behavior is > more intuitive, since the code "reads and executes like SW". Given the > increasing use of retiming optimizations, knowing where registers are > located in your RTL is rapidly becoming useless anyway. > > For the remaining < 1% of the time when I need an in-to-out > combinatorial logic path through a module/entity, I'll go ahead and > use a combinatorial process (implied by a concurrent assignment or > otherwise). That doesn't mean I'm going to throw away the benefits of > using only clocked processes for the other > 99%, just for purity's > sake. Yes, the two process model probably isn't nearly as useful in VHDL. As others have been quick to point out, you don't need a combinatorial process in verilog either, but then you have to be careful about blocking vs. non-blocking, not using variables which have blocking assignments to them from other processes, etc. The two process model is simply an organizing principle that provides a separation of concerns and simplifies the rules a bit, making it easier to reason about the code. Extremely simple code doesn't gain anything from using this model, but a lot of real-world code does. Regards, Pat |