Hi Tristan, Now the -g options are implemented and work at run time, I tend to love it, and use it.
I often design with large number of generics in order to be able to investigate impact on design efficiency / latency / throughput. I compile all VHDL files with the gcc version of GHDL, and obtain an executable. Then I launch many runs in parallel with different parameters (with -g options), and in different folders with different data files. This is extremely convenient. With -g options applying only at elaboration, I would have to do re-elaboration for each tested configuration. I suspect I would need to generate N versions of the simulator, in different directories, which could make GHDL usage more complicated. Elaboration take time (at least with the gcc version). Olof Kraigher suggested using --elab-run but measuring simulation time gets strongly biased this way. On one hand, I think being able to set some generics with -g at elaboration time can have a positive impact, on the generated simulator speed and on the generated executable size. But on the other hand, the disappearance of ALL generics for run time would be painful. But I haven't seriously investigated : what I wrote above is only assumption, please correct me if I'm wrong! The ideal flow would be, from my point of view: - all -g options set at elaboration time make the corresponding generic value be hard-set in the generated simulator, - -g options for remaining generics are still available at run time Such a flow would be very generic and this is guaranteed to fit any serious or fancy user need. Is -g support at run time really hard to maintain for current and future GHDL developments? Regards, Adrien On Thu, 2015-09-24 at 21:15 +0200, Tristan Gingold wrote: [...] > BTW, I plan to change the switch to override generics of > the top entity. It will still be -gNAME=VAl but have to be > set during elaboration. > This won't happen before 0.33. I plan to have both > mechanisms for 0.34 but remove the current mechanism > for 0.35. Let me know if this is an issue for you. > > Tristan. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
