Sanjay Singh escribió: >> Hmmm ... LEON isn't a good example of normal VHDL coding. Gaisler used a >> special technique to code LEON, this technique is very different to >> regular VHDL coding. >> > > The PDF from Jiri Gaisler which I ran across in the last week or so, seems to > suggest that this 2 process coding style that he used for LEON2 is a definite > win across a number of metrics. >
Yes, it suggest this, we couldn't verify their claims. Our results aren't conclusive. > So while it may not be typical VHDL coding, perhaps it should be. > > >> A paper (included in a chapter of LEON docs) >> explains it. Is something like this: blocks get in/out records >> containing all the I/O. One process determines the next state from the >> current and the I/O. Another process transfers the next state to the >> current and sets the outputs. >> > > Can you please provide a URL, if it goes into more detail than the PDF I > reference below? I think this particular coding style from Gaisler is worth > digging into. > I'm not sure which one are you referring, the one we used is: http://www.gaisler.com/doc/vhdl2proc.pdf > It reminds me of a VHDL analogy to OOP design patterns, ie a particular > methodology for writing VHDL to improve its readability and maintainability > and lower development time. > > >> According to Gaisler it allows for a much higher abstraction. We tried >> to apply this technique with mixed results, usually involving slower >> simulation as the portions recoded like this increased. >> > > 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. > Be careful, which is good for Gaisler isn't necessarily good for you. Gaisler cores are usually very nice and functional, but really huge. We compared the USB core from Gaisler with other cores, including ours ... Gaisler core is the biggest Our full paper can be downloaded from: http://utic.inti.gov.ar/publicaciones/iberchip2009/usb_en.pdf You can see it graphically in the slide 28 of the presentation: http://utic.inti.gov.ar/publicaciones/iberchip2009/usb_presentacion.pdf The technique should also increase readability ... one of junior from my lab. tried to analyze the ethernet core to see if the implementation could be adapted for our needs ... the coding style didn't help at all. 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
