( ESNUG 160 Item 1 ) ---------------------------------------------- [11/3/93]
From: brooks@dvs.com (Walter Brooks)
Subject: Verification Error Problem & Solution
Hello, John,
We had a verification error with one of our VHDL synthesis runs. Originally,
the problem was not identified until after a logic simulation run because
the verification gave up. We then reduced the VHDL module size in an attempt
to get verification to spot the problem.
Basically, the synthesis did not handle sign extending the operands by
assigning the upper bits from the lower bits. Instead, the upper bits had to
be assigned a constant based on the lower bits. Also, the synthesis DOES (no
verification errors) work if no constraints are applied. It appears to be a
problem confined to the faster synthesized adders.
The circuit was part of a multi-tap filter where the inputs and intermediate
terms have been sign extended. The concatenation operations were not done
inside the add function call to get around a problem with our VHDL simulator
(VIEWlogic).
The solution was to manually sign extend the operands using a conditional
concurrent assignment, instead of assigning the upper bits from a lower bit.
(i.e. when i_sum = '100000000', I wanted sum_A = '111100000000'. When
i_sum = '000010000', I wanted sum_A = '000000010000'.)
Example VHDL that would work:
sum_A <= '1'&'1'&'1'&i_sum when i_sum(8) = '1' else '0'&'0'&'0'&i_sum;
Example VHDL that wouldn't work:
sum_A <= i_sum(8)&i_sum(8)&i_sum(8)&i_sum;
Here's the error I'd get from Synopsys during verification:
Verifying Designs (High effort)
Information: Verification Failed. (OPT-103)
Verification endpoint sum[12] is different.
A distinguishing pattern is:
sum_A[8] : 0
sum_B[8] : 1
sum_C[8] : 0
sum_D[8] : 0
Compile script used:
read -format vhdl my_little_adder.vhd
max_delay 10 -to sum_A
compile -ungroup_all -map_effort medium -verify -verify_effort high
exit
The synopsys hotline has been informed of the problem (but not the solution),
but has yet to reply to us with a work-around. Hopefully they read ESNUG :-)
- Walter Brooks
Digital Video Systems of Scientific-Atlanta
( ESNUG 160 Item 2 ) ---------------------------------------------- [11/3/93]
Subject: (ESNUG 158 #4 159 #2) 'Disable DesignWare' a.k.a. 'Licensing Wars'
> What is the resolution? Synopsys wants me to buy enough HDL Compiler
> licenses to match 1-to-1 with Design Compilers. There has not been much
> give on their part in pricing or terms. They claim we are one of only a
> few companies which do not have parity in licenses (is this true? anyone
> else out there have the same problem?). We have suggested to Synopsys
> technical solutions such as "wait" for a license, turn off DesignWare,
> etc., but have been rebuffed so far.
--- --- --- ---
From: James Muha~ <jmuha@sedona.intel.com>
We do not have parity in licenses either. We have more Design Compiler
licenses than VHDL licenses.
- James Muha~
Intel
--- --- --- ---
From: [ Definitely Anonymous ]
John, please keep me definitely anonymous.
Definitely not everyone has the same number of licenses! It is ridiculous
that they should try to force you to do this, and TWICE as ridiculous that
they don't release the license at the point it is no longer needed.
We often have several designs going on at the same time. While some of
the people may be using the Design Compiler licenses (and therefore
VHDL compiler), others are often only using VHDL compiler because they
are just developing the code and aren't to the point of synthesis yet.
What are we supposed to do? Have twice as many VHDL compilers as Design
compilers so that both groups can work? That is absurd, and even if we
wanted to buy them, the price makes them unaffordable.
This isn't sales/marketing, it is blackmail.
- Definitely Anonymous
--- --- --- ---
From: trevor@sheridan.ncd.com (Trevor Pearman)
I am completely with you on this one. We have a disparity between VHDL
licenses and design compiler licenses and its a pain because of what you have
pointed out. I havn't had a go as Synopsys on this issue since I guessed what
their attitude would be. I will be looking with interest at how much response
this generates.
On a similar note we have 1 dc_expert license and multiple dc_professional
licenses since we were led to believe that the expert license was mainly for
back annotation from layout and other "once only" operations. I have since
found that multi clock designs cannot be compiled without the expert license
and everything we do has more than 1 clock in it. I would be interested to
know if many people are able to make efective use of dc_professional without
dc_expert.
I have to now explain to my management that I need more money to match expert
licenses with professional licenses. I am, needless to say, not very happy
about the way these 2 products are differentiated, marketed and sold. I feel
misled.
- Trevor Pearman
Network Computing Devices
--- --- --- ---
From: [Synopsys R&D] and [Synopsys Customer Applications Engineering]:
This message is in response to esnug posting 158 (item 4), which talked
about the use of the HDL-Compiler license (HDL-C) during "compile".
This posting clarifies the reasons as why the compile command checks-out
a HDL-C license, and also provides alternative methods of using "compile"
to avoid this situation. The implications of the proposed methods are
also discussed.
When synthesizing a design described at the RTL using VHDL or Verilog, as
part of the synthesis process, the "compile" command applies High Level
Optimization (HLO) techniques to improve the Quality of Results (QOR).
The HLO process includes resource sharing, carry-in inference, tree
height minimization, and common-sub expression sharing. HLO also includes
"implementation selection" (IS), which is the "process" of selecting
implementations of high-level building blocks, or DesignWare parts, that
best satisfy the delay/area constraints. The HLO process requires an
HDL-C license.
There are two methods for disabling HLO to prevent "compile" from checking-out
an HDL-C license:
- HLO can be turned off by setting the following variable *before*
elaborating or reading-in the design:
hdlin_replace_synthetic = true;
This causes all synthetic operators to be replaced during the read
or elaborate step, thus, there is no need for HLO during compile.
- Use the "replace_synthetic" command after "read" but before "compile"
to turn-off HLO. This has the same effects as setting
"hdlin_replace_synthetic" to true. However, "replace_synthetic"
itself needs to check-out an HDL-C license to execute.
As mentioned earlier, these two alternative methods disable HLO which may
lead to degradation in the overall quality of the design.
If either of these two techniques are employed to turn-off the HLO process,
and the design contains arithmetic components or relational operators which
are in the critical paths, the designer may decide to *re-read* the design
(from HDL source), set "hdlin_replace_synthetic" to "false", and re-compile
the design to improve the critical path by applying HLO. The *re-read* from
HDL source is *necessary* since HLO is applied only during the first "compile"
after "read" or "elaborate".
- Synopsys R & D and Synopsys Customer Applications Engineering
( ESNUG 160 Item 3 ) ---------------------------------------------- [11/3/93]
Subject: (ESNUG 159 #1) "Test Compiler Left Ports Unrouted Out Of Subdesigns"
> We are trying to create a scan path in a circuit. One of the circuit
> modules already contains a scan chain set, while the others don't ... the
> scan chains in were routed by hand ... After the second insert_test command,
> the scan chains are exactly as desired, but several submodules contain some
> fake scan routing. Usually, the new submodule instance has some extra
> test_si<n> and test_so<n> ports, where n > 29. The submodule itself does
> not contain any scan FF, and so test_si<n> is directly wired to test_so<n>.
>
> NOTE: The corresponding ports are NOT routed outside the submodule, and are
> left hanging by the test compiler!
From: maurizio.paolini@cselt.stet.it (Maurizio Paolini)
I can now add that the reported behavior disappears if you set the scan to
"false" for all the involved submodules. I suppose that the scan variable
is erroneously set to true when the dont_touch attribute is removed - but
this is no more than a guess.
- Maurizio Paolini
CSELT - Centro Studi E Laboratori Telecomunicazioni
[ Thanks for following up on this once you found a solution! - John ]
( ESNUG 160 Item 4 ) ---------------------------------------------- [11/3/93]
From: monks@azmda.sps.mot.com (Morgan Monks)
Subject: VSS VHDL SDF Timing File Bug
ESNUGites,
I have run into a bug in Design Compiler that can produce a misleading VSS
simulation. The problem is when writting out an SDF timing file, Design
Compiler will only write one triplet for both the rise and fall delays.
Equal rise / fall delays can occur in the interconnect delay and some special
cells. The SDF file from design compiler will look like:
(INTERCONNECT U4/X RAM1/RWB (1.001:1.001:1.001))
when U4 is back annotated in VSS only the rise delay is set to 1.001 ns !
What I need is :
(INTERCONNECT U4/X RAM1/RWB (1.001:1.001:1.001)(1.001:1.001:1.001))
Synopsys has acknowledged this problem and claims to have fixed this in 3.1
Beta2.0 ! My question is has anyone found a work around other than [yuk!]
editing the SDF file. I really don't want to tell my customer to edit again
the SDF file ( that was yesterday's bug work-around !)
Any ideas anyone?
- Morgan Monks
Motorola HPMG Semi-Custom Division
|
|
