From: Paul on 14 Feb 2010 10:24 On 14 Feb, 09:34, Jan Decaluwe <j...(a)jandecaluwe.com> wrote: > > So what you're saying is that *because* RTL coding is harder, > methodologies that may make it easier are not applicable ??? > That's not what I said at all!! :-) OK, my point was too narrow, i.e. specs for FPGA designs tend to be pretty well specified and so you don't need agile methodology, which essentially I construe as being geared up to deal with implementing a design that has changing requirements. > To understand how agile concepts such as unit testing and test driven > development can be used for HDL design, also check out MyHDL. I do use unit tests on occasion for software, but I don't use test driven development. For VHDL, unit tests would mean I would have to write self-checking testbenches, and unfortunately I don't tend to get the time for that. It would be nice however to have a unit test environment for VHDL. One day I might get the time to use it.... Regards, Paul.
From: Petter Gustad on 14 Feb 2010 11:02 Paul <pault.eg(a)googlemail.com> writes: > driven development. For VHDL, unit tests would mean I would have to > write self-checking testbenches, and unfortunately I don't tend to get > the time for that. It would be nice however to have a unit test How do you have time *not* to do that :-) Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
From: Nico Coesel on 14 Feb 2010 11:10 Petter Gustad <newsmailcomp6(a)gustad.com> wrote: >nico(a)puntnl.niks (Nico Coesel) writes: > >> Bottom line is that VHDL is more powerful & complicated than Verilog >> but neither are the perfect language. For people with a background in > >Depends upon which Verilog standard you refer to as Verilog. IEEE-1800 >is way more powerful than any of the VHDL standards IMHO. I'm talking about the Verilog you can actually use with todays tools. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico(a)nctdevpuntnl (punt=.) --------------------------------------------------------------
From: Paul on 14 Feb 2010 11:13 On 14 Feb, 16:02, Petter Gustad <newsmailco...(a)gustad.com> wrote: > > driven development. For VHDL, unit tests would mean I would have to > > write self-checking testbenches, and unfortunately I don't tend to get > > the time for that. It would be nice however to have a unit test > > How do you have time *not* to do that :-) Because I write stimulus only test benches. Which of course only means visual inspection of results. That method I find is the quickest way of getting to a working FPGA design. How do you get the time to do self-checking testbenches? :-) Paul.
From: rickman on 14 Feb 2010 12:15
On Feb 14, 11:13 am, Paul <pault...(a)googlemail.com> wrote: > On 14 Feb, 16:02, Petter Gustad <newsmailco...(a)gustad.com> wrote: > > > > driven development. For VHDL, unit tests would mean I would have to > > > write self-checking testbenches, and unfortunately I don't tend to get > > > the time for that. It would be nice however to have a unit test > > > How do you have time *not* to do that :-) > > Because I write stimulus only test benches. Which of course only means > visual inspection of results. That method I find is the quickest way > of getting to a working FPGA design. > > How do you get the time to do self-checking testbenches? :-) > > Paul. I tend to use self-checking test benches. There is some question as to what is best, but I find that often my design has to be tweaked after I have it working and once I have the test bench working, the tweaked design can be tested very easily. I guess it is a question of whether the test bench is a one time thing or will be "reused". I often find I "reuse" my test benches in both ways, I often run them more than once and I use parts of one test bench in others as I test my way up the integration process. Oh, also, there has been more than once that my test bench was actually another FPGA design that ended up on a test fixture to production test the real board. That can be a fair amount of work, but not as much work as separately testing two FPGA designs. Rick |