Subject: RE: SystemVerilog: always_comb and functions
From: Tom Fitzpatrick (fitz@co-design.com)
Date: Thu Mar 28 2002 - 14:39:46 PST
Hi Kevin,
I'm not sure I see where your comment
> Argh... more stuff working against modular compilation... :-/
applies. You're not suggesting that functions should be compiled in the
absence of their declaring module, are you? If the smallest unit of compile
is a module (or interface), then I fail to see how this feature affects
modular compilation. Please help me understand your concern.
Thanks,
-Tom
> -----Original Message-----
> From: owner-vlog-pp@server.eda.org
> [mailto:owner-vlog-pp@server.eda.org]On Behalf Of Kevin Cameron x3251
> Sent: Thursday, March 28, 2002 4:23 PM
> To: vlog-pp@server.eda.org; cliffc@sunburst-design.com
> Subject: Re: SystemVerilog: always_comb and functions
>
>
> > 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.
>
This archive was generated by hypermail 2b28 : Thu Mar 28 2002 - 14:38:39 PST