NO clock event, but signal changes anyway!

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?

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?

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.

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.