>From: gderti@dtc.Kodak.COM (Gzim Derti)
>Subject: "The Origins of ESNUG" Article in this month's ASIC & EDA
>
>Hi John - just a note to let you know that it's nice to see what someone
>who has provided such a great service to the engineering community et al,
>looks like. Nice article, nice sheep, also neat to know all the problems
>and headaches you had to go through to get the group put together.
>
> - Gzim Derti (say Zim Dair-tee)((aren't parents wonderful!?!?))
> Eastman Kodak Company
Thanks, Gzim. Starting ESNUG was easy. The hard part was surviving the
lawyers, the initial user apathy, getting the word out to Synopsys R & D,
internal corporate politics, external corporate politics and just
tirelessly selling the idea such that everyone sees how they win with
ESNUG. But I never lose sight of the real reason why ESNUG works. It's
because of the many contributors who understand that sharing bugs,
workarounds and experiences actually serves their own enlightened self
interest in the long run. For those who take the time to write up and send
items for ESNUG, I thank you. You're the real reason why this works.
- John Cooley
the ESNUG guy
( ESNUG 153 Item 1 ) ---------------------------------------------- [10/5/93]
From: Ken.Kappeler@FtCollinsCO.NCR.COM
Subject: (ESNUG 151 #4 & 152 #3) "More On Clock Trees"
>The primary concern in clock synthesis, whether the drive is centralized or
>localized, is end-to-end clock skew. It is especially important in
>asynchronous designs, scan/atpg designs and designs with multiple clock
>zones.
>
>Personally, given the garbage that I have seen out of Synopsys for synthesis,
>I would be scared to death to let Synopsys generate any type of clock tree.
>
>That's all I can say on this topic. I suggest you interrogate your vendor
>closely.
I am responsible for developing Synopsys technology files at NCR. We do not
recommend using the Synopsys clock tree synthesis capability for the simple
reason that it has no correlation to silicon. And while I have not studied
their algorithms, preliminary information indicates that their trees are
neither balanced nor optimal. We provide a our own in-house balanced clock
tree synthesis tool which generates a Synopsys timing model as well as a
balanced clock tree. Then in layout we route this clock tree. So what you
get back from layout matches your synthesis and simulation timing. I would
hope other ASIC vendors do a similar thing.
- Ken Kappeler
NCR Microelectronic Products
( ESNUG 153 Item 2 ) ---------------------------------------------- [10/5/93]
From: victor@boiler.truevision.com (Victor J. Duvanenko)
Subject: VHDL-Compiler License Troubles Leads To Sporadic Resource Allocation
John,
With version 2.2 synthesizer we used to be able to have multiple synthesis
licenses (Design-Compiler) and one VHDL-Compiler license. When you launched
a synthesis job, the script would wait until a VHDL-Compiler license was
available, then grab it, use it and let it go when it was done. Then the
VHDL code would be synthesized.
This is no longer true with version 3.0. Version 3.0 compile command
checks out a VHDL-Compiler license during the "Resource Allocation" step
of the 'compile'. Then does not give the license up when it is done. What's
even worse is that the Resource Allocation may or may not happen depending on
whether the resouce is already in your 3.0 resouce cache or not. So, you can
no longer get along with one VHDL-Compiler license.
Also, this behavior of checking out a VHDL-License may appear sporadic,
since a VHDL-Compiler license is checked out only if the resouce is not in
your personal resource-cache. This is definitely a bug by this users
standards!
- Victor J. Duvanenko
Truevision
[ Editor's Note: The hotline confirms that this has been found to be a
real bug and that Synopsys R & D is looking into it. - John ]
( ESNUG 153 Item 3 ) ---------------------------------------------- [10/5/93]
From: uunet!uranus!splinter!flieder (Jeff Flieder)
Subject: (ESNUG 137 & 152 #4) FSV Script and 2-D Verilog Busses
>Original Synopsys gate level verilog:
>
> MYFF \Reg_reg[2][11] ( .Q(\Reg[2][11] ), .D(n2969), .CK(Clock) );
>
>After FSV:
>
> MYFF Reg_reg_2 ( .Q(Reg_reg_Q[2][11] ), .D(n2969), .CK(Clock) );
>
>Should be something like:
>
> MYFF Reg_reg_2_11 ( .Q(Reg_reg_Q[2][11] ), .D(n2969), .CK(Clock) );
> ^^^
>because otherwise \Reg_reg[2][11] equals \Reg_reg[2][12] after FSV. ( i.e.
>they would both be translated to "Reg_reg_2". )
I agree with Greg that there is a bug in FSV with the renaming of register
files, but the syntax he proposes for the bus is not legal Verilog syntax.
You cannot have two dimensional busses.
MYFF Reg_reg_2_11 ( .Q(Reg_reg_Q[2][11] ), .D(n2969), .CK(Clock) );
^^^^ ^^^^^^^
This is OK This is not OK
I am not sure how to fix this so that all busses will be unique. Any
suggestions you would be appreciated. I would be happy to fix the code to
handle this, I am just not sure how to do it. One idea is:
MYFF Reg_reg_2_11 ( .Q(Reg_reg_Q_2[11] ), .D(n2969), .CK(Clock) );
If this is acceptable to the FSV community (such as it is), please let me
know and I can make this change and post the new version to ESNUG. Thanx for
the input.
- Jeff Flieder
Ford Microelectronics
( ESNUG 153 Item 4 ) ---------------------------------------------- [10/5/93]
Subject: (ESNUG 150 #1 152 #2) "Understanding 'set_clock_skew -uncertainty'"
>> I don't quite get the results of using the set_clock_skew -uncertainty...
>> If you set it too high, you get hold errors on single flip flops!
>>
>> I think this is a bit harsh, and it seems like the uncertainty value
>> is actually more like a clock jitter value in the above case... I do
>> expect skew between two different flip flops, but not from one clock edge
>> to the next... I had to turn down the uncertainty to avoid what I consider
>> spurious hold errors.
>
> Some time ago (v2.0), I spoke with Synopsys at length about this class of
> timing analysis problem which I refer to as a case of reconverging paths.
>
> The guy from Synopsys development listened quietly for about an hour & then
> said, gee that's an interesting problem, maybe we can address it sometime
> (after 2.2). Then he went on to discribe how they defined skew & (IMHO)
> pretty much proved that real skew analysis wasn't in the cards for Synopsys.
From: cindy@zoran.hellnet.org (Cindy Eisner)
well, to do skew analysis at the level of detail you describe in your post
seems not suitable for synthesis, since you need the post-layout numbers
in order to be accurate enough. but to just solve the single flip-flop
skew problem, use:
set_false_path -hold -from o_reg/Q -to o_reg/D
true, this is not practical for an entire block, because you need to
name each flop, but:
a) it can help you with a specific problem now
b) that fact that this command exists means that it should be a simple
enhancement for synopsys to mask out skew problems between a flip-
flop and itself. anyone from synopsys listening? please respond.
- Cindy Eisner
Zoran
( ESNUG 153 Item 5 ) ---------------------------------------------- [10/5/93]
Subject: (ESNUG 152 #5) 'The Mysterious "set_output_delay" in 3.0b'
> I have a question concerning the use of "set_output_delay." If I have it
> right:
> "set_output_delay -clock CLK -max n { output list }"
>
> imposes that no output in the list moves AFTER n units before the next CLK
> rising edge. At this point,
>
> "set_output_delay -clock CLK -min n { output list }"
>
> should impose that no output in the list moves BEFORE n units before the
> next CLK rising edge. However, Design Compiler 3.0b seems to ignore
> the latter. That makes a minimum output delay impossible to constrain.
> Am I using "set_output_delay" improperly? Is this a Design Compiler bug ?
From: Oren Rubinstein <oren@waterloo.hp.com>
What set_output_delay does is tell Synopsys that your output goes through
some logic which takes "n" timeunits, and then to a flop clocked on CLK.
In other words: n = CLK_edge_time - output_change_time
For the max case (setup), your syntax is fine.
For the min case (hold), you need a negative number, because the change
time for the output is bigger than the CLK time.
- Oren Rubinstein
Hewlett-Packard (Canada) Ltd.
( ESNUG 153 Item 6 ) ---------------------------------------------- [10/5/93]
From: frankz@kpc.com (Frank Zappulla)
Subject: Too Many Nets In Final Designs
We are seeing a high percentage of nets per gate in our design using Synopsys.
It appears that the synthesizer is chosing a lot of simple gates,
(i.e 2 input) rather than 4 or 5 input gates to implement a logic function.
This is resulting in a large number of nets per gate.
I understand that this is inherent with the use of Synthesis in general.
However this is resulting in our ASIC being difficult to route. Could you
make any recommendations or suggestions on how to constrain the synthesizer
to help this problem?
- Frank Zappulla
Kubota Pacific
|
|
