[ What follows in NOT a paid advertisement. I've received no money,
no sexual favors, :^(, no nothing from anyone for this; it's purely
my own personal professional opinion. - John ]
Editor's Note: I would like to publically applaud Chronologic Simulation's
approach to doing business. Most EDA vendors put special clauses in their
licencing agreements to forbid customers from doing comparitive benchmarks
on their software. Also, most EDA vendors *say* that the vast majority of
their customers are repeat customers, they have very few bugs in their
products and those bugs they do have are fixed quickly -- you know, the
usual happy customer marketing drivel that's unconfirmable and perfect for
salesmen to use to convince you to buy their products.
In contrast, Chronologic Solutions actively encourages everyone to benchmark
their products. Now they're offering an upgrade from Verilog-XL to their
high speed Verilog simulator (VCS) for what works out to be $5000 ($1000 plus
$4000 maintanance) with a limit of one upgrade per engineering lab. Through
these *actions* Chrono is clearly showing that the vast majority of their
customers are repeat customers. They don't make money selling at this price;
their *actions* show they're confident they'll make money when you return to
buy a *second* VCS licence. They don't have a large aggressive sales staff
out to give you the hard sell; they let the benchmarks speak for themselves.
Also, because Chrono's a small company; you're not four beaureaucratic layers
away from the guy who wrote the code when you report a problem. Overall, I
see this as a company of engineers who wanted to make a screaming fast
Verilog simulator -- not businessmen out to make a
Synopsys VSS ## 1.0 quick buck in the EDA industry. Because
Mentor ## 1.1 Chronologic Solutions sells, in my opinion,
Viewlogic #### 2.0 a well supported kick-butt Verilog simulator,
Silicon Auto #### 2.1 I'm recommending you take advantage of
Cadence Turbo ####### 3.5 this upgrade offer before the January 31st
Vantage ######## 4.1 deadline. They're at 1-800-VERILOG.
Model Tech ######## 4.1
Cadence Leap ########### 5.4 - John Cooley
Simucad SILOS ########### 5.6 the ESNUG guy
Racal-Redac ################# 8.3
Chronologic ###################################################### 27.0 !
Relative Speed Benchmark of HDL Simulators (June 14, 1993 EE Times)
( ESNUG 172 Item 1 ) ---------------------------------------------- [1/93]
From: brien@acuson.com (Brien Anderson)
Subject: Test Compiler Breaking Scan Chains During Insertion
Hello John,
We are finding that Synopsys 3.0b test compiler is breaking scan chains. In
the picture below, before scan insertion, the output of Q1 goes to an output
pad as well as back into the core. Our desire is to insert scan logic as
shown below between Q1 and the output pad.
Where we're starting before scan insertion:
BACK INTO
CORE LOGIC <-----
|
CORE FF |
______ |
| | |
--|D |------|
| Q1 | |
| | |
--|> | |
------ ----------->OUTPUT PAD
After scan insertion, what we're looking for:
BACK INTO
CORE LOGIC <-----
|
CORE FF |
______ |
| | |
--|D |------|
| Q1 | |
| | |
--|> | | ------
------ ---| SCAN |
| MUX |-------->OUTPUT PAD
SCAN FF ---| |
------ | ------
| | | |
--|SI |------ |
| | Scan Enable
--|> |
| |
------
When test compiler inserts the scan chain, the output of Q1 goes directly
to the output pad. The output of the scan MUX goes back into the core as
shown below. What we're getting but don't want from test_compiler:
BACK INTO
CORE LOGIC <--------------------------
|
D FF |
______ |
| | |
--|D |------------->OUTPUT PAD |
| Q1 | | |
| | | |
--|> | | ------ |
------ ---| SCAN | |
| MUX |---------
SCAN FF ---| |
------ | ------
| | | |
--|SI |------ |
| | Scan Enable
--|> |
| |
------
partial code
-------------
current_design = "core"
set_test_methodology multiplexed_flip_flop
set_signal_type test_scan_in -index 1 data_in_1_
[and so on...]
set_signal_type test_scan_out -index 1 data_out_reg_1_
[and so on...]
compile_test -max_scan_chain_length 100 -scan_chains 20
Does anyone have any suggestions to get test_compiler to do what we want?
- Brien Anderson
Acuson
( ESNUG 172 Item 2 ) ---------------------------------------------- [1/93]
From: [ Synopsys R & D and the Synopsys Support Center ]
Subject: (ESNUG 170 #1) "Sequence Of Clock Definitions Effects Results ?!?"
Hi John,
The following item appeared in ESNUG Post 170 #1. It describes a case where
one clock is defined near the root of a clock tree, and the other is defined
further down the clock tree. Currently the clock information is propagated
from each source to registers without stopping if it meets another clock
source. So, yes, it is dependent on the order you specify the clocks.
/--->> clk1 (to I/O latches)
|
|
external INV1 | INV2
clock >>----- DRVT8 ----+------ IDRV16 ------->> clk2 (to core of chip)
|
|
clock port
of a subdesign
So the thing to avoid is having two clock sources at different points along
a single path through the tree. You should also avoid having different
clock skews defined at points along a single path. Either case will be
order dependent; you need to specify the left-most source first. Placing
different sources or skew on adjacent branches of the tree is fine (if there
is no path through both source points).
If you want to avoid the order dependency, use disable_timing to break
the timing path from I1/Z to the clk2 registers. Create clocks as before:
disable_timing INV2 -from A -to Z
create_clock find(pin, I1/Z) -name clk1 -period 30 -waveform {1.0 20.0}
create_clock find(pin, I2/Z) -name clk2 -period 30 -waveform {6.0 25.0}
- [ Synopsys R & D and the Synopsys Support Center ]
( ESNUG 172 Item 3 ) ---------------------------------------------- [1/93]
From: [ Silenced By Company Politics ]
Subject: Dangling Logic w/Clocks and 'dont_touch_network'
John-
If you could, keep my name anonymous. Politics over here are tremendous,
and [Company Name Deleted] would be most upset by me broadcasting that we're
using Synopsys.
FYI- I found a problem using Synopsys 3.0b in dc_shell when putting
dont_touch_network on the clock lines generated from hand-instantiated
buffers. The end result in the netlist yielded extra gates with inputs
of reset and clk (same clock that I did the dont_touch_network on) and
outputs going nowhere. My script that I used looked something like:
...
create_clock clk13 -period 50 -waveform {0 25}
create_clock {CLK_BUF/z} -name clk -period 50 -waveform {0 25}
dont_touch_network clk13
dont_touch {CLK_BUF*}
...
set_false_path -from reset
compile -boundary_optimization
...
Basically, the "13" clock went into a 5x buffer named CLK_BUF and had the
output named clk. I did a dont_touch_network on the clk13 and the buffer.
It appears that 3.0c has the same problem, but we don't have it up and
functional over here yet.
Any rate, here's the response I got from Synopsys and the workaround.
It may be wise to review your design in Design Analyzer to see if you've
got hanging gates.
- [ Silenced By Company Politics ]
--- --- ---
From: [Synopsys Support]
The hanging gates problem you are seeing is a result of the
dont_touch_network command in your script (dont_touch_network clk13). The
command is not working properly in this case. This is a bug which should
be fixed in v3.1a. STAR 17272
The 'dont_touch_network' command was really designed to preserve mapped
structures (a hand-designed clock network, for example).
When you use 'dont_touch_network' on an unmapped design, the way it is
supposed to work is the tool will not 'dont_touch' any unmapped (generic)
cells or nets which have any unmapped cells on them. In other words, the
command is essentially ignored if the network is unmapped, but then later
on in the compile, after the initial technology mapping, the
dont_touch_netork is reapplied. So, when you use dont_touch_network on an
unmapped design, what you really should get is the first mapped logic and
that will be dont_touched.
The problem in v3.0b is that there are new types of 'unmapped' cells (gtech
components and synthetic cells), and these are not being recognized as
unmapped. This means that dont_touches get applied to some nets even though
they have these unmapped components on them, and later when these components
are mapped, the nets still have dont_touches, and so remain in the design
(dangling).
The workaround in v3.0b is to use a two-pass compile methodology. In the
first pass do not assert the dont_touch_network, and use a 'compile
-no_design_rule'. This works since clock networks don't have any delay
constraints, they will not be optimized (buffered) except to fix design-rule
violations (max_fanout, max_trans, etc). Then for the second compile,
assert the dont_touch_network (which will work fine now because the design
is mapped), and do a 'compile -only_design_rule'. This will complete the
optimization by doing the design rule fixing phase of the compile.
I hope this helps! Please let me know if you need additional information.
- [ Synopsys Support Center ]
( ESNUG 172 Item 4 ) ---------------------------------------------- [1/93]
From: uunet!fmicos!argus!dillinge (Stephen Dillinger)
Subject: Seeking A State Machine Rule-of-Thumb
Does anyone have a "rule-of-thumb" for the maximum size of a state machine
before Synopsys gags? Issues of readability aside, I was just wondering
what size state machine causes compile times become excessive.
- Steve Dillinger
Ford Microelectronics
( ESNUG 172 Item 5 ) ---------------------------------------------- [1/93]
From: saad@psi.ericsson.se (Saad Guedira)
Subject: Re: FPGA Compiler bug
Status: RO
Hi John,
The command "set_pad_type" doesn't work with the Xilinx XC4000 library. I
needed a PULLUP (and PULLDOWN) on some given ports, so I used "set_pad_type"
successfully as follows:
set_pad_type -pulldown en_par_err_clr_tfx
Performing set_pad_type on port 'en_par_err_clr_tfx'.
1
When I used the insert_pads command, Synopsys gave the following warning:
Warning: Relaxing user-specified IO pad constraints on
port 'en_par_err_clr_tfx' (OPT-1005)
I could also see after the PPR program (Place & Route) that the pad in
question had no PULLUP on it. I tried this both in Synopsys 3.0b and 3.0c.
Has Someone seen this problem and perhaps its solution?
- Saad Guedira
ERICSSON COMPONENTS AB
|
|
