( Post 115 Item 1 ) --------------------------------------------------------
From: "Bradshaw, Lee" <LBradshaw@engineer.clemsonsc.NCR.COM>
Subject: (Re: Post 114 Item 4) "Multi-Cycle State Machine Synthesis"
> after REQ is asserted, the hazard in the combinatorial circuitry while REQ
> going from 0 -> 1 may cause ACK and ACK* to temporarily not have opposite
> values; this would clobber the next-state logic.
>
> I have a couple of questions for Synopsys users. Is this scenario even
> possible? If so, are there ways to detect it and correct it?
Yes, this is a problem. We have seen generated circuits which could fail on
real parts. Synopsys seems intent on ignoring it -- we haven't gotten a
good response in two years. One way to fix the problem is to instantiate an
and gate to block the changing signal. One input is ACK (the changing
signal), the other is a decode from your state machine which guarantees ACK
is stable. We generally use "dt_" as a prefix to the gate name and have
"dont_touch dt_*" in our script file. This does create a problem of having
vendor parts in what should be portable code.
With 3.0, you can modify the method slightly. You can instantiate an "and"
gate (GTECH_AND2) from the generic library (gtech.db), and use the map_only
attribute. Use the prefix "smo_" and the command "set_map_only smo_*". The
map_only attribute tells compile to attempt to find a one-to-one match for
the generic part functionality in the target library. The cell which is
instantiated will not be modified by logic optimization. This will let you
compile to any vendor library without changing your source code or translating.
The problem with this new method is that you must create a Verilog module to
describe the functionality of any generic parts you instantiate. Of course,
for GTECH_AND2 you only have to map the pins to a Verilog primitive and.
But if everyone who wants to write more vendor independent code uses this
method, there will be many people writing multiple versions of the same
model. There would be far fewer hours spent if Synopsys would provide
models with their generic libraries. Someone should mention this at SNUG.
One of the main advantages of the Synopsys tools is vendor independence.
They may be happy to provide these libraries.
lee.bradshaw@clemsonsc.ncr.com
( Post 115 Item 2 ) --------------------------------------------------------
From: sgolson@trilobyte.com (Steve Golson)
Subject: Library Compiler 3.0a: sub_symbol Doesn't Rotate as Described
I'm using Synopsys 3.0a on SPARC under SunOS 4.1.3.
Page 4-18 of the Library Compiler Reference Manual gives the syntax of
sub_symbol as follows:
sub_symbol ( symbol_name, x, y, r ) ;
where "The r value is the angle of rotation, from 0 to 360 degrees."
Actually, an r value of "1" gives you a rotation of 90 degrees,
an r value of "2" gives you a rotation of 180 degrees,
an r value of "3" gives you a rotation of 270 degrees, etc.
It's not clear whether this is a software bug or a documentation bug.
Steve Golson -- Trilobyte Systems -- Carlisle MA -- sgolson@trilobyte.com
( Post 115 Item 3 ) --------------------------------------------------------
From: knight@acuson.com (Jon Knight)
Subject: Can't Get Synopsys to Use Wider Gates
We are trying to implement a synthesized look-up table, but the results from
Synopsys contain an extremely high percentage of 2-input gates. Our vendor
has found this to be unroutable. Is there a way to force Synopsys to use wide
input gates (a PLA-like structure) without a 'don't use' on the 2-input gates?
J. Knight, Acuson
( Post 115 Item 4 ) --------------------------------------------------------
From: jim@deming.b11.ingr.com (James Deming)
Subject: Semi-Static Register Values
One of my modules produce combinational outputs based on the
value of some mode registers, some data path registers, and the current
state of the machine. The mode registers do not change value for many
clocks before the module outputs are needed. The data path registers
may change value on the same clock the output must be valid, or they
may be valid any number of clocks before hand. The current state
changes every clock.
For example:
o1 = f(m,d);
o2 = g(m,d) & (s == 2);
where:
m = mode register values
d = data path register values
s = current state
f(m,d) = some arbitrary function of m and d
g(m,d) = some arbitrary function of m and d
and
o1 must be valid on every clock
o2 must be valid only in state 2.
If I specify the arrival times of all the inputs based on the
clock-to-out of the registers that drive them, Synopsys can not
synthesize the circuit within the constraints. It assumes that the mode
inputs create the worst case path, even though the mode registers are
valid long before the outputs need to be valid. (If I specify negative
arrival times for these inputs, Synopsys adds delay to fix bogus hold
time violations.)
I have used "disable_timing" on the mode inputs, but this fixes
only half the problem. In the case of output o2, Synopsys can not meet
the constraints due to the data path inputs. But o2 is only valid when
the machine is in state 2, and the data path inputs have been valid for
at least two clocks. If I "disable_timing" on the data path inputs,
then output o1 may not be optimized to meet its contsraints.
What is the best way to tell Synopsys how these inputs function
when the module is compiled alone, and when it is instantiated in the
complete circuit?
Jim Deming
Intergraph Corporation, Huntsville Alabama
( Post 115 Networking Section ) ---------------------------------------------
AMD, Austin TX, Logic Synthesis Apps. Eng. to participate in designs applying
Synopsys tools. Design experience required. Email: rajiv@dvorak.amd.com.
|
|
