Subject: [vhdl-200x-perf] Re: From VASG/VHDL-200X meeting notes, ...
From: Jim Lewis (Jim@SynthWorks.com)
Date: Tue Dec 09 2003 - 10:22:26 PST
Steve,
>>From a use model consideration, it is unreasonable to expect users to
> change existing code to explicitly identify clocks. It also would not
> be required to do so going forward as synthesis tools and simulators
> would continue to be able to handle the current modeling status quo.
I agree. No changes to RTL and most code.
Ideally explicit clock identification should happen
at the clock driver. If the clocks and all derived
clocks are updated before any other processes run,
then we don't have any clock/data race conditions.
So one candidate implementation would be to generate
clock and derived clocks with a procedure:
Gen_Clock(Clk, ...) ;
Gen_Derived_Clk(Clk1, Clk2, ...) ;
Probably lots of othe ways to do this (attributes?).
This should not break or require any changes to
any existing code. However, with future code
and any code that is running too slow, replace
the clock (testbench) and derived clock generation
logic (possibly in the RTL code), with the above,
and the "after 1 ns" can be removed.
If this were added to the language and it solved the
delta cycle aligning problem, I would use it and
recommend it as soon as it was implemented in
simulators.
Then add to this something that wakes up during the
"clock update cycle" (that precedes all other processes),
such as the following:
-- assume currently aligned with clock and clock period = 10 ns
Wait_for_Clock_Period(100 ns) ;
Use this instead of either of the two following code segments:
for i in 1 to 10 loop -- assuming that clock is 10 ns ;
wait until rising_edge(clk) ;
end loop ;
or instead of:
wait for 100 ns - 1 ns ;
wait until rising_edge(clk) ;
Cheers,
Jim
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Bailey, Stephen wrote:
> That's another possible solution. I'll defer to John and any other > implementor as to which is the most efficient. > >>From a use model consideration, it is unreasonable to expect users to > change existing code to explicitly identify clocks. It also would not > be required to do so going forward as synthesis tools and simulators > would continue to be able to handle the current modeling status quo. > > -Steve Bailey > > >>-----Original Message----- >>From: Jim Lewis [mailto:Jim@SynthWorks.com] >>Sent: Monday, December 08, 2003 3:42 PM >>To: Bailey, Stephen >>Cc: Ries, John >>Subject: Re: From VASG/VHDL-200X meeting notes, ... >> >> >>Steve and John, >>Or the user gets smarter and derives all the clocks to be >>delta cycled aligned. Ok, they can't always do this (yet). >> >>Perhaps you want to consider looking at the problem >>from the other side. Rather than trying to put a delay >>on data, is there a way to model clocks and derive clocks >>so that they always get executed before anything else? >>Perhaps even go as far as create a special "pre-cycle" >>that is before the first simulation cycle of a time step. >> >>Keeping on this vein, but going in a different direction, >>perhaps rather than writing code to model clock, >>we create a clock construct. Perhaps rather than >>deriving a clock, we create a clock derivation construct >>(using the clock derivation construct is special and >>results in ...)? >> >>Clocks are special in hardware, it would not necessarily >>be wrong to treat them as such in an HDL. Perhaps even >>good things could happen for simulation? >> >>It would be nice if an exact semantic could always >>happen for: >>wait until Clk = '1' ; >>Sel <= '1' after 2 ns ; >> >>wait for 10 * tperiod_clk ; >>wait until Clk = '1' ; >>Sel <= '1' after 2 ns ; >> >> >>Depending on how clock gets created both of the above >>can differ by a clock period. >> >>Could we also derive a more efficient way to wake up >>when waking up on a clock edge? For example, if I >>change the above example to the following, it always >>wakes up in 10 clocks: >> wait for 10 * tperiod_clk - (0.5 * tperiod_clk); >> wait until Clk = '1' ; >> >>tLets assume that I know that I am starting the above >>aligned to the rising edge of clock. Is there >>a way to extend wait so that I can use a single wait to >>wake up during the "clock evaluation cycle" of the >>10th edge of clock. >> >> wait for clock 10 * period_clk ; >> >>Cheers, >>Jim >> >>Bailey, Stephen wrote: >> >> >>>The issue is that alot of people model DFFs with unit delay: >>> >>> process(clk, rst) >>> begin >>> if (rst = '1') then >>> Q <= '0'; >>> elsif rising_edge(clk) then >>> Q <= D after 1 ns; >>> end if; >>> end process; >>> >>>The point is to avoid race conditions if the output of the >> >>DFF flows to an input to another FF that has a derived clock >>(for example, a gated clock). If we know what users are >>trying to do, then we can do it with higher performance. >> >>>-Steve Bailey >>> >>> >>> >>>>-----Original Message----- >>>>From: Jim Lewis [mailto:Jim@SynthWorks.com] >>>>Sent: Monday, December 08, 2003 2:29 PM >>>>To: Bailey, Stephen; Ries, John >>>>Subject: From VASG/VHDL-200X meeting notes, ... >>>> >>>> >>>>What is this? >>>>-------------- >>>>Need a unit delay assignment or a Verilog-type NBA >>>>update phase to avoid race conditions related to outputs >>>>of DFFs and inputs of other DFFs >>>> >>>>John Ries will own
This archive was generated by hypermail 2b28 : Tue Dec 09 2003 - 10:22:42 PST