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

I suggest taking the easy route for FT: Make it an error if something outside the parameters of a subprogram is referenced.

We can back off this restriction in a future release, if desired.

-Steve Bailey

> 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
> --
>
>
>
Received on Fri Oct 8 11:18:19 2004