Kudos to Bob Dilly for responding in ESNUG Post 336 (came out today) to the
issue of constraint interoperability. A nice tie in to the DCDL effort was
presented.
---------------
( ESNUG 336 Item 7 ) -------------------------------------------- [11/11/99]
Subject: ( ESNUG 331 #7 333 #7 ) IBM Has Similar Interoperability Issues
> 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
From: Bob Dilly <dilly@us.ibm.com>
John -
At IBM we are running into similar "translation" issues as Nir and London
cite. Our "backend processing" is based on EinsTimer, our IBM-developed
timing engine, and years of scripts that help us close timing here. As our
customers exploit the range of commands available in various timing tools,
we are finding that translation is becoming more of a challenge.
Like Nir, we are developing translators but find that its difficult because
various tools model timing differently, using concepts which sometimes
don't "map" readily between tools. To try to get out from under this
"translation" burden, we've been investing in an emerging standard for
design contraints. We participated in a demonstration at DAC this year,
using a subset of DCDL to exchange constraints between several vendor's
tools.
Although it doesn't solve Eran's issue today, we're working towards having
a good chunk of the timing portion of the standard out by early next year.
The web site is: http://www.vhdl.org/dcwg/
I think I can speak for the working group in that we'd be happy to have
others join us in hammering out a workable standard.
- Bob Dilly
IBM Microelectronics Burlington, VT
-- ------------------------------------------------------------------- Tom Dewey | Phone: (503) 685-1417 Technical Marketing Engineer | Email: tom_dewey@mentor.com Strategic Partnerships & Alliances | FAX: (503) 685-1268 Mentor Graphics Corporation | Web: www.mentor.com/partners