C program that exercises the simulated design

[Thoma]

Hi all,

I asked whether it was possible to mount a test environment where:
- ModelSim simulates the model and
- a C program will exercise the model through two simulators (UART and
proprietary BUS)

+------------+
+-----------+ | | +-----------+
| UART |------>| | | BUS |
TCP/IP <-->| | | D.U.T. |<---->| |<-->
TCP/IP
| SIMULATOR |<------| | | SIMULATOR |
+-----------+ | | +-----------+
+------------+

I heard about FLI. Is it the solution?
If yes, have someone an example that demonstrate this possibility?

Thank you in advance.

Thoma

 

[Amal]

Hi all,

I asked whether it was possible to mount a test environment where:
- ModelSim simulates the model and
- a C program will exercise the model through two simulators (UART and
proprietary BUS)

                               +------------+
           +-----------+       |            |      +-----------+
           |   UART    |------>|            |      |    BUS    |
TCP/IP <-->|           |       |   D.U.T.   |<---->|           |<-->
TCP/IP
           | SIMULATOR |<------|            |      | SIMULATOR |
           +-----------+       |            |      +-----------+
                               +------------+

I heard about FLI. Is it the solution?
If yes, have someone an example that demonstrate this possibility?

Thank you in advance.

Thoma

Take a look at this page for an example of how to use FLI to connect
to a terminal emulator.

http://www.ht-lab.com/howto/uart2fli/uart2fli.html

If you use SystemVerilog though, this can be done much easier by using
DPI.

Cheers,
-- Amal

 

[Thoma]

Take a look at this page for an example of how to use FLI to connect
to a terminal emulator.

 http://www.ht-lab.com/howto/uart2fli/uart2fli.html

If you use SystemVerilog though, this can be done much easier by using
DPI.

Cheers,
-- Amal

Hi Amal,

Seems to be what I want do. Can this kind of operation done with the
ModelSim XE (xilink edition)?
Or is it required to use the other possibility?
http://www.ht-lab.com/howto/remotemti/remote_modelsim.html

Thank you in advance

Thoma

 

[Mike Treseler]

I asked whether it was possible to mount a test environment where:
- ModelSim simulates the model and
- a C program will exercise the model through two simulators (UART and
proprietary BUS)

+------------+
+-----------+ | | +-----------+
| UART |------>| | | BUS |
TCP/IP <-->| | | D.U.T. |<---->| |<-->
TCP/IP
| SIMULATOR |<------| | | SIMULATOR |
+-----------+ | | +-----------+
+------------+

I would use a vhdl testbench to transfer the IP packets
straight to and from the dut, and run bus cycles.
Once that is working, I would add the real serial and bus interfaces
and try it on the bench.

-- Mike Treseler

 

[Kenn Heinrich]

I would use a vhdl testbench to transfer the IP packets
straight to and from the dut, and run bus cycles.
Once that is working, I would add the real serial and bus interfaces
and try it on the bench.

-- Mike Treseler

Another idea along the same lines: if you want to integrate an existing
bit-accurate golden reference model written in 'C' to your VHDL, you
could always get the C program to dump out a file with the reference
data, and use the VHDL testbench to pull the data from the file,
excercise the design, and compare the results.

Since you need to write an extra couple of C functions to do this, you
can even make the C code write the data out as though they were, for
example, VHDL initialized array constants inside a VHDL package, so you
can directly compile the output "vector file" with your VHDL compiler,
and include the package in with your testbench, avoiding the VHDL file
I/O step.

It's kind of klunky, admittedly, and not as neat as a proper FLI
integration, but for some applications it's much less work that going up
the learning curve and/or locking yourself into one tool's
specifics. But at least the process is fully automatic (you could script
it) and bit-accurate to your C test cases.

- Kenn

 

[Jonathan Bromley]

I asked whether it was possible to mount a test environment where:
- ModelSim simulates the model and
- a C program will exercise the model through two simulators (UART and
proprietary BUS)

+------------+
+-----------+ | | +-----------+
| UART |------>| | | BUS |
TCP/IP <-->| | | D.U.T. |<---->| |<-->
TCP/IP
| SIMULATOR |<------| | | SIMULATOR |
+-----------+ | | +-----------+
+------------+

