From: Paul on
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
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
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
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
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