Editor's Note: Remember the killer turkeys that disappeared 2 years ago?
  Yesterday I was driving about half a mile from my farm and saw them next
  to the road!  I stopped the car and counted 19 birds altogether -- three
  toms (male turkeys) and 16 hens (female turkeys).  It really made me
  happy to start the day like that!

  After that, it all went down hill....

  My system crashed and as a result ALL my backlogged e-mail (all 850
  messages) DISAPPEARED.  I got them out of backup but lost 1 day's mail.

  I just changed the spark plugs on my car and am now worried that I may
  have over-tightened them.  (Like Homer Simpson, I forgot about how you
  have to be extra careful putting steel spark plugs into aluminum engine
  blocks because you may accidentaly strip the threads....  DUUUH!)

  For some reason the phone company's automated answering machine also
  stop taking new messages for me for half that day.

  The sheep broke through a back fence and I got a good little 30 minute
  run (in the rain) getting them back in.

  And, reading yesterday's newspaper, I just found out that my birthday
  (this month) is also "National Depression Screening Day"!  :^(

                                               - John Cooley
                                                 the ESNUG guy

( ESNUG 253 Item 1 ) -------------------------------------------- [10/4/96]

Subject: ( ESNUG 251 #8 ) Test Compiler "Moody" W/ Test_Mode and Reset_n

> I have a question about disabling asynchronous resets during test mode.
> Test Compiler requires all asynchronous resets to be disabled during test
> mode.  Should this include our primary input "reset_n" ?  ...  Assume
> active low asynchronous reset for the flip flop and when signal1 = '1'
> then we want to reset the flop.  There is no problem when:
>
>           (reset_n and (test_mode or not signal1))
>
> There is a problem when:
>
>      ((test_mode nand reset_n) nand (reset_n nand signal1))
>
> Even though Test Compiler is infering an asynchonous reset port on
> reset_n.  It is not able to realize that reset_n will be a '1' when
> shifting in and out data.  


From: zehentner@jh-ger.de (Zehentner Georg)

John,

When there is an asynchronous reset controlled by an internal signal
"signal1" and a primary input "reset_n", it is correct to disable the
control of "signal1" for scan test.  This methodology works very well in
my designs.

You have to add a "set_test_hold 1 test_mode", so Test Compiler is sure the
asynchronous reset is only controlled by the primary input "reset_n".

	- Georg Zehentner
	  Heidenhain

  ----    ----    ----    ----    ----    ----    ----    ----    ----

From: Herve.AUCHROY@st.com (Herve Auch-Roy)

You may try <set_test_hold> command to hold your reset_n input pin to a
desired value (1 in this case) during test compile.  Personaly, I would
not mess up the Test Compiler directives with the design itself, as it
appears in the sentence:

        (reset_n and (test_mode or not signal1))

To my opinion, *test_mode* refers to silicon implementation, and
*reset_n = 1* refers to test patterns.  I would rather do:

 [ in my source code ] : (reset_n and not signal1)
 [ as Test Compiler directive] : set_test_hold 1 reset_n test_mode 

Hope this helps.

  - Herve R. Auch-Roy
    SGS-Thomson


( ESNUG 253 Item 2 ) -------------------------------------------- [10/4/96]

From: "Jim Dean" <jimdean@bnr.ca>
Subject:  I Really Like Nextwave's Spread Simulator Called Epilog

Hello John,

I manage the simulation group at Northern Telecom.  I am writing to say
that I find your ESNUG reports to be very informative (as well
as entertaining) and I would like to add my bit to help fellow users.

I've found Verilog-compatible spread simulator called Epilog, from
Nextwave Design Automation in San Jose to be very useful.  I love this
tool, and have purchased several copies.  Epilog is not your average
min-max simulator: it uses probabilistic distributions over the min-max
range to describe what the delay is likely to be for each component,
and when it "adds" delays up, it truncates the tails, which are unlikely
to happen.  This eliminates many of the unlikely hazards which would
reported by traditional min-max methods.  We have used this tool both
in board and in ASIC simulations, and feel that it has saved us an
iteration per ASIC. (The problem being that as we go further and further
sub-micron, delay across a single die is less and less correlated - so
we have to do margin analysis on ASIC's.)  I felt so strongly about
this tool that I helped fund Synopsys/Logic Modelling's effort to put a
SmartModels interface in place so that Epilog had access to timing
info in SmartModels.

  - Jim Dean
    Northern Telecom Ltd


( ESNUG 253 Item 3 ) -------------------------------------------- [10/4/96]

From: Muthu Krishnan <muthu@india.ti.com>
Subject: Forced JTAG Insertion Especially When I Don't Want It

Hi John,

I am using Synopsys 34b.  Irrespective of whether the set_port_is_pad
attribute is set or not, insert_jtag always adds JTAG_BSR for all ports
of my core block!  ( And I do not want to make all my design ports to be
JTAGed!!  Due to performance reasons, I want only a few of them to have
boundary scan cells and avoid it for the rest!)

I tried all options, nothing seems to work to stop this forced JTAGing.
Is it a bug with Synopsys 34b Test Compiler or what ?

Also, I would like to use my own JTAG_BSRIN instead of Synopsys JTAG.db
modules.  How can I tell the Test Compiler to use it?

  - Muthu Krishnan
    Texas Instruments


( ESNUG 253 Item 4 ) -------------------------------------------- [10/4/96]

Subject: (ESNUG 252 #1 ) Correlating Mapped Xilinx to HDL Advisor 3.4b GTECH

> The answer to this user's question is quite involved, but, in following
> your policy of keeping ESNUG a user-driven technical resource, here's the
> *entire* enchalada.  Before going into detail on "Mapped -> Gtech
> Correlation" it makes sense to  give a brief summary of what Mapped and
> GTECH Analysis are...


From: dmullen@net.com (David Mullenex)

Hi John,

The detailed response from the Synopsys HDL Advisor support team is very 
accurate.  It depicts the steps that got me, with a lot of help from them,
to where I'm now using HDL Advisor to track timing violations in my mapped
design, back to the specific lines of my source code.

My thanks to the Synopsys for getting this process to work, and saving me
the time of having to try and document the process and limitations.

  - David Mullenex 
    Network Equipment Technologies.


( ESNUG 253 Item 5 ) -------------------------------------------- [10/4/96]

From: mac@apprentice.silicon-sorcery.com (Mike "Mac" McNamara)
Subject: A Free Verilog-Mode Emacs Editor For ESNUG Readers

Hi, John, I have a complete "freebie" for your ESNUG readers: an emacs mode
which works with Xemacs and GNU-emacs, that 

	1) auto indents verilog code as you type it in, or type TAB  
	2) auto colorizes the code, again as you type it in.
	3) end, else, endcase, `else and `endif are auto commented
	   to describe what they are ending or elsing.
	4) provides context sensitive completion.
	5) standard functions like forward expression M-f and backward
	   expression M-b understand verilog syntax and will move you
	   from a begin to it's end, and so on.
	6) more features as I add them...

