In the following link, a design is presented that alledgedly has a flaw. The claim is that this is a simple case and that any experienced designer will see the flaw immediately. (I don't.) http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705& -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com
VHDL expert puzzle
Started by ●November 25, 2012
Summary
The discussion centers on a VHDL "puzzle" involving an LFSR-based counter that allegedly failed in hardware but worked in simulation.
The discussion centers on a VHDL "puzzle" involving an LFSR-based counter that allegedly failed in hardware but worked in simulation. Participants analyzed the code and found that while it contained poor practices, such as an overcrowded sensitivity list and lack of a reset for certain signals, none explained the catastrophic failure claimed by the original author.
The consensus reached by the experts is that the original author's "fix"—adding behavioral delays—was likely a red herring. They concluded the failure was more probably due to an unrevealed error in the original code, such as a bit-string size mismatch or a simple misunderstanding of simulation waveforms.
- Superfluous signals in a process sensitivity list increase simulation load but typically do not change the synthesized hardware logic.
- LFSRs using XNOR feedback must avoid an all-ones state to prevent latch-up, whereas XOR feedback must avoid all-zeros.
- Adding 'after' delays in RTL is generally discouraged as it can mask race conditions rather than solve them.
- The group concluded the original problem likely stemmed from a mismatch between the author's actual code and the version posted for analysis.
VHDLLFSRSimulationFPGA Design
Reply by ●November 25, 20122012-11-25
Le 25/11/2012 20:11, Jan Decaluwe a �crit :> In the following link, a design is presented that alledgedly > has a flaw. The claim is that this is a simple case and > that any experienced designer will see the flaw immediately. > > (I don't.) > > http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705& >The feedback term is 0 when the LFSR is all 0s so it won't count because it resets to all 0s. Nicolas
Reply by ●November 25, 20122012-11-25
Le 25/11/2012 20:49, Nicolas Matringe a �crit :> Le 25/11/2012 20:11, Jan Decaluwe a �crit : >> In the following link, a design is presented that alledgedly >> has a flaw. The claim is that this is a simple case and >> that any experienced designer will see the flaw immediately. >> >> (I don't.) >> >> http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705& >> >> > The feedback term is 0 when the LFSR is all 0s so it won't count because > it resets to all 0s.Or maybe not... What's that 'xnor' operator ? I've never used it before. Nicolas
Reply by ●November 25, 20122012-11-25
On 25/11/12 19:49, Nicolas Matringe wrote:> Le 25/11/2012 20:11, Jan Decaluwe a �crit : >> In the following link, a design is presented that alledgedly >> has a flaw. The claim is that this is a simple case and >> that any experienced designer will see the flaw immediately. >> >> (I don't.) >> >> http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705& >> > The feedback term is 0 when the LFSR is all 0s so it won't count because > it resets to all 0s. > > Nicolas >I don't think so - with XOR gates you mustn't use all zeros, but he's used XNOR, so you mustn't use all '1's. regards Alan -- Alan Fitch
Reply by ●November 25, 20122012-11-25
On 25/11/12 19:11, Jan Decaluwe wrote:> In the following link, a design is presented that alledgedly > has a flaw. The claim is that this is a simple case and > that any experienced designer will see the flaw immediately. > > (I don't.) > > http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705& >I guess it also depends what he means by flaw. The only signal required in the sensitivity list is clk; and if he'd made LFSR type unsigned, he wouldn't have needed the type conversions. But I guess that doesn't affect functionality (which I assume is what is meant by a flaw). Perhaps I should read the second page of the post... Of course it may just be that the feedback taps on the LFSR are wrong for a maximal length sequence, but I can't be bothered to look that up :-) Alan -- Alan Fitch
Reply by ●November 25, 20122012-11-25
Haven't looked well but about the only unusual thing is the sensitivity list and the the author's explanation which is wrong. D0 is synchronised because it is dependent on lfsr bits. The author should say that he needed one clock latency functionally on D0 instead. Kaz --------------------------------------- Posted through http://www.FPGARelated.com
Reply by ●November 25, 20122012-11-25
On 11/25/2012 09:02 PM, Alan Fitch wrote:> On 25/11/12 19:11, Jan Decaluwe wrote: >> In the following link, a design is presented that alledgedly >> has a flaw. The claim is that this is a simple case and >> that any experienced designer will see the flaw immediately. >> >> (I don't.) >> >> http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705& >> > > I guess it also depends what he means by flaw. The only signal required > in the sensitivity list is clk; and if he'd made LFSR type unsigned, he > wouldn't have needed the type conversions. > > But I guess that doesn't affect functionality (which I assume is what is > meant by a flaw).Correct. The superfluous signals in the sensitivity list are messy, but they don't affect behavior.> Perhaps I should read the second page of the post...I think you may find it interesting.> Of course it may just be that the feedback taps on the LFSR are wrong > for a maximal length sequence, but I can't be bothered to look that up :-)Of course not. Again, he claims that an experienced designer would see it immediately. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com
Reply by ●November 25, 20122012-11-25
On 25/11/12 20:13, Jan Decaluwe wrote:> On 11/25/2012 09:02 PM, Alan Fitch wrote: >> On 25/11/12 19:11, Jan Decaluwe wrote: >>> In the following link, a design is presented that alledgedly >>> has a flaw. The claim is that this is a simple case and >>> that any experienced designer will see the flaw immediately. >>> >>> (I don't.) >>> >>> http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705& >>> >> >> I guess it also depends what he means by flaw. The only signal required >> in the sensitivity list is clk; and if he'd made LFSR type unsigned, he >> wouldn't have needed the type conversions. >> >> But I guess that doesn't affect functionality (which I assume is what is >> meant by a flaw). > > Correct. The superfluous signals in the sensitivity list are > messy, but they don't affect behavior. > >> Perhaps I should read the second page of the post... > > I think you may find it interesting. >OK I cracked and read it. I don't really understand what's going on, I would have to simulate it (though of course you've already done that Jan!). I agree there's something fishy about adding output delays. What difference would that make in this case?>> Of course it may just be that the feedback taps on the LFSR are wrong >> for a maximal length sequence, but I can't be bothered to look that up :-) >By moving the assignment to d0 into the process, he has implied another flip-flop, which makes me think that my guess that the feedback taps are wrong is correct - though there's no way an experienced designer could spot that (unless they'd memorized that table in XAPP 210 - I've memorized the app note number, but not the table :-) ).> Of course not. Again, he claims that an experienced designer > would see it immediately.Mysteriouser and mysteriouser... Alan> > Jan >-- Alan Fitch
Reply by ●November 25, 20122012-11-25
On 11/25/2012 2:11 PM, Jan Decaluwe wrote:> In the following link, a design is presented that alledgedly > has a flaw. The claim is that this is a simple case and > that any experienced designer will see the flaw immediately. > > (I don't.) > > http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705& >I see two things I would flag. One is the fact that they include extraneous signal names in the sensitivity list. This can cause a simulation to run slowly, but I've never seen a synthesizer to create different logic because of it. The other is the omission of a reset assignment for the signal clk_out which is registered. This means the reset will simply disable the clk_out FF from changing state when rst is asserted, but otherwise the circuit will function normally. I don't see an error that will stop the design from working. The use of XNOR gates in the feedback means the all 1s state will latch up while the use of XOR gates in the feedback means the all 0s state will latch up. The XNOR is just an XOR with the output inverted which is the same as either one of the inputs inverted or all three inverted. Thinking of it as all three inverted clearly shows the symmetry of the latch up states. Rick
Reply by ●November 25, 20122012-11-25
On 11/25/2012 3:27 PM, rickman wrote:> On 11/25/2012 2:11 PM, Jan Decaluwe wrote: >> In the following link, a design is presented that alledgedly >> has a flaw. The claim is that this is a simple case and >> that any experienced designer will see the flaw immediately. >> >> (I don't.) >> >> http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=254705& >> >> > > I see two things I would flag. One is the fact that they include > extraneous signal names in the sensitivity list. This can cause a > simulation to run slowly, but I've never seen a synthesizer to create > different logic because of it. > > The other is the omission of a reset assignment for the signal clk_out > which is registered. This means the reset will simply disable the > clk_out FF from changing state when rst is asserted, but otherwise the > circuit will function normally. > > I don't see an error that will stop the design from working. > > The use of XNOR gates in the feedback means the all 1s state will latch > up while the use of XOR gates in the feedback means the all 0s state > will latch up. The XNOR is just an XOR with the output inverted which is > the same as either one of the inputs inverted or all three inverted. > Thinking of it as all three inverted clearly shows the symmetry of the > latch up states. > > RickLooking at Page 2 of the article I don't see what he is going on about. I don't think he knows either... The first response in his blog is trying to grapple with what seems to be an error in his analysis and his response is... "Oh i dunno, its far too early in the morning ;-) anyway the point is it didn't work and now it does Hurrah!!, and hitting things with hammers when they don't work, although satisfying, does get expensive." I'm not going to read 6 pages of reverse sequence blog to try to understand the gist of this conversation, but clearly the original article is just a big goof on the author's part. I hope no newbies read it and get very confused by all the nonsense. One blog comment is rather pertinent. Hamster said, "I'm quite sure that a good test bench will be far more complex than the unit under test, and far harder to write." This has been my experience and I think this point should be emphasized with engineers time and time again! Writing code is easy. Writing verified code, not so much. Rick
