( Post 107 Item 1 ) ----------------------------------------------------------
From: cindy@ca45.zoran.hellnet.org (Cindy Eisner)
Subject: compile/characterize
hi john,
i got the following direct request from an esnug reader, so i figured i
might as well share it with everyone.
Cindy Eisner, CAD group,
Zoran Microelectronics LTD,
Advanced Technology Center
Haifa 31204, Israel
in response to a question from an esnug reader:
>
> I was going back thru the ESNUG postings and came across your where
> you had talked about "avoiding endless loops of compile/characterize"
> I want to get your advice on how to break out of this loop.
>
well, so much depends on the nature of your model and the quality of your
initial constraints, which you do not describe. for instance: size of
sub-modules, is there any logic at the top level or just instantiations,
are your initial constraints educated guesses or just plain guesses, how hard
is it to generate better guesses, how well do the intermediate results compare
with the desired results, etc. still, here are some thoughts as to the
specific steps you take:
> This is the way I am currently handling this
>
> foreach submodule
> apply timing info, constraints manually
> compile
> ungroup
> save db
this is an excellent start. have you checked if maybe it is also enough?
that is, maybe you can stop here?
>
> top_level
> read all sub db's
> link
> reset
> apply top level timing and constraints
>
if there is logic in the top level, then i understand what top level
constraints are. but if there is not (and i suspect so), then how
do top level constraints differ from the sub-module constraints? every
top module constraint can be directly translated into a sub-module
constraint if the top module is all connectivity.
> characterize each submodule
> cd submodule
> compile ( to meet the top level constaints )
> write script
i guess what you are doing here is trying to make up for your bad guesses
in the first step. but, depending on the run-time of your synopys compiles,
it might be better to just do the first step again, correcting the guesses.
this is assuming that your model is stable enough.
>
> foreach submodule
> edit script and change unwanted stuff
> compile
> save
what is this unwanted stuff?
>
> cd top
> dont_touch submodules
> compile -incremental
> write -hier
ok, from here i would guess that maybe you do have logic at the top level.
you might want to consider moving it to a submodule of its own.
>
>
> Anything I can do to improve this
>
well, that's what i can think of off the top of my head. in general, what i
was getting at when i talked about getting out of the endless loop of compile/
characterize is that in the long run, it is generally easier FOR ME to
gradually get to the point of precise initial constraints, so that i need
to do one compile for each sub-module (and none for the top, since it is
all connectivity) rather than multiple ones. again, a lot depends on the
nature (and especially on the size) of your model, and on its stability
(how many times are you going to have to run your script?).
as long as i've gone to the trouble to write this up, i hope you won't mind
my forwarding it to the esnug as well. i am taking out your name, in case
that is a problem for you.
cindy.
( Post 107 Item 2 ) ----------------------------------------------------------
From: moss@mdd.comm.mot.com (Barry Moss)
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. :-)
Now if I could just find a way to get Synopsys to produce HPGL so I could
use our plotter and produce schematics of my state machines and register files
that I could actually read...
Barry Moss
Motorola - Mobile Data Division
Richmond, BC CANADA
( Post 107 Item 3 ) ----------------------------------------------------------
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.
Any suggestions on how to get synopsys to generate resetable logic? I'm using
VIEWlogic 5.1 to simulate the gates.
I've resorted to async resets to get around this problem, but I would like
to use sync resets (design policy).
Walter Brooks
Digital Video Systems
A subsidiary of Scientific Atlanta
---------- cut here -----------
use work.arithmetic.all;
entity ramcnt is
port(
reset : in vlbit; -- sync reset
ck455 : in vlbit; -- master clock
inc_ram : in vlbit; -- increment enable
ld_ram : in vlbit; -- load enable;
ld_addr : in vlbit_1d(14 downto 0); -- initial address
addr : out vlbit_1d(14 downto 0) -- ram address
);
end ramcnt;
architecture behaviour of ramcnt is
constant ACTIVE : vlbit := '1';
constant DISABLE : vlbit := '0';
signal count : vlbit_1d(14 downto 0);
begin
cnt:
process
begin
wait until ck455='1' and ck455'event;
if reset='0' then
count <= b"000000000000000";
else
if ld_ram=ACTIVE then
count <= ld_addr;
elsif inc_ram=ACTIVE then
count <= inc(count); -- just increments by 1
end if;
end if;
end process;
addr <= count; -- inout's conflict with other tools
end behaviour;
|
|
