I'd rather switch than fight!
in [FPGA]
|
From: glen herrmannsfeldt on 21 Apr 2010 07:36 In comp.arch.fpga Nial Stewart <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote: >>> 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). Well, some of the comments were regarding ASIC design, where things aren't so sure. For FPGA designs, there is, as you say, "properly constrained" which isn't true for all design and tool combinations. One that I have heard of, though haven't actually tried, is having a logic block where the delay is greater than one clock cycle, but less than two. Maybe some tools can do that, but I don't believe that all can. -- glen
From: Jan Decaluwe on 23 Apr 2010 18:04 On Apr 23, 11:27 pm, gtw...(a)sonic.net (Mark Curry) wrote: > 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 > > 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. Thanks for going through the effort of coding this up. As I said, if you really think this is clearer, I don't have a case to argue, although as you will expect I disagree. My original concern about raising the abstraction level still stands however. I agree that your style is closer to hardware; you will probably agree mine is at a slightly higher level of abstraction. So how are we supposed to raise the abstraction level significantly (something many clever people claim is urgently required) if we cannot even take a small step that is available today? Best regards, Jan
From: Patrick Maupin on 21 Apr 2010 10:34 On Apr 21, 8:19 am, Jan Decaluwe <j...(a)jandecaluwe.com> wrote: > Thanks for explaining your coding style details, that's much > more enlightening than philosophical discussions. > > I stand by my quote. The context was clearly "using variables to > raise the abstraction level". That's not what this does. I didn't show any variables raising the abstraction level, no, but I showed a context they could be provided in. > Your coding style provides a very verbose workaround for temporary > variables. I just can't imagine this is how you do test benches, that > are presumably much more complex than your RTL code. Presumably > there you use temporary variables directly where you need them without > great difficulty. Why would it have to be so different for > synthesizable > RTL? You're right. Testbenches do not suffer from this limitation. But, in point of fact, I can use any sort of logic in my testbench. I use constructs all the time that aren't realistically synthesizable, so comparing how I code synthesizable RTL vs how I code testbenches would turn up a lot more differences than just this. > You refer to a "mental model" to manage complexity. To your credit, > you provide an argument, something the original author of > guideline #5 never did. However, I find it dubious. To manage > complexity, > I don't need to see the hardware registers, complete with Q and D, > so explicitly in the code. I think I understand pretty well what kind > of > coding styles are efficiently supported by synthesis tools. Given > this, > I try to write the code itself as clearly as possible. Yes, but when you use if/else, or case statements, or other complex structures, it is easy to get lost. Humans can only hold a very few things in their minds at a time, and this is a powerful tool. As I said, I certainly did not invent this style, but I personally know dozens of people who use it, and I have personally introduced it to at least 3 people, and they all find it extremely useful. > Most importantly: your coding style doesn't support non-temporary > variables. In other words, register inferencing from variables is not > supported and therefore ignored as technique. In this sense, this is > actually a good illustration of the point I'm trying to make. Well, it may be a good illustration to you, but now you're waxing philosophical again. Care to show an example (preferably in verilog) of how not using this coding style supports your preferred technique? > I happen to think that register inferencing from variables is an > essential tool. It raises the abstraction level just one notch. The > registers are not glancing at you from the code (although > unambiguously defined) but in return your coding style can be > much more expressive. I am actually doing something similar, I think, in my verilog automagic boilerplate code, which can determine size and type of registers in most cases, and automatically declares them. Regards, Pat
From: Patrick Maupin on 23 Apr 2010 21:26 On Apr 23, 5:04 pm, Jan Decaluwe <j...(a)jandecaluwe.com> wrote: > My original concern about raising the abstraction level still stands > however. I agree that your style is closer to hardware; you will > probably agree mine is at a slightly higher level of abstraction. So > how are we supposed to raise the abstraction level significantly > (something many clever people claim is urgently required) if we cannot > even take a small step that is available today? 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. I haven't given the actual design too much thought, but I dashed out how I think I would approach this. I haven't simulated or synthesized it, but I am confident that any bugs in it would be quite easy to wring out. Also, all except the last few lines are, again, what I personally consider "boilerplate" which requires near-enough zero thought, so I don't see that they affect the abstraction level too much. (But I would like to be able to get rid of them, make no mistake!) 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. module johnson ( clk, reset_n, goLeft_n, goRight_n, stop_n, q ); parameter COUNTER_WIDTH = 4; localparam COUNTER_TOP = COUNTER_WIDTH - 1; localparam STOP[1:0] = 2'b00, RUNRIGHT[1:0] = 2'b01, RUNLEFT[1:0] = 2'b10; input clk; input reset_n; input goLeft_n; input goRight_n; input stop_n; output [COUNTER_TOP:0] q; reg [COUNTER_TOP:0] q, next_q; reg [1:0] state, next_state; always @(posedge clk or negedge reset_n) if (!reset_n) begin q <= 0; state <= STOP; end else begin q <= next_q; state <= next_state; end always @* begin next_state = state; next_q = q; casez ({stop_n, goRight_n, goLeft_n}) 3'b0??: next_state = STOP; 3'b10?: next_state = RUNRIGHT; 3'b110: next_state = RUNLEFT; endcase case (next_state) RUNLEFT: next_q = {q, !q[COUNTER_TOP]}; RUNRIGHT: next_q = {!q[0], q[COUNTER_TOP:1]}; endcase end endmodule BTW, if I read your code right, the casez above should match its behavior. Personally, based on the description I read of the problem (and if my probing of the customer indicated he didn't really care about some of the edge conditions, because, for example, they shouldn't occur), my preferred coding of this would probably be more like: next_state = STOP; ... case ({stop_n, goRight_n, goLeft_n}) 3'b111: next_state = state; 3'b101: next_state = RUNRIGHT; 3'b110: next_state = RUNLEFT; endcase Note also that, if all the variables are assigned a default next state (which could be their previous state, or a constant, or an equation) before any case statements or if/else statements, it is extremely easy to verify, either manually or mechanically, that no latches have been introduced. It would be nice to get away from the boilerplate, and one of these days I would like to get around to making something that would reliably create and re-create the entire verilog file from (essentially) the last few lines, maybe coded in a slightly different style. I think it is doable. Regards, Pat
From: Patrick Maupin on 23 Apr 2010 23:49
On Apr 23, 10:03 pm, KJ <kkjenni...(a)sbcglobal.net> wrote: > Assuming something about other people is almost always a mistake. > I've read Cummings' post before, but not being a Verilog guy and the > issues he covers being very language specific it wasn't relevant to me > in VHDL. Well, I will apologize about one thing. In some of my earlier posts, I restricted my replies to not include comp.lang.vhdl, but I didn't on this sub-thread, so this "leaked" into that newsgroup without me paying adequate attention. So I apologize for assuming that you knew verilog and that you had seen my other posts that did not make it into comp.lang.vhdl. Verilog was the framing point for the one process/two process discussions I was having. The Cummings paper adequately describes several of the bad things that can happen in Verilog if you aren't paying close attention (that the two process model can help alleviate), so that is why I did not feel compelled to provide a similar example. As far as the rest of it goes, you had the chance in multiple posts to step back and say to yourself that you must be misunderstanding me, but in all cases you chose to assume I was a complete idiot. This is certainly a distinct possibility (perhaps even a probability), but the assumption of it starting out did not lead to a fruitful discussion, and, in fact, it was only in your reply to my name-calling that you have given me the chance to see how we are talking past each other. Regards, Pat |