( ESNUG 390 Item 1 ) --------------------------------------------- [03/20/02]
Subject: ( ESNUG 389 #2 ) PhysOpt def2pdef Chokes On Already Routed DEF 5.3
> I have this problem while trying to convert the routed DEF (from SE-Ultra,
> after CTgen and Wroute) to PDEF with the def2pdef I get the following:
>
> Warning: Detect syntax error near token '*' at line 415183. Continue to
> parse until the next correct rule can be applied. (DEFIN-16)
> Warning: Probably the special wiring continue point has incorrect
> syntax. (DEFIN-20)
>
> Those lines in the DEF are net routing information:
>
> - weim_lba_b ( PIN weim_lba_b ) ( z497 x )
> + ROUTED m1 ( 4329800 574150 ) via1 ( * * 500 ) ( 4351200 * 500 ) via2
> ( * * 550 ) ( * 576650 550 ) via3 ( * * 550 ) ( 4352600 * ) ;
>
> Any ideas anyone? The .DEF version is 5.3
>
> - Ofer Paperni
> Motorola Semiconductor Israel
From: [ This Little Piggy Ate Roast Beef ]
John, I work at a competitor of both Cadence and Synopsys. Please keep me
anon here because my boss doesn't like it when I tell the truth.
I am glad to see that Cadence continues to come up with variations of their
DEF syntax, despite any other EDA vendor's efforts to parse their already
ambiguous "standard". As the guy who writes our parser, it's always amusing
to see new variations come up, and new places where Cadence directly violate
either what they say is correct DEF or alternatively make version X of DEF
incompatible with version X-1. You can also detect deliberate attemtps to
make LEF/DEF impossible to parse with lex/yacc, although they haven't
defeated me yet!
What Ofer's problem wiring MEANS is as follows:
"Start on metal 1 at (x1,y1) place a via to metal 2 at that position
but a positive end extension on the track of 500 nm at that point,
then go on metal2 to (x2,y1) and end extend that segment by 500 nm in
the direction of travel, then put a via in up to metal 3 with an
extension of 550nm and route to (x2,y2) with an extension of 550 nm
then go to metal4 and route to (x3,y2)"
What I believe is barfing the PhysOpt def2pdef parser is Ofer's/SE-Ultra's
"viaM ( * * N )" syntax. Normally you only ever have "( x * N )" or
"( * y N )" statements to say the next point has the same x but different y
as the previous point, and to overshoot the end point by N so as to satisfy
end extension rules for via coverage (due to sub-wavelength effects).
Normally you don't give a position just after a via but this is needed here
in order to extend the start of the attached track.
The PhysOpt def2pdef converter may just not cope with end extensions. If it
CAN cope with the extensions but not with the ( * * N ) syntax, then use
your favorite language (Perl/Awk/Python/Tcl) to change each occurence to the
"NEW mP ( x y N )" syntax ( i.e. starting a new path with an extension at the
start.) Unfortunately this is a tad tricky because you need to know which
layer you are starting on and what the current coordinate is. I give below
the desired result, but I cannot guarantee that the script to do it is easy!
What was:
- weim_lba_b ( PIN weim_lba_b ) ( z497 x )
+ ROUTED m1 ( 4329800 574150 )
via1 ( * * 500 ) ( 4351200 * 500 )
via2 ( * * 550 ) ( * 576650 550 )
via3 ( * * 550 ) ( 4352600 * ) ;
Should become :
- weim_lba_b ( PIN weim_lba_b ) ( z497 x )
+ ROUTED m1 ( 4329800 574150 )
via1 NEW m2 ( 4329800 574150 500 ) ( 4351200 * 500 )
via2 NEW m3 ( 4351200 574150 550 ) ( * 576650 550 )
via3 NEW m4 ( 4351200 576650 550 ) ( 4352600 * ) ;
I hope this helps. Basically it comes down to:
1) get Synopsys to update def2pdef. (Good luck!)
2) get Cadence to be a little more open about the current syntax
for LEF/DEF. (Even harder!!)
Good luck.
- [ This Little Piggy Ate Roast Beef ]
---- ---- ---- ---- ---- ---- ----
From: Michael Stabenfeldt <stabie@stabie-soft.com>
Hi, John,
I believe the PhysOpt DEF 5.3 problem is the variable extension syntax. The
+ ROUTED m1 ( 4329800 574150 ) via1 ( * * 500 ) ( 4351200 * 500 ) via2
says extend the metal 2 500 database units before beginning and 500 database
units after 4351200 574150. The variable extension stuff is not used that
frequently. The reason I know this is I got bit by the same problem on the
Verilog reader in my software. Fortunately, my database supported variable
length extensions, so it was an easy fix. I wonder if Synopsys has that
notion...
- Mike Stabenfeldt
Stabie-Soft, Inc. Austin, TX
|
|
