NO clock event, but signal changes anyway!

[Altera_Forum]

In a nutshell, something weird is going on in my simulation... 

 Clearly my code states that upon a rising_edge of nDB_BUF_EN then various outputs are latched. However I have seen the clocking signal nDB_BUF_EN to be stable (at logic 1) BUT the latched outputs change!  How could this be?   proc_IOControlDBBusLatch : PROCESS (nRST, nDB_BUF_EN) BEGIN IF nRST='0' THEN zb2D7_FrameBlank <= '0'; zb2D6_LineBlank <= '0'; zb2D5_CPU_Access <= '0'; zb2D4_AltGREENsel <= '0'; zb2D3_BANK3_CASsel <= '0'; zb2D2_BANK2_CASsel <= '0'; zb2D1_CassMotorEn <= '0'; zb2D0_SpeakerEn <= '0'; ELSIF RISING_EDGE(nDB_BUF_EN) THEN --Latch data from the common databus zb2D7_FrameBlank <= D_7_0(7); zb2D6_LineBlank <= D_7_0(6); zb2D5_CPU_Access <= D_7_0(5); zb2D4_AltGREENsel <= D_7_0(4); zb2D3_BANK3_CASsel <= D_7_0(3); zb2D2_BANK2_CASsel <= D_7_0(2); zb2D1_CassMotorEn <= D_7_0(1); zb2D0_SpeakerEn <= D_7_0(0); END IF; END PROCESS proc_IOControlDBBusLatch;   So my question is, under what possible circumstances can the outputs change (latch) if nDB_BUF_EN is NOT changing??? I see no 'glitch' on nDB_BUF_EN either - there is NO rising_edge event!  Thanks in advance for any insights,  Andy

[Altera_Forum]

It can't except if your reset is changing

[Altera_Forum]

I am very suspicious of anything not named "clk" being used as a clock. If it is logic from elsewhere being used as a clock you're in for trouble. How are you trying to detect this glitch? how do you know the glitch isnt at a higher frequency than your detector can detect? 

 Is nDB_BUF_EN really a clock? is it some logic? how is it generated?

[Altera_Forum]

@Kaz, nRST signal only goes from low to high right at the start of my simulation, so to answer your question, NO it is NOT changing at the point that the latched outputs change. 

 @Tricky, no nDB_BUF_EN is not a 'clock' per-se and yes it is derived logically. And yes I see one of the signals that nDB_BUF_EN is based on change and it is at this change that I see the latched outputs change.  BUT. But but but! I DO NOT see (in my simulation) nDB_BUF_EN change however the latched outputs DO change!  OK, you state "If it is logic from elsewhere being used as a clock you're in for trouble"... but why? Can a simulator 'not quite simulate' things correctly? Are you talking about some kind of logic race hazard here?  In other words (let me see if I can explain what I am thinking here)... logic signals derive nDB_BUF_EN: logic signals change that make nDB_BUF_EN='1' logic signals change that STILL make nDB_BUF_EN='1', but somehow the simulator has decided that there was indeed a 'change' event in nDB_BUF_EN which therefore triggers my process above.  I have re-written the way in which nDB_BUF_EN is derived, and still I see this problem.  Thanks again chaps!  Andy

[Altera_Forum]

What type of simulation is it? RTL or gate level? Either way, your code can only clock if nDB_BUF_EN changes, so there must be a change somewhere. 

Have you got a testbench so we can try and recreate the problem?

[Altera_Forum]

Using logic as a clock is a bad idea because it can be prone to glitching and variation in timing due to temperature and routing differences. It is much better practice to use it as a clock enable rather than a clock.

[Altera_Forum]

From your description: 

