( ESNUG 246 Item 4 ) ---------------------------------------------- [8/8/96]
Subject: (ESNUG 245 #1) My Multicycle Path Odyssey With Synopsys So Far...
> [...] ending at the same point can be dangerous. That is exactly what I'm
> doing above, since there is a multicycle path of 3 from A to B, and a
> "multicycle path of 1" from change_B to B.
From: kaufmann@shraero.shraero.co.at (Roland Kaufmann)
Well, IMHO the signal change_B (called ENA in the code below) changes only
every third cycle, so you have a "multicycle path of 3" to your
register B (called STATE below).
I had a design which produced a bit-serial stream of data which was
processed internally in 4-bit chunks, so most of the chip effectively
ran at oune fourth of the clock CLK using a timing signal ENA to
enable the registers every 4th CLK cycle:
-- This is the register, updated on posedge CLK when ENA = '1'
Storage: process (CLK, RESETn)
begin
if (RESETn = '0') then
STATE <= (STATE'range => '0');
elsif (CLK'event) and (CLK = '1') then
if (ENA = '1') then
STATE <= NEXTSTATE;
end if;
end if;
end process;
-- The combinatorial logic (STATE + 1 in Andy's case)
Feedback: process (STATE, inputs)
begin
NEXTSTATE <= f(STATE, inputs)
end process Feedback;
Then I had to tell Synopsys about the multicycle paths for *every*
such register:
set_multicycle_path 4 -setup -hold -to { "INSTANCE_NAME/STATE_reg[*]" }
this was kinda tedious but our design was small enough to allow this.
What I would try next time is to encode the name of the enable signal
in the register so that I can use a 'foreach' construct to set the
multicycle path on these regs.
It gets more difficult when you have several such signals which are
having different periods, as Synopsys' documentation is not very clear
about this. I also was amazed that the construction above was not
mentioned anywhere in the documentation/application notes --- it
sounds like a common problem to me.
- Roland Kaufmann
SCHRACK Aerospace
---- ---- ---- ---- ---- ----
From: Vlad Sindalovsky <vlad@aloft.att.com>
Hi John,
I could not help jumping into discussion on "Multicycle path Odyssey...".
Let me diverge from the usual bug/workaround routine and dwell on design
style in general.
Every time I read or hear: "Our design is fully synchronous", I get
bewildered. Why? Is synchronous design really better or this is just
surrender to the tools which handle synchronous design easier?
When the signal SAMPLE_B had been created in aforementioned design, it
was only one step left to enter "The unknown land" of asynchronous
design. Let us consider:
SACRILEGE: PROCESS (SAMPLE_B)
begin
if (SAMPLE_B'event and SAMPLE_B='1') then
B <= A + 1;
end if;
END PROCESS SACRILEGE;
If SAMPLE_B is generated appropriately, and there is enough time for A+1
to settle, the correct value of A+1 will be written into register B on
the rising edge of the new clock signal.
Advantages:
- register B is always kept clean;
- the description is very well synthesizable in Synopsys (I tried
something like this many times);
- register B is clocked when necessary, reducing power consumption;
- no additional "crazy" schematic (mux's or registers);
Penalty to pay:
- the content of register B changes with some delay from the edge of
the system clock;
If you handle the output of register B as a regular delayed output of
combinational logic, you can literally end sacrilege with the end of the
process, described above, and return to the Holy Land of Synchronous
Design.
- Vlad Sindalovsky
Lucent Technologies
|
|
