Peter LaDow escribió: > On Fri, Aug 7, 2009 at 10:46 AM, Sanjay Singh<[email protected]> wrote: > >> I was wondering if this is what you're referring to: >> >> http://www.gaisler.com/doc/structdes.pdf >> >> A comment on this two-process VHDL style slowing simulation. On GHDL it >> might very well be slower, until GHDL is further refined. But if one factors >> in a long lifecycle for VHDL as comparable to Ada projects, ie. 10-20 years, >> the human-centric gains for maintaining a large VHDL codebase in this way >> might be a significant win versus some percentage slower RTL simulation, >> whatever that percentage might be, I suspect less than 20% at the most. >> >> After all, Jiri Gaisler implemented an entire SPARC core for the European >> Space Agency. I would give this technique some leeway on those grounds. >> > > I admit, I hadn't seen this presentation before. And it is one very > interesting to me. The use of records to pass data between portions > of the design is nothing new. In fact, I have been using this as a > standard method of transferring data through pipeline stages for > years. The distinction, however, is that we have never done it for > ports on entities. And why not? For the very same reason you mention > above: 10-20 years design lifecycles. We went back and did a bug fix > on a design first done in 1999. Back then we used a version of > Autologic (remember that!) that did not support anything other than > std_logic or std_ulogic on entities, and had very limited support for > records (only std_logic/std_ulogic as members, no booleans, naturals, > etc). Our coding standard is a holdover from the rules defined by a > 10 year old synthesizer. > :-) similar reason made me discard this technique the first time a read the paper from Gaisler. We re-thinked it when the support for records in gtkwave (thanks to the GHW format) was added.
> And I think that is the crux of the issue. While VHDL may define a > significant number of features, such as buffer ports, user defined > types for ports, entity assertions, etc, synthesizers, either ignore > (when they should error out), get confused (generate bad hardware), > and if you are lucky, error out. VHDL is afterall, a _hardware_ > description language. Much of of what is done in RTL is imposed by > the synthesizer, not by the simulator or by the language standard. > > Finally, I will say that synthesizer support has improved > considerably. We did an internal project (read: non-production) and > we used records to pass data between entities. We even had naturals > and booleans in some of the records and it synthesized fine. Now, we > are using a full-blown (and expensive!) commercial tool, so one > perhaps should expect that. But cheaper tools, say Xilinx's > synthesizer, may not support such constructs (I have no idea, I've > never used it for more than very simple designs). Modern XST versions support it quite well. > And for new > designs, perhaps such constructs would be a good idea, but I do know > in my company there would be opposition for one simple reason: the > way we have been doing it for the last 15 years works, why change it? > I've been doing ASIC's and FPGA's since 1996, and in that whole time > there have been very few changes to the coding standards at companies > I've worked at. But one thing that has never changed in all that > time: only std_logic/std_ulogic for entities. > > And as a postscript, I have one criticism of the pdf. It sets up a > false dichotomoy between its "two-process coding style" and the > traditional fsm design. But it seems to define traditional fsm design > the two-process (combinational and sequential) using discrete inputs > and outputs. At the risk of starting the usual one vs. two process > state machine arguments, there is a third way. And it is the > one-process state machine that I have been using, which bypasses much > of the issues that he uses as cons to the traditional method. I think > the best way to do things probably lies somewhere in between Gaisler's > and traditional methods. > Most probably. Regards, SET -- _______________________________________________________________ Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/ INTI-Electrónica e Informática Tel: (+54 11) 4724 6315 Colectora de Av. General Paz 5445 San Martín - B1650KNA Casilla de Correo 157 FAX: (+54 11) 4754 5194 Buenos Aires * Argentina http://www.inti.gob.ar/ _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
