Subject: Re: SystemVerilog: always_comb and functions
From: Michael McNamara (mac@verisity.com)
Date: Thu Mar 28 2002 - 16:32:52 PST
Kevin Cameron x3251 writes:
> > From owner-vlog-pp@eda.org Thu Mar 28 11:15:00 2002
> >
> > Hi, All -
> >
> > A discussion came up on our conference call last Monday concerning whether
> > or not variables inside of functions, but not declared in the function
> > header, should be part of the always_comb sensitivity list. In
> > Verilog-2001, we explicitly said that the always @* combinational always
> > block did not have to descend into tasks and functions to find additional
> > variables to add to the sensitivity list. We did this to unburden the
> > language from being required to descend multiple levels of tasks calling
> > tasks that might recursively call tasks, etc.
> >
> > Based on our discussion, I contacted a group studying Superlog at Intel to
> > ask for their input. They gave what I consider to be good reasons to
> > require always_comb to find all internal function variables to add to the
> > sensitivity list. Their feedback follows.
> >
> > It should be noted that we are fortunate to have a group doing large
> > designs that sees more opportunities for abstraction. As a SystemVerilog
> > Standards Group, we have a tendency to focus on small examples that do not
> > really show how we can improve the Verilog language. The group from Intel
> > has clearly looked at a large design and the potential benefit that can
> > result from small changes to the Verilog syntax.
> >
> > From the SystemVerilog 3.0/draft 4 - section 10.3, page 40, 2nd bulleted
> > paragraph:
> >
> > The SystemVerilog always_comb procedure differs from the Verilog-2001
> > always @* in the following ways:
> > - <text>
> > - always_comb is sensitive to changes within the contents of a
> > function, whereas always @* is only sensitive to changes to the arguments
> > of a function.
> > - <text>
> >
> > PROPOSAL: do NOT change the second bullet. Users have found intelligent
> > ways to take advantage of this functionality to add both abstraction and
> > readability to their code.
> >
> > This does of course open another avenue for language abuse (function1 calls
> > function2 which calls function3 which calls function1 again, etc.) but it
> > will be up to us trainers to explain the features and benefits while still
> > warning against the unintended potential abuses.
> >
> > After seeing what the Intel group wants to do, I support the idea of
> > always_comb descending into functions (or perhaps tasks) to find signals
> > required for the sensitivity list.
> >
> > Regards - Cliff
>
> Argh... more stuff working against modular compilation... :-/
>
>
> > ==== Notes from a group studying Superlog at Intel ====
> ...
> >
> > We're open to other ideas. We had originally conceived of something like a
> > task/function that functioned as a macro. Each task/function call would be
> > replaced by its contents, in-place during parse or elaboration time so the
> > automagic sensitivity could be accurately calculated. We still like this
> > idea very much.
> >
> > <Cliff-note: in-place replacement would make line-reporting in debuggers
> > somewhat tricky. Tasks were intended to be abstractions for blocks of code.
> > We use read and write tasks all the time in Verilog Verification>
>
>
> I suggest that we add the keyword 'inline' for tasks and functions and restrict
> the use to only inlinable functions and tasks where appropriate. I don't think
> making the debuggers come up with the right source code is that hard a problem
> (compared to others we are creating).
>
> Tasks and functions declared 'inline' would be expanded like macros during
> parsing, and would have the restriction that they can only call other 'inline'
> functions or "pure" functions (and it might be worth adding the keyword 'pure'
> for them too so it can be recognized/enforced).
>
> Kev.
I second the motion.
I feel very very strongly that making always_comb reach into functions
that could be located in other modules; could be called by other
modules, tasks or functions is very bad coding style. and will
seriously hurt the language.
I would support inline, with the restriction that inlined functions
could not be called as from other moduless, can not call other tasks
or functions, et cetera.
-mac
This archive was generated by hypermail 2b28 : Thu Mar 28 2002 - 16:35:17 PST