Combinatorial logic causing delta impulse

[V.]

I have sig1 and sig2 that are both driven by a synchronous process.

I have a line of combinatorial logic that simply checks that both are high:

out <= sig1 and sig2.

In my ModelSim simulation, at the moment of the falling edge of sig1 and rising edge of sig2, I see the "out" signal pulse high just for only one delta delay cycle.

I assume there's a moment in time while sig1 is falling and sig2 is rising that the simulator thinks they are both high?

I am not sure if this only exists in simulation environment or will it propagate to my real world implementation? How can I prevent it in simulation?


Thanks for your guidance.

Regards,
V.

 

[Mark Curry]

In article <b6acc126-b5a6-4b67-8eef-f5d728025acf@googlegroups.com>,
V. <mr.jay.diem@gmail.com> wrote:

I have sig1 and sig2 that are both driven by a synchronous process.

I have a line of combinatorial logic that simply checks that both are high:

out <= sig1 and sig2.

In my ModelSim simulation, at the moment of the falling edge of sig1 and
rising edge of sig2, I see the "out" signal pulse high just for only one
delta delay cycle.

I assume there's a moment in time while sig1 is falling and sig2 is rising
that the simulator thinks they are both high?

I am not sure if this only exists in simulation environment or will it
propagate to my real world implementation? How can I prevent it in simulation?

Think it through more V, as it'll happen in the real world.
The signals "sig1" and "sig2" are never going to have exactly
matched delays. So of course in the real world perhaps "sig1" rises
just a few moments before "sig2" falls. What do you get? - a glitch.

Do you care? Not if you've followed proper synchronous design principles.
You registers up the "out" signal one period later after everything's settled.

As to the sim - again, do you care? It's a reprsentative model
of what could happen in the real circuit. It's ok, no need to "prevent it
in simulation".

Regards,

Mark

 

[Dio Gratia]

On Wednesday, August 13, 2014 5:37:01 AM UTC+12, V. wrote:

How can I prevent it in simulation?

As Mark notes it can occur in the real world. However if you never use a vulnerable combinatorial product as a latch enable or clock it has no meaning other than difference in propagation times of the inputs in delta cycles to the expression and you can prevent it simulation. That difference in propagation time can match differences in gate delays, travel times or rising/falling edge times in actual hardware.

You could also note that in a zero timed model it tells you one of your synchronous processes is either using a delta delayed clock or already has a combinatorial expression on a sequential storage element's output.

To prevent a delta cycle impulse from propagating look to signal assignment:

signal_assignment_statement :: [ label : ] target <= [ delay_mechanism ] waveform ;

delay_mechanism :: transport
| [ reject time_expression ] inertial

target :: name
| aggregate

waveform :: waveform_element { , waveform_element }
| unaffected

Where you'd use inertial impulse rejection with a time expression set to the smallest unit of the resolution limit selected primary or secondary time unit (without setting the resolution limit that would be 1 fs, the default resolution limit set to femto-second). The idea here is to prevent an impulse rejection interval of 0 which happens to match a delta cycle delay.

Such a signal assignment should have the delay mechanism ignored by synthesis.

A rule of thumb should be to never rely on inertial rejection to insure proper operation of a model.

I recall issues we had in the late '70s and early '80s with silicon being too fast, sub nanosecond gate delays in 74LSXX MSI from Japanese vendors and AMD having DRAM with almost zero holdover on Data Out from CAS invalid. Mixing things with different propagation delays can result in unforeseen complications.

The same sort of effects can occur on silicon devices, and the same synchronous design rules are used as cures.