( Post 117 Item 1 ) --------------------------------------------------------
From: rhughson@wellfleet.com (Richard Hughson)
Subject: Characterize Function (or Misfunction)
I've been using a methodology with uses the characterize/write_script
commands to create constraint files for my leaf modules. After
investigating the contents of the write_script output files and
cross-referencing them to each other, I've discovered something
disturbing. I'll describe the processes and then the results.
Process:
1. Compile all leaf modules using a set of generic constraints.
An example of the generic constraints are:
set_arrival 20 all combinational inputs
set_arrival 6 all registered input
max_delay 10 all combinational output
max_delay 6 all registered output
max_period 30 clk
as well as standard drive and load attributes
and the other necessary clock attributes/constraints.
These constraints provide a quick and easy starting point.
2. Once all leaf module are compiled, I read in the top level
design, link all, and characterize all leaf modules. After
characterization is complete, write_script produces constraint
files that will be used for future compiles.
Results:
Suppose for this example a design exists of two leaf modules, A and B.
Module A has an output "net01" which feeds an input to module B.
After the first compile which uses the generic constraints, net01
has a maximum delay of 13ns out of module A. After the generic compile
of B, it is reported that net01 is required to be at the port
by 19ns in order to make set-up time to an internal register.
At this point things are great. I've got 6ns of slack. Here is the problem.
It seems that when characterizing net01 on module A, it sees that module B
only needs the signal to be available by 19ns and therefore places a
"max_delay 19 net01" constraint on module A. Likewise, when characterizing
module B, a "set_arrival 13 net01" attribute is assigned. If a compile is
executed with using these write_script constraint files, each leaf can
pass without any violations but the top level design will have up to a 6ns
violation.
The characterize command should not assign constaints/attributes which will
violate the "max_period" constraint!
If other users have seen this same behavior, I'd like to hear what solutions
have been found. If we are all "just living with it," maybe we ought to
inform Synopsys of this issue.
- Richard Hughson, Wellfleet Communications
( Post 117 Item 2 ) --------------------------------------------------------
From: sgolson@trilobyte.com (Steve Golson)
Subject: One Can't Have a Library Cell with Pin Name 'NS'
I'm using Synopsys 3.0a on SPARC under SunOS 4.1.3.
If you try to build a library cell using Library Compiler, and one of your pin
names is 'NS', then the library gets built fine. However if you instantiate
this cell, and try to link it, you get the following error message:
Error: Can't find input port 'NS' on reference to 'FOO' in 'test'. (LINK-1)
It turns out that 'NS' is a reserved word. According to Synopsys, 'NS' or 'ns'
means nanoseconds and is used in the predefined physical type TIME. Ergo, you
can't use it as a pin name.
I haven't been able to find any listing of these reserved words anywhere in
the manuals. Does anybody know what *other* words are reserved?
- Steve Golson, Trilobyte Systems, Carlisle, MA
( Post 117 Item 3 ) --------------------------------------------------------
From: [A User]
Subject: Back Annotation from Synopsys to Verilog
Hi, John:
Please make this posting anonymous.
I'd like to know if there is any people out there have ever tried to generate
the pre-layout SDF file from Synopsys 3.0a and then back annotate to the
Verilog environment.
According to my understanding, this can be done with the following steps:
1. in Synopsys: write_timing -format sdf -output xxx.sdf -context verilog
2. in Verilog: add the following lines to the system simulation level of the
verilog source code:
initial begin
$timeformat(-9, 2, " ns", 20);
$sdf_annotate("xxx.sdf", system,,, "MAXIMUM", "1.0:1.0:1.0", "FROM_MTM");
end
However, the verilog annotator failed to finish the annotation. I'm pretty
sure that I used the correct scope because otherwise the annotator would
complain about instance not found.
Here's what I get from the run:
Configuring for back-annotation...
Reading SDF file and back-annotating timing data...
WARNING - Hierarchy divider in SDF is being mapped to `.'
SDFA ERROR - error annotating to MIPD
SDFA ERROR - error encountered during timing annotation of instance top
SDFA ERROR - error encountered during timing annotation - back-annotation
terminated
Can anyone help me?
|
|
