VHDL vs Verilog

On Feb 13, 12:48 pm, Jonathan Bromley <jonathan.brom...@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?

On 2/13/2010 11:17 PM, Michael S wrote:
> On Feb 13, 12:48 pm, Jonathan Bromley<jonathan.brom...@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.

On 2/13/2010 5:22 AM, KJ wrote:
> On Feb 12, 8:16 pm, Symon<symon_bre...@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.

Paul wrote:

> 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 could argue that RTL is very similar to software, because the only
difference is that HDLs support time. The information content of such
statements is not very high.

> 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.

It is "of course" trivial to emulate static objects in dynamic languages:
just don't touch them after creation :-) The principal RTL restriction
lies elsewhere: only a limited subset of types can be implemented
in silicon.

> 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.

So what you're saying is that *because* RTL coding is harder,
methodologies that may make it easier are not applicable ???
The logical conclusion would be the opposite.

> 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 don't see how the rapidly evolving FPGA technology can be optimally
used without drastic changes to traditional FPGA design methodology.

> I can't think of how any recent software methods would help RTL. Maybe
> I'm a stick-in-the-mud :-)

I think your a little fast with conclusions.

For an HDL based on a dynamic language, check out MyHDL.

To understand how agile concepts such as unit testing and test driven
development can be used for HDL design, also check out MyHDL.

For an agile VHDL development platform, check out Sigasi HDT.

Jan


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

>> Just a slip or Freudian Slip?
>
>A Freudian slip is when you say one thing, but mean amother.

And presumably a (capitalized) Freudian Slip is when you
ask for one piece of underwear, but want another?
-- 
Jonathan Bromley

On Sat, 13 Feb 2010 15:17:09 -0800 (PST), Michael S
<already5chosen@yahoo.com> wrote:

>On Feb 13, 12:48 pm, Jonathan Bromley 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.
>
>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."

No, I meant what I said.  I agree that Verilog pre-2001, 
with absolutely everything being static, was fairly painful 
for writing any kind of software.  But VHDL pre-2008 (and, 
because of lack of interest by tool vendors, VHDL even today) 
lacks cross-module references, which is a show-stopper.

SystemVerilog, Vera, 'e' and other dynamic testbench 
languages (even C++, if you really must) are so much 
more fit-for-purpose that there is no point in looking 
back unless you're constrained by lack of availability 
of the appropriate tools.
-- 
Jonathan Bromley

nico@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.

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?

On Sun, 14 Feb 2010 01:35:12 +0000, Symon wrote:

>OT, but couldn't resist.
>
>A Freudian slip is when you say one thing, but mean amother.

I thought a Freudian slip occurs when you say the
embarrassing words that you really mean, instead of 
the weasel words you were trying to say?  When your
id slips through your superego's security checks?
-- 
Jonathan Bromley

On 14 Feb, 09:34, Jan Decaluwe <j...@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.

Paul <pault.eg@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?