( Post 75 Item 1 ) ---------------------------------------------------------
[ Editor's Note: Sorry for being so late in posting Cindy's reply; I
temporarily lost it when my company moved to another building...]
From: cindy@ca45.zoran.hellnet.org (Cindy Eisner)
Subject: Re: ESNUG Posting Number 64
jaa@mongoose.ess.harris.com (john auer) writes:
> For this problem, pin_equal and pin_opposite have no effect (Synopsys
> confirmed this when I first ran into this problem). Pin_equal/opposite
> statements seem to be used by Synopsys only if the equations for the
> function of the gate and/or three_state are not given; otherwise,
> Synopsys deduces them from the equations.
well, i agree that they have no effect, but not that they are supposed to
work that way. what the manual says is that FOR OUTPUTS, the statements
are used only if the function is not given, etc., etc. but the manual
explicitly states that FOR INPUTS, the pin_equal/opposite attributes are
requirements from the synthesis.
> I don't use verilog, and I haven't seen a similar mapping problem with
> VHDL. I ran a test case on a VHDL tristate design today without incident.
> The problem as originally reported to Synopsys is accurate, so I will not
> be upgrading the STAR to a bug.
if after reading the above, you still do not want to upgrade it, let me
know and i'll submit a BUG report. there may come a day very soon when i
will need this functionality...
> Did Synopsys have any trouble making the synthetic library? (install_synlib)
> In my experience, "unable to map" reflects an out-of-date synthetic library
> (library.mod file). Just a thought...
sorry i did not make myself clear here. what i meant was that when i
defined a tri-state buffer with inputs required to be opposite, using
the pin_opposite attribute, i got the "unable to map" error message.
otherwise, the tri-state buffers were mapped fine.
Cindy Eisner, CAD group, Zoran Microelectronics LTD
Advanced Technology Center, Haifa 31204, Israel
( Post 75 Item 2 ) ---------------------------------------------------------
From: d_pinvidic@emulex.com (Dan Pinvidic)
Subject: Question for ESNUG group
Question: Can a verilog description of a 2-1 mux which has one data
input grounded get mapped to a 2-1 mux from the library. All efforts result
in a nor gate controlling EMO. EMO and FMO must have matched path delays.
Compiled with flatten & structure set to "false", -map_effort low
I really don't want to instantiate a mux.
This code produces a nor gate driving EMO.
always @ (MODE or BC_DIV[3] or CLK40_I)
begin
case ( MODE ) //synopsys parallel_case
2'b00 : EMO = CLK40_I;
default : EMO = 1'b0;
endcase
end
The following code produces a 2-1 mux for a clock which I must match
in the code above.
always @ (SYNSLO_FAS or FASCLK or FAS_DIV[3])
begin
case ( SYNSLO_FAS ) //synopsys parallel_case full_case
1'b1 : FMO = FAS_DIV[3];
1'b0 : FMO = FASCLK;
endcase
end
All thoughts welcome,
Dan Pinvidic
Emulex Corp.
Costa Mesa, Ca.
|
|
