HOME UP PREV NEXT (Compute/Commit Cycle With Delta Cycles)

Inertial and Transport Delay

Consider a simple `NOR' gate model with 250 picosecond delay. It has two inputs, and the behavioural code inside the model will be something like (in SystemC-like syntax, covered later)

  SC_MODULE(NOR2)
  {  sc_in < bool > i1, i2; sc_out < bool > y;
     void behaviour()
     {  y.write(!(i1.read() || i2.read()), SC_TIME(250, SC_PS));
     }
     SC_CTOR(NOR2) { SC_METHOD(behaviour); sensitive << i1 << i2;
  }

The above model is run when either of its inputs change and it causes a new event to be placed in the event queue 250 picoseconds later. This will result in a pure transport delay, because multiple changes on the input within 250 picoseconds will potentially result in multiple changes on the output that time later.

This is unrealistic, a NOR gate made of transistors will not respond to rapid changes on its input, and only decisively change its output when the inputs have been stable for 250 picoseconds. In other words, it exhibits inertia.

To model inertial delay, the event queue insert function must scan for any existing schedulled changes before the one about to be inserted and delete them. This involves little overhead since we are scanning down the event queue anyway.

Consider the behaviour of the above RS-latch when a very short (runt) pulse or glitch tries to set it. What will it do with transport models?: the runt pulse will circulate indefinitely. What will it do with inertial models?: ignore the glitch.

Flash Player Upgrade Needed

READY