( Post 108 Item 1 ) ----------------------------------------------------------
From: frazer@idtinc.COM (Andrew Frazer)
Subject: Plotting Question in ESNUG Post 105
>>In ESNUG 105 Robert Marshall asks, "Can anyone confirm/deny that Synopsys
>>postscript output will not print to a Sun SPARCprinter...?"
>
>Well I can confirm that Sysnopsys _will_ plot correctly on a Sun
>SPARCprinter; I've been doing it all week and it's much faster than our old
>QMS laser. :-)
That's interesting. The last time I tried was with Synopsys 2.2a and we could
not print through a SUN SPARCprinter. Synopsys told us that that that
particular printer was interpreting the PostScript wrong and Sun told us that
Synopsys was outputting PostScript wrong. I never tried it with Synopsys
2.2b. Thanks for the tip.
Andy Frazer
Integrated Device Technology
( Post 108 Item 2 ) ----------------------------------------------------------
From: cindy@ca45.zoran.hellnet.org (Cindy Eisner)
> From: brooks@dvs.com (Walter Brooks)
> Subject: problems generating synchronous resets with SYNOPSYS 2.2b.
>
> Hi,
>
> I've been having problems generating synchronous resets with SYNOPSYS 2.2b.
> I've included the entire code for anyone that wants to try this problem out.
>
> Synopsys generates gates that will not reset.
walter,
you do not say why they won't reset. i am assuming that they stay in x,
rather than simply showing wrong behavior. if so, look at esnug posts
60 through 70 (starting with paul micheletti's post in #60) for a discussion
of correct but un-simulatable logic. good luck.
Cindy Eisner, CAD group, Zoran Microelectronics LTD
- - - - - - - - - - - - - - - - - - - - - -
From: "Victor Duvanenko" <victor_duvanenko@gatormail-m.truevision.com>
Subject: Post 107 item 3 problems generating synchronous resets w/ SYN 2.2b
You've hit on a good one!!! I ran into this one about a year and a half ago
and it's still not solved. Synopsys even has an application note on this one,
and the best solution is to use global asynchronous reset on all flip-flops. I
do not forsee a solution to this problem in the near term either, because it is
a logic simulator problem and not a synthesis problem (if you dig deep enough
into the problem). The logic is right (i.e. all possible logic cases are
covered, except X's), so the circuit will work in real life, but the logic
simulator can't deal with it, because it thinks initializes all nodes to X's
(even Q and not Q out of flip-flops, which truely should be X and not X). And,
the problem propagates from there.
My advice is try to make reset arrive really late (i.e. close to the sampling
clock edge of your flip-flops) to move the reset logic close to the D input of
the FF. If that doesn't work the asynchronous reset will (but your clock to Q
is a bit slower on those FF's).
In v3.0 Synopsys talks about other possible solutions. Good luck!
-Victor J. Duvanenko (victor@truevision.com)
- - - - - - - - - - - - - - - - - - - - - -
From: smartin@comanche.ess.harris.com (Stacy Martin)
Subject: Post 107 item 3 problems generating synchronous resets w/ SYN 2.2b
The following case statement results in the signal SYNC_RESET_N
being synchronuos and simulates correctly in VHDL and gates ->
process (CNT_ENABLE_N, CLK, RESET_N, SYNC_RESET_N)
begin
--Asynchronous Reset
if(RESET_N = '0') then
STATE <= s0;
ADD <= "10000000";
elsif(CLK'event and CLK = '1') then --clock state machine on rising edge
case STATE is
when s0 => --add = 7
if(SYNC_RESET_N = '0') then --make "ramcnt" architecture
STATE <= s0; --a case statement vs. an
ADD <= "10000000"; --if/then/else
elsif(CNT_ENABLE_N = '0') then
STATE <= s1;
ADD <= "00000001";
else
STATE <= s0;
ADD <= "10000000";
end if;
when s1 => --add = 0
if(SYNC_RESET_N = '0') then
STATE <= s0;
ADD <= "10000000";
elsif(CNT_ENABLE_N = '0') then
STATE <= s2;
ADD <= "00000010";
else
STATE <= s1;
ADD <= "00000001";
end if;
--=======etc.
Stacy Martin, Harris GASD, Palm Bay, Fl.
- - - - - - - - - - - - - - - - - - - - - -
From: Juno <heine@cortez.etdesg.trw.com>
Subject: Post 107 item 3 problems generating synchronous resets w/ SYN 2.2b
In regards to the synchronous reset problem encountered in 2.2b. We just
ran into the exact same problem. What happens is the reset logic in front
of the flip flop is optimized away so the reset line actually has to travel
through several layers of logic before reaching the input to the flip flop.
A basic simulator problem is what causes the error - if any of the other
signals combined with the reset happen to be unknown - as they will be at
startup in a simulator, then the output of that gate will be unknown - that
is how the simulation model is written. So, unknowns get propogated through
your design to the input of the flip flop and it never gets reset! The
problem is solved in 3.0a with a compile variable called
compile_preserve_synch_resets
It is defaulted to false, you must change it to true, then compile - works
like a charm! The only other solution I can think of is to use their new
design ware products and produce a synchronous resetable flip flop for the
design compiler to choose, then your reset logic will always be with the flip
flop.
Good luck!
Juno A. Heine
TRW, Inc.
( Post 108 Item 3 ) ----------------------------------------------------------
From: uunet!uranus!splinter!flieder (Jeff Flieder)
Subject: Problems Inferring Muxed-D Flip-Flops
John,
I've been an avid reader of ESNUG for about a month now, and have
found it to be extremely useful for my Synopsys evaluations. I have
answered a few questions on the net, and now it my turn to ask one.
This has to do with the synthesis of flip/flops.
I am currently using Motorola's MDA08 synthesis library and I am
having trouble getting Synopsys to infer a muxed-D flip/flop. The
following is an exerpt of code from one of my models:
always @(negedge ph1 or negedge iresetbx)
begin
if (!iresetbx)
ppdir = 6'b0;
else if (!(enpddrx | wrbx))
ppdir = iimbus;
end
This synthesizes to two components per bit, a MUX2H and a DFFRP. These
components are a 2-input mux and a D flip/flop with asynchronous
reset.
Here is the problem: The library include a number of muxed-D
flip/flops which would lead to a smaller design, but it is impossible
to get Synopsys to use them correctly. If I force the use of the muxed
flip/flops, the tools simple grounds the select line and the second input,
and uses a the mux on the first input, not too bright!
Has anyone had luck in inferring muxed-D flip/flops ? If so I would
appreciate any help. Thanx in advance, and happy synthesizing.
Jeff Flieder, Senior Engineer, I.C. CAD Development
Ford Microelectronics, Inc., Colorado Springs, CO 80921-3698
|
|
