Subject: RE: [vhdl-200x-perf] Sensitivity Lists, semantics, and execution
From: Jay Lawrence (lawrence@cadence.com)
Date: Fri Nov 07 2003 - 17:45:32 PST
Jim,
To back up Steve's comments. In general simulation vendors like you to
code what you mean, what is intuitive to you, in the simplest means
possible. Then we twist it in all sorts of unnatural ways to make it go
fast.
If you right something simple like:
AReg <= A when rising_edge(Clk) ;
We can easily recognize all sorts of fun optimizations (only wake up on
rising edge, only assign when A is new (assuming no one waits on
Areg'transaction).
If you get cute and try to right:
process (A, Clk)
variable old_a : std_ulogic;
begin
if rising_edge(clk) then
if (old_a != A)
Areg <= A;
end if;
end if
end process;
This becomes much more difficult to read and harder to recognize as the
simple latch that it is.
As long as we preserve the semantics of the reference simulation model
we can do anything we want.
Jay
===================================
Jay Lawrence
Senior Architect
Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
> -----Original Message-----
> From: Bailey, Stephen [mailto:SBailey@model.com]
> Sent: Thursday, November 06, 2003 8:35 PM
> To: 'vhdl-200x-perf@eda.org'
> Subject: RE: [vhdl-200x-perf] Sensitivity Lists, semantics,
> and execution
>
>
> Jim,
>
>
> The LRM makes no comment about optimizations. If the
> behavior of the simulator after applying optimizations is
> equivalent to the behavior without optimizations (assuming
> the unoptimized behavior is compliant with the LRM), then the
> optimizations are also compliant with the LRM.
>
> I can tell you that, at least some, if not all, VHDL
> simulators already apply these optimizations in many situations.
>
> On the need for enhancing sensitivity lists, this is a
> (mostly) different question. Here's the reasons I can think
> of for enhancing sensitivity lists:
>
> 1. It simplifies the recognition of when certain
> optimizations can be applied (which would make compilation faster).
>
> 2. It allows compilers, linters, etc. to help ensure that
> the designer's intent holds. For example, if a FF is
> specified but the process code would infer a latch (or
> combinatorial is desired and a latch is inferred), then the
> compiler or linter could easily flag such inconsistencies
> between design intent and what was actually coded. I know
> tools do this today, but with explicit intent, there would be
> far fewer false errors reported.
>
> 3. If done properly, it should reduce the coding without
> sacrificing readability.
>
> 4. In fact, readability and maintainability should be
> enhanced as the design intent is directly specified and not
> inferred from the coding style.
>
> -Steve Bailey
>
> > Future RTL coding styles will permit the following
> > to generate a register:
> >
> > AReg <= A when rising_edge(Clk) ;
> >
> > Implicitly, both A and Clk are on the sensitivity list.
> >
> > Are simulators currently allowed to analyze the semantics
> > of code and remove signals from the sensitivity list,
> > such as A, to improve performance?
> >
> > If not, is there language we can add to enable this?
> > In addition, since the rising edge function is used here,
> > can the statement only be activated on the rising edge of
> > clk?
> >
> > Similarly with a wait statement in a process, can the
> > simulator only run the process on the rising_edge of Clk:
> > process
> > begin
> > wait until clk ='1' ;
> > AReg <= A;
> > end process ;
> >
> > Similarly for:
> > process
> > begin
> > wait until rising_edge(clk) ;
> > AReg <= A;
> > end process ;
> >
> > Likewise can a clocked process using a sensitivity
> > lsit and the rising_edge of clock:
> > process(Clk)
> > begin
> > if rising_edge(Clk) then
> > AReg <= A ;
> > end if ;
> > end process ;
> >
> > Although these are very limited cases, these
> > are common and frequent in RTL code.
> >
> > Going further, the following is also in the
> > proposed revision to the VHDL RTL subset.
> > BReg <= B when rising_edge(Clk) and LoadEn = '1' ;
> >
> > It would be desirable if the simulator were permitted
> > to have full understanding of the semantics of the statement
> > when it considers the statement for evaluation. Hence
> > only wake up on rising_edge of clock, or better, only wake
> > up on a rising_edge of clock when LoadEn = '1'.
> >
> >
> > And perhaps also for the similar process forms:
> > process
> > begin
> > wait on Clk until Clk = '1' and LoadEn = '1';
> > BReg <= B;
> > end process ;
> >
> > process
> > begin
> > wait until rising_edge(clk) and LoadEn = '1';
> > BReg <= B;
> > end process ;
> >
> > process(Clk)
> > begin
> > if rising_edge(clk) and LoadEn = '1' then
> > BReg <= B;
> > end if ;
> > end process ;
> >
> >
> > If these type of optimizations are permitted, I
> > think it would eliminate the need to enhance
> > sensitivity lists for performance. If a
> > simulator did this now, would anyone be able to prove
> > it is a violation of the current standard?
> >
> > Likewise for subprograms:
> > procedure DFF (
> > signal Clk : in std_logic ;
> > D : in std_logic ;
> > signal Q : out std_logic
> > ) is
> > begin
> > if rising_edge(Clk) then
> > Q <= D;
> > end if ;
> > end process ;
> >
> > ...
> >
> > DFF(Clk, C, CReg) ;
> >
> > Note, for synthesis, these procedures are likely
> > to be called concurrently. Furthermore, it is
> > unlikely that a procedure that is called concurrently
> > like this would use a wait statement (since it will stop
> > an addional time and perhaps execute incorrectly).
> >
> >
> > Regards,
> > Jim
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Jim Lewis
> > Director of Training mailto:Jim@SynthWorks.com
> > SynthWorks Design Inc. http://www.SynthWorks.com
> > 1-503-590-4787
> >
> > Expert VHDL Training for Hardware Design and Verification
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >
>
This archive was generated by hypermail 2b28 : Fri Nov 07 2003 - 17:53:23 PST