Re: [Iverilog-devel] Always blocks with out delays (pr1862744)

[Cary R. <cy...@ya...>]

--- On Sat, 4/19/08, Stephen Williams <st...@ic...> wrote:

> Well, if you pass a control flag to the calculation of this
> state,
> then you are implying that it is calculated on demand,
> possibly
> multiple times (and possibly no times) whereas if you just
> calculate
> the more expressive value, then you can reuse the value for
> different
> needs. (Again, perhaps you need it zero times.)

For the always I think it should be calculated each time since the delay could change for each instantiation of the module.
 
> My sense is that if every always statement is going to need
> this
> value, then it is going to be needed almost always, and
> might as
> well be calculated during elaboration. It strikes me that
> it will
> be very easy to calculate during elaboration, skipping the
> need
> for a post-process recursive test later when the data is
> needed.

If we make this part of the general elaboration then initial blocks will also do the calculations and my feeling is that there are far fewer always block. I would also guess that always blocks are in general simpler.

> It can be that the expressive enum value be hidden behind a
> pair
> of boolean methods that the clients use, so this method if
> calculating
> the expressive value can have any reasonable interface.
> 
> Hmm, I'm thinking about where this information may be
> used, and
> I'm starting to realize that only NO_DELAY is useful.
> If you have
> an always statement, you want to generate a warning if it
> IS
> NO_DELAY, and if the NetProc is a function definition you
> want
> to generate an error if it is NOT NO_DELAY.

This isn't quit correct. NO_DELAY is correct for a function, but you want to print a warning for an always that has either no delay or may possible have delay. I was reflecting earlier and this probably would need to be a four state value. No delay, zero delay, possible delay and definite delay. A function definition can only have no delay and an always will not complain only when you definitely have delay. No and zero delay are definite infinite loops and possible delay may be an infinite loop.

I have build some basic infrastructure using NetProc and friends. I'm thinking that the four state method is the correct way to go so we can reuse the basic code for both the always and function checks. I think the function definition checks can cache their check state, but I think the always blocks need to be checked each time. Think about the following:

#<param_value>

This could be different for each module instantiation and when zero we would have a looping problem. Not matter what the value this is illegal in a function definition. 

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