cocotb
Restart Simulation not working with FLI interface for Questa
After a simulation of mine had completed in the GUI, I made some updates to the test and then hit the "restart" simulation, followed by the "Run -all" command, expecting my test to be reloaded and then the run to complete with my changes.
Instead, I see the FLI library get re-loaded and the coctb_init and fli_elab_cb functions are called again, but when it goes to register the FLI interface with the GPI, the BPI says that the FLI is already registered (GpiCommon.cpp:60).
I think that while the FLI library gets reloaded, any libraries associated with it are not getting reloaded so the GPI isn't re-loading the python test.
I haven't had a chance to fix this yet. Right now the simulator has to be restarted every time. I will need to add code to clean everything up and reinitialize everything.
Such feature would be great, even if it is too complicated for me to implement...
This is the most important issue I see so far with cocotb, using Modelsim/Questa. Has someone worked on this ? I'll try and dig what I can. I guess it's somewhere around the cocotb/lib/fli directory...
Well it's fairly simple to add a callback on restart thanks to the modelsim API command
mti_AddRestartCB()
I'm working on a disconnected server so I can't easily share what i codded but I basically added a restart function in cocotb/lib/embed/gpi_embed.c that was called whenever I triggered a restart in Modelsim.
The problem now is What do I do with said function ? I've realized cocotb is using static variables to track state of simulation which is strongly unadvised by Modelsim, I guess for good reasons, mostly in our case when we would just want to restart the tool without having to close it.
Because FLI shared libraries might or might not be reloaded during a restart, it is wise to always include a restart callback function (see mti_AddRestartCB() (FLI-69)) in your FLI application that frees any memory that your code has allocated and resets the internal state of your application. It is also a good idea to avoid the use of static local variables.
Because of that, what we need to do now is we need to find everything that traces the state of simulation and manage to reset it in the restart function I managed to create.
I guess in the long run we should replace state control with static variables by something else, but that would be a separate Issue.
I found 2 variables in cocotb/lib/embed/gpi_embed.c
static PyThreadState *gtstate = NULL;
static PyObject *pEventFn = NULL;
setting gtstate to NULL on restart causes modelsim to crash
setting pEventFn to NULL during restart actually helps go further.
Cocotb goes as far as to list all tests and launch the first one.
The behaviour is quit the same as the first run -all up until the very beginning of the test, when it is added to the scheduler. At that point, Modelsim inexplicably crashes...
I suspect some python module global variables somewhere in cocotb to also track state and cause the crash ...
Has anybody got some insight on this ?
@jevinskie had pointed to https://github.com/potentialventures/cocotb/commit/e8d8942b6b821e58369b7bdea1ba5e0a53783cb4 in the Gitter channel a while ago.
Sorry @cmarqu I'm new to Github ... does this link represent a commit or a work in progress ?
@leftink, I've seen you opened a new Issue regarding FLI (#820) Have you by any chance worked on this Issue ?
@TrampHRC, I looked into it originally, and realized it isn't a trivial task and if I remember correctly, behaved differently on each interface. One of the big things is everything has to be re-initialized, i.e. the code executed on the EndOfElaboration call-back, but that also means you have to free the cache and clean-up any allocated memory prior to the re-initialization of everything.
I was reading through my original post and it jogged my memory, in Questa at least, only part of the libraries are re-loaded, i.e. the FLI, and not any of the other shared libraries (e.g. GPI library), which is why it is a pain to resolve this issue.
A workaround that we ended up using at work:
You can call vsim command again to relaunch the test without using restart (which causes the crash).
Figuring out the entire vsim command is a PITA. Calling vsim will also reset your UI layout and wave window, etc..
A more convenient option is to export the vsim command and layout settings to a do file an then simply load the do file.
write format restart <dofile>; do <dofile>
We added this command to a toolbar button.
