«

Hello!

I am currently doing some testbench pre-studies involving some Mixed
Analogue Digital (MAD
components, and have tried an implementation using global signals
(signals defined in a package)
to communicate events between the different instances.

I have tried to provide the final testbench user with procedures (that
I had planned to write in the
package body) that drive these global signals with statements like
(code complexity reduced for posting):

procedure pulseA is
begin
sigA <= '1', '0' after 50 ns;
end;

only to find out that, according to LRM 93[8.4.1]:

[..]
If a given procedure is declared by a declarative item that is not
contained within a process statement, and if a signal assignment
statement appears in that procedure, then the target of the assignment
statement must be a formal parameter of the given procedure or of a
parent of that procedure, or an aggregate of such formal parameters.
[..]

NOTES
1--These rules guarantee that the driver affected by a signal
assignment statement is always statically determinable [..] In this
case, the affected driver is the one defined by the process[..]

In short words: My implementation doesn´t work.

However, I would say that if the main purpose of these particular rules
is to "guarantee that the driver affected by a signal assignment
statement is always statically determinable", the driver that the
signal assignment
statement in the package body affects is in my opinion static.

Any other opinion?

Best thanks in advance for a fruitful conversation,

yaveh (Yet Another Vhdl/Verification Engineer Hoping)

yaveh (Yet Another Vhdl Engineer Hoping) a écrit :

> Hello!
Hello,

[...]
> In short words: My implementation doesn´t work.
Yes

>
> However, I would say that if the main purpose of these particular rules
> is to "guarantee that the driver affected by a signal assignment
> statement is always statically determinable", the driver that the
> signal assignment
> statement in the package body affects is in my opinion static.
Yes it is. The note is not well written.

The drivers of a process must be easily extracted. Easily means during
process analysis.

JD.

I'm not sure, but I think the goal of the LRM limitation was to be able
to _locally_ statically determine the list of signals that a process
(implied or explicit) drives. Changing that would mean that the list
would not be available until during/after elaboration, which is when
the list of drivers for each signal is trying to be built. Your
proposed change would not be trivial to implement. Perhaps the LRM
limitation could be restated in such terms (assuming that was the
goal), to allow procedures declared within an architecture to drive
signals/ports declared within that entity/architecture, but that would
not help your situation.

To simplify the argument list on testbench procedures, I have used
record types, with an inout mode on the entire record port. That means
you can only use resolved types in the record, and every procedure must
drive a 'Z' on every element that is not really being driven from the
procedure. This works well for procedures like read(bus, addr, data),
etc. where bus is a record of all the signals of the bus (pci, vme,
60x, etc.)

One of the proposed new things to work on in future versions of VHDL is
"interfaces", whatever they mean by that... One nice thing to have
would be user-defined modes that define individual modes (in, out,
inout, etc.) on elements of record definitions, thus you could have a
"master" mode for a bus port on a procedure that initiates transactions
(like read(), write(), etc.), a "slave" mode for a bus port on a
procedure that only responds to transactions (like a memory, etc.), and
a "monitor" mode for procedures or entities that perform protocol
checking, etc. That would allow you to avoid using inout on everthing,
and to use unresolved data types in bus records that would greatly
speed up simulations.

Andy




yaveh (Yet Another Vhdl Engineer Hoping) wrote:
> Hello!
>
> I am currently doing some testbench pre-studies involving some Mixed
> Analogue Digital (MAD
> components, and have tried an implementation using global signals
> (signals defined in a package)
> to communicate events between the different instances.
>
> I have tried to provide the final testbench user with procedures (that
> I had planned to write in the
> package body) that drive these global signals with statements like
> (code complexity reduced for posting):
>
> procedure pulseA is
> begin
> sigA <= '1', '0' after 50 ns;
> end;
>
> only to find out that, according to LRM 93[8.4.1]:
>
> [..]
> If a given procedure is declared by a declarative item that is not
> contained within a process statement, and if a signal assignment
> statement appears in that procedure, then the target of the assignment
> statement must be a formal parameter of the given procedure or of a
> parent of that procedure, or an aggregate of such formal parameters.
> [..]
>
> NOTES
> 1--These rules guarantee that the driver affected by a signal
> assignment statement is always statically determinable [..] In this
> case, the affected driver is the one defined by the process[..]
>
> In short words: My implementation doesn´t work.
>
> However, I would say that if the main purpose of these particular rules
> is to "guarantee that the driver affected by a signal assignment
> statement is always statically determinable", the driver that the
> signal assignment
> statement in the package body affects is in my opinion static.
>
> Any other opinion?
>
> Best thanks in advance for a fruitful conversation,
>
> yaveh (Yet Another Vhdl/Verification Engineer Hoping)

yaveh (Yet Another Vhdl Engineer Hoping) wrote:
Dependencies are on primary design units. A package
body is a secondary design unit. Hence, you can
compile a new package body. Run a simulation with
a new package body without recompiling any of the
designs that reference it. Hence, "... no static at all" [Steely Dan].

Lets pretend that we removed the restriction in 8.4.1.
This would mean that you could drive global signals in
a procedure defined in a package. This does not seem like
a huge win. You could also write a procedure in an
architecture declaration region that drives signals in
the architecture - this is not a win at all since this
can already be done in a process.

One change in Accellera VHDL 2006 standard 3.0 (approved
at DAC and ready for adoption by industry) is the keyword
all in the sensitivity list in place of signal names.
This new feature is greatly simplified by 8.4.1. If I had
to choose, I would rather have this than that driving
global signals directly from a procedure.

To communicate between models in a testbench I use records.
See the second half of the paper: "Accelerating Verification
Through Pre-Use of System-Level Testbench Components"
which is posted at: http://www.synthworks.com/papers/
I will be writing a paper just on using the records as I
have some improvements over what is in the paper.

Cheers,
Jim


> Hello!
>
> I am currently doing some testbench pre-studies involving some Mixed
> Analogue Digital (MAD
> components, and have tried an implementation using global signals
> (signals defined in a package)
> to communicate events between the different instances.
>
> I have tried to provide the final testbench user with procedures (that
> I had planned to write in the
> package body) that drive these global signals with statements like
> (code complexity reduced for posting):
>
> procedure pulseA is
> begin
> sigA <= '1', '0' after 50 ns;
> end;
>
> only to find out that, according to LRM 93[8.4.1]:
>
> [..]
> If a given procedure is declared by a declarative item that is not
> contained within a process statement, and if a signal assignment
> statement appears in that procedure, then the target of the assignment
> statement must be a formal parameter of the given procedure or of a
> parent of that procedure, or an aggregate of such formal parameters.
> [..]
>
> NOTES
> 1--These rules guarantee that the driver affected by a signal
> assignment statement is always statically determinable [..] In this
> case, the affected driver is the one defined by the process[..]
>
> In short words: My implementation doesn´t work.
>
> However, I would say that if the main purpose of these particular rules
> is to "guarantee that the driver affected by a signal assignment
> statement is always statically determinable", the driver that the
> signal assignment
> statement in the package body affects is in my opinion static.
>
> Any other opinion?
>
> Best thanks in advance for a fruitful conversation,
>
> yaveh (Yet Another Vhdl/Verification Engineer Hoping)
>


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
Jim Lewis
Director of Training private.php?do=newpm&u=
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~

yaveh (Yet Another Vhdl Engineer Hoping) wrote:

> procedure pulseA is
> begin
> sigA <= '1', '0' after 50 ns;
> end;

> In short words: My implementation doesn´t work.

I pass signal arguments to such procedures.
That works fine.
See the procedure toggle in the testbench here:

http://home.comcast.net/~mike_treseler/test_uart.vhd

-- Mike Treseler

Andy wrote:
>
> One of the proposed new things to work on in future versions of VHDL is
> "interfaces", whatever they mean by that... One nice thing to have
> would be user-defined modes that define individual modes (in, out,
> inout, etc.) on elements of record definitions, thus you could have a
> "master" mode for a bus port on a procedure that initiates transactions
> (like read(), write(), etc.), a "slave" mode for a bus port on a
> procedure that only responds to transactions (like a memory, etc.), and
> a "monitor" mode for procedures or entities that perform protocol
> checking, etc. That would allow you to avoid using inout on everthing,
> and to use unresolved data types in bus records that would greatly
> speed up simulations.
>
I'm not sure what future VHDL 'interfaces' are either (perhaps Jim
would like to toss in a comment here) but I second you (almost totally)
about the concept of master and slave but would suggest that if you
have this concept you won't need to define directions for the
individual signals since they will be implied by the interface that it
is a part of.

Presumably an 'interface' would consist of some collection of signals,
so once you know if that a particular collection is a 'master' or a
'slave' then you know the following (which could all be checked at
compile time)...
- The direction of each signal within that collection had better agree
with the entire concept of 'master' and 'slave' or it's an error (i.e.
'read' is an output of a master, 'wait' is an input, etc.)
- Unless the interface is specifically declared to be multi-masterable,
there had better be only one master for each slave.

A component (or entity) then would consist of a number of interfaces
plus the inevitable occasional stragglers that don't want to fit into
the concept of an 'interface' without a struggle.

KJ

KJ wrote:

>
> Andy wrote:
>>
>> One of the proposed new things to work on in future versions of
>> VHDL is
>> "interfaces", whatever they mean by that... One nice thing to have
>> would be user-defined modes that define individual modes (in, out,
>> inout, etc.) on elements of record definitions, thus you could have
>> a "master" mode for a bus port on a procedure that initiates
>> transactions (like read(), write(), etc.), a "slave" mode for a bus
>> port on a procedure that only responds to transactions (like a
>> memory, etc.), and a "monitor" mode for procedures or entities that
>> perform protocol checking, etc. That would allow you to avoid using
>> inout on everthing, and to use unresolved data types in bus records
>> that would greatly speed up simulations.
>>
> I'm not sure what future VHDL 'interfaces' are either (perhaps Jim
> would like to toss in a comment here)

