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 world. > 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: http://www.section5.ch/doc/jtag/movies/ Cheers, - Martin _______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
