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. 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). 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. Just my $0.02 worth. Pete -- -- "To love for the sake of being loved is human; to love for the sake of loving is Angelic." -- Alphonse de Lamartine _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
