EDK : FSL macros defined by Xilinx are wrong

[Jeff Cunningham]

On 3/13/10 10:35 PM, rickman wrote:

1 million, you won't get their attention or even a quote.
I can get quotes from others, so why not from TierLogic ?

I don't understand the question. The point is they can't make enough
money from a small user to make it worth their while. So they exclude
the engineers that won't make them much money and deal with the flak
from that rather than get a bad rep from not being able to support
every engineer with a wild hair.

What part of this is hard to understand?

I don't understand why selling to the small users and not supporting
them well and therefore losing some sales from them because of "bad rep"
would be a worse business strategy than imposing a boycott on yourself
and not selling any parts at all to any of that group of people. Are you
saying that the bad rep among the little guys would rub off onto even
the big customers that do get good support? It seems kind of weird to
me, but what do I know.

Jeff

 

[rickman]

On Mar 14, 4:39 pm, -jg <jim.granvi...@gmail.com> wrote:

On Mar 15, 4:25 am, rickman <gnu...@gmail.com> wrote:



On Mar 14, 8:26 am, Uwe Bonnes <b...@elektron.ikp.physik.tu-

darmstadt.de> wrote:
rickman <gnu...@gmail.com> wrote:

...

As an example, show me a part from Xilinx or Altera that sells for
under $10 in qty 100.  I don't care what size, but an FPGA, not a
CPLD.  I am using the smallest part I can get (although I would like
bigger, it just doesn't come in the 100 TQFP) and am paying under $10
making batches of 100-200 boards at a time.  I couldn't find that
price anywhere else but Lattice.

The XC3S50A-4VQG100C sells for 5.52$ at Digikey

Ok, the way I made the statement I stand corrected.  Someone else
emailed me about Actel parts in this price range.  But these parts
have half the logic of the Lattice part.  The Actel part in the same
size range is half again as pricey and the Xilinx part in the same
size range is about the same price, but lacking the config memory.

 That depends on where you set the threshold.
We have an app, that needs PLL+BlockRam, and not a huge
amount of logic. - same package dictates as yours.

 On this yardstick, Actel are now in front with the ProASCI3 at
$5.26/100+, but the smallest Lattice LFXP3C is $10.93/100+, the
Lattice LCMXO1200C is $11.50, whilst the XP2-5 is higher in price and
package.
 Xilinx need Loader memory added to their OK price,
and the -3AN fails the package test.

Actel also have to other choices, in the same package, at $7.23 and
$8.94, so have some upgrade elasticity. [Lattice show just the one
choice]

The point is that using an older process (130 nm) Lattice is competing
with products built on newer processes (90 nm Spartan 3A, et al).

Yes, and your example shows a gap : As the FPGAs push higher in pin-
counts and packages, they leave a widening tail-end, where you need a
low-mfg-cost package, but a CPLD does not cut it.

I believe there is another market opening, for a device that has more
ram, but not massive I/O counts.

I agree that there are opportunities at the low end. I don't know
exactly what mix is optimal, but even the XP3C part I am using is an
older technology for Lattice. If they make an XP2 in 100 pin part,
the price would be lower than in the higher pin count packages and
that is what I would be using. I need the gates!

But as we have been discussing, there is little incentive for the FPGA
makers to flesh out their low end parts. It just doesn't have the
same profit margin or even total profit. At some point I am going to
have to move to a larger pin count BGA package if I want a bigger LUT
count. I've tried talking to the company reps until I am blue in the
face, they ain't gonna support the low end like they do the top.

Rick

 

[whygee]

rickman wrote:

I agree that there are opportunities at the low end. I don't know
exactly what mix is optimal, but even the XP3C part I am using is an
older technology for Lattice. If they make an XP2 in 100 pin part,
the price would be lower than in the higher pin count packages and
that is what I would be using. I need the gates!
similar problem with Actel,

I was explained that the large die size can't fit in smaller packages
than what is proposed... too bad :-/

Rick
yg

--
http://ygdes.com / http://yasep.org

 

[Rob Gaddi]

On Sun, 14 Mar 2010 20:47:24 -0400
Jeff Cunningham <jcc@sover.net> wrote:

On 3/13/10 10:35 PM, rickman wrote:

1 million, you won't get their attention or even a quote.
I can get quotes from others, so why not from TierLogic ?

I don't understand the question. The point is they can't make
enough money from a small user to make it worth their while. So
they exclude the engineers that won't make them much money and deal
with the flak from that rather than get a bad rep from not being
able to support every engineer with a wild hair.

What part of this is hard to understand?

I don't understand why selling to the small users and not supporting
them well and therefore losing some sales from them because of "bad
rep" would be a worse business strategy than imposing a boycott on
yourself and not selling any parts at all to any of that group of
people. Are you saying that the bad rep among the little guys would
rub off onto even the big customers that do get good support? It
seems kind of weird to me, but what do I know.

Jeff

Absolutely it would. When a vendor agrees to work with me and then
leaves me hanging because my project is important to my company but
not to theirs, it really ticks me off. When I change jobs, I carry that
grudge and, when asked my opinion of that company, will give it freely.

It's 100% better to not work with someone at all than to hang them out
to dry. If I never design you in in the first place I've lost
nothing. If I've got a prototype in hand, and NOW you're not
interested, we've got a problem.

--
Rob Gaddi, Highland Technology
Email address is currently out of order

 

[rickman]

On Mar 15, 2:30 am, whygee <y...@yg.yg> wrote:

rickman wrote:
I agree that there are opportunities at the low end.  I don't know
exactly what mix is optimal, but even the XP3C part I am using is an
older technology for Lattice.  If they make an XP2 in 100 pin part,
the price would be lower than in the higher pin count packages and
that is what I would be using.  I need the gates!

similar problem with Actel,
I was explained that the large die size can't fit in smaller packages
than what is proposed... too bad :-/

I'm not familiar with Actel, but with the others I know it is not a
die size issue. They use even smaller packages than the 100TQFP, but
they are BGA (chip scale?) or worse, LGA packaging or in one Actel
case I seem to recall a possibly difficult to use 132 pin QFN. If the
die fit these packages, they will fit in a 100TQFP. They just don't
want to support this package for marketing reasons. I assume they
have determined the effort is not justified by the market... I can't
tell them what their markets are, but to some extent it is a build it
and they will come. If the part prices have a floor determined by
testing time which in turn depends on IO count, it seems they could
drop even high volume pricing even more by using these smaller and
lower cost packages.

I guess there is a reason why I'm not in FPGA marketing... maybe I
just don't see things the same way...

Rick

 

[Charles Gardiner]

Hi,

the local Lattice FAEs here in Germany recommended me to get a USB ethernet card
for my PC and tie the license to that. It works a treat. In the office I usually
have it on a windows 2003 server machine (officially not supported but works
anyway and I can log in from a quiet thin client).

When I go to a customer, trade fair etc. I run the same license from my laptop or
one of these neat small form factor PCs from Fujitsu
(http://de.fujitsu.com/products/deskbound/personal_computers/esprimo_q_series.html)

rickman schrieb:

On Mar 21, 9:25 am, "Helmut Sennewald" <helmutsennew...@t-online.de
wrote:
"Mawa_fugo" <cco...@netscape.net> schrieb im Newsbeitragnews:308d0cd3-5784-4cd8-8325-9d8cbb831776@z3g2000yqz.googlegroups.com...
On Mar 21, 7:00 am, Peter <pe...@peter2000.co.uk> wrote:

http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=290416326824
x----------x
What? I have tons of those

;-))))))

