( ESNUG 319 Item 6 ) --------------------------------------------- [5/26/99]
Subject: Modelsim & VSS Having VITAL (VHDL) SDF Lib Conflicts W/ DC 99.05
> I'm trying to do a post-synthesis simulation with Modelsim EE 5.2, using
> the VITAL lib of my ASIC vendor. I keep getting errors that some instances
> do not have one or two generics (e.g.: tpd_c_q_posedge). (I do not have
> errors of missing instances...) I don't think there is any error on the
> top instance I apply the SDF file, nor similar things... However, I don't
> know if I produce wrongly the SDF/VHDL files from Synopsys DC 99.05 (I use
> the SDF v2.1 format). Is there any chance that the vendor ASIC VITAL
> models are not 100% VITAL compatible, as said in the Modelsim user manual?
From: alex_schreiber@my-dejanews.com
The story has two sides. For an ASIC library used inside DC, a Synopsys
model needs to be described (.lib) which is compiled into a binary format
(.db) by Library Compiler (lc) of Synopsys. Usually the ASIC vendor is
already providing the .db format, so you as customer do not need to have
the lc license and do not need to compile it yourself.
In this Synopsys model below there is a delay defined from the rising edge
of 'c' to the output 'o' (for tpd_c_q_posedge). It looks like follows in
the .lib model (often not delivered by the ASIC vendor):
pin(q) {
:
timing() {
timing_type : rising_edge;
timing_sense : "non_unate";
intrinsic_rise : 2.00;
intrinsic_fall : 2.00;
rise_resistance : 0.20;
fall_resistance : 0.20;
related_pin : "c";
}
}
Based on this model the delay calculator in Synopsys DC is generating the
SDF file. In your case you will find there an entry like
IOPATH (posedge c) q (2.00:2.00:2.00)
The second part are the VITAL models of your standard cell library. To be
able to backannotate the values estimated by Synopsys delay calculator, the
VITAL timing generics need to meet certain requirements. Only then the SDF
backannotator in the Simulator (like ModelSim) can map the SDF entry with
the VITAL generic correctly. In the assumed SDF entry given above the
generic needs to be like follows:
tpd_c_q_posedge
If you have the VHDL/VITAL source code of your standard cell lib (usually
delivered by the ASIC vendor) you can check the defined timing generics of
the cell which makes trouble. I guess, you will find either no definition
or something like
tpd_c_q
The missing edge specifyer is enough to let the SDF backannotator failing.
- Alex Schreiber
---- ---- ---- ---- ---- ---- ----
From: Alan Fitch <alan@doulos.com>
I've seen this problem twice at two different customers when we were running
the Design Flow exercise in our Comprehensive VHDL training course.
The customers both told me that it was a problem with Synopsys writing
out SDF. However I have no proof of this.
Unfortunately as I was on customer sites, I could not take away the log
files. I cannot reproduce the problem back in the office, as we haven't
got VITAL compliant ASIC libraries, so I haven't reported it to Synopsys.
Both the customers had other routes to create SDF files which were then
compatible with Modelsim, which is why I suspect Synopsys. However I
must stress that I have no proof of this, and it is certainly possible
that the respective ASIC libraries were in error.
- Alan Fitch
DOULOS Hampshire, UK
P.S. If anyone knows of a VITAL compliant ASIC library that we could use
on our public training courses, we should be eternally grateful!
---- ---- ---- ---- ---- ---- ----
From: Laurens Drost <drost@synopsys.com>
Alan,
The constructs used to write out SDF depend somewhat on the actual
technology library you use, and might depend on the version of our software.
The SDF we write out is 2.1 compliant, but VITAL level 0 (perhaps 1 as well)
has not necessarily a one on one relationship with the SDF. Your VITAL lib
might not fully support SDF v2.1.
- Laurens Drost
Synopsys (Northern Europe) Ltd. Reading, UK
---- ---- ---- ---- ---- ---- ----
From: Kyungjin Jang <sandrose@phoenix.dwe.co.kr>
I confronted similar problem. I used Synopsys's DesignPower to estimate of
power of the chip. When I compiled the VITAL internal memory libary of STM
by VSS, such as lines made errors.
==> VITAL Entity 'FIFO_94X16' has VITAL conformance error(s):
TPD_OE_Q : VitalDealyArrayType01z(7 downto 0) := (others =>
^
**Error: vhdlan,2148 FIFO_94x16_ent.vhd(20):
The type of a scalar timing generic parameter 'TPD_OE_Q' does not
match the type of the associated ports.
Other man who compiled by Cadence Leapfrog said he didn't have such error.
I could escape the error by changing the name TPD_CK_Q => aTPD_CK_Q. I
don't kwow why such error, but after changing it compiled well. Maybe the
name was a reserved word of VSS? So, in my opinion, you may avoid error by
changing names... Is there a person who knows the reason of my case?
- Kyungjin Jang
Daewoo Electronics Korea
---- ---- ---- ---- ---- ---- ----
From: alex_schreiber@my-dejanews.com
Kyungjin,
I guess, that something in your FIFO model is not correct. In the VITAL
standard the width of the type is defined like follows (types as example):
Case 1: at least one port is bus
--------------------------------
tpd_<Input_Port>_<Output_Port> : VitalDelayArrayType01Z(0 to
((width_Input * width_Output)-1))
Case 2: both ports are pins
---------------------------
tpd_<Input_Port>_<Output_Port> : VitalDelayType01Z(0 to
(width_Output-1))
Please check in your FIFO model if the ports (in the entity) are defined
correctly:
OE : std_logic
Q : std_logic_vector(7 downto 0)
By changing the name
TPD_OE_Q => aTPD_OE_Q
you excluded the generic (it's no more a VITAL generic) from the conformance
check of the VHDL compiler. Because of this you do not get any error
anymore. BUT you excluded it from backannotation as well. When you try
to read in a SDF file, you will get an error of missing generic as well.
- Alex Schreiber
|
|