See
http://groups.google.com/group/comp....&output=gplain

Pretty much the same what you want.

--
Paul.
www.aimcom.nl

Thanks a lot to everyone for contributing to the discussion!

Jim Lewis wrote:
> Dependencies are on primary design units. A package
> body is a secondary design unit. Hence, you can
> compile a new package body. Run a simulation with
> a new package body without recompiling any of the
> designs that reference it. Hence, "... no static at all" [Steely Dan].

I must agree then: It is actually "no static at all".

I just wanted to hide the implementation of these procedures in
the package body, so that the end user could just call them from
his/her process, withouth having to pass too many parameters or
knowing about the implementation.

I will have to think of other ways.

Jim Lewis wrote:
> One change in Accellera VHDL 2006 standard 3.0 (approved
> at DAC and ready for adoption by industry) is the keyword
> all in the sensitivity list in place of signal names.
> This new feature is greatly simplified by 8.4.1. If I had
> to choose, I would rather have this than that driving
> global signals directly from a procedure.

I also would find this "all" keyword very useful. But I must wait
until my simulator supports it...

Jim Lewis wrote:
> To communicate between models in a testbench I use records.

That was my first approach too. However I work in a MAD (Mixed Analogue
Digital) environment, where the top level is a Verilog netlist, that is
why
I ressorted to global (in a package defined) signal records, then to
shared
variables, only to realise that I do need some event driven parts where
I must
use signals to synchronise, but that I could still use the shared
variables for
"information broadcast", but not for event triggering.

