Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Dr. Don Goodeve
I have a complex product that I am trying to 'prove' the code for over a long simulated deployment. I am looking to extract the core simulation engine and modify it for 16F876 and then embed this into code simulating the rest of the system. A straightforward stimulus approach will not work due to the complexity of the environmental feedback loops this system is in.
I am going to see where I can get to with the code right now - but any and all pointers to help with this effort would be greatly appreciated.
Here are a couple of options:
1) Assertions. gpasm (in relative mode, not absolute mode) supports assertions which gpsim understands. Take a look at the regression/ directory to get an idea how these are used. But in general, the assertions allow you to valid (assert something) in the assembly code that when simulated gpsim can check. The assertions of course have no impact on code running in a real processor.
2) Modules. gpsim supports a module mechanism that can be just about anything you imagine. For example, you could write a module that hijacks the simulation (the whole gpsim api is accessable) and single step, set breaks, read the symbol table, etc.
3) Sockets. gpsim supports a socket interface and exposes some of the API through it. The whole command line is also exposed. This is useful for writing scripts or whatever in any programming language in such a way that you don't have to link with gpsim. I haven't used this recently, and in practice found the socket interface somewhat cumbersome (when compared to writing a custom module).
4) SWIG. JR (one of gpsim's developers) has added a swig interface to gpsim. He's written PERL scripts that call directly into gpsim via the SWIG wrappers. This is still in the early stages, but may be an option.
5) KTechLab. David Saxton's KTechLab embeds gpsim's simulation engine. You can check out his code to see his approach.
I am a complete neophyte - what would be the relative complexity of connecting this to the Verilog PLI? Certainly we could do it with sockets but given the comments above... Has anyone undertaken this and what were your experiences. Thanks, SysTom