Re: Brainstorming VHDL 200x


Subject: Re: Brainstorming VHDL 200x
From: Evan Lavelle (eml@riverside-machines.com)
Date: Wed Apr 19 2000 - 07:30:09 PDT


Stephen Bailey wrote:

> > Good idea. I suppose the only downside is that simulation of clocked
> > processes will be slower if this is used indiscriminately. I suspect
> > that there will also be combinatorial cases in which pre- and post-synth
> > sims will differ (can't think of one right now) but this will be a case
> > of buyer bewares.
>
> You are missing the point. What Lance has proposed here is for
> *combinatorial* processes and not *sequential* processes (in usage).

That's why I said "if used indiscriminately". If the feature exists,
then there's nothing to stop it being used for clocked processes. The
sim's not going to complain, but will run slower.

> Synthesis style guidelines would still apply. Therefore synthesis tools
> would expect to only see the "clk" and "asynchronous control" (if any)
> signals in the sensitivity list for a sequential process.

The synth tools I use ignore the sensitivity list, but may issue a
warning if it's "wrong". I don't believe that I've seen warnings issued
if there are too many signals in the list. Certainly, a F/F template
will produce a F/F, irrespective of the contents of the sensitivity
list.

> Synthesis
> guidelines expect all signals read in a combinatorial process to be in the
> static sensitivity list. If the sensitivity list is incomplete, synthesis
> completes it. This can result in differences between simulation behavior
> and synthesis results.

Conversely, if the list is complete when it should have been incomplete,
then there's a potential for problems. It's easy to think of simulation
cases to demonstrate this, but more difficult to come up with something
synthesisable - that's why I said I couldn't immediately think of a
case.

I'm not disagreeing with Lance - as I said, I think it's a good idea,
but the user has to beware. It shouldn't be used indiscriminately.

Evan



This archive was generated by hypermail 2b28 : Wed Apr 19 2000 - 07:59:41 PDT