JTAG-Adapters, dongles, I doubt.

If somebody has to change an old Xilinx-design,
he will need the right software revison plus the dongle.
The latest revisions dont help, because they no more
support the old FPGA devices.

Helmut

Doesn't Xilinx provide a "Classic" version of their tools?

I also have old versions of the Xilinx tools complete with dongle and
programming cables. That's one of the reasons why I hate licenses.
You may have everything you need, except if the PC is different you
may need a new license file. That's the way it is with my current
Lattice software. So far they have been happy to provide a license
file for every new machine I've wanted to port the software to. But I
am sure that one day that will no longer be the case and I'll be
stuck!

The first time I see a way to get away from these proprietary,
licensed tools, I'm gone in a flash!

Rick

 

[Jan Pech]

On Tue, 2010-04-06 at 02:09 -0700, Kappa wrote:

Hi,

I have one problem to extract single bit from std_logic_vector, with
use of HEX suffix.

Ex:

signal out : std_logic;
signal in : std_logic_vector(7 downto 0);

out <= in(x"03");

I use HEX for compatibility with C source ...

When I check syntax with ISE I obtain an error, why ?

Thanks.

secureasm

Because you did not use hex integer but bit_vector/std_logic_vector.
Hexadecimal integer constant would be 16#03#.

Jan

 

