I'd rather switch than fight!
in [FPGA]
|
From: Nial Stewart on 22 Apr 2010 05:26 > 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. As Kim says multi-cycle paths have been 'constrainable' in any FPGA took I have used for as long as I can remember. Nial.
From: Muzaffer Kal on 23 Apr 2010 12:57 On Fri, 23 Apr 2010 08:32:48 -0700 (PDT), Jan Decaluwe <jan(a)jandecaluwe.com> wrote: >So this is now already the third post that I devote to explaining >to two seasoned Verilog designers how a very simple example in >their favourite language with the ultra-short learning curve >actually works. I'm beginning to think that Verilog designers >don't know how to use variables :-) > Actually it was mostly a matter of not paying close attention to something one "knows" would not work. Of course in a clocked process if a register is not assigned in a path it remembers its value so a register is inferred and if it's a blocking assignment, its value is available in the same clock cycle. When one finally puts these together, your example is "obvious". And you're right; personally I don't use variables in this fashion. I would write the same logic as follows: if (turnleft) was_turnleft <= 1; if (turnleft || was_turnleft) do_left turn; which I think how the synthesizer would generate the logic for your example. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.com
From: Andy on 23 Apr 2010 14:26 You seem to put a lot of stock in the effortlessness of boilerplate, yet you prefer a language that is said to reduce the need for boilerplate. OK, so you mention that you could write a script to automate all of that, but to work, it would depend on a specific non-standard, non- enforceable naming convention. Not to mention this script has yet to be written and offered to the public, for free or fee. Which means each of those who would follow your advice must write, test, run and maintain their own scripts (or maybe even sell it to the rest of us, if they felt there was a market). Alas, we have no such scripts. So that would put most users back at typing out all that boilerplate. Once it is typed, there is no compiler to check it for you (unlike much of the boilerplate often attributed to vhdl). You recommend all of this extra work, rather than writing just one process, with none of your boilerplate (no additional process, no additional declarations, no additional assignments, no chances for latches, no simulation-slowing effects). What's really silly is how the two-process code model even got started. The original synthesis tools could not infer registers, so you had to instantiate them separately from your combinatorial code. Once the tools progressed, and could infer registers, the least impact to the existing coding style (and tools) was simply to replace the code that instantiated registers with code that inferred them, still separating that code from the logic code. Finally, someone (God bless them!) figured out how to do both logic and registers from one process with less code, boilerplate or not. For all your staunch support of this archaic coding style, we still have not seen any examples of why a single process style did not work for you. Instead of telling me why the boilerplate's not as bad as I think it is, tell me why it is better than no boilerplate in the first place. Andy
From: KJ on 22 Apr 2010 21:57 On Apr 22, 6:36 pm, Patrick Maupin <pmau...(a)gmail.com> wrote: > 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'. > Ha, ha, ha...having a convention naming style prevents latches???!!! Ummmmmm, noooooooo, don't think so, but thanks for the possibly unintended humor. Whether you have a naming convention or not, latches will be created when assignment statements to cover every path are not included in an unclocked process totally independent of how they are named...end of story I suppose your point is that calling things 'next_x' and 'x' then makes it easier to do a *manual* inspection and perhaps catch such a missing assignment but that is a far, far stretch from your actual statement "Unintentional latches don't happen if...". Andy, on the other hand, is on much firmer ground had he said "Unintentional latches don't happen if you only use clocked processes"...he didn't explicitly say that, but I'm fairly certain he would agree. Yes, you can do things to make *manual* inspections better...which is like saying it hurts my head less if I use a rubber hammer to hit my head than a steel one...but it is a far better process improvement to just not hit my head at all with any hammer. KJ
From: Patrick Maupin on 22 Apr 2010 22:12
On Apr 22, 8:57 pm, KJ <kkjenni...(a)sbcglobal.net> wrote: > I suppose your point is that calling things 'next_x' and 'x' then > makes it easier to do a *manual* inspection and perhaps catch such a > missing assignment but that is a far, far stretch from your actual > statement "Unintentional latches don't happen if...". Andy, on the > other hand, is on much firmer ground had he said "Unintentional > latches don't happen if you only use clocked processes"...he didn't > explicitly say that, but I'm fairly certain he would agree. Yes, I should have been more clear about that. Any decent synthesizer or simulation tool will report latches, but sometimes the reports are hard to interpret. If you use a consistent naming convention like I have described, it is easy to find the latches, and also easy to write a script to find them, as well. And I agree that you won't have latches if all your processes are clocked, but latches are much easier to detect and rectify than some other possible logic problems. Regards, Pat |