On 8 Dec 2013, at 12:02 am, Svenn Are Bjerkem <svenn.bjer...@googlemail.com> 

> 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 

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

Reply via email to