VHDL expert puzzle

A VHDL simulator broken in this way? Hard to imagine.

I can't understand your advice. For more than a decade I have used ModelSim to

functionally verify chains of DSP modules and never needed to put any delay

inside RTL code. In the top level testbench all inputs are generated on the

clocks so I wouldn't worry about delta delay problem.

Kaz

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

Correct, I misstated. Only the internal nets will see the added delay.

I think your hypothesis is correct; we are missing part of the story. Either the code is not the original code, he had some other error in the process, or he ignored the timing reports and the second run he just happened to meet timing. To your point, if he runs syn+P&R again, it might fail. Nothing solved or fixed.

Which is odd, they should care. In my mind that is the beauty of a technical *community*, in the end you get a much better result. This is a perfect example, his goal was to show simulating/testing can be beneficial. But his example *failed* to prove the point. To the rescue the community ... except the author didn't want to participate?

In general this is bad, because the correct feedback is available to the author and it is not being fixed. Hopefully, the poor quality will will only reflect on the author and not APP's reputations. And yes, it doesn't seem like any progress is being made, what's the saying, the advice is falling on deaf ears.

wiggle_bench

I agree, I don't like and would not advocate adding these type of delays to behavioral simulations. If you want a more "physical" simulation there are other methods. If you don't trust the static timing analysis you can simulate gate-level structural simulation with back-annotated timing information. You can do this with an FPGA and the FPGA tools. But this is usually not done because we typically are ok with the static timing results and then take it to the lab, for an FPGA.

Regards, Chris

I would agree to this further. For this puzzle, some vendor synthesisers have treated sensitivity lists differently and made different assumptions to complicate things still further.

I have sometimes had to put delays on I/O signals between my FPGA and vendor-supplied models, e.g. for memory devices, to make a board level behavioural simulation match the real world. If I didn't, data would appear a cycle early, or be written to an off-by- one address, or the "data stable" eye would miss my sampling point, etc.

I think this is justifiable as making the FPGA model more closely match its real world behaviour, but I have never had to do the same internally!

- Brian

There a issues at multiple levels with this. However a major one has only to do with modeling and simulation, namely whether adding the delays should make a difference to the behavior of the clock output (as he claims), or not (which is what we see and expect).

Any standard VHDL simulator should give the same answer here.

Jan

...

An original code is o.k. except for bad style, as mentioned by just about everybody above, and for kludgy idea to use MLSR to divide clock. At least what's implemented is real 14-bit MLSR with period = 2^14-1. It appears to divide the input clock by 24998 and that's supposedly was an original intention. Or did he tried to divide by 25000? Or, may be he really divides by 25000 and I miscalculated by one somewhere? Anyway, it's pretty close :-)

A "fixed" code is much worse. It, supposedly unintentionally, implements 15-bit LSR with period=7905, i.e. *not* MLSR. Input clock is divided by 11684. It's sounds damn unlikely that that was an intention.

On this one, and only this one, I disagree.

I also don't like naming synchronous reset 'rst'. I'd rather prefere 'srst" or 'sreset'.

Just about everything he wrote on the second page makes no sense.

Oh, another style flow is xnor. The only valid use of xnor is when you want to obfuscate your intentions.

In DSP I guess you have in general only one clk and all modules synchonous.

Consider a larger design using IP (and maybe several clock with some relation). the following construct might be hidden within some IP most likley over hierarchy boundaries and more difficult to detect.

Clk1

Actually your example does not quite demonstrate the point you were making. In your example, you have actual function (the muxing and enabling) betwe en the clocks so you're describing a gated clock system. That system, if b uilt, could very well behave exactly as you have described but not be what the designer intended simply because the designer did not account for the c lock skew. The simulation without the added delay very well may describe t he actual hardware. In this case, adding the delay 'to fix the simulation' would be sweeping the design error under the rug until it eventually is un covered in real hardware.

To demonstrate your point though you simply need to generate the new clock as this:

clk1

I've had to put (simulation-only) delays on internal signals.

There was one version of Xilinx's block ram in their Verilog unisim library that was broken. IIRC, the bug had something to do with a delay on the clock inside the unisim model.

Synthesis was fine, but it didn't give the right result in simulation until I modified my source code to add a delay on the signals feeding the ram.

I think it might have been the version of unisim that came with ISE 10.1.

Regards, Allan

I had a bit of confusion on this one myself. Not that he was using an integer per-se, but that he didn't explain in a comment why this value was important or how it was derived. I had to consider that this value was ill-conceived and didn't want to bother with looking up the LFSR and calculating where this value would appear in the sequence, etc. It would have been useful if he had added a comment saying the length of the loop is xxx clocks or yyy time.

I think for FPGAs it is very common to specify an async reset to assign the configuration value of each FF, so I have come to expect async resets. But if they use a sync reset, it doesn't bother me. I don't expect that aspect of the reset to be part of the name. I think resets are complex enough that they should be designed and documented at the system level.

Yes, I'm not sure what he was thinking. It is a bit funny how he responds to this in the blog. He starts out discussing it a little defensively and after three or four rounds of increasing defensiveness on his side he says something like, "Just forget about it". I expect it was a bit embarrassing to make a mistake so publicly. I'm sure we have all made similar mistakes, the kind where we slap the side of our head and say, "what was I thinking?" But to do it publicly is a different matter.

I think the "Just forget about it" comment was on the second page of comments and there were six when I read it. So I guess he is getting beat up pretty badly. I feel for him.

Rick

I don't understand. What would you use in place of xnor? In LFSRs there are two ways of coding them. Using the XOR function creates two loops, one being the all zeros state. Using the XNOR function creates two loops, one being the all ones state. What is wrong with using the XNOR function to describe a LFSR with the all ones state as the excluded state?

Rick

I think the problem is not the LFSR, but that the XNOR operation can be non-intuitive.

For example: a XNOR b XNOR c is equivalent to a XOR b XOR c Since there is an even number of inversions, the inversions cancel out. In the given example, there is an odd number of XNORs, so it works as written.

My preferred style would be. d

Yes, that's exactly what I meant to say.

I wouldn't worry too much :-) Let me summarize.

Let's be clear about how bad this really is. He describes the simulation with delays, and draws all kinds of nonsensical conclusions from it. However, by simulating his code, everybody can verify that it simply doesn't behave in the way he describes. He makes his points while misrepresenting his own (public!) code.

For days, I have been trying to point out that there is something fundamentally wrong here :-) No reaction from the community on APP on this particular point. In the end, the OP came back and stated (screamed) that he "just does not care whether his code works or not". Those who do "are missing the point". (I think he means that he should be praised for using the word "testbench").

Guess what: again no reaction to this date on APP. The only behavior that has been criticized is my own, for calling this article "sloppy". (I confess.)

In short, he is getting away with this.