( ESNUG 138 Item 1 ) ----------------------------------------------- [8/4/93]
From: gerold@lsil.com (Gerold Butz)
Subject: ( ESNUG 132 Item 1 ) "Working with MUXes using Verilog and VHDL"
In ESNUG 132, the anonymous Synopsys poster misstated the gate impact
of muxes:
>To implement this structure with multiplexers, it would require four 4 to 1
>multiplexers. Simply multiplying the number of combinational cells required
>for a 4 to 1 multiplexer (6 ANDs, 3 ORs and 2 INVERTERs) would produces an
>estimate of 44 gates total for this circuit.
In reality, gate array technologies can usually implement a 4-bit pass
gate mux in 6 gates. For the 4 bit bus, that would be 4x6=24 gates, which
is less than the 44 gates required by combinational logic.
Furthermore, there is a huge factor not being taken into account with
combinational logic, particularly the smaller gates. They may be smaller in
area, but they have a huge impact on routability. Therefore the gatecount
would be low, but the ASIC would need more silicon to route completely.
At LSI, we have seen again and again that when the customer uses muxes (which
he usually has to insert by hand since Synopsys does not implement them very
well), the routability and utilization increases significantly.
For that reason, I am a big proponent of using muxes in some of the cases that
you mentioned and I would like to see Synopsys implement them more often.
- Jerry Butz
LSI Logic
( ESNUG 138 Item 2 ) ----------------------------------------------- [8/4/93]
From: "Parthiban" <kandappan@asic.enet.dec.com>
Subject: CMOS modelling & characterize
Status: R
G'day John,
When I try to generate a loading constraint file using the "characterize"
followed by "write_script" commands, the file generated contains statements
of the form:
"set_load -pin....." and
"set_load -wire...."
But this is not correct since I am using a CMOS technology; and for CMOS
it is not supposed to split it into pin & wire loads. (Incidentally, the
same script generated the correct statements in Synopsys 2.2b!)
Do you have any idea? Have you seen this before?
FWIW, I am using Synopsys 3.0a-10063
- Parthi Kandappan
Digital Equipment Corporation
( ESNUG 138 Item 3 ) ----------------------------------------------- [8/4/93]
From: serre@acri.fr (Sylvain Serre)
Subject: (ESNUG 133 #4) "Test Compiler"
>(Using Synopsys version: 3.0a-10063)
>
>After running insert_test there is a very high fanout on the
>test scan enable (test_se) signal. The Test Compiler manual
>recommends running 'compile -incremental' which is a very slow
>procedure for a large design. Is there a faster way to do this?
>I don't want it to consider every net - it just needs to fix
>test_se. (Can I dont_touch everything except this net? How?)
>
>It's interesting to note the Test Compiler manual states: 'If a
>design has no design-rule constraint violations before you add
>scan-test circuitry, it usually has no design-rule constraint
>violations after you add scan-test circuitry.'
>
>Except for on test_se that is....
"Procedure to fix fanout on test_se"
We just ran into the same problem and we fixed it with:
compile -only_design_rule
This compilation is pretty fast even for a large design since only
max-fanout violations are fixed.
- Sylvain Serre
ACRI - France
( ESNUG 138 Item 4 ) ----------------------------------------------- [8/4/93]
From: John Vogel <RYGK80@WACCVM.corp.mot.com>
Subject: ( ESNUG 136 Item 1 ) "Follow Up on White Space / Comments Bug"
> Concerning the white space / comments bug and Synopsys 2.2b, I asked
> Synopsys about this and they report that this bug doesn't effect Synopsys
> 2.2b or Synopsys 2.2b-8468. Not to nag, but the Synopsys technical gurus
> recommend that all users migrate to Synopsys 3.0a-10063 until Synopsys 3.0b
> comes out. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
John,
Synopsys 3.0a-10063 has been known to crash for large block synthesis. One of
my customers and I loaded the software as soon as it came out. The design we
were working, about 12K gates, started crashing during logic compile. We
tried the same HDL on 3.0a and it compiled without crashing. We also
experienced large block compile crashing on another completely different
design. We concluded that patch 10063 was the problem. We have both switched
back to 3.0a. We are told that area savings can be achieved by using 10063.
If your compiled blocks do not crash in 10063, I suggest you stay with
10063, but be on the alert for any unexplained crashes.
- John Vogel
Motorola ASIC
( ESNUG 138 Item 5 ) ----------------------------------------------- [8/4/93]
From: [ a new subscriber ]
Subject: Re: Discussing Non-Synthesis Issues
> John, I noticed that ESNUG seems to only discuss synthesis bugs. Are you
> interested in feedback on their VHDL simulation software?
Yes, I'm interested in questions/comments/bugs/workarounds/anything concerning
any Synopsys product -- not just synthesis issues! (Even though that seems to
be focus of many of the ESNUG posts -- I think that's because most users tend
to use Synopsys primarily for synthesis.)
For VHDL, I dug around the archives and found:
ESNUG 80: Synopsys & Vantage's VHDL Incompatabilities
ESNUG 81: A Better VHDL Random Number Generator
ESNUG 85: vhdl_strict variable
ESNUG 99: Synopsys VHDL and Actel FPGAs
ESNUG 100: Synopsys VHDL and Actel FPGAs
ESNUG 101: Synopsys VHDL and Actel FPGAs
ESNUG 109: 3.0 bugs?
ESNUG 116: VHDL Code That Causes Synopsys Analyzer To Core Dump
ESNUG 119: V3.0a "read -f vhdl" Fatal : Internal system errors
ESNUG 126: (Repost ESNUG 81 Item 1) "A Better VHDL Random Number Generator"
ESNUG 132: Working with MUXes using Verilog and VHDL
ESNUG 134: It Initializes in VHDL But Not After Synthesis
ESNUG 136: (ESNUG 132 #1) "Working with MUXes using Verilog and VHDL"
ESNUG 136: VHDL Compiler problems
(If you don't have a copy of the ESNUG archives, send e-mail to
"khaddock@intellitech.com" and Kareen will send them to you!)
To re-iterate, send in your wisdom concerning *any* Synopsys product itself,
how it interacts/compares with other software and/or chip technologies or
anything that you think an ASIC designer might find to help him do his job;
that's what ESNUG's around for!
Also remember, ESNUG's interested in good information -- not the source, if
you wish to remain anonymous just say so and "I've never heard of you."
- John Cooley
the ESNUG guy
(and ASIC Design Consultant)
|
|