Still a bit unsure whether its "initial" or "initail"?  As you type the
"initial" turns a satisfing brown color (it's a keyword) but "initail"
stays white (it's user variable.)

Having a hard time figuring out which in that series of 

   end	
       end
     end
    end	
	
is the "end" you want to add a bit of code after?  With this emacs mode your
"ends" are labeled.  If the labels get out of date, two keystrokes (C-c C-b)
and all the ends in the current module are relabeled.

If you inherit un-indented or worse, incorrectly indented code, just type
the emacs standard M-C-\ and the whole region is indented correctly.

To get it just e-mail me at "mac@silicon-sorcery.com" along with your: Name,
Title, Company, Phone Number and your e-mail address.  Once I have this
info, it goes into a mailing list; whenever I update the verilog-mode, I
mail it to the list.

  - Mike "Mac" McNamara
    Silicon Sorcery


( ESNUG 253 Item 6 ) -------------------------------------------- [10/4/96]

From: "Victor Duvanenko" <victor_duvanenko@quickmail.truevision.com>
Subject: Is Behavioral Compiler Worth It Or Just So Much Hype?

John,

I've been eye-ing Behavioral Compiler (BC) for the last 3 years, and have
just been through training on BC.  However, I'm still not convinced it's
a clear productivity gain (or coding reliability improvement), as
there is with Design Compiler, which I've been happily using for the last
5 years.  This uncertaintly may just be due to the domain of my design
space.  I have seen the write-up from Apple's David Black (first in ESNUG,
then in "Integrated System Design" magazine and now in Synopsys's "Impact!"
mailer) but would like to hear on ESNUG from other BC users where BC helped
(in technical detail) over RTL design methodology.  I would also love to
see positive and negative comments about BC on ESNUG.

  - Victor J. Duvanenko
    Truevision

 
( ESNUG 253 Item 7 ) -------------------------------------------- [10/4/96]

From: [ Not A Synopsys EDA Developer ]
Subject: Synopsys Patent On Latch Inferencing

John,

Last week's EETimes has a "Late News" article about Synopsys getting a
patent apparently for their latch inferencing rules.  I'm curious if
you know more about it than the article states.

It seems to me that awarding such a patent might make it impossible
for any other company to compete with Synopsys based on using a common
subset of Verilog.  What do you think?

I considered posting a message to comp.cad.synthesis, but decided against
it because my employer sells synthesis tools, and my questions could
easily be misread or misconstrued.

  - [ Not A Synopsys EDA Developer ]


( ESNUG 253 Item 8 ) -------------------------------------------- [10/4/96]

From: daver@packetengines.com (David A. Roth)
Subject: Synopsys + Solaris 2.5.1 + 60K Gate Design = Infinite Hang????

John,

Do you know if anyone out there using Solaris 2.5.1 and Synopsys are getting
infinite run times?  The design I'm working on will compile for the smaller
blocks, but seems to get hung up with larger chunks.  The same design and
scripts ran in 3 hours on a sparc 20.

  - David A. Roth
    Packet Engines


( ESNUG 253 Item 9 ) -------------------------------------------- [10/4/96]

From: landman@hal.com (Howard Landman)
Subject: Dealing With Different Capacitance On Different Pins Of One Bus

Hi, John,

I've got some cells in my library that have different capacitances on
different pins of a bus.  The most common case is that all the even-
numbered pins have one capacitance number, and all the odd-numbered ones
have another capacitance.

In the past, we have done a fairly kludgey thing to work around this:
we had our synthesis library have cells with individual pins named (e.g.)
"\A[0]" (all the affected busses were "bit-blasted" into scalar pins).
This is pretty messy, since it means the Verilog out of (and into)
Design Compiler has to not be simulatable due to the Verilog library
cells being bussed.  We have to use scripts to "fix" the netlists before
we can do anything else with them.  But, it does mean that we can get
the right capacitance (and hence, we hope, accurate timing) on each pin.

On page F-28 of the Library Compiler Reference Manual Vol. 2 version 3.3a
it says that it is legal syntax to have a pin group inside of a bus group:

    cell (name) {
       bus (name) {
          pin (name | name_list) {
            ... pin description ...
            }
       }
    }

Has anyone else on ESNUG used this feature of Library Compiler successfully?
If so, what is the precise syntax I need?  What should the pin names be so
that LC knows they are bits of the bus?  Is this order dependent?  If so,
which order?  (All our busses are MSB first, e.g. bus32 = 31 downto 0 or
[31:0] in Verilog terms.)

	Howard A. Landman
	HAL Computer Systems, Inc.


( ESNUG 253 Item 10 ) ------------------------------------------- [10/4/96]

From: patrickm@BayNetworks.COM (Patrick Murphy)
Subject: Does Synopsys Synthesis Support VHDL Recursion Now?  How?

John,

   I recently heard that Synopsys supports Recursion in VHDL, and will
synthesize recursive VHDL code!  Recursion is a very powerfull tool, and for
instantiating highly repetitive blocks it would be very useful.  I'm sure
the recursive call is closely coupled with the generate statement, and the
generate statement needs a TRUE or FALSE boolean declaration in order to
determine when to stop generating the architectures.

   Peter Ashenden of University of Cincinatti has an example of a recursive
call upon a VHDL entity to generate a buffer tree, the paper is called
"Recursive and Repetitive Hardware Models in VHDL".  I've read the paper,
and it never states whether the code is synthesizable by Synopsys or not.

  If it does support recursion, could you tell me how it does it with perhaps
an example or two?  If at all possible I would appreciate a simple example,
something like a clock tree or priority encoder would be nice.  It would be
interesting to know if Synopsys can handle Synthesizable Recursive VHDL code
that has synchronous logic in it, thus maybe you can recursively instantiate
several simple state machines.

  Also it would be nice to know what the limitations are for Synopsys to
compile this kind of code, I'm sure if you make it too complex the compiler
will probably go out and pick daisies for a few hours before it returns
with a core dump, and one of those wonderful cryptic error messages.

  - Patrick J. Murphy
    Bay Networks


( ESNUG 253 Item 11 ) ------------------------------------------- [10/4/96]

From: Atle.Haga@alcatel.no (Atle Haga)
Subject: Yikes!  I Can't Resest "max_capacitance" Post-layout?   Damn!

While receiving a post-layout netlist we usually get some/many design rule
violations depending on the design and the quality of the libraries.
Usually max_capacitance violations can be ignored if they're less than 150%
and you do not want to change the netlist more than necessary.  It seems
Design Compiler is not capable of handling this problem since it will 
try to remove *all* violations.  It is not possible to increase the 
max_capacitance value?!!  (Does anyone not want this? Why?)

We managed by manipulating (subtracting) capacitance from the data in the
annotation-file.  However, this is not our preferred design methodology!
Anyone else having other ways of solving this problem ?

  - Atle Haga
    Alcatel Telecom Norway



 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)