On Sun, 12 Jan 2014 11:46:42 +0000
Brian Drummond <[email protected]> wrote:

> There's a problem with this, as frequently pointed out by David
> Koontz : other languages don't share the discrete-event model. Thus
> the VHPI only really works in one direction : outwards from VHDL.
> 

Executing an external function and accepting its returned data in
zero simulation time shouldn't be a problem, right?

> That means you can call external functions from VHDL which will (from
> VHDL's POV) return within the same delta cycle, allowing VHDL to
> control the timing model. This mode of operation can be completely
> successful, as long as you can design the interactions around that
> constraint (which implies the calling process - and thus the entire
> sim time model) is blocked until the external function returns)
> 

Ah, exactly what I want. Imagine calling [GLPK][1] from VHDL to perform
a linear optimization, for example.

> Calling VHDL from external code, all I have managed to do is to run a
> top level design (which can then call back and dictate timings to
> external code).
> 

Very interesting! Not what I have in mind but definitely something
worth exploring.

> Now those external subprograms (called from VHDL, returning
> immediately) may control parallel software activities such as a GUI.
> But to do so they must be something like critical sections - an
> obvious model would be accessor methods to an Ada protected object.
> 

Hmm, "parallel software activities"? Are you describing a situation
where the VHDL might make calls into a threaded (or otherwise
internally concurrent) system?

> Thus for example if you're selling a UART chip, (but don't want it
> copied) you might provide a VHDL model callable from a software
> component representing the UART driver : that component would start
> the UART testbench and interact with it via protected objects
> representing the UART ports, and interact with the user app via the
> UART driver calls.
> 

It would be amazing to put together a small test case demonstrating
this capability! Again, it's not what I have in mind for my immediate
project but I can easily imagine many situations where this would be a
really nifty thing to do!

> In which case you might want to supply the VHDL component (testbench
> and UART, or possibly just the UART itself) as a binary.
> 
> Too far fetched?
> 

Not at all, from my perspective. Nice!

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss

Reply via email to