On 8 Dec 2013, at 2:00 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:

> The specific import of this - to ghdl - is that ghdl's VHPI interface
> really only supports procedure/function calls between languages. 
> So if you can structure the interaction such that a VHDL process calls a
> C function or procedure (void function), that process will block until
> the function's return, and that takes zero simulation time (occurs
> within a delta cycle). 
> Thus with the VHDL side in control, the simulation cycle controls the
> timing. 

There was a ghdl-discuss thread earlier this year, mid April "Calling functions 
written in VHDL from a linked C-language-compiled binary" which got slightly 
derailed by a post by René Doß, where I modified an assignment statement making 
a foreign call from:

    global <= set_global(2);

In a concurrent signal assignment statement, to:

    global <= set_global(2) when board_clock'event and board_clock = '1';

Which adds a signal event sensitivity to the equivalent process. You could note 
the process blocks until set_global returns while the rest of the VHDL 
simulation continues to run.  I attached a waveform showing a boatload of clock 
events over a couple of hundred milliseconds with three events on the 
equivalent process for the concurrent
signal assignment statement - set_global(2) gets standard input (key strokes).  
That's also simulation time and doesn't match real time in front of the 

VHDL is inherently parallel. Making the VHDL side of a co-simulation effort not 
consume simulation time while waiting on the C side would require stopping the 
simulation cycle. It'd require ghdl change that would effectively make the VHDL 
simulation a subsidiary process to the C side, and isn't really co-simulation. 

Instead of a ghdl change stopping the simulation cycle it should be possible to 
introduce a command line variable for specifying a resolution limit, which is 
effectively a pre-scalar for simulation time.  Setting the resolution limit to 
ns for instance would allow specifying time events (after, wait for) to an 
accuracy of 1/100th of a nanosecond and allow the simulation to run for several 
months of simulation time without increasing the size (range) of time.  

You could note that qemu simulations can take advantage of Modelsim's -t option 
to set the resolution limit. 

The changes to ghdl include using the resolution in reporting time and an 
assertion when assigning future events at a resolution less than the resolution 

We ought to put implementing resolution limits as a goal for ghdl, and from the 
interest shown in the last year a fairly high one.  Resolution limit is 
mentioned in IEEE Std 1076-1993,  Predefined physical types (, 

There's a class of co-simulation involving synchronizing 'real-time' as opposed 
to simulated time for the C side model to passage of simulation time on the 
VHDL side that's not covered by this.  This is usually the domain where 'corner 
cases' live, which can be simulated by capturing vectors to apply to a 
standalone VHDL model.

> My experience calling VHDL from C is less successful; though it ought to
> be possible at a coarse (outer) level, to start the VHDL system (e.g.
> bring the SOC out of reset). Further interaction would then be triggered
> from the VHDL side.

Because the C side has no way of generating signal events without a relaxation 
process on the VHDL side 'polling'.  From the VHDL side Foreign process calls, 
File I/O operations, shmem ops in foreign processes...(the latter also saying 
the VHDL side could start the C side going).

Building a VHPI interface for the C side to interact with signals doesn't solve 
most of the issues, it would have the ability to make the C side wait on the 
VHDL simulator for signal events as opposed to flags in FIFOs (in shmem, etc.).

Having the VHDL side in charge is actually cleaner system design, with the 
exception that is now responsible for translating vectors (collections of data 
changes) into signal events, albeit likely more efficiently than using textio.

Ghdl-discuss mailing list

Reply via email to