Reminder: To get back ESNUG posts, e-mail "khaddock@intellitech.com"
(Kareen Haddock) the following:
NAME:
COMPANY NAME:
ADDRESS 1:
ADDRESS 2:
ADDRESS 3:
CITY, STATE, ZIP:
BUS. PH:
BUS. FX:
EMAIL ADDRESS:
ESNUG POSTS:
example,
NAME: Kareen Haddock
COMPANY NAME: Intellitech Corp.
ADDRESS 1: 66 Route 25
ADDRESS 2:
ADDRESS 3:
CITY, STATE, ZIP: Meredith, NH 03253
BUS. PH: 603-279-6308
BUS. FX: 603-279-5135
EMAIL ADDRESS: khaddock@intellitech.com
ESNUG POSTS: 59,65-75
Kareen Haddock will send the posts as one large text file that you can cut
into seperate posts if you wish. The first archived post is ESNUG 40.
- John Cooley
ESNUG Moderator
( ESNUG 127 #1 ) ------------------------------------------------------------
From: lewis@protocol.zycad.com (Jim Lewis)
Subject: (ESNUG 126 #3) "2.2b write_script Crash"
>From: Steve DeGroof <steve@sun1.atitech.ca>
>I've been having trouble with the 'write_script' command. If I 'characterize'
>a block that has more than one unconnected input, and do a 'write_script' for
>that block, Synopsys crashes. (this is v2.2b)
>
>Anyone else run across this problem?
>From: jcooley@world.std.com (John Cooley)
>Yes, Steve, I've seen that one myself. What's going on is that Synopsys
>sees the unconnected outputs as equivalents and seems to dislike this
>a lot. If you look at the file written out by the write_script, it died
>immediately after writing something like "set_equal port_one port_two"
>where port_one and port_two are the unconnected ports.
>
>This also happens if you try to a write_script on a module with two or more
>constant inputs (like having them all tied to logic high) or designs with two
>or more unconnected inputs (because they all default to the same logic value.)
As John said the problem seems to occur when there are more pins on the
cell than nets connecting to it.
We noticed that if you did not use the "-connections" switch on
characterize that the write_script would not fail. That is not really a
solution to me.
In 2.2b the following fixed the problem. It seems that
when you group a design there will be one input for each
net connected to the design and any constants that were connected
to the cell will be contained within the grouped design. Assuming
the name of your original design was BLOCK1, the following group
command will accomplish this:
group BLOCK1 -design_name NEW_BLOCK1 -cell_name I_NEW_BLOCK1
To complete the solution / workaround, ungroup the logic in
NEW_BLOCK1. This way you don't increase the number of blocks in
your design.
current_design = NEW_BLOCK1
ungroup -all -flatten
Regards,
- Jim Lewis
Zycad/Protocol, Design Services
[ Editor's Note: Jim mentioned that refraining from using the
"-connections" switch in characterizing was an unacceptable
solution. Here's why: by not using this switch, you are disabling
a whole class of constraints being characterized to the lower
level modules. For more info, read ESNUG 91 "How 'characterize'
Command Really Works." - John ]
( ESNUG 127 #2 ) ------------------------------------------------------------
From: nguyen@ATK.COM (ba nguyen)
Subject: New User / Possible Bug
Hello,
I am a relatively new Synopsys user and I think I might have found a bug.
After applying fix_hold to all clocks, I used the command:
"compile -prioritize_min_paths -only_design_rules"
to fix only hold violations. After the compilation was done, the command
"report_constraints -all_violators -verbose"
shows that there are still hold violations in the design. Any explanation
on this problem would be appreciated. Thanks.
( ESNUG 127 #3) ------------------------------------------------------------
From: cindy@zoran.hellnet.org (Cindy Eisner)
Subject: (ESNUG 125 # 2) Re: "Seeking Spare Gate Methodologies"
> From: lewis@zycad.protocol.com (Jim LEWIS)
> Subject: (Post 120 Item 2) "Seeking Spare Gate Methodologies"
>
> I see there being a couple of possiblities as to what the
> problem is in trying to create a spare gate methodology.
>
> In general if you want an instanciated library cell to
> remain when reading and compiling you may put a dont_touch on
> the library cell. The hazzard of doing this is that wherever
> this cell is used (instanciated or mapped by design compiler)
> it will be dont_touched (and as a result not removed). Two passes
> can solve this type of a problem. The first pass dont_touch the
> library cell. The second pass remove the dont_touch attribute
> from everything except the cell you want it on.
this is a very roundabout way to get an instanciated library cell to
stay around. much simpler is just to dont_touch the instance name,
so that instead of:
> dont_touch find( cell, act2_22.db:act2/INVA )
you have:
dont_touch act2/i1
dont_touch act2/i2
etc. if you use some kind of naming convention, then you can do something
like:
dont_touch act2/i*
- Cindy Eisner, CAD group,
Zoran Microelectronics LTD,
Advanced Technology Center
( ESNUG 127 #4) ------------------------------------------------------------
From: uunet!jericho!gord (Gord Wait)
Subject: Q_Bar pins on DFFs
I thought I'd seen this mentioned before, but I can't find it:
How do you get Synopsys (3.0x) to utilize the q bar pin of a d flip flop?
Or can you? I made a simple test module in Verilog, with both q and q_bar
outs, but Synopsys ignored the q_bar pin from the library part, and
just added an inverter to the q output. Kind of a pain.
Any suggestions besides hand instantiating? I wouldn't bother
hand instantiating them at this point. I prefer wasting a gate
to remain portable...
- Gord Wait, S-MOS Systems, Vancouver Design Center
|
|
