I'd rather switch than fight!
in [FPGA]
|
From: Patrick Maupin on 11 Apr 2010 17:02 On Apr 11, 2:13 pm, KJ <kkjenni...(a)sbcglobal.net> wrote: > On Apr 10, 9:42 pm, "jt_eaton" > > <z3qmtr45(a)n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > > Why do people keep comparing the checking that is inherent in VHDL with > > what is done in Verilog? > > Are you suggesting that it is not a fair comparison of two things that > purport to fulfill the same need? Just like any other competing > products, boosters of one will claim advantage over the weakness of > the other. Well, as you point out, comparisons will be made. Then again, as I tried to explain in an earlier post, typing errors are but a tiny class of potential errors that can be made. > > There is a whole class of tools called rtl > > checkers that are designed to catch these language gotches before you run > > simulation. > > There are almost always new products that pop up to fulfill any > shortcoming. That's the marketplace in action. <MeaninglessGoogleExample> When I google for "vhdl rtl checker" I actually get more hits than when I google for "verilog rtl checker". What does it mean? Who knows? </MeaninglessGoogleExample> > While this will most likely be a misinterpreted analogy, the existence > of an additional tool such as a crutch is not a reason to prefer a > broken leg over an unbroken one. While this will most likely be a misinterpreted analogy, the potential existence of a car that will drive for you and automatically encase you in foam in the event of an accident (like in "Demolition Man") is not a reason to prefer cars over motorcycles. > > Yes there are lots of ways to make mistakes in verilog. That > > simply means that you need to add a tool that can catch them. > > Or ask yourself if the hassle of yet another tool (and possible > licensing costs) is worth it? Maybe it is, maybe it's not, but that > 'worth it' decision will most likely be an individual one unless the > tool is very, very good and near zero cost (product cost and learning > curve cost). Generally speaking, most people would not prefer to use > 'yet another' tool in the tool chain unless they feel it adds real > value...and dislike additional tools that fundamentally are there to > catch shortcomings...even if the tool is really good at what it does > and is free, open source. These are good points, but at least *some* people believe in the Unix mindset of small, great, tools with a laser focus, instead of some big monolithic black box that you shove code in one side and get a bit file out the other side. And the nice thing about (Verilog and VHDL) RTL checkers is that most of them are quite configurable to a given company's design rules. Having said all that, it is true that a lone developer might prefer a cheap, all-in-one solution, and it might be that VHDL is closer to that than Verilog, but it is certainly not a panacea, and as Rickman is finding out, the cost of having the additional "safety" features (in terms of difficulties trying to coax VHDL into letting you do a few things that Verilog would let you do quite easily) might in some cases outweigh the cost of not having those same safety features. > Rickman's original point is that he thinks he can be more productive > using Verilog than VHDL. Whether or not *he* can be more productive > or not depends a lot on Rickman, his usage and frequency of usage of > any language, the types of design errors that he tends to make, etc. Absolutely agreed. > In the end, Rickman learning Verilog likely increases his > marketability since he may master yet another skill that could be of > use in his career. Also agreed. Learning tools that can be useful for your job is always a great thing. > The actual increased or decreased productivity > that prompted him will in the end will probably be found to be very > low...probably much lower than the ability to work with both languages > (assuming that he can achieve relatively high skill in both languages, > rather than only be marginally skilled in either). We will have to see his anniversary report this time next year ;-) BTW, slashdot had a verilog/vhdl question awhile back -- which one should be taught as a first HDL? http://ask.slashdot.org/article.pl?sid=09/05/31/187208 One of the commenters noted that the all the anecdotal evidence provided by the other comments indicated that people who learned VHDL first had no problem subsequently learning and working with Verilog, but that the converse was not true, so *obviously* teaching VHDL was the correct answer. http://ask.slashdot.org/comments.pl?sid=1251483&cid=28160801 I agree with his observation of the provided anecdotes, but the conclusion seems a bit stretched to me. If I am allowed one more bad analogy, it would be as if a study showed that people who learned how to do basic math with Roman numerals had no problem adapting to Arabic numerals, but people taught with Arabic numerals struggled with basic math when they were later expected to use Roman numerals (so *obviously* we should teach math with Roman numerals first). Regards, Pat
From: Jan Decaluwe on 12 Apr 2010 05:23 On Apr 11, 5:03 am, Patrick Maupin <pmau...(a)gmail.com> wrote: > So, no, I don't think I'm confused at all (I can't speak for my > readers; I often leave those confused, I'm sure) and I stand by my > assertion that one of the key principles of programming in Python is > that typing errors are typically the least of the possible errors in a > real program. As a thought experiment, imagine a Verilog revision based on a pythonic mindset. Here's what would likely happen to Jonathan's examples: Issue: Most-significant bits silently lost when you copy a wide vector into a narrow one. New behavior: run-time or compile-time error. Rationale: "Errors should never pass silently". (Python zen) Issue: Signed values silently zero-filled to the width of a wider target. New behavior: Use sign bit extension instead. Rationale: Obvious language design errors should be fixed. Verilog designers are surprizingly tolerant to those, but a Python language designer would never get away with this. As a conclusion, your reference to Python to justify Verilog's current behavior is rather unconvincing. Jan
From: Chris Higgs on 12 Apr 2010 06:49 On Apr 9, 9:05 pm, Patrick Maupin <pmau...(a)gmail.com> wrote: > And BTW, (IMO) it's *much* easier to code a reasonable testbench in > verilog than in VHDL. But, obviously, your mileage varies. I fail to understand why people don't code testbenches in a nice dynamic language like python. Limit the use of HDLs to describing the hardware and make use of a high-level scripting language to read in files/generate stimuli, check results and introduce errors/modify state dynamically. It's time to move on from the immensely limited HDL fileIO testbench model. Thanks, Chris
From: KJ on 12 Apr 2010 07:12 On Apr 12, 6:49 am, Chris Higgs <chiggs...(a)googlemail.com> wrote: > On Apr 9, 9:05 pm, Patrick Maupin <pmau...(a)gmail.com> wrote: > > > I fail to understand why people don't code testbenches in a nice > dynamic language like python. > Because it's just as productive to code models and deal with only one language. > Limit the use of HDLs to describing the hardware and make use of a > high-level scripting language to read in files/generate stimuli, check > results and introduce errors/modify state dynamically. It's time to > move on from the immensely limited HDL fileIO testbench model. > Perhaps you should adjust your mindset and consider that testbench models are in no way limited to 'fileIO testbench models'. Testbenches can use real models of real devices, it's not that hard. Error injection handled easily as well. 'High level' scripting languages don't necessarily have any inherent advantages, they're just different languages. KJ
From: Chris Higgs on 12 Apr 2010 07:44
On Apr 12, 12:12 pm, KJ <kkjenni...(a)sbcglobal.net> wrote: > On Apr 12, 6:49 am, Chris Higgs <chiggs...(a)googlemail.com> wrote: > > > On Apr 9, 9:05 pm, Patrick Maupin <pmau...(a)gmail.com> wrote: > > > I fail to understand why people don't code testbenches in a nice > > dynamic language like python. > > Because it's just as productive to code models and deal with only one > language. > > > Limit the use of HDLs to describing the hardware and make use of a > > high-level scripting language to read in files/generate stimuli, check > > results and introduce errors/modify state dynamically. It's time to > > move on from the immensely limited HDL fileIO testbench model. > > Perhaps you should adjust your mindset and consider that testbench > models are in no way limited to 'fileIO testbench models'. > Testbenches can use real models of real devices, it's not that hard. > Error injection handled easily as well. 'High level' scripting > languages don't necessarily have any inherent advantages, they're just > different languages. > > KJ The way most people* tend to write testbenches is to use a scripting language to generate stimuli file and check the results (also written to a file) afterwards. That's fine if you're doing some pipelined transformation function where no re-ordering or dropping of data can occur, but falls down with less rigid designs. The point is that HDLs aren't well suited for writing complex testbenches. Yes, many things are possible but in practice they are clunky and tend to balloon into a mess. I've seen far too many unmaintained, overly complicated and indecipherable testbenches written in HDLs. I've seen a several thousand line VHDL package to generate ethernet frames. In python its as simple as "from scapy.all import Ether; pkt=Ether()". 'High level' scripting languages have many inherent advantages. For example - I'm currently testing an "ethernet switch" like device. It's behaviour depends on various dynamic configuration options and internal state (fill levels etc). Try writing a testbench for that in VHDL - it would take forever! Using python, I can generate packets using an existing library, directly read (and modify) the internal state, use the state to determine the correct actions for each packet (not possible in an HDL testbench without artificially bringing signals out of the top level). I can also use the exact same software written to configure and control the programmed FPGA in hardware to control the unit under test in the testbench, widening the scope of the test coverage. The biggest advantage, however, is the speed with which I can write complex tests. *Obviously this is all in my own humble opinion and limited experience. I'd be interested to hear alternative approaches to testing that people use. I just happen to be strongly prejudiced and believe many people would benefit from adopting approaches more similar to my own ;) Thanks, Chris |