Hello Adam,
Thanks for your suggestions. Yes, I am going for the custom
syntax/parser, as I believe in the KISS philosphy :). As far as I know,
we don't have a clear goal of a more complex simulation that requires a
scripting language interpretor, but here I am not the most informed
person ;). And if in several years we finaly find out that we need a
scripting language interpretor, we will probably take different
decisions than if we would do the choice today, because we will better
know what would be our needs and new scripting languages may emerge
until then.
Yes libconfig is too much for only signal selections. I can imagine that
in some day the trace configuration file could also include simulation
options like the duration of the simulation, but even in this case,
maybe broadly 95% of the file will still be about signal selection. So
the file synthax should still be in this case optimized for the 95% of
lines about signal selection.
And sorry that you didn't receive here more enthousastic answers for
your proposition about a tcl interpretor ;).
Cheers,
Jonas
Le 05.07.16 à 20:13, Adam Jensen a écrit :
On 07/05/2016 02:12 AM, Tristan Gingold wrote:
On 03/07/16 20:47, Adam Jensen wrote:
On 07/03/2016 11:20 AM, Jonas Baggett wrote:
Hello,
I had some more thoughs on the signal selection for the waveform, and I
made an example of a wave signal file (is there a better english therm
for that ?) that reflects them :
Have you considered embedding a Tcl interpreter?
Can you clarify why an interpreter would help to select signals ?
The file format is so simple that 'parsing' it manually would be very
simple too.
A custom syntax/parser for a signal-trace configuration file seems like
a perfectly valid way to implement a very useful function. If that is
the only goal, then libconfig is probably overkill and jimTcl is
certainly excessive.
I've been imagining that one day GHDL might have richly structured HDF5
signal-trace capabilities, and that simulations might be configured with
elaborate IPC/RPC (for interaction with Octave, R, SciPy, etc.), and a
few other slightly more unusual deployments. It seems like much of this
might benefit from a [scriptable] embedded shell with access to both the
simulation-model and the OS.
But these suggestions [from me] are all just "what if..." and "would it
be nifty if..." type remarks. I'm not implementing anything and the
decisions are ultimately going to be made by the people who actually
build things. Viva la open-source! ;)
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
_______________________________________________
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
