VHDL vs Verilog
in [FPGA]
|
From: Symon on 13 Feb 2010 14:15 On 2/13/2010 5:25 AM, whygee wrote: > thanks for the off-topic anyway :-) > > yg ....and thank you for taking it in the spirit it was intended! :-) All the best, Symon.
From: Paul on 13 Feb 2010 15:46 > > The RTL community's reluctance to adopt what it can > from the software world is saddening and mystifying. > I cannot think of even one serious attempt to raise > the abstraction level of RTL design in the last > 20 years that has been commercially successful. > But RTL generally is very different to software, because RTL has the extra requirement that things have to happen at explicit times. I'm not sure RTL could adopt much from the software world that would make RTL quicker/easier. I can't think of how OO methods would work for RTL coding. For testbenches maybe. Although procedural testbenches are probably more than adequate for the majority of cases. Dynamic types of course are also no good for RTL, because signals/ variables are static. Dynamic languages could be used for testbenches but then dynamic languages are slower, possibly not what you want for testbenches. Although I guess the speed impact of a dynamic language for testbenches would depend on the relative complexity of a testbench to the RTL design. Agile methods are probably out. Apparently they're good for quickly changing code to accommodate quickly changing requirements. But because RTL coding is harder than writing software (because of the extra requirement that things have to happen happen at specific times), quickly changing RTL code isn't really possible. And for FPGA designs tying specs down to a reasonable level is a lot easier than for software engineering, because an FPGA has at least well defined requirements in what it has to drive on a circuit board. So just write the specs right, or mostly right to start with, and you don't need agile. I can't think of how any recent software methods would help RTL. Maybe I'm a stick-in-the-mud :-) > By contrast, VHDL's limitations in the world of > testbench writing are so severe that it's amazing > it gained any traction at all in that space. (1) vhdl is used for RTL so use the same language for testbenches, and (2) a lot of electronics engineers' requirements for test benches are pretty simple, and so VHDL is mostly adequate; i.e. basic test- benching, then debug on hardware, maybe also using something like chipscope. Writing good testbenches, especially self-checking ones, takes time. And you have to debug the testbenches as well as the RTL. So if you can debug the RTL in hardware, why spend a lot of time writing/ debugging testbenches? The reason why I say 'suspect' above is because I don't really know, but the majority of electronics engineers who design FPGAs that I've come across whilst working as an electronics engineer, do the minimum amount of testbenching, with self-cheking testbenches very thin on the ground. I'm supposing that full time ASIC/FPGA designers (rather than electronics engineers who design hardware as well as designing FPGAs) do put a lot of effort into writing good testbenches, but then they'll probably be using SystemVerilog or something similar. It would be interesting to see some statistics on debug methods actually used in industry. Of course you could say that if VHDL was easier to use for writing testbenches more electronics engineers would be writing more comprehensive testbenches, hmmm... It would be nice if VHDL had a more flexible approach to creating/ controlling processes (or threads or tasks, whatever they might be called). VHDL static processes are fine for RTL of course, but essentially a bit crumby for testbenches. It will be interesting to see what future vhdl standards throw up. I would like some process/ thread/task control in VHDL, much more than OO additions.
From: Michael S on 13 Feb 2010 18:17 On Feb 13, 12:48 pm, Jonathan Bromley <jonathan.brom...(a)MYCOMPANY.com> wrote: > On Sat, 13 Feb 2010 06:25:13 +0100, whygee wrote: > > By contrast, VHDL's limitations in the world of > testbench writing are so severe that it's amazing > it gained any traction at all in that space. > > Jonathan Bromley I am assuming the above was intended to read as "By contrast, Verilog's limitations in the world of testbench writing are so severe that it's amazing it gained any traction at all in that space." Just a slip or Freudian Slip?
From: Symon on 13 Feb 2010 20:35 On 2/13/2010 11:17 PM, Michael S wrote: > On Feb 13, 12:48 pm, Jonathan Bromley<jonathan.brom...(a)MYCOMPANY.com> > wrote: >> On Sat, 13 Feb 2010 06:25:13 +0100, whygee wrote: >> >> By contrast, VHDL's limitations in the world of >> testbench writing are so severe that it's amazing >> it gained any traction at all in that space. >> >> Jonathan Bromley > > I am assuming the above was intended to read as "By contrast, > Verilog's limitations in the world of testbench writing are so severe > that it's amazing it gained any traction at all in that space." > Just a slip or Freudian Slip? OT, but couldn't resist. A Freudian slip is when you say one thing, but mean amother. HTH, Syms.
From: Symon on 13 Feb 2010 20:41
On 2/13/2010 5:22 AM, KJ wrote: > On Feb 12, 8:16 pm, Symon<symon_bre...(a)hotmail.com> wrote: > >> ...to comp.lang.vhdl where you will find polite software people. Ask for >> Jonathan, Mike and KJ. Tell them I sent you. >> > > Ooooo...you read my posts and am on your recommended reading list > now!!! > > KJ I have do a lot of HDL in my job, and you guys really know your stuff. I rarely have to post to ask, because a search reveals your considered solutions! Thanks!! Syms. |