Using IPC is a big performance hit. It might be good enough for analysis tasks, but it's a bottleneck for co-simulations. Which IPC technique works on all supported GHDL platforms?
I saw an EDA tool which has 2 embedded scripting languages: Tcl and Python!
Counter question: Why do CAD tool users think that Tcl is a GOOD embedded scripting language? Just because vendors ship their tools with Tcl, doesn't make Tcl a good language...
Kind regards
Patrick
Wissenschaftliche Hilfskraft
Technische Universität Dresden
Fakultät Informatik
Institut für Technische Informatik
Lehrstuhl VLSI-Entwurfssysteme, Diagnostik und Architektur
01062 Dresden, GERMANY
Tel.: +49 351 463-38451 Fax: +49 351 463-38324
E-Mail: patrick.lehm...@tu-dresden.de
WWW: http://vlsi-eda.inf.tu-dresden.de
-------- Ursprüngliche Nachricht --------
Von: Adam Jensen
Datum:26.10.2016 21:44 (GMT+01:00)
An: ghdl-discuss@gna.org
Betreff: Re: [Ghdl-discuss] Synthesis for FPGAs
On 10/26/2016 01:44 PM, Vern Muhr wrote:
[snip]
> I have read that there is consideration of embedding Python in the GHDL
> system.
[snip]
<polemic> I still don't get why so many people believe that embedding a
Python interpreter is a desirable thing to do. The methods of the pyCult
are undeniably effective. ;) </polemic>
I suggest that any co-processing that the simulation model needs should
take place in a separate process and be accessed via typical IPC
(Inter-Process Communication) methods. This would allow flexibility in
the selection of the co-processing environment (e.g., Octave, R, SciPy,
etc.).
Given that situation, some configuration support might be in order. I
would prefer a command shell for interactive exploration of the model's
structure & state, and loadable scripts for configuration and automated
control of the simulation.
It seems desirable that the source code, syntax, and embedded executable
should be light-weight and straight-forward to use, document, and maintain.
This problem has already been solved.
http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html
http://jim.tcl.tk
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
[snip]
> I have read that there is consideration of embedding Python in the GHDL
> system.
[snip]
<polemic> I still don't get why so many people believe that embedding a
Python interpreter is a desirable thing to do. The methods of the pyCult
are undeniably effective. ;) </polemic>
I suggest that any co-processing that the simulation model needs should
take place in a separate process and be accessed via typical IPC
(Inter-Process Communication) methods. This would allow flexibility in
the selection of the co-processing environment (e.g., Octave, R, SciPy,
etc.).
Given that situation, some configuration support might be in order. I
would prefer a command shell for interactive exploration of the model's
structure & state, and loadable scripts for configuration and automated
control of the simulation.
It seems desirable that the source code, syntax, and embedded executable
should be light-weight and straight-forward to use, document, and maintain.
This problem has already been solved.
http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html
http://jim.tcl.tk
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
