luke
/
iverilog
mirror of https://github.com/steveicarus/iverilog.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Describe the new .net behavior.

This commit is contained in:
steve 2001-08-10 04:31:27 +00:00
parent 645c8913f1
commit a98b5023a8
1 changed files with 52 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

90
vvp/README.txt
View File

@ -1,7 +1,7 @@
/*
* Copyright (c) 2001 Stephen Williams (steve@icarus.com)
*
* $Id: README.txt,v 1.34 2001/07/04 22:59:04 steve Exp $
* $Id: README.txt,v 1.35 2001/08/10 04:31:27 steve Exp $
*/
VVP SIMULATION ENGINE
@ -246,50 +246,64 @@ exactly the same as the .var statement:
<label> .net "name", <msb>, <lsb>, <symbols_list>;
<label> .net/s "name", <msb>, <lsb>, <symbols_list>;
A .net statement creates a functor for each bit of the vector in
exactly the same way that a .var creates functors. The truth table for
a .net functor is the same, as well. The net has an output that may be
connected to something, but need not. The 0 (zero) input of each bit
functor is the normal input, and is connected to the output of a
functor or another net.
Like a .var statement, the .net statement creates a VPI object with
the basename and dimensions given as parameters, but unlike a .var
statement, it creates no functors. The symbol list is a list of
functors that feed into each bit of the vector, and the vpiHandle
holds references to those functors that are fed it.
The second functor input is a force net. This connects to an
expression that is announced by a force statement of some sort. The
third input is the only input settable by behavioral code, it selects
between the normal input and the force input. These inputs work
exactly the same as those for the .var functors.
The <label> is required and is used to locate the net object that is
represents. This label does not map to a functor, so only references
that know they want access .nets are able to locate the symbol. In
particular, this includes behavioral %load and %wait instructions. The
references to net and reg objects are done through the .net label
instead of a general functor symbol. The instruction stores the
functor pointer, though.
Since .var items are written by behavioral code, there is no worry
about how to connect their inputs. You don't. But .net items do have
inputs that need to be connected to the outputs of other
functors. Nets are also complicated by the fact that they come in
vectors, so the inputs of all the functors in the array need to be
connected. Fortunately, there is only one input per .net functor that
can be connected, and that is input 0.
X A .net statement creates a functor for each bit of the vector in
X exactly the same way that a .var creates functors. The truth table for
X a .net functor is the same, as well. The net has an output that may be
X connected to something, but need not. The 0 (zero) input of each bit
X functor is the normal input, and is connected to the output of a
X functor or another net.
The force input and selector input are manipulated exactly the same
way as with .var force and selector inputs, so there is no need for a
syntax to handle them.
X The second functor input is a force net. This connects to an
X expression that is announced by a force statement of some sort. The
X third input is the only input settable by behavioral code, it selects
X between the normal input and the force input. These inputs work
X exactly the same as those for the .var functors.
Since there is exactly one input per bit in the vector, it is easy
enough to just list the vvp_ipoint_t symbols in order. Each symbol
references a functor, and connects the corresponding .net input to the
output of that functor, as if the .net is an <N> bit wide functor. The
bits of the vector are connected least-significant-bit first. It is
legal to leave a bit unconnected. To do that, simply leave the
position for that bit blank. Bits of .nets are initialized to
z. Unconnected bits keep the value z throughout the simulation.
X Since .var items are written by behavioral code, there is no worry
X about how to connect their inputs. You don't. But .net items do have
X inputs that need to be connected to the outputs of other
X functors. Nets are also complicated by the fact that they come in
X vectors, so the inputs of all the functors in the array need to be
X connected. Fortunately, there is only one input per .net functor that
X can be connected, and that is input 0.
The special input symbols "C<0>", "C<1>", "C<x>" and "C<z>" and magic
symbols that set the net to a constant value instead of accepting an
input from a functor. This can happen, for example, when a wire is
declared like so:
X The force input and selector input are manipulated exactly the same
X way as with .var force and selector inputs, so there is no need for a
X syntax to handle them.
wire foo = 1'b1;
X Since there is exactly one input per bit in the vector, it is easy
X enough to just list the vvp_ipoint_t symbols in order. Each symbol
X references a functor, and connects the corresponding .net input to the
X output of that functor, as if the .net is an <N> bit wide functor. The
X bits of the vector are connected least-significant-bit first. It is
X legal to leave a bit unconnected. To do that, simply leave the
X position for that bit blank. Bits of .nets are initialized to
X z. Unconnected bits keep the value z throughout the simulation.
This prevents any real functor being created and connected, and
instead leaves the input unconnected and initializes the wire with the
specified value, instead of the default z.
X The special input symbols "C<0>", "C<1>", "C<x>" and "C<z>" and magic
X symbols that set the net to a constant value instead of accepting an
X input from a functor. This can happen, for example, when a wire is
X declared like so:
X wire foo = 1'b1;
X This prevents any real functor being created and connected, and
X instead leaves the input unconnected and initializes the wire with the
X specified value, instead of the default z.
MEMORY STATEMENTS: