Hi YG, > > So your overall events system must work in a "polled" way, > with your C function called everytime GHDL has done its work for the > current cycle.
This is probably where the VHPI interface is often misunderstood. So if you want your simulation to serve an external client asynchronously (by TCP, or similar), it makes sense to start up a thread (e.g. ghdlex starts up a netpp server for its virtual devices/pins/rams). Since you might not want to mess with mutexes inside GHDLs event handling, you just mutex all inter-thread communication *inside* your VHPI-wrapped C function. I couldn't see any performance penalty with that. You could introduce event signals to cause the polling function only to be called when, say, data is available from the outside virtual interface. That again works only via the VPI interface though, and has threading issues. > >> If you want more complex shit with >> autogenerated HW description and virtual devices, google for >> ghdlex/netpp. >> Some folks are also using simple unix pipes for C <-> Simulation I/O, >> like the classic trick with 'socat' to fake a virtual UART via a PTY. >> Just found something that should come close, see attachment. You can >> hack a tad more solutions with socat that can do networking without >> requiring you to set up your own socket dance. > > This system looks great, where do you host it ? It should go to > the GHDL page of external resources ! > I didn't properly 'host' it so far apart from throwing in download links. Somebody had put it up on a source hoster, but this tree doesn't seem to be active (I'm not involved). I'm gonna revisit the full release/documentation dance again when heading towards v1.0 stability. Greetings, - Martin _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
