Hi all,
It occurred to me while having a walk about a few moments ago that there
could be a confusion of two separate ideas in these discussions: first,
is embedding an interpreter into the run-time results of the ghdl
compiler (into the simulation model); the second is embedding an
interpreter into the ghdl compiler itself (extending its capabilities in
some way, I suppose). I've been thinking and remarking entirely on the
first scenario.
There's more confusion to be added, even:
a) Control simulation from outside (asynchronously)
b) Do "client side" stuff from inside the simulation
I think most users would want (a) to control the simulation process. I
don't really see the reason embedding a Python interpreter, although
that can be done on an ortho-generated exe already - you just need to
call an init wrapper from your VHDL TB that spawns a thread. But calling
Python-Coroutines from GHDL doesn't make sense to me.
It rather makes sense to me giving access to more GHDL internals over an
asynchronous command interface, for example, if you want the modelsim
like start/stop or specific signal trace/selection features.
The mcode GHDL is of course a different story. But I guess both ortho
and mcode could supply a plugin API for simulation control (on top of
the VHPI interface) that would load a user specific extension DLL.
On 10/26/2016 04:20 PM, Patrick Lehmann wrote:
Using IPC is a big performance hit. It might be good enough for analysis
tasks, but it's a bottleneck for co-simulations.
Others on this list have used the IPC technique. They're probably better
equipped to remark on performance issues and partitioning thresholds.
I'm even using RPC over networked simulations, like a gdb speaking over
virtual JTAG to a simulated SoC which again spits out data over a pty
(using ghdlex/netpp).
Or the dance with qemu and GHDL-simulated peripherals. Since simulation
is typically slower, there's no significant bottleneck, unless you have
a lot of ping-pong between simulation domains, such as a virtual bus.
Via ghdlex, Python scripted control of the VHDL simulation (_not_ the
simulator engine) is already possible. However, I've never covered the
mcode side of it.
Counter question: Why do assume that is the reason? (Rhetorical
question, I know why. (Have I mentioned the feistiness?)).
It's not a poor reason - if CAD tool users already know the syntax, that
reduces the obstacles and burdens.
I don't want to start a language war, but tcl/tk appears a bit outdated
to me and doesn't have the ecosystem that the Python world has, apart
from performance/integration issues with C DLLs or object kernels. The
point that EDA people are used to TCL is certainly valid, on the other
hand, I believe it's worth modernizing that domain a bit. I have made
good experiences with the CAD dudes adopting Python :-)
Greetings,
- Martin
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