[Patrick Maupin]

On Apr 9, 2:07 pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

I guess part of my frustration is that I have yet to see where strong
typing has made a real difference in my work... at least an
improvement.

I think Andy has it about right.  If you think signed arithmetic
was a tad messy in VHDL, wait until you find how successfully you
can be screwed by Verilog.  The really cool thing is that Verilog
is polite, and doesn't tell you when it's screwing you.  At least
VHDL is up-front about it.  How many times have you created a
design in VHDL that got through compilation, but was broken in
a surprising way that was directly related to a quirk of the
language?  Betcha you can count the occurrences on one hand.
Verilog does that to you all the time; it has startlingly
weak compile-time checking, and only slightly stronger
elaboration-time checking.

How comfortable are you with most-significant bits being
silently lost when you copy a wide vector into a narrow
one?  How about signed values being silently zero-filled
to the width of a wider target?

Personally? Very.

As the proponents of agile programming languages (I love Python) will
point out, the sort of typing errors that you are describing are but a
small subset of the ways you can screw up your design. Any reasonable
testbench will find these issues.

And BTW, (IMO) it's *much* easier to code a reasonable testbench in
verilog than in VHDL. But, obviously, your mileage varies.

Regards,
Pat

 

[Patrick Maupin]

On Apr 9, 2:31 pm, n...@puntnl.niks (Nico Coesel) wrote:

I also write a lot of C. Over the past years I've noticed that C
compilers (GCC to be exact) have become much more strict when it comes
to type checking. No more automatic casting. I'm sure this is done for
a good reason!

I used to write a lot of Modula-2. It was much better than (pre-ANSI)
C (and in fact was one of the contenders for the language the DOD uses
as ADA now, which is what VHDL was based on). IMO, Modula-2 was at a
sweet spot on verbosity vs. checking. But then ANSI C came along, and
was "good enough". Combine that with the compilers getting smart
enough to let you know about potential pitfalls, and there wasn't much
room for another language in the ecological niche that C fills, and,
for example, the Modula-2 ecosystem dwindled to nothing, and the Ada
ecosystem limped along, primarily propped up by the DOD and
educational institutions.

I think there really is a good corollary with HDLs there -- Verilog
synthesizers and simulators have a lot of options for telling you
about warnings and things, and Verilog occupies the same sort of sweet
spot as C, with only a few people preferring Ada or VHDL over C or
Verilog.

Regards,
Pat

 

[-jg]

On Apr 10, 2:07 am, rickman <gnu...@gmail.com> wrote:

One of my goals over the summer is to teach myself Verilog so that I
can use it as well as I currently use VHDL.  Then I can make a fully
informed decision about which I will continue to use.  I'd appreciate
pointers on good references, web or printed.

You could also look at Jan Decaluwe's MyHDL ?

http://www.myhdl.org/doku.php

and a case example here :

http://www.jandecaluwe.com/hdldesign/digmac.html

this allows you to go in either direction, to VHDL to Verilog, and to
'test early'.

-jg

 

[Jan Decaluwe]

On Apr 9, 10:05 pm, Patrick Maupin <pmau...@gmail.com> wrote:

On Apr 9, 2:07 pm, Jonathan Bromley <s...@oxfordbromley.plus.com
wrote:



I guess part of my frustration is that I have yet to see where strong
typing has made a real difference in my work... at least an
improvement.

I think Andy has it about right.  If you think signed arithmetic
was a tad messy in VHDL, wait until you find how successfully you
can be screwed by Verilog.  The really cool thing is that Verilog
is polite, and doesn't tell you when it's screwing you.  At least
VHDL is up-front about it.  How many times have you created a
design in VHDL that got through compilation, but was broken in
a surprising way that was directly related to a quirk of the
language?  Betcha you can count the occurrences on one hand.
Verilog does that to you all the time; it has startlingly
weak compile-time checking, and only slightly stronger
elaboration-time checking.

How comfortable are you with most-significant bits being
silently lost when you copy a wide vector into a narrow
one?  How about signed values being silently zero-filled
to the width of a wider target?

Personally?  Very.

