( Post 61 Item # 1 ) -------------------------------------------------------
If you're missing some ESNUG posting, please send me a letter in the form:
I'm missing posts 47, 52 and 60.
youraddress@yourcomputer.com
This way I can easily cut & paste everything but your address out and throw
it in the mail expander. Please DON'T send me an entire copy of the
post you got this from!
Also, please give non-path dependent addresses. ( GOOD: bob@wallyworld.com
BAD: zaire!gambia!george!ralph!fooby!yaya@uunet.uu.net )
Having to hunt down an address inside a large file means lots of needless
work.
- John Cooley
( Post 61 Item # 2 ) -------------------------------------------------------
[ from an American engineer ]
I would like to share this information with ESNUG. Let me know what you think
about it. I'd greatly appreciate it if you do not post my name or company.
Q. After compiling my design there is unmapped logic (called MSELECTOR) that is
left in my design which causes unresloved reference problems. How do I get rid
of this and what is causing it ?
A. First an explanation why this is happening:
When a dont_touch is placed on a synthetic cell, such as the MSELECTOR, the
cell is not mapped to gates. It is not possible to map a synthetic cell after
placing a dont_touch on it in successive compile runs, as its identity as a
synthetic cell has been lost. In most instances, the problem can be resolved by
mapping HDL description to gates before applying the dont_touch.
There are four scenarios in which unresolved MSELECTOR references could occur :
1) There is a dont_touch on a net which feeds a SELECTOR in the original HDL.
WORKAROUND: Map the design down to gates and then place a dont_touch.
2) There is a dont_touch_network on a network which feeds a SELECTOR in the
original HDL.
WORKAROUND: Map the design down to gates and then place a dont_touch_network.
3) isolate_timing_path causes an arc to be disabled within a SELECTOR in the
original HDL.
WORKAROUND: Map your design down to gates and then use isolate_timing_path.
4) Combination feedback loop(s) cause an arc to be disabled within a
SELECTOR in the original HDL.
WORKAROUND: Break the feedback loop at an approriate point.
This bug occurs in 2.2b only.
( Post 61 Item # 3 ) -------------------------------------------------------
From: victor@truevision.com (Victor J. Duvanenko)
I was unfortunate enough to be the first to discover the 'synthesizable-but-
unsimulatable' bug. This came very late in the design cycle as well, to make
things even worse. The trouble with synthesis in general is that the
synthesizer treats logic in terms of a truth-table, and then finds an
implementation that will have an equivalent functionality. The logic that
the synthesizer generates will work in real life, since every node will be
a 1 or a 0 (since there is no such logic state as a X). But, the simulators
start up with all nodes being at X, and can't deal with another node being
(not X). If simulators could actually keep track of node A being X, and node
B being (not node A) then the synthesized logic would work fine. But, most
simulators don't keep track of node-to-node relationships - they simply say
(not X equals X).
What I've been asking Synopsys to add is an option to the 'compile' command -
'compile -for_simulation'. This, however, forces Synopsys to modify the
synthesizer so that it does not generate situations that simulators can not
deal with - so, don't expect a solution until version 4.0. For now the best
solution is to have a global asynchronous reset.
Enjoy,
-Victor J. Duvanenko
|
|
