I'd rather switch than fight!
in [FPGA]
|
From: Bernd Paysan on 23 Apr 2010 06:01 Andy wrote: > Other than twice the declarations, unintentional latches, explicitly > coding clock enables, simulation penalties, etc., using separate > combinatorial and sequential blocks is just fine. LoL. Note that there are further difficulties to understand this separated code due to the fact that things which conceptually belong together are spread apart over the file. This is just too messy. > Most designers here use single clocked processes / always blocks. > Those that don't are 'encouraged' to. I'm fully on your side. -- Bernd Paysan "If you want it done right, you have to do it yourself!" http://www.jwdt.com/~paysan/
From: Marcus Harnisch on 23 Apr 2010 06:14 Chris Higgs <chiggs.99(a)googlemail.com> writes: > I'd recommend casting your eye over this presentation. It details some > of the advantages of the "2 process" coding style with a real world > example (LEON SPARC-V8 processor). Actually the rpesentation seems to compare two entirely different designs done using different approaches. In this comparison, the Two-Process-style appears to only *one* of the aspects. -- Marcus note that "property" can also be used as syntactic sugar to reference a property, breaking the clean design of verilog; [...] (seen on http://www.veripool.com/verilog-mode_news.html)
From: Brian Drummond on 23 Apr 2010 07:35 On Fri, 23 Apr 2010 01:03:03 -0700 (PDT), Chris Higgs <chiggs.99(a)googlemail.com> wrote: >On Apr 23, 5:38�am, KJ <kkjenni...(a)sbcglobal.net> wrote: > >> Ah well...as long as there are textbooks I guess there will always be >> those disciples that think that separating combinatorial logic from >> the register description actually is of some value to somebody, >> somewhere at some point in time...but inevitably they come up short >> when trying to demonstrate that value. > >http://www.gaisler.com/doc/structdes.pdf > >I'd recommend casting your eye over this presentation. It details some >of the advantages of the "2 process" coding style with a real world >example (LEON SPARC-V8 processor). > Not over the single-process style, which it doesn't even mention. Other aspects of this document are worthwhile, however. - Brian
From: KJ on 23 Apr 2010 09:12 On Apr 23, 1:01 am, Patrick Maupin <pmau...(a)gmail.com> wrote: > On Apr 22, 11:38 pm, KJ <kkjenni...(a)sbcglobal.net> wrote: > > > > but latches are much easier to detect and rectify than some > > > other possible logic problems. > > > And much easier to avoid in the first place too...with the correct > > methodology (hint: that would be the one that avoids using unclocked > > processes) > > > Just having fun...like I said, every now and then it's good sport to > > poke fun at the people who make their own problems. > > But, the reason I was unclear to start with, is that it's been so long > since I've had an unintended latch (probably several years) that I > really don't think that hard about it at all. The two process people generally do fall back on excuses about being misunderstood. > So you can think what > you want, but the *reason* I code the way I do isn't really that much > about latches at all (obviously, if I was *worried* about them, I > would code everything in sequential blocks, where they could never > happen, Hmmm...so you prefer to take what you admit as unnecessary chances....fair enough, that implies though that you expect some actual benefit from that decision...but are probably unable to come up with an actual example demonstrating that benefit. > but I could have some other hard to find logic problems, which > I *have* had in the past). Ahhh....one of those examples...now what sort of 'hard to find' logic problem would you like to offer up to to the group to actually demonstrate that two processes are better than one? I'm willing to listen, but I'll warn that you that every time in the past that this debate pops up, the two process people are unable to coherently describe anything other than vague generalities as you've done here...so here is your opportunity to present a clear example describing a 'hard to find' logic problem that is easier to find when coded with two processes. The clocked process folks (i.e. the one process camp) have in the past presented actual examples to back their claims, Googling for 'two process' in the groups should provide some good cases. > However, unintended latches just don't > happen for me with my coding style, so I don't worry about it until > somebody like you comes along to tell me about all the problems that > I'm causing for myself that I never knew I had! Whether you in particular have this problem, I don't know (apparently not). You in particular though are - Doing more work (two process will always be more typing and lines of code then one process), - Producing less maintainable code (two process will always physically separate related things based only on whether the logic signal is a 'register' or not) Kevin Jennings
From: KJ on 23 Apr 2010 10:02
On Apr 23, 4:03 am, Chris Higgs <chiggs...(a)googlemail.com> wrote: > On Apr 23, 5:38 am, KJ <kkjenni...(a)sbcglobal.net> wrote: > > > Ah well...as long as there are textbooks I guess there will always be > > those disciples that think that separating combinatorial logic from > > the register description actually is of some value to somebody, > > somewhere at some point in time...but inevitably they come up short > > when trying to demonstrate that value. > > http://www.gaisler.com/doc/structdes.pdf > > I'd recommend casting your eye over this presentation. It details some > of the advantages of the "2 process" coding style with a real world > example (LEON SPARC-V8 processor). > OK, but it doesn't compare it to the 'one process' approach, the comparison is to a 'traditional method'. The 'traditional method' though is all about lumping all signals into records (refer to the 'Benefits' area of that document). All of the comparisons are between 'traditional method' which has discrete signals and 'two-process method' which lumps signals into a record. There is absolutely nothing comparing 'one process' and 'two process'. Why the author chose to title his new method the 'two- process' method is totally unclear...just another example either of sloppy academic thinking to name your method after something that is not even relevant to the point of the paper. The author does mention "No distinction between sequential and comb. signals" as being a "Problem". Maybe it's a problem for the author, but it's somewhat irrelevant for anyone skilled in design. The author presents no reason for why having immediate knowledge of whether a signal comes out of a flip flop or a gate is relevant...(hint: it's not). What is relevant is the logic that the signal represents and whether it is implemented properly or not. Whether 'proper implementation' means the signal is a flop or not is of very little concern (one exception being when you're generating gated clocks...which is a different can of worms). Even the author's 'State machine' example demonstrates the flaw of using two processes. Referring to slide #27 partially shown below, note that (the undeclared) variable v has no default assignment, v will result in a latch. begin comb : process(...., r) begin case r.state is when first => if cond0 then v.state := second; end if; when second => .... This to me demonstrates that the author didn't even take the time to compile his own code...and not notice the (possibly) unintended latch that gets generated. Maybe the author is living in an ASIC world where latches are not a problem, who knows? But in an FPGA, a latch most certainly is indicative of a design problem more times than not. You seem to have been caught up by his statement "A synchronous design can be abstracted into two separate parts; a combinational and a sequential" and the slide titled "Abstraction of digital logic" and thought that this was somehow relevant to the point of his paper...it's not...his point is all about combining signals into records...totally different discussion. The only conclusion to draw from this paper is that you shouldn't believe everything you read...and you shouldn't accept statements that do not stand up to scrutiny. Kevin Jennings |