RE: [vhdl-200x-ft] Ft19 process_comb

I agree with Charlie's summary. It nicely captures the discussion. The process(all) feature captures the process input/sensitivity side of the equation. The process type (design intent) is captured by monitoring the output behavior.

I believe that the proposal is for FT to address the process(all) capability where this captures the design intent of sensitivity on all signals read in a concise and easy-to-maintain manner.

Further assertions as to the intended behavior of a property could be added in a subsequent revision. It seems the discussion is whether the FF, latch and combinatorial intent capturing should be included in FT or deferred.

-Steve Bailey

> -----Original Message-----
> From: owner-vhdl-200x-ft@eda.org
> [mailto:owner-vhdl-200x-ft@eda.org] On Behalf Of Charles Guy
> Sent: Thursday, October 07, 2004 10:25 AM
> To: vhdl-200x-ft@eda.org
> Subject: Re: [vhdl-200x-ft] Ft19 process_comb
>
> The point of ft19 is two fold. One is to automatically build
> a sensitivity list. The other is to check the intent of the process.
>
> The discussion of the use of all addresses the first issue.
> However, the second issue appears to be ignored or dropped in
> the current discussion.
>
> The intent of a process may be to create some combinatorial
> logic, create some latched values, or create some flip flops.
> Having the compiler confirm/check the code matches the
> intended purpose is a big time saver for the designer. It is
> a big time sink to change code late in the design cycle after
> finding the synthesis tools creates unintended logic like latches.
>
> The three process types proposed are to allow a designer to
> declare the intended behavior of a process. This is intended
> to be checked at compile time to verify that the process code
> matches the declared intention. This would be highly useful
> even if restrictions are placed on these new processes.
> Restrictions might include:
> use only signals visible in the current entity (no global)
> all functions must be pure function calls Those who wish
> to do the above still can use a standard process.
>
> The checking is then all about the outputs of the process.
> The checking consists of ensuring the output assertions match
> the intended function.
> Three checks are required to ensure this.
> process_comb check that all the outputs are asserted for
> each evaluation of the code
> process_latch check that all the outputs are held based
> on some combination of inputs
> process_ff check that all the outputs are clocked based
> on a single signal (clk).
> check that all asynchronous signals affect
> all outputs.
>
> Are there other items that need checking? Do other things
> need to be added? These could be expanded to include
> additional options in the future.
>
> Keep in mind that I assume the input sensitivity list is
> automatically generated as if (all) were used.
>
> Then the question becomes, what is the complexity of adding
> these checks?
>
> Charles B. Guy Voice (503) 628-0643
> Avsys Corp. FAX (503) 628-5401
> www.avsyscorp.com email cbguy@avsyscorp.com
>
> ----- Original Message -----
> From: "Ajayharsh Varikat" <ajay@cadence.com>
> To: <dbishop@vhdl.org>
> Cc: <vhdl-200x-ft@eda.org>
> Sent: Wednesday, October 06, 2004 1:26 AM
> Subject: Re: [vhdl-200x-ft] Ft19 process_comb
>
>
> |
> | I think somebody had proposed this earlier also, though
> | I can't remember why we went back to "process_comb". To
> | me, this looks the cleanest syntax for providing sensitivity
> | to all signals read by a process.
> |
> | I also support your suggestion that we drop latch and ff processes
> | from this revision. I never really liked the idea of introducing
> | new kinds of processes or primitives into the language for modeling
> | FF or latch functionality - it somehow goes against the VHDL
> | tradition of simply providing the required language mechanisms and
> | leaving it to users to define behavior.
> |
> | -ajay
> |
> |
> | ----- Begin Included Message -----
> |
> | From owner-vhdl-200x-ft@eda.org Tue Oct 5 19:44 IST 2004
> | Date: Tue, 05 Oct 2004 10:13:21 -0400
> | To: vhdl-200x-ft@eda.org
> | Subject: [vhdl-200x-ft] Ft19 process_comb
> | X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version
> 0.74a
> | on server
> | X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version
> 0.74a
> | on server
> | X-Virus-Status: Clean
> | X-Virus-Status: Clean
> | Sender: owner-vhdl-200x-ft@eda.org
> |
> | Came up with an interesting solution to our discussion last night.
> |
> | How does this sound:
> |
> | process (all) is
> | a <= b and c;
> | end process;
> |
> | Simply state that if keyword "all" (which is already a
> reserved word)
> | appears in the sensitivity list then all of the inputs to
> that process
> | will appear on the sensitivity list.
> |
> | I think that this is a much more generic solution than
> "process_comb".
> | Also with the discussions last night around "process_latch" and
> | "process_ff" I think that they should probably be dropped in this
> | round.
> |
> | --
> | David W. Bishop dbishop@vhdl.org All standard
> disclaimers apply.
> |
> |
> | ----- End Included Message -----
> |
> |
> |
>
>
>
Received on Thu Oct 7 10:51:14 2004