Emulation | Simulation | Test Harnessing combined?

[paulca]

So I can "simulate" a 68k processor in iverlog and execute code on it from a file-fake ROM.hex

I can also emulate a 68k in Mushashi and write my own custom bus glue, fake RAM/ROM in C.

I can capture and send signals to/from real hardware with a logic analsyser/sequencer (Digital Discovery).

If I keep going around that matrix certain combinations pop out.

For example.  I believe it should be possible to shift a bunch of that emulator C glue code into "verilator?" cpp 'simulations' and have the C code just set the virtual bus and call that CPP code to get the resulting bus states.... at some multiple/division of the host clock of CPU clock depending on needs.

Does that work?  Can I simulate the PCB hardware in the FPGA and "hook" it into the C based emulator?

The other combination I think is a lot harder.  That being to stream the logic analyser data to "software" have it pass through some verilog simulation and then stream out the signals for the LA's control outputs.  I'm not even sure the digital discovery supports streaming, there is sigrok though.  USB isn't fast enough for 'realtime' so it would be a buffer sequence with the stream getting left well behind unless it can trigger, stop, trigger, stop on command too.  I figure this is more than an evenings work.

[laugensalm]

Does that work?  Can I simulate the PCB hardware in the FPGA and "hook" it into the C based emulator?

Sure. It's just a matter of putting the right components together. Generally, this subject runs under "Co-Simulation" and hasn't obviously got much popularity, due to the costs of such simulation tools in the past, neither does it seem to be taught much in the adacemic places I have been involved with.
What I started with was GHDL, for which I hacked some extensions (ghdlex) to implement virtual UARTs, USB ports, etc. or LCD screens. Nowadays I'm deploying CXXRTL compilates from RTL in two ways: either as Co-Simulation module from Python or for import into the Renode CPU simulator. The latter for instance allows to create a particular SoC peripheral I/O (memory mapped registers, peripheral interfaces, etc) and run it alongside a selected CPU from the Renode library via those virtual interfaces. For example, I've built a virtual communication radio setup with LCD and radio chip mockup to test firmware interactively against outside signals in an asynchronous, non-deterministic way. The Python co-simulation part again is more of the deterministic sort to carry out unit or regression tests against external models. The next stage is where the AI fun comes in, such as customized agents being allowed to download created images into an FPGA and test register bits through JTAG at free will. For data exchange, the virtual FX2 chip (USB FIFO) does then exactly the same as its simulated counter part.
For the academic side of it, I've played with Jupyter Notebooks a while ago to allow remote-players to verify virtual hardware against their models, for instance a JPEG encoder cosimulation (https://gist.github.com/hackfin/0b124e280c42f5099aa7d6464cf19ee9).

This turned out an extremely powerful method, compared with the classical rather tedious testing using legacy tools.
Plus, it's easy to turn working Python prototypes into real hardware and have them verified kinda automatically.  So the C/C++ part of the game is merely glue between APIs, which you also don't have to deal much anymore using Cython.

As you're already familiar with Verilator, you might find it straightforward to integrate CXXRTL into your setup and just call the .step() method from your main loop to get maximum fine grained control over your interaction with the simulation.