[Join Team Specman in welcoming guest blogger Jason Andrews. Jason is a recognized hardware-software co-verification expert (he's written books on the subject!) and a fellow blogger]
One of the long-time features of Specman is "CVL". It stands for "Co-Verification Link", but is somewhat misnamed. CVL connects a host compiled C program to Specman via a network socket. This feature enables e methods calling C functions and C functions calling e methods over the socket. We have used CVL many times in the context of ISX to provide a connection to a host-compiled program or another type of simulator that cannot be directly linked to Specman.
Debugging a host compiled program is normally done with gdb. Because CVL operates over a socket connection with Specman, one of the following can happen:
• Specman is running and the host-code program is blocked waiting for data
• The host-code program is running and Specman is blocked waiting for data
This blocking creates a problem during interactive debugging with gdb, because gdb waits for commands when you stop execution. When you try to activate Specman to inspect the state of the verification environment Specman is frozen because of the blocking operation on the socket.
The good news is this blocking problem is solved using custom gdb commands you can use to transfer control from the gdb prompt to Specman, do some Specman commands, and then return back to the gdb prompt.
The good news is that no modifications to gdb are required because gdb has a feature that allows the user to create custom commands for the debugger. Specman is shipped with a .gdbinit file that implements this capability. The path to the file is
For the real curious engineer, here is the code that "wakes up" the Specman prompt from gdb You can include this also as a "code fragment".#
# Activate the Specman prompt
echo CVL request already in progress\n
echo Issue sn_safe first\n
echo CVL is not connected\n
To activate the custom gdb commands, do one of the following:
1. Copy the file to the directory where you invoke gdb
o gdb automatically reads a .gdbinit file in the current directory
2. Copy the file to your home directory
o gdb automatically reads a $HOME/.gdbinit file
3. Manually source the file from the gdb prompt
gdb does not allow environment variables, so you must provide the full path:
(gdb) source <path to SN Home>/sn_lib/vr_gsa_sw_debug/cvl/.gdbinit
To see if gdb now understands your custom commands use:
(gdb) help user
Now, how to use it. If you are running a test and sitting at the gdb prompt and you need to do something in Specman use the sn command:
This transfers control to the Specman prompt. After you are done with Specman stuff you can just hit return at the Specman prompt and you will get back to the gdb prompt. Check out the screenshots below for an example.
If you want to try all this out, there is a simple example that ships with Specman -- use sn_which.sh to find it.
% sn_which.sh ex_gsa_simple
As always, there are more details in the Specman User Guide about the custom gdb commands and running the simple example.
Happy bug hunting!
P.S. You might ask, “What’s the difference between CVL and Incisive Software Extensions (ISX)”? The answer to that is coming in a future post …