Quartus 9.1 VHDL strange behaviour

I am unsure about the meaning of yor post. What I have done was:

- Compile

- Generate Net-List

- Start Simulation (Blue triangle with rectangular wave,

there is a warning that this simulation will supported in future).

I expect that the different length of the "high" and "low" - states reflects the runtime to the different pins, but the marked "high"-state is strange.

I will try to download the latest release (9.1 service pack 2) and the new simulator.

The clock line (125MHz) is attached at a clock input and declared as clock insige the simulation setup.

So what you have done is a post fit simulation, simulating real hardware.

You can also simulate the code to see that the code itself functions as you expect. I find that good practice and correctly functioning code will 99% of the time give you the correct hardware. Code simulation is also massivly quicker than post fit gate level simulation.

thanks for the advise. I found where to switch between "functional" and "timing" simulation. I attached two pictures one for each mode.

As expected the functional simulation shows (luckily for me) that the code works correctly, but the timing simulation shows unexpected behaviour.

So back to the roots, is there any explanation why the 1ns spike appears at 70ns in the timing simulation? I understand that the different length to the output pins cause the different timestamps where the pins change there value but the spike? I dont have any idea how to avoid this.

I will try to analyse the code in reality (scope).

But unfortunally I found unwanted strange behaviour in the hardware implementation and traveled down to the code and simulation - and (surpise) it's unclear there aswell.

Maybe the volcano ash from Iceland had more impact than we all recogniced :-)

Hello again,

I made a new approach to the problem. I have created two projects one in VHDL and one in AHDL, doing both the same functions. I made functional and timing simulation for both projects.

While the functional simulation is same for both projects the timing simulation differs from AHDL and VHDL.

The AHDL approach seems to be ok, while the VHDL approach shows unexplainable spikes.

I attached the both projects and and the four screenshots.

Meanwhile I belive that there is a bug in the VHDL compiler causing the spikes.

I use the Quartus II Version 9.1 Build 350 03/24/2010 SJ Web Edition Service Pack 2, but the previous Service pack 1 Version shows the same error.

I would be very happy to understand what happned!

best regards

Ekkehard

--- Quote Start ---

The AHDL approach seems to be ok, while the VHDL approach shows unexplainable spikes.

--- Quote End ---

These spikes aren't unexplainable nor even a compiler bug. They are basically normal behaviour with an asynchronous decoder.

An interesting question is, why the VHDL variant is showing stronger glitches than the AHDL. Apparently, the synthesis is different. You should consider, that the delay skew of the AHDL "pinsCypressData" output lines can already cause problems when sampling the data with an unsuitable timing. In contrast, registering the decoded VHDL output can remove the glitches.

Thanx for the answer. I would follow your explanation (Spikes "are basically normal behaviour with an asynchronous decoder") *when* I had made an binary counter.

*But* I have implemented an Gray-Code counter, where from each state to the next only a single bit change it's value.

So it is per definition that during the change from one state to next the asynchronous decoder can have only the previous or the next state. If the decoder output decodes the same value in both states, then the outputs must stay stable even if the decoder input switches randomly between the two states. Correct?

I think that the AHDL version does this correctly while the VHDL version fails.

--- Quote Start ---

So it is per definition that during the change from one state to next the asynchronous decoder can have only the previous or the next state. If the decoder output decodes the same value in both states, then the outputs must stay stable even if the decoder input switches randomly between the two states. Correct?

--- Quote End ---

No. You havn't glitches in the gray encoded output. But pinsCypressData is not gray encoded. If more than one input term to the combinational logic for an output bit changes, you can get gliches.

By the way, I got glitches in the simulation of your AHDL, too.

P.S.: It's not exactly clear, what can be regarded as glitches in this design. When you look at the AHDL simulation, the decoded output pins are changing it's state at different times. So the output code has already glitches. With the VHDL design, you often see glitches of a single output bit. If you look at the technology map, you realize, that each output bit is generated by two cascaded LUTs. At the second LUT stage, multiple input bits can change simultaneously. In this case, glitches are normal behaviour.

Also the AHDL design has cascaded LUTs, but the structure is different. To avoid glitches of individual output bits, the outputs must be registered. But you have the problem of delay skew between outputs, so the code still has glitches.

There has been a discussion, if the LUT output can be always expected glitch free with only one input bit changíng. The empirical results seem to suggest this, but apparently, it can't be guaranteed.