( ESNUG 357 Item 9 ) --------------------------------------------- [8/10/00]
Subject: ( ESNUG 356 #7 ) DC, Multiple Clocks, and MUXes In Clock Gating
> What I tried to avoid is to instantiate a technology/vendor specific MUX
> in my RTL code in order to make the code technology independent and
> portable in future. The best solution I have found from solvit is to
> instantiate a GTECH MUX. I am still not very happy for this solution
> either.
>
> - London Jin
> Toshiba San Jose, CA
From: "V. Menezes" <inod@hotmail.com>
John,
With regard to clock gating, the fundamental issue behind writing the code
by London was to ensure that prop delays are "matched." Leaving it to a
synthesis tool is asking for trouble. There are no guarantees the same
MUX cell is being used for matching the prop delays. The foolproof method
is to instantiate a hardcoded MUX instance. If you stick with a specific
ASIC vendor, there is a high probability that the cell name may not change
with technology, thus one may not have to edit the RTL. A small price
to pay!
As a side note, one should also be very careful with clock gating using
MUXes. It is possible for certain circuit topologies of MUXes to produce
a glitch at the output of the MUX, even if the inputs are at the same logic
level and the select input changes. While this problem is a non-issue for
combinational logic that is registered, it can be a disaster if there are
glitches on the clock line. This fact is sometimes hidden from a passive
user of a library. When ever using a MUX for clock gating, (scan mode,
power savings, etc) always use a clock gating MUX provided by your ASIC
vendor.
- V. Menezes
|
|
