VHDL expert puzzle

Le 25/11/2012 20:11, Jan Decaluwe a écrit :

The feedback term is 0 when the LFSR is all 0s so it won't count because it resets to all 0s.

Nicolas

Le 25/11/2012 20:49, Nicolas Matringe a écrit :

Or maybe not... What's that 'xnor' operator ? I've never used it before.

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

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

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

Correct. The superfluous signals in the sensitivity list are messy, but they don't affect behavior.

I think you may find it interesting.

Of course not. Again, he claims that an experienced designer would see it immediately.

Jan

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?

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 :-) ).

Mysteriouser and mysteriouser...

Alan

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

Looking 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

The big flaw is the combinatorial feedback of bit 0. since d0

sorry correcting myself: there is one register between bit0 and d0. I believe the author has wrong observation. if simulation worked it should work in hardware. The fact that it didn't then it worked by moving d0 to clocked process is fishy.

Kaz

--------------------------------------- Posted through

I thank each one of you very much for the comments.

It's good to talk to people who care about these matters and know what they are talking about. On APP, there was almost no progress during 5 (five!) days.

Even better, one of the comments inspired me to construct an hypothesis of what went wrong here. Alan Fitch wondered why lfsr was not an unsigned to make the comparison nicer.

Suppose that in his original code (not the one he posted) the comparison would be with a bitstring of the wrong size. That would always fail and explain the behavior that he describes.

He may have misunderstood the fix when making changes to the code. Where he then gets his strange explanations is anybody's guess.

Thanks,

Jan

Le 25/11/2012 21:53, rickman a écrit :

Rule of thumb I once heard is to put twice as much engineers in verification as there are in design. Funnily, the company I worked for at the time did exactly the reverse. And surprisingly they were kicked out of the project (and I resigned)

Nicolas

This is one of the reasons why I've never created a blog or other "expert" column on the web. I may be fairly experienced, but by writing things like this blog I may be showing what things I *don't* know rather than what I do... lol

Rick

I sign this statement ;)

If this code is from an experienced designer I see that much flaws, that have no effect of synthesis or simulation itself, but on readability. The sensitivity list is horrible and will cause unnecessary simulator load, the code indention is best effort to confuse readers. Some code beautify would do better. And as simple as this design is, a real world code without any comments is only good for protecting your failures from reviewers.

The usage of integer as start value for a lfsr is quite error prone. A hex value would be easier to read and would allow to design this module without integer or unsigned values. That clk_out is missing in reset path leads to one cycle latency of rst to clk_out, that is most likely not intended here. But you could only guess if that has impact on system or is even necessary. If there is an abvious error in cycle lenght (be it start value or feedback function), you can see this in simulation. I assume if you use lfsr, you know that you should double check this, if you are not really sure what you are doing.

bye Thomas

Yes.

According to me, none whatsoever. And that is also what I see in my simulation.

The crazy thing is that he says he does see a difference, in the sense that the version with delays "reveals the problem." In particular, he claims that the output clock clk_out never toggles in the version with delays, which is what he says he sees on the FPGA also.

He includes waveforms and uses that observation to claim that "the mystery has been solved".

But I see clk_out toggling correctly (as I would expect). In particular, in my simulations it toggles at exactly the same moments as in the version without delays.

The code has been posted on APP in ready-to-run format. What is driving me crazy is that noone else on APP seems to be interested in running it and confirming my results, or not.

I'm not going to ask that from anybody here - you have helped me enough already. Still, I include the code as it was posted below, perhaps someone is interested anyway. (The test bench as posted contains the design with the delays, and is ready to run.)

Thanks,

Jan

----

First pass at code

library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all;

entity lfsr_counter is port ( rst, clk : in std_logic; clk_out : out std_logic); end lfsr_counter;

architecture imp_lfsr_counter of lfsr_counter is signal lfsr: std_logic_vector (13 downto 0); signal d0, clk_i: std_logic; constant countmax: integer:=2685; begin

d0

For giggles I ran the simulation, both are identical (except clock_out is delayed by tpd in the second). The two waveforms he has in the post are not on the same "zoom". The first is zoomed way out where you can see clock_out (solid for clock_in). The second is zoomed way in where you can see the individual clock_in.

So, clock_out is probably toggling but he's not centered over an edge to actually view it. If he used a self checking testbench he might have caught it (or rather not caught it) instead of relying on manually viewing the waveform.

Post should have been titled "Foiled by testbenches"?

Regards, Chris

Many thanks!

Mm, that holds for the intermediate clock signal clk_i, but clk_out itself has no delay, correct?

Could that be it? He wouldn't have bothered to do a full zoom first? That would be such silly error that I admit I didn't consider it!

My hypothesis of initially faulty code would be consistent with what he sees on the fpga.

Heck, perhaps I should just throw the towel. Noone on APP seems to care.

Of course. Actually, sometimes I think that if it's not self-checking, it shouldn't be called a testbench.

It wouldn't be hard for a case like this (by checking edges, you can verify whether the generated clock with some frequence or period spec.)

Jan