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

The issue was if a subprogram reads a signal not in its parameter list
should it be considered part of the sensitivity list or should it be considered
an error. The Verilog mistake was that @* does neither, so the user
incorrectly thinks the sensitivity list is complete when it is in fact
incomplete.

Making it an error makes life of the compiler writer simpler and since
most if not all synthesis tools don't allow reading of non-parameter signals
in subprograms, it doesn't seam to be to great of restriction.

On the other hand adding it would allow synthesis tools to improve in
the future.

Regards,
   John

Bailey, Stephen wrote:
> 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 -----
> > | > |
> > | > |
> > | > |
> > | >
> > | >
> > | >
> > |
> > |
> >
> >
> >
>

-- 
-- mailto: johnr@model.com     phone: (503)685-0864
--   http://www.model.com        fax: (503)685-0921
--