On 07/04/2016 05:35 PM, Adrien Prost-Boucle wrote: >> >> I agree. Yes to scripting, but maybe not with tcl. >> (Although it would be better to have a generic scripting infrastructure >> to support any language). >> >> Tristan. > > I agree with that. Here is my point. > > TCL can certainly easily become a nightmare, but it depends on the > application. > GHDL lives very well without scripting, so the needs are probably light. > In terms of number of commands to implement and complexity of those, I mean.
Off the top of my head (and with a couple of beers in me (Independence Day barbecue (woohoo))), I imagine what might be needed/useful would be a facility to: 1) configure a trace file 2) configure IPC/RPC 3) a shell to explore the model and set values (maybe) 4) [a shell/]config-file to control the simulation It seems like any serious co-simulation can/should be done in a separate process, interacting via some kind of IPC or RPC, using whatever language/runtime that is most appropriate for the problem domain. For the most part, it seems like almost all of this can be done [currently] in an ad-hoc fashion (except for the trace file config). The embedded light-weight Tcl interpreter seems like a way to consolidate these four facilities with a uniform, documented syntax in a self-contained, manageable code-base. I still haven't gotten my mind around the strongly adverse reaction people on his list have to the Tcl syntax. Perhaps people are imagining the intention is to use it for serious programming workloads rather than using it as a configuration file syntax with light-weight scripting capabilities(?). _______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
