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
keyboard.
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
limit.
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, 3.1.3.1 Predefined physical types (5.2.4.2,
-2008).
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
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