I heard about FLI. Is it the solution?

You got some useful answers to that.

Another possibility is to use Tcl to control the high-level
stimulus. ModelSim supports Tcl very well, and Tcl provides
truly excellent features for operating system interface, file
access, remote control via TCP/IP sockets and so on.

Tcl, of course, is quite slow. Even slower when you must use
the simulator's [force] and [examine] commands to gain access
to HDL signals. But if you can keep the Tcl side of things
operating at a fairly abstract level, so that Tcl only manages
complete cycles on the bus and complete bytes (or even packets)
on the TCP/IP side, the overhead should be small in relation to
the cost of simulating the DUT.

You could even use Tcl's sockets interface so that the TCP/IP
stimulus was in fact coming from real TCP/IP traffic from
another piece of software.

Tcl is a strange language, but it has considerable merits
for this sort of high-level control and interaction; don't
ignore its possibilities.

 

[Thoma]

You got some useful answers to that.

Another possibility is to use Tcl to control the high-level
stimulus.  ModelSim supports Tcl very well, and Tcl provides
truly excellent features for operating system interface, file
access, remote control via TCP/IP sockets and so on.

Tcl, of course, is quite slow.  Even slower when you must use
the simulator's [force] and [examine] commands to gain access
to HDL signals.  But if you can keep the Tcl side of things
operating at a fairly abstract level, so that Tcl only manages
complete cycles on the bus and complete bytes (or even packets)
on the TCP/IP side, the overhead should be small in relation to
the cost of simulating the DUT.

You could even use Tcl's sockets interface so that the TCP/IP
stimulus was in fact coming from real TCP/IP traffic from
another piece of software.

Tcl is a strange language, but it has considerable merits
for this sort of high-level control and interaction; don't
ignore its possibilities.

Hi all,

Just before continuing with this topic, I wish you all a happy new
year.

Jonathan, your idea is I think the easiest for me.
I will write a collection of VHDL procedures that exercise the DUT.
I never write TCL code before but I took a look on various tutorials
and it seems feasible.

I have not found a tutorial that explains how to fire the different
VHDL procedures from TCL.

Can someone share a example?

Do you think that I am on the good way?

Thank you in advance

Thoma

 

[Jonathan Bromley]

I have not found a tutorial that explains how to fire the different
VHDL procedures from TCL.

Usually the easiest way is to create a signal of integer or
enumeration type, with one value for each of your procedures
(and probably one additional value to represent "do nothing").
You can then write a VHDL driver block that uses this signal
to fire the procedures:

type tcl_TEST_ACTION is (tcl_DO_NOTHING, tcl_ACTION_A, ...);
signal tcl_COMMAND : tcl_TEST_ACTION;
signal tcl_BUSY : boolean;
...
process
begin
-- Wait for a command to come from Tcl
wait until tcl_COMMAND /= tcl_DO_NOTHING;
-- Respond to the command
tcl_BUSY <= TRUE;
-- Do the command
case tcl_COMMAND is
when tcl_DO_NOTHING => null;
when tcl_ACTION_A => do_ACTION_A_procedure;
....
end case;
-- Indicate not busy
tcl_BUSY <= FALSE;
-- and go back to waiting
end process;

Now, from your simulator's command line (or a Tcl script running
in the simulator's console) you can use a combination of "force"
commands to drive the tcl_COMMAND signal, "examine" commands to
look at the tcl_BUSY and other signals, and signal breakpoints
to detect the TRUE/FALSE transitions on tcl_BUSY. Something
like this should work in ModelSim (details will vary for
other simulators, but the principles should be the same):

# Tcl procedure to respond to changes on tcl_BUSY
proc respond_busy {} {
set busy [examine tcl_busy]
if {$busy} {
# VHDL accepted your command. Remove the command.
force -deposit tcl_command tcl_do_nothing
}
}

# Trigger some activity whenever tcl_BUSY changes
set when_handler [when tcl_busy {respond_busy}]
# Run the simulation for a while
run 100 ns
# Run a command
force -deposit tcl_command tcl_action_a
# Run the simulation some more
run 1000 ns
......
# Cancel the "when" handler
nowhen $when_handler

Note that ModelSim maps all VHDL names to lowercase.

Hope this helps