Hi Svenn,

I guess you're generally referring to a Co-Simulation environment what
the big guys like Cadence, Mentor, etc. offer.
Now, GHDL is pretty darn powerful WRT Co-Simulation, but you have to
write some code. Let me respond 'inline':

> I'm the VHDL developer in our team, and I am not really good at deciding
> the level of effort needed to combine qemu and ghdl to make a more
> generic virtual development platform for software developers. If it
> would be easy, I guess somebody would have done this by now.

I've messed with some extensions to allow software simulators or data
acquisition modules to directly talk to the virtual FPGA hardware.
Some entry point: http://tech.section5.ch/news/?p=124
Look for the ghdlex extensions, there are some examples using either
unix pipes or the netpp protocol.

> Isn't ghdl creating gcc code for the simulation, and could this
> generated c-code be linked into a qemu binary to have a simulation level
> of the hardware?

That won't work just like that. You can import .so's into a GHDL
simulation that messes with virtual pins via virtual I/O, but running
qemu on top of that might be a real adventure. You could fork it as a
thread, but you'll have to take care of all I/O, the VPI interface of
GHDL is not thread safe, according to experiments.

I'd suggest to add a virtual hardware module to qemu and let it speak to
the simulation via a virtual interface (from the ghdlex extensions
mentioned, that might tunnel through netpp/networking or a Unix pipe).
For the interface side however, you'll have to deal a lot with timing,
because the cycle accurate simulation will run way slower than the real

> I hope to provide testvectors to the VHDL hardware level which represent
> corner cases difficult to reproduce in the lab and to give the software
> developers a reliable development platform.

You can do quite some funky stuff, really. So your hardware simulation
can run on a linux server while the SW guys access it on their desktop
via their qemu simulation through, say a virtual memory bus that tunnels
through netpp/ghdlex.

I've put together a few movies of a debugging scenario a while ago,
basically it shows how to connect a GNU debugger to a virtual CPU SoC
running as cycle accurate simulation - maybe it gives you an idea:



- Martin

Ghdl-discuss mailing list

Reply via email to