Subject: RE: [vhdl-200x-perf] Sensitivity Lists, semantics, and execution
From: Bailey, Stephen (SBailey@model.com)
Date: Thu Nov 06 2003 - 17:35:12 PST
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 : Thu Nov 06 2003 - 17:42:26 PST