( ESNUG 209 Item 2 ) ---------------------------------------------- [2/1/95]

From: [ Anon. ]
Subject: Synopsys/Mentor Interaction Causing Shorts On The *SAME* Bus

Hi John!

We've never met but I feel I know ya after cruising through the ESNUG
postings.  Just for grins (or at least until I clear it with my boss)
ya better keep me anonymous also.

From what I understand concerning the Mentor/Synopsys interface people are
talking about a "physical" short that occurs because Mentor and Synopsys
handle bus rippers differently.  When the schematic is transferred across, it
is not in a "netlist" format but in a graphical format (i.e.  Draw line from
point A to point B.  Place ripper at location x,y.  Draw line from C to D).
If line CD happens to intersect the end of the ripper (which are sometimes
different sizes in the two libraries) Mentor treats it as a short.

The problem that I am having is not as subtle.  When I run change_names with
the rules that are spelled out in the answer that I got back from SolvIt,
change_names actually "Warns" me that it is changing bus members.  It seems
that if there are any unused bits in the bus it shuffles the other bits "up"
to fill in the gaps.  Thus, if you have a bus A(1:0) and within the block
only use A(0) it "changes" the net name of the net after the ripper to A(1).
Then it realizes that A(1) already exists and so it, using its naming
convention, appends a 1 on the end of the name so as to make it unique, thus
you have A(1)1.  So on one side of the ripper you have A(1:0) and on the
other A(1)1.  Of course, Mentor looks at the name, sees the closed parenthesis
and says "Ah ha!, I have a schematic that has on one side of a ripper A(1:0)
and on the other A(1) but the "rule" property on the ripper is specifying
that this is bit 0.  Therefore, there is a short between A(1) and A(0)!

BTW, I am using 3.1b (historic reasons; not due to any loyalty) and sent a
test case that displays this action to the Synopsys support center.  Also my
"local" AE came up with a workaround which is to define a second set of name
rules that contains only the rule equal_port_nets (which is in the original
rule set).  Running change_name a second time using this second rule set
magically "straightens" things out but I am not impressed.  I want to know
what it is doing.

  - [ Anon. ]



 Sign up for the DeepChip newsletter.
Email
 Read what EDA tool users really think.


Feedback About Wiretaps ESNUGs SIGN UP! Downloads Trip Reports Advertise

"Relax. This is a discussion. Anything said here is just one engineer's opinion. Email in your dissenting letter and it'll be published, too."
This Web Site Is Modified Every 2-3 Days
Copyright 1991-2024 John Cooley.  All Rights Reserved.
| Contact John Cooley | Webmaster | Legal | Feedback Form |

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)