As the proponents of agile programming languages (I love Python) will
point out, the sort of typing errors that you are describing are but a
small subset of the ways you can screw up your design.  Any reasonable
testbench will find these issues.

I believe you are mixing up dynamic typing (Python) with
weak typing (Verilog).

Python is dynamically but strongly typed. The silent Verilog-like
behavior as Jonathan was describing is extremely un-pythonic.
In Python, you would get a traceback immediately.

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

 

[jt_eaton]

Why do people keep comparing the checking that is inherent in VHDL wit
what is done in Verilog? There is a whole class of tools called rt
checkers that are designed to catch these language gotches before you ru
simulation. Yes there are lots of ways to make mistakes in verilog. Tha
simply means that you need to add a tool that can catch them.


John

---------------------------------------
Posted through http://www.FPGARelated.com

 

[Patrick Maupin]

On Apr 10, 8:04 pm, Jan Decaluwe <jandecal...@gmail.com> wrote:

As the proponents of agile programming languages (I love Python) will
point out, the sort of typing errors that you are describing are but a
small subset of the ways you can screw up your design.  Any reasonable
testbench will find these issues.

I believe you are mixing up dynamic typing (Python) with
weak typing (Verilog).

No, not at all. Sure, Python will give you an error, if, for example,
you add an int to a string:

1 + '1'
Traceback (most recent call last):

File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'


But, Python will quite happily let you add an int to a float:

1 + 1.0
2.0

And, of course, it has no concept of unsigned numbers, etc. Now, you
can use some modules that know about a few of these things, like the
array module.

Also, Verilog understands a few things about its types, such as the
fact that you can't do a continuous assignment to a register, for
example.

SO, while in principle I *agree* that Python is "dynamically" typed
instead of "weakly" typed, that doesn't alter the fact that in Python
I can bind anything to any identifier.

x = 'a'
x = 1
x = 2.0

Oh, sure I can build my own objects to restrict this, but people who
do that are usually called "static typing weenies" by the Python
community.

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.

Regards,
Pat

 

[KJ]

On Apr 10, 9:42 pm, "jt_eaton"
<z3qmtr45@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.

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.

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.

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.

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.

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

Kevin Jennings

 

[Patrick Maupin]

On Apr 11, 2:13 pm, KJ <kkjenni...@sbcglobal.net> wrote:

On Apr 10, 9:42 pm, "jt_eaton"

z3qmtr45@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

 

[Jan Decaluwe]

On Apr 11, 5:03 am, Patrick Maupin <pmau...@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

 

[Chris Higgs]

On Apr 9, 9:05 pm, Patrick Maupin <pmau...@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

 

[KJ]

On Apr 12, 6:49 am, Chris Higgs <chiggs...@googlemail.com> wrote:

On Apr 9, 9:05 pm, Patrick Maupin <pmau...@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

 

[Chris Higgs]

On Apr 12, 12:12 pm, KJ <kkjenni...@sbcglobal.net> wrote:

On Apr 12, 6:49 am, Chris Higgs <chiggs...@googlemail.com> wrote:

On Apr 9, 9:05 pm, Patrick Maupin <pmau...@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

 

[David Brown]

On 11/04/2010 01:06, -jg wrote:

On Apr 10, 2:07 am, rickman<gnu...@gmail.com> wrote:
One of my goals over the summer is to teach myself Verilog so that I
can use it as well as I currently use VHDL. Then I can make a fully
informed decision about which I will continue to use. I'd appreciate
pointers on good references, web or printed.

You could also look at Jan Decaluwe's MyHDL ?

http://www.myhdl.org/doku.php

and a case example here :

http://www.jandecaluwe.com/hdldesign/digmac.html

this allows you to go in either direction, to VHDL to Verilog, and to
'test early'.

That occurred to me too. FPGA design is not limited to VHDL or Verilog
- there are many other options.

One of the challenges is finding a tool that has strong enough support
to be around for the future. Many years ago I did some FPGA (and CPLD)
work using confluence - I found it much easier to write compact and
correct code with confluence than with VHDL or Verilog. But the tool's
author dropped development to work on other projects (fair enough, I
suppose - he never claimed confluence to be anything other than free
development software). Although it was open source, it didn't have a
strong enough community to survive.

MyHDL, on the other hand, has been around for many years, and has a
reasonable-sized community. It is definitely worth looking at if you
are not happy with Verilog or VHDL.