logic signals change that make nDB_BUF_EN='1' logic signals change that STILL make nDB_BUF_EN='1' To me, that's a glitch. I'm not good at simulation, but it's a hardware glitch. It's important to note that synthesis can change your logic too, which is another concern beyond what you're seeing. For example, I've seen synthesis take a signal that drives into a cloud of logic, and change it so that it drives multiple LUTs in that cloud. As a result, when that signal changes, a glitch occurs. For example, let's say your logic was an OR gate, and at least one signal was a constant high, so even if another signal is changing, the output should be stuck high. In reality it's that type of thing that is prone to glitching. You need to either take it off the clock and make it a clock enable as already suggested, or minimally re-register the logic so the final thing driving the clock signal is a register, which won't glitch assuming everything is synchronous. You may have other issues closing timing, but they'll be readily apparent in static timing analysis rather than glitches which are a pain to debug. As for why it's not showing up in your simulation, I'm not sure. Don't simulators have a way to trace back what caused a signal to change, i.e. you can look at the register changing and ask the simulator to show what previous transition caused it? Again, I'm not a simulation person but thought that was possible. Maybe someone else can chime in. What simulator are you using?

[Altera_Forum]

any glitch in simulation should show if zoomed in. The only thing left is wrong observation especially on a bad day.

[Altera_Forum]

If you use modelsim for your simulations expand time deltas mode. Your computer cannot run a parrellel simulation, and therefor calculates sequentially. This may have consequences in the simulation accuracy.

[Altera_Forum]

Looks like this is very prone to glitches. You should'nt use logic as a clock. 

Make a rising edge(CLK) and inside the rising_edge(CLK) put your if nDB_BUF_EN = '1' to latch the data.  It will generate FFs with an ENABLE port connected to the nDB_BUF_EN signal.

[Altera_Forum]

I agree with aprado, but what happens if the above is used and the nDB_BUF_EN is high for more than one clock cycle?  

I suggest using a rising edge detector. Unless you are sure nDB_BUF_EN is never longer than one clock cycle high.

[Altera_Forum]

Wow, thanks for the VERY helpful insights / suggestions everyone. Excellent responses on this forum as usual. 

 Zooming in showed no glitch. You can advance to 'next transition' in my simulator (for any selected signal) and there is NO transition in this area that would drive a change in the process.  To solve the problem, as suggested, I now clock the latch using the system clock thus:   proc_IOControlDBBusLatch : PROCESS (nRST, M4MHz) BEGIN IF nRST='0' THEN zb2D7_FrameBlank <= '0'; zb2D6_LineBlank <= '0'; zb2D5_CPU_Access <= '0'; zb2D4_AltGREENsel <= '0'; zb2D3_BANK3_CASsel <= '0'; zb2D2_BANK2_CASsel <= '0'; zb2D1_CassMotorEn <= '0'; zb2D0_SpeakerEn <= '0'; ELSIF RISING_EDGE(M4MHz) THEN IF nDB_BUF_EN='1' THEN --Latch data from the common databus zb2D7_FrameBlank <= D_7_0(7); zb2D6_LineBlank <= D_7_0(6); zb2D5_CPU_Access <= D_7_0(5); zb2D4_AltGREENsel <= D_7_0(4); zb2D3_BANK3_CASsel <= D_7_0(3); zb2D2_BANK2_CASsel <= D_7_0(2); zb2D1_CassMotorEn <= D_7_0(1); zb2D0_SpeakerEn <= D_7_0(0); END IF; END IF; END PROCESS proc_IOControlDBBusLatch;   The D_7_0(7 DOWNTO 0) signal(s) remains stable for the (total of 4) clocking pulses of M4MHz that is active for the above process when nDB_BUF_EN is at '1'.  I am now searching through the rest of my code for any other similar processes implemented in this manner.  Thanks again everyone!  Andy  PS, For the record (in case any of you were wondering WHY I chose to use a logic source as a clocking event) these signals are driven from a Z80 core (actually a T80 core from opencores). Everything appears to 'do it's stuff' apart from a few issues (like this one) I am trying (very slowly) to hunt down.

[Altera_Forum]

You could have had a 1 delta wide pulse. They dont tend to show up on the waveform, but will cause a clock to happen.

[Altera_Forum]

Hmmm. I am wondering now how such an event can be traced back to the source of the problem. 

 A

[Altera_Forum]

put some debug asserts in your code: 

  process(nDB_BUF_EN) begin if rising_edge(nDB_BUF_EN) then report "a Rising edge on nDB_BUF_EN just occured" severity Failure; --or note or warning or error if you want simulation to continue end if; end process;