( Post 69 Item 1 ) -------------------------------------------------------
From: xpoint!landman@uunet.UU.NET (Howard Landman)
I've run into the mux-model issue several times, and doing it right
has been almost a matter of habit for several years now. Although I do get
people calling up and saying "Hey, you've got a redundant term in your mux
model!" as though they had found a bug ...
Howard A. Landman
landman@xpoint.com
( Post 69 Item 2 ) -------------------------------------------------------
From: watters@twisto.compaq.com ( John Watters )
Indeed x-handling is an issue with the simulation library. It's not
really related to synthesis 99% of the time. However we have seen one
case where the optimization of a network produced logic that passed an X
through whereas the unoptimized logic did not. This was a result of logic
reduction and quite correct as far as that goes. The designer was
naturally unhappy with the extra x propagation in his gate-level
simulation since it got loose into some registers. Nevertheless the logic
was correct and the x handling was correct.
( Post 69 Item 3 ) -------------------------------------------------------
There were seven responses to the discrepency in timing reports problem
(ESNUG 68 Item 2) which all said the same thing. Here's one of them:
From: sgolson@trilobyte.com (Steve Golson)
Let's compare the reports side by side: **upper level** **lower level**
Max Delay Max Delay
Point Type Fanout Path Incr Path Incr
---------------------------------------------------------------------------
Clock in 42 0.00 r 0.00
r2/q_reg[1]/q fd1a 5 3.49 f 3.49
mux4/U213/yn iv104 3 4.04 r 0.55
mux4/U188/yn nd204 5 5.13 f 1.09
mux4/U224/yn oai28a 2 8.42 r 3.29
add1/r44/U106/yn iv1 2 9.72 f 1.30 1.22 r 1.22 ?
add1/r44/U163/yn nd204 8 10.47 r 0.75 2.45 f 1.24 ?
add1/r44/U100/yn nd3 2 12.46 f 2.00 3.65 r 1.20 ?
add1/r44/U98/yn nd402 3 13.70 r 1.24 5.86 f 2.21 ?
add1/r44/U108/yn enr202 2 15.70 f 2.00 7.86 f 2.00 !
add1/r37/U88/yn nd302 1 16.55 r 0.84 8.70 r 0.84 !
add1/r37/U87/yn iv104 4 17.64 f 1.10 9.80 f 1.10 !
add1/r37/U93/y ad3 2 19.45 f 1.80 11.61 f 1.80 !
add1/r37/U74/yn mx2d 1 20.71 f 1.26 12.81 f 1.20 ?
r32_ne_2/q_reg[6]/d
fdr1a 1 20.71 f 0.00 12.81 f 0.00
Compare the numbers in the "Incr" column for both reports. All lines marked
with "!" have identical timings, as expected. But why are the "?" lines
different? Notice the "r" and "f" in the "Path" column. One path is timing a
rising output, and the other is timing a falling output. We would expect the
times to be different, and they are.
The final line is different even though both paths show falling edges. This is
because the two reports have different output loads on that pin.
Steve Golson -- Trilobyte Systems -- Carlisle -- sgolson@trilobyte.com
( Post 69 Networking Section Survey Results ) ---------------------------
ADMIN NOTE: In Post 67, I asked:
> How would you feel about the creation of a small limited section that
> consists of two line contributions from readers in companies that are
> looking to hire Synopsys experienced engineers?
And was flooded with positive reactions (and not a single "no"!) Here's
some of the replies:
> Excellent idea. Run with it.
> I certainly would have no complaints about a networking section.
> This is something that I would definitely like to see.
> I think that the possible employment section would be a great idea.
> Sounds O.K. to me, John. I don't think it would hurt anything. Would you
> summarize the reasoning for me if this proposal is denied?
Consequently, I'm asking if you have Synopsys related job openings, send
them in two line format and they'll be posted. - John
|
|