I definitively have to rethink my strategy.

yaveh()

"Paul Uiterlinden" <> wrote in message
news:45354513$0$11688$4a ll.nl...
> KJ wrote:
>
>>
>> Andy wrote:
>>>
>>> One of the proposed new things to work on in future versions of
>>> VHDL is
>>> "interfaces", whatever they mean by that... One nice thing to have
>>> would be user-defined modes that define individual modes (in, out,
>>> inout, etc.) on elements of record definitions, thus you could have
>>> a "master" mode for a bus port on a procedure that initiates
>>> transactions (like read(), write(), etc.), a "slave" mode for a bus
>>> port on a procedure that only responds to transactions (like a
>>> memory, etc.), and a "monitor" mode for procedures or entities that
>>> perform protocol checking, etc. That would allow you to avoid using
>>> inout on everthing, and to use unresolved data types in bus records
>>> that would greatly speed up simulations.
>>>
>> I'm not sure what future VHDL 'interfaces' are either (perhaps Jim
>> would like to toss in a comment here)
>
> See
> http://groups.google.com/group/comp....&output=gplain
>
> Pretty much the same what you want.

Yep, exactly. On top of what Andy outlined I would add...

- One would need to have a 'complementary' set of each set of interface
signals. By that I mean, where you have a record type that defines the 'in'
and 'out' modes of each signal for 'master' and 'slave' you would then need
a different record type that has the same elements but the modes are
reversed. Andy's example didn't show it very well since he was indicating
how you would implement an interface for a simple point to point connection.
In a real design though the outputs of the 'master' would go to some address
decoding and/or arbitration logic which would then generate the signals
needed for the actual 'slave'. Given that picture one could see that the
slave peripheral's address would typically be narrower than the master
device and that the decode/arbitration logic would need to deal with both
record types as he defined as well as two that are the 'complements'. In
Andy's example the 'slave' record type happens to form this complement for
the 'master' record type but in general this would not be the case....it
would be handy if this type could be easily derived without copy/paste from
the original record type definition.
- One would not want to be limited to having address and data widths defined
as global bus constants. One should be able to define appropriate address
widths to match the address space of each peripheral and not require master
and slave peripherals to all act on globally defined data widths.

KJ

yaveh (Yet Another Vhdl Engineer Hoping) wrote:

> I just wanted to hide the implementation of these procedures in
> the package body, so that the end user could just call them from
> his/her process, withouth having to pass too many parameters or
> knowing about the implementation.
> I will have to think of other ways.

One work-around is to package the procedure with
signal parameters that are then overloaded
in the calling process. The result is a small signal overload
procedure in each calling process but a common package.
The package hides the implementation from the processes
and the local procedure hides the signal list from
all of the calls in the process.

> I ressorted to global (in a package defined) signal records, then to
> shared
> variables, only to realise that I do need some event driven parts where
> I must
> use signals to synchronise, but that I could still use the shared
> variables for
> "information broadcast", but not for event triggering.
> I definitively have to rethink my strategy.

Any process can synchronize its inputs using local variables.
Signals or global variables are required to connect processes.

-- Mike Treseler