Re: [vhdl-200x] VHDL enhancements wish list

From: Daniel Kho <>
Date: Fri Feb 18 2011 - 07:58:28 PST

Hi Martin,
Yes, using "only the sensitivity list" to specify triggers for a process is
good. In fact, it makes more sense to just use the sensitivity list (without
the if-conditions).

However, the current industry practice now is for us to specify both the
sensitivity list AND the if-statement, which, I agree with you, makes the
scheme prone to mistakes :)

One thing we could do to improve this is we could add an edge specification
into the sensitivity list. This should tell the compiler which edge to
trigger, and which signal is the clock signal. Of course, there should only
be one signal that has a 'rising or 'falling specification:
*process*(clk'*rising*) *is*
   --synchronous logic here:
*end process*;

Here, the compiler should think that the clock signal is "clk", and
triggered at the rising edge.

For asynchronous signals within a clocked process, I was thinking of the
following. We just need to specify an "asynchronous block" within such a
process, and everything else outside of the block should be synchronous to
the rising/falling edge of the clock:
*process*(clk'*rising*, rst) *is*
   --something here to tell the compiler that these signals should be
   --I was thinking that specifying an asynchronous block should suffice:
   *asynch begin*
      *if *rst='1' *then *q<='0';
      *end if*;
   *end asynch*;

   --everything else outside of the "asynch" block should be synchronous to
*end process*;

This would mean the compiler should recognize the preceding description to
be equivalent to the following synchronous process with an asynchronous
*process*(clk, rst) *is*
   *if *rst='1' *then *q<='0';
   *elsif rising_edge*(clk) *then *q<=d;
   *end if*;
*end process*;

Just my thoughts. We can expand more on this idea.


On Fri, Feb 18, 2011 at 9:45 PM, Martin.J Thompson <> wrote:

> >>> On 18 February 2011 at 13:29, in message
> <>, Daniel
> Kho
> <> wrote:
> > Hi Martin,
> >
> > If Rst is in the sensitivity list, does this not imply an async
> reset? And
> > if not, then a sync reset?
> >
> > Yes, you're right. I think the intent of having Rst in the
> sensitivity list
> > together with specifying "synchronous" or "asynchronous" within the
> process
> > is to distinguish between the two.
> >
> That's my point - you don't need to specify it, the sensitivity list
> already does (and we're all already used to doing so). Specifying it
> twice allows you to get it wrong once :)
> (For example currently you can intend an async reset, but get a sync
> one:
> process (clk)
> being
> if async reset = '1' then this is actually a "both edges" sync
> reset!
> elseif rising_edge.....
> end if
> With a "just use the sensitivity list" approach, you can;t make that
> mistake...
> > Yes, we may need to evaluate how much gains this enhancement would
> bring to
> > the community. As for myself, I do try to use many small processes as
> much
> > as I can (sometimes with only several lines of code per process). I
> do start
> > with a big process in the beginning, but will try to break the
> single
> > process down into smaller processes.
> Out of interest (and maybe reply to this off-list ;) why do you feel
> theneed to break things down to very small processes?
> Cheers,
> Martin
> --
> Martin Thompson CEng MIET
> TRW Conekt, Stratford Road, Solihull, B90 4GW. UK
> +44 (0)121-627-3569 :
> Conekt is a trading division of TRW Limited
> Registered in England, No. 872948
> Registered Office Address: Stratford Road, Solihull B90 4AX

Daniel Kho
Confidentiality Notice.
This communication may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any use, disclosure, dissemination, distribution, or
copying of this message, or any attachments, is strictly prohibited. If you
have received this message in error, please advise the sender by reply
e-mail, and delete the message and any attachments. Thank you.
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Feb 18 07:59:17 2011

This archive was generated by hypermail 2.1.8 : Fri Feb 18 2011 - 07:59:23 PST