I'd rather switch than fight!
in [FPGA]
|
From: KJ on 23 Apr 2010 00:38 On Apr 22, 10:12 pm, Patrick Maupin <pmau...(a)gmail.com> wrote: > On Apr 22, 8:57 pm, KJ <kkjenni...(a)sbcglobal.net> wrote: > > Yes, I should have been more clear about that. Agreed, you're not very clear when you have statements like this from your previous post... > Unintentional latches don't happen if you use a consistent naming > style with, e.g. 'next_x' and 'x'. followed up with statements like this... > If you use a consistent naming convention like I > have described, it is easy to find the latches, So, first you say that the naming convention by itself will prevent unintentional latches and then follow that up to say that the naming convention helps you to *find* the unintended latches that couldn't be created in the first place...hmmm....yes, I agree, not very clear. Both statements indicating that you may be oblivous to the simple point that using non-clocked processes opens you up to making it easy to create your own problems (i.e. the latches) that are easily avoided in the first place... > And I agree that you won't have latches if all your processes are > clocked, Oop, I guess not because now it seems that you do get the point that clocked processes for the most part avoid the unintended latch...but based on the earlier comments I guess you must not practice it or something for some reason...You admit it avoids a potential design problem, but don't use it because....hmmmm....well, perhaps you have a sponge hammer... 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. > easy to find the latches, and also easy to write > a script to find them, as well Then they will trot out the methods they use to minimize the problem that others do not even have. While those disciples are steadfast in their belief, it usually doesn't get across to them that the value they perceive is actually negative, it is costing them...and they are left clinging to the only thing they have left which is always a statement of the form "That's the way I do it, I'm comfortable with it, I feel I'm productive doing it this way" Every now and then, it seems like good sport to challenge those folks to see if they have anything better to offer, but it never seems to be. > 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. Kevin Jennings
From: Patrick Maupin on 23 Apr 2010 01:01 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. 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, but I could have some other hard to find logic problems, which I *have* had in the past). 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! Regards, Pat
From: Chris Higgs on 23 Apr 2010 04:03 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). Thanks, Chris
From: Mark Curry on 23 Apr 2010 17:27 (With apologies to Jan, I accidently emailed this first time to him instead of posting... ) >>On Apr 22, 10:08 am, Jan Decaluwe <j...(a)jandecaluwe.com> wrote: >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 Ok, coming in late. I'm a two always block designer. And I use "variables". For me, it's an issue of how far away from the hardware do you want to be. I've done the block entirely in my coding style including parameterizing the counter width, and naming conventions (not simulated): module jc2 #( parameter WIDTH = 4; ) ( input wire clk_i, input wire goleft_i, input wire goright_i, input wire stop_i, output reg [ WIDTH - 1 : 0 ] q_o ); reg [ WIDTH - 1 : 0 ] next_q; reg dir, next_dir; reg run, next_run; always @( posedge clk ) begin q_o <= next_q; dir <= next_dir; run <= next_run; end always @* begin next_q = q_o; next_dir = dir; next_run = run; if( goright_i ) begin next_dir = 1'b0; next_run = 1'b1; end else if( goleft_i ) begin next_dir = 1'b1; next_run = 1'b1; end if( stop_i ) next_run = 1'b0; if( next_run ) begin if( ~next_dir ) next_q = { ~q_o[ 0 ], q_o } >> 1; else next_q = { q_o, ~q_o[ WIDTH - 1 ] }; end end endmodule Not much bigger than what's on your website for the myhdl code. Yes, the top always block for the registers is overhead (above myhdl), but I've got text editor macros to do that. Same for the default assign of the next_* register to set my initial decode (and coincidentally always prevent latches). The initial decode in this case is a simple "stay in current state" but it doesn't have to be. The benefit, to me, it's clearer. I know what's registers, what's combinational. I also know that by using the "next_run", and "next_dir" variables near the end of that combinational block - instead of the state registers "run" and "dir" - I'm adding more decode - I may have a critical path issue (Not likely in this trivial example, but with large decodes...) It comes down to what designers prefer. I like to "see in my head" the logic I'm generating. The style above works for me quite well. I get all the benefits that you tout about using "variables". Others obviously wish to be more concise and use one always block. They're allowed to. It's all a designers style. Regards, Mark
From: Nial Stewart on 21 Apr 2010 06:02
>> The point is that if you don't do static timing analysis (or have an >> analyzer that is broken) timing verification is nearly impossible. > > And even if you do, the device might still have timing problems. Can you expand on this Glen? As I have always understood it one of the bedrocks of FPGA design is that when it's passed a properly constrained static timing analysis an FPGA design will always work (from a timing point of view). Nial. |