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

It was my understanding from the meeting that:

Process(all)

Would add ALL signals read by the process to the sensitivity list. This would include signals read in subprogram calls and global signals. As I recall, part of the discussion was that Verilog screwed up with (@*) in that it does not traverse subprogram calls to construct the entire sensitivity list.

-Steve Bailey

> -----Original Message-----
> From: owner-vhdl-200x-ft@eda.org
> [mailto:owner-vhdl-200x-ft@eda.org] On Behalf Of Charles Guy
> Sent: Friday, October 08, 2004 10:45 AM
> To: vhdl-200x-ft@eda.org
> Subject: Re: [vhdl-200x-ft] Ft19 process_comb
>
> First, please ignore my discussion about checks. Let us
> return to the current FT-19 proposal as the basis for
> discussion. The goal is to include FT-19 in the next release of 1076.
>
> In our 10/4/04 meeting global signals were discussed at
> length. Yet, the proposal explicitly flags use of global
> signals as an error.
>
>
> Any problems with not allowing global signals in these
> special processes?
>
>
> Can we leave the special processes at the erroneous level for
> this release?
>
>
> Could we add some wording around erroneous indicating that a
> future release will replace erroneous with error?
>
>
> Charlie Guy
>
> ----- Original Message -----
> From: "Bailey, Stephen" <SBailey@model.com>
> To: <vhdl-200x-ft@eda.org>
> Sent: Thursday, October 07, 2004 10:51 AM
> Subject: 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 Fri Oct 8 10:43:48 2004