1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
PLI 2.0 VPI ROUTINE EXAMPLES AND INSTALLATION TEST
This directory contains PLI 2.0 API vpi_ routine examples to illustrate use
of PLI 2.0. To test for correct installation run the inst_pli.sh script that
compiles vpi_ programs into .so libraries which are dynamically loaded
using new +loadvpi= Cver command line option and run.
To see an example asynchronously driven PLI 2.0 vpi_ model, look
at async.c (and async.v) test below. The other tests show various
PLI 2.0 vpi_ routine capabilities but are not complete models.
To learn more about PLI 2.0 capabilities, read the various examples. To
learn how to use a particular vpi_ routine, access method, or to get
properties from a particular object, run "grep [object or routine name] *.c".
This script assumes you are using new +loadvpi= dynamic library PLI
execution. If you need to statically link your PLI libraries contact
Pragmatic C to obtain the libraries and test scripts.
HOW TO RUN THE TEST SCRIPT FOR ALL SYSTEMS EXCEPT MAC OSX AND CYGWIN (below)
1) Run the shell script inst_pli.sh [OS name]. Various compiler and Verilog
output messages will be printed but there should be no diff command
differences printed. You must pass the name of your system as the one
argument to the script. Depending on your platform, names are:
for X86 linux (suffix lnx), Sparc (suffix sparc-gcc),
X86 64-bit (suffix lnx64).
Run the shell script opt_inst_pli.sh [OS name] to test PLI using
optimizer (-O) incremental compiler.
By convention makefile.[OS name] assumes this test is run in release
directory tree with include files in pli_incs 2 directory levels up
and Cver binary also 2 levels up.
The commands to run Cver with dynamically loaded user PLI library
explicitly access the user .so library in this directory. For your
PLI libraries, it is better to set the LD_LIBRARY_PATH environment
variables so explicit "./" is not needed
2) After completing the test, run clean.sh to remove work files.
The inst_pli.sh script removes each PLI library .so dynamic library after
running the test that uses it so unless something went wrong, you
do not need to run clean.sh.
3) Use makefile.[your OS] as a template for your vpi_ PLI 2.0 models.
Notice to use the PLI1 user defined PLI system/task function interface,
you must use +loadpli1= option. To use newer PLI2 vpi_ user defined PLI
system/task function interface you must use +loadvpi=. You should
use the +loadvpi= option for all new PLI code because of the additional
capabilities. +loadpli1= system tasks can't be used with new vpi_
system task and function access methods because +loadpli1 system tasks
and functions must support old behavior.
HOW TO RUN THE TEST SCRIPT FOR MAC OSX
1) Run the shell script inst_pli.osx.sh. Notice you do not need the
OS shell argument here. Various compiler and Verilog
output messages will be printed but there should be no diff command
differences printed. You must run this different script for MAC OSX
because OSX uses .dylib suffix for dynamic libraries and uses the
mach dynamic library mechanism instead of normal .so and dlopen.
By convention, makefile.osx assumes this test is run in release
directory tree with include files in pli_incs 2 directory levels up
and Cver binary is in bin directory also 2 levels up.
The commands to run Cver with dynamically loaded user PLI library
explicitly access the user .dylib library in this directory. For your
PLI libraries, it is better to set the LD_LIBRARY_PATH environment
variables so explicit "./" is not needed
Mac OSX linker (from mach OS) requires that a leading '_' be added to
each symbol name. Cver does this automatically but you must make
sure that your bootstrap routine name does not start with underscore ('_').
2) After completing the test, run clean.sh to remove work files.
The inst_pli.osx.sh script removes each PLI library .so dynamic library
after running the test that uses it so unless something went wrong, you
do not need to run clean.sh.
3) Use makefile.osx as a template for your PLI models. You must use
exactly the LFLAGS options and set and export LD_LIBRARY_PATH
environment variable, or your .dylib user PLI code will not load
properly.
HOW TO RUN PLI ON CYGWIN
****IMPORTANT - as of 02/02/04 the latest version of Cygwin contains a
bug which doesn't run the PLI correctly. To run the PLI you will need
Cygwin version 1.5.5 or earlier.
1) First, you must make a cver dll and executable. Go to the objs directory
(gplcver-*/objs/), and type the following commands:
make -f makefile.dll dll #makes the dll library
make -f makefile.dll exe #make the new cver.exe
2) Next copy the libcver.dll library to the lib directory:
cp libcver.dll /lib/
3) In the vpi examples directory (this one), type the following commands:
make -f makefile.cygwin dll #compiles libvfopen1.c
make -f makefile.cygwin run #runs the PLI example
4) All of these should compile correctly, and 'make -f makefile.vpi run',
runs the PLI example vfopen1.v after making the libvopen1 library.
---------------------------------------------------------------------------
Tests are:
1. async.c is asynchronously switching not gate implemented using vpi_.
2. vhello1.c and vhello2.c are "hello world" tests that also show use
of environment determing vpi_ routines.
3. vhelbad.c is a "hello world" test with some vpi_ errors to illustrate
vpi_ error checking.
4. findcaus.c is test that traverses Verilog design hierarchy.
5. vcabtsts.c is a test that registers every call back and prints a message
when it occurs.
6. vprtchg.c adds cbValueChange callbacks to every .v file varaibles and
prints a message on every change.
7. vprtchg2.c test also prints every variable change in a design
except it uses vpi_get_value and vpi_get_time instead of the built in
value change callback values.
8. vprtchg3.c prints new and old variable values using an on change call
back.
9. vprtdels.c accesses and prints every delay in a design.
10. vprtdel2.c illustrates vpi_ timscale handling.
11. vsetdels.c use vpi_ to set delays.
12. vsetval1.c tests various vpi_put_value uses.
13. vtimcbs.c illustrates use of various delay callbacks.
14. vfopen1.c implements $fopen built in system function using PLI 2.0.
15. vfopen2.c is variant of the vfopen1.c test using vpi_ system task
instead of vpi_ system function.
16. vconta1.c tests continous assignments and non lvalue expression
decomposition.
17. vchkprt1.c tests most port and vpiHighConn/vpiLowConn one to one
and one to many iterators. It is possible that either the .c model
or Cver's interpretation of the LRM are not right because Cver
assumes all bit iterators are LSB to MSB in terms of vpi_scan order.
18. vdrvld1.c tests vpiDriver and vpiLoad iterators for nets.
19. vdrvld2.c tests vpiDriver and vpiLoad iterators for bits of nets.
20. dfpsetd.c tests vpi_put_value to defparam and specparam during
cbEndOfCompile call back for delay annotation (allows delay annotation
to procedural delay controls and continuous assignments). Test
sets same delays and produces same results using vpi_ as dfpsetd.vc
in install.tst directory that uses 2 SDF delay annotation files.
|
