Stats

  • Locked Locked
  • Replies 3
  • Subscribers 164
  • Views 15140
  • Members are here 0
More Content
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Signames on pins? How do I get rid of them? (You will want to read this!)

Mike Veal

Hi all,

It appears that Allegro HDL has started assigning invisible signal_name properties to pins of bodies.

I believe this is a REALLY bad idea.  It is perfectly reasonable for example to copy a resistor already on your schematic. However, if you do so, the invisible signal_name prop will also get copied and you generate an invisible short between the pins of the two independant resistors.

We have a schematic where this has happened in at least one place.

OK, so having defined the problem, I wrote the following script to remove these pesky sig_name props:

 Method #1:

set nextgroup a
find sig_name
set nextgroup b
select wi all
include properties
exclude a b
del a

wr

 

(Change "del a"  to "dis bot a <<CR>> dis 6 a" to show this problem on your schematic, without changing anything).

The script runs fine, finds all the unwanted sig_name props and deletes them. Then, when it hits the "wr" the tool puts them all back, exactly as before. So I tried a different route.

Method #2:

Type "attr" on the command line, and click on an offending pin. In the pop up window, highlight the sig_name property line & click delete to remove it. Save the design via a quick "wr" et voila, the offending sig_name properties do not re-appear.

The disadvantage with this technique is that I feel it's going to be a bit tedious on our 160 page design.

 

Does anybody understand why method #2 works whereas method #1 doesn't?

Can anybody provide hints on how to create a script that will work?

 

Many thanks,

Mike.

  • BrynH

     Hi Mike,

    I'm using DEHDL 16.2 and I've tried to replicate this problem. See attached screenshot.

    In this example I placed and connected R1 and R2 and could then view the SIG_NAMEs UN$1$RES$I16$A/B

    I then replicated R1 (using copy-all) as R3 and R4, connected R3 and R4 together and could see the SIG_NAMEs UN$1$RES$I18$A/B

    It appears that whilst the SIG_NAME property is present, it has been assigned a new instance name when the component has been copied.

    Note, we are using our own resistor library rather than the standard Cadence library.

    Let me know if you'd like me to try anything else out.

    Cheers

    Bryn 

     

  • Mike Veal

     Hi Bryn,

    I'll freely admit that I don't understand the exact mechanism for creating shorts like this. If my example of copying a component doesn't do it, that is good news. But the fact remains that I have a short in my schematic (and worse, on my prototype hardware) generated because Cadence has decided to attach sig_names to component pins.

     

     Please see the attached bitmap. It shows a short between two pins generated by the tool

     

    If a schematic has SIG_NAME properties attached to anything other than wires then it's associated netlist simply cannot be trusted.

     

    I still need to know, how can I remove these with a script, or even better, how do I turn this behaviour off?

    For info, I'm running 16.1p004.

     Best regards,

  • summer07

    Hi MIke,

    I've tried this on both 16.1-s036 (1/5/2009)  and 16.2-s010 on WinXP, and both releases behave similar to what Bryn described, that is, even though the invisible sig_name props are on the pins, the tool makes them unique when I do a write.

    The invisible sig_name prop (for unnamed nets) on pins has been around for quite a while - at least as far back as release 15.7. When working properly, the tool is supposed to make the names unique so that you don't get a short as you have described.  Have you applied the latest patches?  Maybe it is already fixed.

    I think it would be futile to remove these sig_name properties.  The reason is that when I use your method#2 (select the pins and delete the properties manually), the sig_name re-appear when I do a save, so this seems to be the intended behavior.  Not sure why method#2 works for you - maybe because we are at different patch levels?  Anyway, maybe you could  write a script with Concept-Skill to find the sig_name attached to pins and check to see if any of them are the same and catch the problem this way.

    Best regards

     

     

Cadence Guidelines

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.