Subject: Re: SystemVerilog: always_comb and functions
From: Adam Krolnik (krolnik@lsil.com)
Date: Mon Apr 01 2002 - 12:22:52 PST
Hi Peter;
I am now torn between competing philosophies on this feature.
1. I like the idea that you are documenting what information
a function requires. I like the idea that you are documenting
which signals influence a particular combinatorial block.
2. I find that sensitivity lists, partitioning of signals, etc.
is tedious and causing more code than is actually necessary.
In many places the amount of extra code only seems to confuse
the code by spreading out the informative code off the page,
screen, etc.
There are also downsides to each of these.
A. Documenting what is required (lists, etc) is something
that is sometimes automated or put in once other things
are done - showing that it's not necessary for design most
of the time.
B. The assign style (which does not require partitioning, lists
of signals, etc.) requires care in its usage lest the code
becomes a spaghetti pile of logic that winds in and out of
other code lines with no apparent organization.
The risk of 1/A is that you take more time. The risk of 2/B is
that the designer may create something too confusing or obtuse
that you can't make it functional.
Would something like this save time? I don't know. It almost seems
like the calling of the function is does not matter when you have
no signals/arguments that you explicitly are passing. If this is
the preferred style, it would seem that in Cliff's example, the
block that calls the functions would be just as appropriate
as if it was a comment. The functions themselves would then become
an always_comb or always @(*) block themselves.
Would something like this produce wrong results? I don't know. I
don't though see this feature as very useful from the possible
code examples I've seen.
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
You were commenting on Stu's suggestion for functions:
:>I would like to just throw an idea in to the arena, and leave it to
:>you
:>syntax/semantic wolves to attack... Could we add the now infamous .*
:>connection to function call argument lists? It would be used to say
:>"any
:>names common within the function and the calling scope are inferred
:>in the function call argument list". This would mean:
:>
:>- An always_comb only has to be sensitive to the function call
:>arguments (listed and inferred). The function might still reference
:>something outside the calling scope, but the always_comb would not be
:>sensitive to it.
:This would still require the user to list the sensitivity and
:therefore enable errors.
I looked at a possible usage from Cliff. The desire in that example
is not one of reuse of a function, but instead to show some
high level flow of operation (through the names and order of the
function calls.)
This kind of code reminds me of method calls. E.g.
$cfg->processInputs();
$cfg->elaborateAlg1();
$cfg->elaborateAlg2();
$cfg->composeOutputs();
This is nice because you can explain the order and names of
the higher level steps. The details of each is recorded
in the definition below.
This is a reasonable style - to implement it in verilog requires
computation of the sensitivity list which is more easily accomplished
if the tool would figure out the entire thing through all calls, etc.
Stu suggested use of .* to solve the specification of signals in the
call invocation. This would then not require the user to list the
sensitivity list in the calling section. E.g.
processsInputs(.*);
elaborateAlg1(.*);
It would preserve the function definition purpose - to list the
variables necessary to compute the function result. If you are
reviewing source code - having a function define the variables
necessary is a reasonable idea so that you can properly understand
and review the code. I think it would be improper to allow one
to define a function that
This archive was generated by hypermail 2b28 : Mon Apr 01 2002 - 14:16:52 PST