( ESNUG 225 Item 4 ) ---------------------------------------------- [8/24/95]
Subject: ( ESNUG 224 #4 ) Critiques Of The Synopsys Scripting Language
>I rather disagree with the semantics of the Synopsys scripting language.
>The typing rules are complex and obscure. The correct working of commands
>is sometimes a matter of trial-and-error, even for the hotline staff. The
>understanding of some types is difficult, (e.g. can somebody tell the exact
>distinction between a design, a cell and a reference?) Attributes are
>indispensable for making scripts do what you want, but it is often unclear
>at what moment they are set by the tool. Is an attribute set after reading
>the database, after elaboration or after compilation? If it is set for a
>reference, is it also set for a cell? Some attributes appear to be set only
>after seamingly unrelated commands. User-defined variables often must be
>type cast by a find command, but if this is obligatory again is a matter of
>trial-and-error. Between different versions of the tool the rules appear
>to change, so my scripts maybe will not work in the next release.
From: hill@synnet.com (Shannon Hill)
Hey, John,
I must agree with W. Boeke's view of dc_shell's scripting language expressed
in ESNUG 224 Item 4... I'm always surprised by the its rules and how long it
takes to get moderately complicated recipes working correctly. To prove my
point, I'll ask ESNUG readers: "How long does it take you to figure out why
the following line has a syntax error in dc_shell script-land??"
dc_shell>dat_clock_pin = find(pin,*MEM*DAT*REG*/CK, -hierarchy )
- Shannon Hill
3COM Switching Division
|
|
