Subject: Re: SystemVerilog: always_comb and functions
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Thu Mar 28 2002 - 13:23:15 PST
> 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 - 13:24:55 PST