( Post 76 Item 1 ) ---------------------------------------------------------
There is a bug in Synopsys 2.2 when mapping flip-flops that can produce
incorrect logic.
The bug occurs when trying to map a D flip-flop with clear into a library
which has no such FF, but does have a D FF with both set and clear for
which clear "wins", that is, if both set and clear are asserted the FF clears.
In such cases, 2.2 will map the clear FF onto an instance of the latter FF
which has set and clear tied together. This works fine when asserting the
clear, but when deasserting it causes a race condition. If the internal
timing of the FF is such that clear deasserts faster than set, then the FF
may be set when the clear is removed.
It is correct to instead tie the set signal inactive, which is what happens in
2.0b and earlier.
This bug could occur with almost any library if the user puts enough dont_use
attributes on FFs, leaving Design Compiler a similar choice.
EXAMPLE:
The link library contains a FF with clear (timing data deleted for simplicity):
cell (FDP1C) {
state("IQ0","IQN0") {
next_state : "D " ;
clocked_on : "CK" ;
force_01 : " ! CDN " ;
}
pin (Q) {
direction : output ;
function : " IQ0 " ;
timing () {
timing_type : rising_edge ;
related_pin : "CK" ;
}
timing () {
timing_type : clear ;
related_pin : "CDN" ;
timing_sense : positive_unate ;
}
}
pin (CDN) {
direction : input ;
timing () {
timing_type : recovery_rising ;
related_pin : "CK" ;
}
timing () {
timing_type : hold_rising ;
related_pin : "CK" ;
}
}
pin (CK) {
direction : input ;
}
pin (D) {
direction : input ;
timing () {
timing_type : setup_rising ;
related_pin : "CK" ;
}
}
}
The target library contains only a FF with both set and clear:
cell(TEST_FDP1B) {
state("IQ0","IQN0") {
next_state : "D" ;
clocked_on : "CK" ;
force_01 : "!CDN" ;
force_10 : "CDN !SDN" ;
}
pin(D) {
direction : input ;
}
pin(CK) {
direction : input ;
}
pin(CDN) {
direction : input ;
}
pin(SDN) {
direction : input ;
}
pin(Q) {
direction : output ;
function : "IQ0" ;
}
}
and the result of the mapping under 2.2a-6762 or 2.2b is (in Verilog):
module fdp1c ( Q, CK, D, CDN );
input CK, D, CDN;
output Q;
TEST_FDP1B U_fdp1c ( .D(D), .CK(CK), .CDN(CDN), .SDN(CDN), .Q(Q) );
endmodule \|/
wrong
while the mapping under 2.0b was:
module fdp1c ( Q, CK, D, CDN );
input CK, D, CDN;
output Q;
wire n17;
TEST_FDP1B U_fdp1c ( .D(D), .CK(CK), .CDN(CDN), .SDN(n17), .Q(Q) );
assign n17 = 1'b1;
endmodule
which was correct. Setting the prefer_tied attribute on the set and clear
pins seems to have no effect.
Does anyone have any ideas for workarounds? Preferably, changes to the target
library that would prevent this problem?
Howard A. Landman
landman@xpoint.com
408 988-1584
|
|
