Quartus 9.1 VHDL strange behaviour

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.

True but the seen glitch is on a single pin who's value is not a logical combined value, instead its a constant declaration.

If I had declared pinX <= pin[0] and pin[1] than I would expect the glitch or spike.

But the discussion seems to end, because my expectations on VHDL and what the compiler creates are not very close together.

The basic answer to all this - dont use asynchronous encoders in FPGAs, use synchronous, whatever the langage. Glitches just go away (assuming you meet timing requirements).

When you compile something for the FPGA, you get whatever the synthesiser gives you, which will be a reduction of the boolean equations you wrote, which may have glitches. Go synchronous.

Where to generate the clock from, in the current example?

The source 125MHz for the gray counter seems not to work because there is a huge runtime gap between this signal and the counter output.

If I define the falling edge of 125MHz I will receive tons of timing warnings.

I think I should use the decoded states, but I am unsure about this since the output of the stages (as shown) are not reliable, e.g. I am afraid that decoding a clock from the counters stage will cause glitches in the clock just as it does on the output.

Just some few words to close the case.

I made several tests with clocked buffers prior the output pins and the hints given by the other users.

It seems to work (at least the spikes are gone).

So I declared

signal CypressData : std_logic_vector(15 downto 0);

in the architectur header,

and replaced every place where "pinsCypressData" is used (e.g.)

when GRAY_STEP_XXX => pinsCypressData <= x"XXXX";

with

when GRAY_STEP_XXX => CypressData <= x"XXXX";

at the very end of the process section I inserted

if rising_edge(pinClk125MHz) then

pinsCypressData <= CypressData;

end if;

The amount of used blocks increased in numbers of 10 blocks for 16 Pins.

The spikes are gone.

I made a simmilar design with a binary counter instead of a gray-code stepper, and the clocked output are stable as well.

My conclusion is that result of combinational logic on the output pins are not reliable, even if the same design build with 74xxx chips would work.

Strange but true.

Thanx for your patience and your help!