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

It can't except if your reset is changing

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?

@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

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?

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

Honored Contributor

11 years ago

NO clock event, but signal changes anyway!

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

14 Replies

Altera_Forum
Honored Contributor
11 years ago
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
Honored Contributor
11 years ago
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
Honored Contributor
11 years ago
Hmmm. I am wondering now how such an event can be traced back to the source of the problem.

A

Altera_Forum

Honored Contributor

11 years ago

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;

Forum Discussion

NO clock event, but signal changes anyway!

14 Replies

Recent Discussions

Timing analysis - long combinational path

timing violation fix

Issues with downloading

Quartus Prime Lite 25.1 License Error - "Unable to checkout a license" (SALT_LICENSE_SERVER)

Quartus Prime Pro 26.1 - Where to find Documentation of new Signaltap features