On Jan 14, 2012, at 11:09 PM, Walter F.J. Mueller wrote: > I put it a little wider: > > - when ghdl wants to survive on the long run it has to implement > also the major vhdl-2008 language features in the future. > - by the time vhdl-2008 is supported by synthesis tools one wants > to use some of them, and it be sad if the state of ghdl would > prevent that. > - vhpi and thus "C" code interfacing is now formally part of vhdl-2008.
You realize we're working on P1076-2013 right now. The majority of HDL use in the world is still probably VHDL. There's a fairly small number of users clamoring for compliance, involved in verification and system simulation. Historically new version standards compliance was a marketing qualifier. That hasn't really been the case. Xilinx for instance does using configuration statements properly - you can't overload generic yet identically interfaced entities with specific ones by configuration. It means you can't instance hierarchy containing elements differing by contents but not interface. An example would be a standard ROM, with different contents in several instantiations. (And yes you could partially load them, but that isn't the point, it's a pain to load them in your simulator and requires a gate level representation (primsim or unisim). If you can't get the guys responsible for some large part of the VHDL use to be compliant with VHDL-93, what good is yet another version? I'm aware of one vendor claiming to be VHDL-2008 compliant, but I'd be willing to bet someone could write test cases that would disabuse the notion. There's also a couple of things in 2008 that are guaranteed to kill performance if used. The point of all this is that the standard isn't driving the tools, it's feature usage, and the two aren't as strongly coupled as they might have been in the past, particularly in the view of those interested in creating a System-VHDL. The market for that is already occupied by System-Verilog and System-C and one of the two of those could co-exist in a simulation engine with VHDL. _______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
