On 8 Dec 2013, at 12:02 am, Svenn Are Bjerkem <svenn.bjer...@googlemail.com> wrote:
> Hi, > I am currently working on a SmartFusion2 project, and did some search on the > web. I found several pages describing how to write bare-metal applications > for ARM Cortex-M3 using qemu. I even found a project with efforts to make a > virtual development environment for PCIe on github. > https://github.com/texane/vpcie. > > 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. > > 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? > > 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. > A VHDL model is a bunch of processes driven by sensitivity to signal updates as a result of simulation cycles, including delta cycles. Concurrent statements either devolve into processes or blocks containing processes. The only way to drive an elaborated VHDL model is through the simulation cycle. A VHDL model can accept stimulus and transfer results via File I/O, and imaginably through the use of UNIX FIFOs. Synchronization of two disparate systems so their notion of time passing is synchronized by event transactions caused by the I/O is imaginable. It would entail process suspension (blocking) while one system or the the other was waiting on the other and require that there could be no dead locks, which could be difficult in complex systems because you can also imagine using foreign functions to synchronize other events (clocks, interrupts,...). There are a couple of bounds on the execution of a VHDL model. First there's a limit as to how long a model can run, from time=0 to time'High, although there can be a scalar multiplier on that based on the granularity of time events in the model. Likewise a model quits when there are no future events scheduled (which is why you need to interlock a VHDL model with a co-simulation system). There's also no guarantee that you can build a working system that doesn't advance simulation time (counting delta cycles in the simulator instead). Most VHDL simulators have a maximum delta cycle count (ghdl's is 5,000, settable up to 2^^31). It prevents models from spinlocking. The need to interlock the passage of time between the two models, VHDL and system would result in some portion of serializing the models when one is waiting on the other, potentially slowing down the whole simulation significantly. At about this point not having a clear idea of what you're actually building I'd imagine asking the vendor, so looking through the SmartFusion2 SoC FPGA microsemi page which leads you their Libero SoC software tools which doesn't include co-simulation from the looks of it. I'd imagine the development effort doing this on your own might be significant and I'd search real hard for alternatives or method of parallelizing development effort as much as possible. I can't imagine a combined model would run very fast, and ghdl for instance isn't the fast VHDL simulator out there. You'd think the vendor would have a development kit that would enable your software guys and platform development in parallel, it's a matter of how much money you can throw at it. Without knowing what you're trying to do I see co-simulation as being of limited value based on effort and schedule time, when with an evaluation kit board as a starting point you could 'grow' your target platform incrementally. When you reach some threshold you're done with the development kit and using your own platform.
_______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
