Hello,
On 21/10/15 20:49, Adrien Prost-Boucle wrote:
Hi everybody, I've just thought about a possibly strong reason to keep run-time override of generics (and also provide possibility to override some of the generics at elaboration time). In industry, it is often necessary to provide partners/clients some means to evaluate performance of IPs, but without disclosing critical aspects of internal implementations. Imagine you're an IP provider and your client of the moment needs to explore the design space to appropriately balance performance and cost of individual elements of the system. But development costs and validation time are crucial. Your IP is designed and validated, it is synthesizable. You don't want, or can't, spend time developing and maintaining a separate simulation model. So it is just great to directly convert the golden VHDL into a ready-to- use simulation model that is just appropriately configurable at run- time for the client needs. The partner/client uses that simulator to load its own test data (a generic to specify the file to open), and observes the behaviour under various design parameters (other generics) with cycle-accurate and bit-accurate precision. GHDL (at least llvm and gcc flavors) generate a standalone simulator so it seems this would just perfectly fit the needs. Some generics would be incorporated at elaboration time, hiding them for the client.
I am not sure it fits the needs. This will be a monolithic design and the user won't be able to easily instantiate it.
Some cons: - The resulting simulator would be limited to one entity in particular, which may reduce the use cases. But it may still be very useful. - The waveforms may disclose some details of the implementation. About waveforms being available, I was wondering whether disabling waveform generation could actually be an appropriate option for GHDL.
Yes, it could be possible, but...
On one hand, indeed, it's not pleasant to think about some part of GHDL being designed to lock users out of key features. But on the other hand, that could lead to enormous simulation speed optimization opportunities: - the simulator would be (much?) smaller,
Not really. The code to dump waveforms is separate from the design.
- many instructions would be removed which may lead to better compilation results,
Not so easily.
- and certainly the most interesting (my points of view xD) consequence: because the simulation delta cycles are no longer a mandatory precision level, many simplifications of miscellaneous signal assignations (= array copy for GHDL) can be merged and/or simplified away.
Delta cycles are mostly required for accurate results. It is possible to remove some/most of them, but this requires a global analysis which isn't possible if generics can be overridden at execution time!
In one of my designs where I put tons of generics, the simulation time increased from several seconds to several minutes between the initial baseline implementation and the final generic-stuffed version. Because some generics are enabling pipeline stages, I have to use temporary and very wide signals to identify input and output points. This creates an enormous amount of dummy signal assignations. So the simulations I can launch are strongly limited by simulation speed, which is, it seems, a direct consequence of the amount of customizability I put in the design.
Interesting. My plan is to address this inefficiency, but this would remove generic override at execution time :-(
@Tristan: this could be in the direction of an idea you mentioned (at FOSDEM and on the mailing list some time ago): transform the design, sort of pre-synthesis process, to keep only memory elements and transform the combinatorial elements towards logic synthesis-like elements. Such a transformation would destroy symbols and would make waveforms output far from the original VHDL code.
You're right for waveforms! Tristan. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
