I'd rather switch than fight!
in [FPGA]
|
From: Jan Decaluwe on 22 Apr 2010 17:21 On Apr 22, 9:11 pm, Patrick Maupin <pmau...(a)gmail.com> wrote: > On Apr 22, 10:08 am, Jan Decaluwe <j...(a)jandecaluwe.com> wrote: > > > > > > Or is there something else you're trying to convey that I'm missing? > > > Yes, the fact that 'run' and 'dir' are state variables. Therefore, > > your > > proposed approach wouldn't work. You have the test vectors, you can > > try it yourself. > > > Quoting from the article: > > """ > > This example is more subtle and complex than it may seem at first > > sight. As said before, variables dir and run are state variables and > > will therefore require a flip-flop in an implementation. However, they > > are also used combinatorially: when they change, they may influence > > the counter operation in the same clock cycle, that is, before the > > flip-flop output changes. This is perfectly fine behavior and no > > problem for synthesis tools, but it tends to confuse a lot of > > designers. > > """ > > OK, I admit I didn't read that carefully enough; in fact, I just > glanced at the actual code before my coffee this morning. But you > know what? Where I come from, "subtle" that "tends to confuse a lot > of designers" is just a synonym for "screwed up." Let me put it more correctly. Initially, I think, everyone is confused about this. I know I was (20 years ago already!). The confusion is resolved by a new insight: how RTL synthesis *really* works. Some get it quickly, others need more time. I think that's a common pattern with new paradigms. The benefit: a coding technique to solve real problems significantly more elegantly. > The whole point of the coding style I was describing is to NOT write > stuff that would confuse other designers. After all, in C I can write > perfectly valid code like "0[x] = 3". But just because I can, doesn't > mean it's a good idea. I suggest you try your coding style with my examples. You have the spec and test vectors. If you find your code much clearer, I don't have a case (with you) to argue further. Otherwise, you'll remember me when you start applying this technique in your designs :-) Jan
From: Patrick Maupin on 22 Apr 2010 17:37 On Apr 22, 3:04 pm, Muzaffer Kal <k...(a)dspia.com> wrote: > On Thu, 22 Apr 2010 08:08:59 -0700 (PDT), Jan Decaluwe > >This example is more subtle and complex than it may seem at first > >sight. As said before, variables dir and run are state variables and > >will therefore require a flip-flop in an implementation. However, they > >are also used combinatorially: when they change, they may influence > >the counter operation in the same clock cycle, that is, before the > >flip-flop output changes. This is perfectly fine behavior and no > >problem for synthesis tools, but it tends to confuse a lot of > >designers. > > I am not sure who is really confused here. What is suggested in the > above paragraph is not really feasible; assuming by 'dir' one refers > to the output of a flop. It's not possible to use the output of a flop > at the same clock when its input changes (without generating an > intentional hold violation by playing with clock skews). What one can > do is to have a combinational signal dir_d which gets computed by > dir_q and other signals. This dir_d can be used in the same clock > cycle but dir_q will not be available till next cycle: I don't think Jan is confused. While I haven't actually simulated it, I have no reason to disbelieve that he has built a flop which feeds into a combinatorial network, and the only thing here with a name is the output of the combinatorial network, which also happens to feed back into the flop. Verilog will certainly let you do such things. And now (I think) I understand a bit better what Jan means by "register inferencing" -- in this case, this capability is manifested by the ability to not give a name to a register itself, but only to the combinatorial net feeding the register. When I first started using Verilog, I would do such things, and confuse myself and others mightily. So I stand by my opinion that having two distinct yet related names for the input and output of a hardware register makes it easier for someone to pick up some code and conceptualize what is going on and not get it wrong at first glance. FWIW, in a case like this, rather than having 'next_dir' and 'dir', I might use 'dir' and 'prev_dir'. So the start of the combinatorial block could have "dir = prev_dir", followed by conditionally setting dir as required. Then in the synchronous block, you would have "prev_dir = dir". As I originally mentioned, this style is a bit more verbose, but since code is read much more often than it is written, it is a net win. Regards, Pat
From: Patrick Maupin on 22 Apr 2010 17:40 On Apr 22, 4:21 pm, Jan Decaluwe <j...(a)jandecaluwe.com> wrote: > Let me put it more correctly. Initially, I think, everyone is confused > about this. I know I was (20 years ago already!). The confusion > is resolved by a new insight: how RTL synthesis *really* works. I got it. In fact, I used to do what you said, but sometimes I would be confused, or others would be. Haven't done that in 15 years. > Some get it quickly, others need more time. > I think that's a common pattern with new paradigms. That's an old paradigm. > The benefit: a coding technique to solve real problems > significantly more elegantly. But, in my previous experience, it doesn't. It just confuses people. > I suggest you try your coding style with my examples. You have the > spec and test vectors. If you find your code much clearer, I don't > have > a case (with you) to argue further. Otherwise, you'll remember me > when you start applying this technique in your designs :-) Been there, done that, got the t-shirt; somebody else showed me the light over a decade ago, and I never went back. Regards, Pat
From: Andy on 22 Apr 2010 18:32 Other than twice the declarations, unintentional latches, explicitly coding clock enables, simulation penalties, etc., using separate combinatorial and sequential blocks is just fine. Most designers here use single clocked processes / always blocks. Those that don't are 'encouraged' to. Andy
From: Patrick Maupin on 22 Apr 2010 18:36
On Apr 22, 5:32 pm, Andy <jonesa...(a)comcast.net> wrote: > Other than twice the declarations, unintentional latches, explicitly > coding clock enables, simulation penalties, etc., using separate > combinatorial and sequential blocks is just fine. Unintentional latches don't happen if you use a consistent naming style with, e.g. 'next_x' and 'x'. I don't think simulation penalties happen if the simulator is halfway decent. Twice the declarations is a slight issue, but if you do reg [2:0] x, next_x; it's not too bad at all. Explicitly coding clock enables -- not sure what you mean here -- that's an if statement no matter how you slice it. Regards, Pat |