( ESNUG 330 Item 8 ) --------------------------------------------- [9/30/99]
Subject: ( ESNUG 329 #17 ) Cadence 'Pearl' & DC Just *Won't* Play Nice
> I would like to ask a question. We, Chip Express are an ASIC vendor. We
> are now in the process of developing a layout flow that is using Timing
> Driven Q-place placement software from Cadence. Being timing-driven, the
> software reads constraint files produced by, you guessed it -- Synopsys.
>
> The tool that reads and converts the constraint file is: Pearl (Cadence
> static timing analysis tool). We are receiving Synopsys constraint files
> from various Synopsys versions. Almost each time we use Pearl there are
> statements that are not recognised by the tool, and causes it to produce
> erroneous output.
> The only thing we can do is manually change the constraint file, and try
> again. As I said, we get different "types" of constraint files, depending
> on the Synopsys version used. Does anyone know of a formal / informal way
> to overcome this problem ?
>
> - Eran Rotem
> Chip Express (Israel) Ltd. Haifa, Israel
From: Frank Emnett <frank@aiec.com>
Eran,
Have you tried the write_script command in Synopsys? It might help
eliminate some of the variance in constraint types. We are trying it as
an interface to Cadence tools (SE-DSM), where it gets converted to GCF.
- Frank Emnett
Automotive Integrated Electronics Corp. Phoenix, AZ
---- ---- ---- ---- ---- ---- ----
From: London Jin <londonj@eng.adaptec.com>
Hi John,
I share Eran's pain. Using Synopsys' constraints and applying them to
Cadence does not work well because Synopsys does not tell Cadence what
changes down the road, and Cadence does not keep pace with every Synopsys
version upgrade. As a result, the TDL flow is full of issues, and does not
produce promising results.
Issue #1. Before 1998.02, in "set_false_path -through {A B}", A, B are
considered as AND relation in Synopsys. This is what Cadence
has supported. However, Synopsys changed from the AND relation
to the OR relation in 1998.02 and Cadence remains unchanged as
of today. To make it backward compatible, Synopsys has a
variable you can set: set timing_through_compatibility "true"
If you are not aware of it, your timing exceptions are incorrect
in Cadence.
Issue #2. Cadence does not support multiple -through as of today.
Both issues above introduce errors in timing constraints. I am not excited
about TDL. Do you have any successful cases?
- London Jin
Adaptec Milpitas, CA
---- ---- ---- ---- ---- ---- ----
From: Nir Sever <nir@gigapixel.com>
Hi John,
The problem Eran is facing is what I consider today to be my biggest problem
in setting up Timing Driven design flows, using different tool vendors.
I've been working with some EDA companies developing timing driven back-end
tools (floorplanners and P&R) and it seems like everyone is having its own
constraints format. Even worse, everyone supports different types of
constraints. Since Synopsys is the source for the constraints, you need to
translate from Synopsys to everyone else's format, and try to restrict the
design to use just the constraints your tool vendor can support.
For example, in Synopsys you can define multi-cycle path with -through
attribute. This can be translated to GCF (allthough not with the Cadence
supplied translator), but Pearl doesn't support this so basically you can't
use this constraint to drive Qplace. My conclusion:
1. Write your own translator(s) (I did...)
2. Restrict your designers to constraints that are translatable (I
know it's easier for me than it is to you).
3. When you have a certain structure that requires more complicated
constraints (I have an AGP/PCI combo block with very complicated
constraints), take it out of the "big chunk" and use the SDF Path
Constraints for it.
Best Regards,
- Nir Sever
GigaPixel Corp. Santa Clara, CA
|
|
