( Post 60 Item # 1 ) -------------------------------------------------------
From: Paul Micheletti 3774 <pm1@ws081.torreypinesca.NCR.COM>
Subject: Response to Posting 59 Item #1.
> [ parkin@ultrasparc.Eng.Sun.COM (Michael Parkin) writes: ]
>
> The selector operator will propagate unknowns (provided
> in0 & in1 are different) and is more concise.
>
> assign result = a ? in0 : in1;
>
> If "a" is unknown and (in0 == in1) the return value should be
> known. Muxes should be modeled in this way so that the
> gate-level logic simulates correctly, otherwise some flip-flops
> will not reset.
When using Synopsys for ASIC design where you desire simulatable logic
using the same test vectors as were run in VHDL land, this method will
not always work due to a problem Synopsys has with resetable logic.
Most gate-level simulators will produce a behavior different from the
one described above. If Synopsys generates logic where the (synchronous)
RESET signal sets both inputs to a multiplexer to the same value, but
the select line for this mux is not gated with RESET (thus unknown upon
initialization), then the output of this mux will be unknown in most gate
level simulators.
The problem we should be addressing here is not how to guarantee that
this mux will always generate a known value when both inputs are the same,
but how to get Synopsys to generate logic that a gate-level simulator will
be able to reset. Toying with the timing constraints can fix the problem
on one flip-flop in a low-level module, but could cause a similar problem
in a different flip-flop in the same module.
After invloving Synopsys AE's for a couple of weeks on this one, we gave up
and changed all of our flip-flops to have Asynchronous resets. This was
the only way we could guarantee that the results from our VHDL simulations
matched those of our gate-level simulations.
Synopsys needs to allow the user to define a signal as a synchronous reset
so that it's ability to reset a circuit is not compromised. In keeping with
Synopsys' naming tradition, we should have a new directive with as many
words as possible:
set_this_signal_to_be_reset_so_dont_allow_unknowns_on_this_logic_please RESET
-- Paul Micheletti NCR Torrey Pines Development Center
-- email: paul.micheletti@SanDiegoCA.NCR.COM
( Post 60 Item # 2 ) -------------------------------------------------------
From: bygate@ncrcol.columbiasc.NCR.COM (Terry Bygate)
> 3) We are using the IEEE MVL9 system instead of bit, or Synopsys's MVL7.
> Unfortunately, all of Synopsys's documents use bit.
I believe Synopsys has provided the hooks for this. I have been told that
the simulator allows users to map their own MVL to Synopsys's MVL7 (although
I would guess that there is no equivalence to the states that are unique to
your MVL system).
The synthesis tool, on a limited basis, has the same type of capability.
But, I believe it is limited to Synopsys vhdl output. See vhdlout_bit_type
and related variables. It gets kind of tricky, though, when your simulator
and synthesizer use different MVL's and you want to simulate the code you
run through the synthesizer. Actually, the work around that we got from
the hotline is quite kludgy. (No reflection on the hotline. They were
very helpful).
We (I say we because it was another persons design, and I was helping him)
created a subtype, which was used throughout the design. The subtype
definition was setup in a file (or maybe a package or a library ?) which was
included in the design. Two files were created, one for simulation (based
on type qsim_state - gee, can you guess which simulator we use) and another
for synthesis (based on bit, bit_vector, etc.).
It would be nice if Synopsys synthesizer recognized other MLV sets when
reading in VHDL, especially if they have gone to the trouble of allowing
one to use alternate MLV sets for output.
|
|
