Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 147150

Article: 147150
Subject: Re: I'd rather switch than fight!
From: Muzaffer Kal <kal@dspia.com>
Date: Thu, 15 Apr 2010 14:31:01 -0700
Links: << >>  << T >>  << A >>
On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin
<pmaupin@gmail.com> wrote:

>On Apr 15, 3:12 pm, David Brown <da...@westcontrol.removethisbit.com>
>wrote:
>
>> Another famous contest involved a C and Ada comparison.  It took the Ada
>> more than twice as long as the C team to write their code, but it took
>> the C team more than ten times as long to debug their code.
>
>Well, this isn't at all the same then.  The Verilog teams got working
>designs, and the VHDL teams didn't.

There are two issues to consider. One is the relative times of writing
the codes vs debugging ie if writing took 5 hours and debugging 10
minutes (unlikely) then C still wins. Which brings the second issue:
it is very likely that the programming contest involved a "larger"
design to be finished. If I am remembering correctly RTL was  an async
reset, synchronously loadable up-down counter which is a "smallish"
project. If programming contest involved something more "involved" it
still points to the benefit of strong typing and other features of
Ada/VHDL etc.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 147151
Subject: Re: I'd rather switch than fight!
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Thu, 15 Apr 2010 14:33:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 14, 9:45=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:

> When I used confluence, my results were far better. =A0It was simpler and
> clearer, and it handles the low-level Verilog or VHDL details
> automatically. =A0You can't accidentally end up with a latch or
> asynchronous logic in your state machines - in fact, it won't let you
> generate latches at all. =A0You don't have registers that are reset in
> simulation and preset in synthesis, because all the Verilog/VHDL
> registers are generated with explicit resets (or presets). =A0You don't
> have problems when mixing signed and unsigned values, because these are
> handled correctly.
>
> I haven't used MyHDL for more than brief tests, but it appears to give a
> similar isolation from the messy low-level details of Verilog and VHDL,
> while (even more than confluence) it gives you higher level features.
> People often compare Verilog to "C", and VHDL to "Ada" - I think they
> both share a lot with assembly language.

It is easy to use MyHDL in "Confluence mode", for example to describe
recursive structures and dataflows. However, conceptually the
languages are completely different.

It is remarkable that most HDLs that are *proposed*, including
Confluence,
have parallel-only semantics. This idea of a "HDL closely matching
hardware" is rediscovered once in a while. However, it seems the
market just doesn't want it. Personally I'm convinced that such HDLs
are not powerful enough for general purpose digital design work.

In this respect, MyHDL is proudly in the VHDL/Verilog camp, with
strong support for sequential descriptions also. That gives you much
more power, but it implies that there is more to learn and to
understand.

For example, with MyHDL you will also have to learn about latch
inference and how to avoid "unwanted latches". However, just like in
VHDL/Verilog there is a much better solution for this than using a
limited HDL: use a clocked process template by default.

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


Article: 147152
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Thu, 15 Apr 2010 14:48:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 15, 4:31=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
> On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin
>
> <pmau...@gmail.com> wrote:
> >On Apr 15, 3:12=A0pm, David Brown <da...@westcontrol.removethisbit.com>
> >wrote:
>
> >> Another famous contest involved a C and Ada comparison. =A0It took the=
 Ada
> >> more than twice as long as the C team to write their code, but it took
> >> the C team more than ten times as long to debug their code.
>
> >Well, this isn't at all the same then. =A0The Verilog teams got working
> >designs, and the VHDL teams didn't.
>
> There are two issues to consider. One is the relative times of writing
> the codes vs debugging ie if writing took 5 hours and debugging 10
> minutes (unlikely) then C still wins. Which brings the second issue:
> it is very likely that the programming contest involved a "larger"
> design to be finished. If I am remembering correctly RTL was =A0an async
> reset, synchronously loadable up-down counter which is a "smallish"
> project. If programming contest involved something more "involved" it
> still points to the benefit of strong typing and other features of
> Ada/VHDL etc.

But it's mostly academic and FPGA people who think that VHDL might
have any future at all.  See, for example:

http://www.eetimes.com/news/design/columns/industry_gadfly/showArticle.jhtm=
l?articleID=3D17408302

Regards,
Pat

Article: 147153
Subject: Re: I'd rather switch than fight!
From: Andrew FPGA <andrew.newsgroup@gmail.com>
Date: Thu, 15 Apr 2010 14:57:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
Interesting in the discussion on myHdl/testbenches, no-one raised
SystemVerilog. SystemVerilog raises the level of abstraction(like
myHdl), but more importantly it introduces constrained random
verification. For writing testbenches, SV is a better choice than
MyHdl/VHDL/Verilog, assuming tool availablility.

It would seem that SV does not bring much to the table in terms of RTL
design - its just a catchup to get verilog up to the capabilities that
VHDL already has.




Article: 147154
Subject: Re: I'd rather switch than fight!
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Thu, 15 Apr 2010 14:58:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 15, 10:21=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:

> Well, this isn't at all the same then. =A0The Verilog teams got working
> designs, and the VHDL teams didn't.

It's really about time that this old VHDL-Verilog shootout nonsense
was shown up for the garbage it was.

It was set up by John Cooley many years ago.  It took place in the
US where Verilog predominated, then as now, so there was a much
smaller pool of skilled VHDL users than Veriloggers at the host
event.  At the time, VHDL did indeed lag badly behind in some
respects - the situation with numeric packages was chaotic, and
the design was a (very simple) counter of some kind so anyone
who wasn't fluent with the VHDL numeric packages **as accepted
by the tools in use** was doomed.  And, as Andy pointed out, the
scale of the problem was so tiny that Verilog would always come
out on top - Verilog is definitely faster to write for tiny
designs; you don't need a contest to work that out.

All of this means that the "contest" was little more than a
good way to show how feeble were VHDL's **tools** at that
time.  It wasn't very long before the tool vendors got their
acts together, but the shootout wasn't re-run; instead, it
became part of the folklore.  It was unreliable populist
hokum then, it's out-of-date unreliable hokum now, and I'm
saddened to see it adduced in evidence so many years on.

There's a lot wrong with VHDL, for sure, but a lot right too.
Here's a sampler of a few things that have been in VHDL since
at least 1987:

Added to Verilog in 2001:
- generate
- multi-dimensional arrays
- signed vector arithmetic
- configurations (nasty in both languages!)

Added to SystemVerilog in 2003-2005:
- packages
- structs (a.k.a. records)
- non-trivial data types (e.g. arrays, structs) on ports
- enumeration types
- unresolved signals (compiler errors on multiple drivers)
- non-trivial data types as subprogram arguments
- reference arguments to subprograms
- default values for input arguments
- inquiry functions to determine the dimensionality and
  bounds of an array

May possibly be added to SystemVerilog in 2012:
- parameterized subprograms (like VHDL unconstrained arrays)
- subprogram overloading

Of course, there's also a ton of stuff that Verilog can do
but VHDL can't.  And it's rarely a good idea to judge any
language by a laundry-list of its feature goodies.  But
it is NEVER a good idea to trivialize the discussion.
--
Jonathan Bromley

Article: 147155
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Thu, 15 Apr 2010 15:30:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 15, 4:58=A0pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

> Of course, there's also a ton of stuff that Verilog can do
> but VHDL can't. =A0And it's rarely a good idea to judge any
> language by a laundry-list of its feature goodies.

Agreed completely.

> =A0But it is NEVER a good idea to trivialize the discussion.

Well, you have to talk to others about that.  Somebody else brought up
the stupid Verilog contest, and David, apparently agreeing with some
sentiment there, said:

> Another famous contest involved a C and Ada comparison.  It took the Ada
> more than twice as long as the C team to write their code, but it took
> the C team more than ten times as long to debug their code.

To which the only sane answer was my flippant "it's not the
same" (and, of course the very first thing that's not the same is who
the purported winner was).  I don't think either contest is worth a
hoot, but I do find it interesting that you found it necessary to pen
a long response to my flippant response, yet found it acceptable to
ignore the statement about the C vs. ADA contest.

Regards,
Pat

Article: 147156
Subject: Re: Implementing bidirectional bus inside the FPGA
From: james <bubba@bud.u>
Date: Thu, 15 Apr 2010 21:58:06 -0400
Links: << >>  << T >>  << A >>
On Tue, 13 Apr 2010 16:50:41 -0700 (PDT), Andy Peters
<google@latke.net> wrote:

|No, internal tristates have vanished from Brand X FPGAs after the
|XC4000 series.


Dissapeared after the Spartan 2 series I beleive is correct.

james 

Article: 147157
Subject: Re: Implementing bidirectional bus inside the FPGA
From: james <bubba@bud.u>
Date: Thu, 15 Apr 2010 22:00:42 -0400
Links: << >>  << T >>  << A >>
On Thu, 15 Apr 2010 21:58:06 -0400, james <bubba@bud.u> wrote:

|On Tue, 13 Apr 2010 16:50:41 -0700 (PDT), Andy Peters
|<google@latke.net> wrote:
|
||No, internal tristates have vanished from Brand X FPGAs after the
||XC4000 series.
|
|
|Dissapeared after the Spartan 2 series I beleive is correct.
|
|james 

i stand corrected the Spartan 2 series has three state bus.

james

Article: 147158
Subject: Re: I'd rather switch than fight!
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Fri, 16 Apr 2010 00:47:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 15, 11:30=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:

> I do find it interesting that you found it necessary to pen
> a long response to my flippant response, yet found it acceptable to
> ignore the statement about the C vs. ADA contest.

I try to write on things I know something about :-)

I am painfully familiar with the Cooley Verilog-vs-VHDL nonsense,
but know nothing about that C-Ada contest.

In any case, I wasn't particularly responding to you.  I took an
opportunity to say something I've wanted to say for a long time
about an exceedingly faulty part of the HDL mythology.
--
Jonathan Bromley

Article: 147159
Subject: Re: I'd rather switch than fight!
From: Paul <pault.eg@googlemail.com>
Date: Fri, 16 Apr 2010 00:47:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 15 Apr, 22:33, Jan Decaluwe <j...@jandecaluwe.com> wrote:

> For example, with MyHDL you will also have to learn about latch
> inference and how to avoid "unwanted latches". However, just like in
> VHDL/Verilog there is a much better solution for this than using a
> limited HDL: use a clocked process template by default.

:-) In a rather long thread about vhdl Vs verilog, you seem to have
placed your can opener on another tin of worms marked one process
state machines vs two. What you trying to do, crash google's servers?

Article: 147160
Subject: Re: I'd rather switch than fight!
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 16 Apr 2010 11:15:35 +0200
Links: << >>  << T >>  << A >>
On 15/04/2010 23:31, Muzaffer Kal wrote:
> On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin
> <pmaupin@gmail.com>  wrote:
>
>> On Apr 15, 3:12 pm, David Brown<da...@westcontrol.removethisbit.com>
>> wrote:
>>
>>> Another famous contest involved a C and Ada comparison.  It took the Ada
>>> more than twice as long as the C team to write their code, but it took
>>> the C team more than ten times as long to debug their code.
>>
>> Well, this isn't at all the same then.  The Verilog teams got working
>> designs, and the VHDL teams didn't.
>
> There are two issues to consider. One is the relative times of writing
> the codes vs debugging ie if writing took 5 hours and debugging 10
> minutes (unlikely) then C still wins. Which brings the second issue:
> it is very likely that the programming contest involved a "larger"
> design to be finished. If I am remembering correctly RTL was  an async
> reset, synchronously loadable up-down counter which is a "smallish"
> project. If programming contest involved something more "involved" it
> still points to the benefit of strong typing and other features of
> Ada/VHDL etc.

The contest in question was a substantial programming project over a 
longer period - weeks rather than hours.  I don't remember how much time 
was actually spend on debugging rather than coding, but it certainly 
worked out that the Ada team were finished long before the C team.


Article: 147161
Subject: Re: I'd rather switch than fight!
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 16 Apr 2010 11:31:40 +0200
Links: << >>  << T >>  << A >>
On 16/04/2010 00:30, Patrick Maupin wrote:
> On Apr 15, 4:58 pm, Jonathan Bromley<s...@oxfordbromley.plus.com>
> wrote:
>
>> Of course, there's also a ton of stuff that Verilog can do
>> but VHDL can't.  And it's rarely a good idea to judge any
>> language by a laundry-list of its feature goodies.
>
> Agreed completely.
>
>>   But it is NEVER a good idea to trivialize the discussion.
>
> Well, you have to talk to others about that.  Somebody else brought up
> the stupid Verilog contest, and David, apparently agreeing with some
> sentiment there, said:
>

I wasn't agreeing with the validity of the Verilog/VHDL contest, 
although I suppose by not saying that, it looked like I agreed with it. 
  It would have been more useful if I'd given a little more detail.  The 
Ada / C contest was over a much longer time scale, using a real-world 
project - and thus is a much more valid contest (though obviously, like 
any test or benchmark, you can't apply it thoughtlessly to other contexts).

It was an indication of where the stronger typing and generally stricter 
compiler and language was demonstrated to give a faster development time 
in a real case.  I can't say whether those results could carry over to a 
comparison between VHDL and Verilog, or how much the results are the 
effect of strong typing.  But since VHDL is often though of as being a 
similar style of language to Ada, and Verilog is similarly compared to 
C, it may be of interest.

I couldn't find references to the study I was thinking of, but I found 
one in a similar vain:

<http://www.adaic.org/whyada/ada-vs-c/cada_art.html#conclusion>

Of course, I haven't scoured the net looking for enough articles to give 
a balanced view here.  So if my comments here are of interest or use to 
anyone, that's great - if not, I'll not complain if you ignore them!

>> Another famous contest involved a C and Ada comparison.  It took the Ada
>> more than twice as long as the C team to write their code, but it took
>> the C team more than ten times as long to debug their code.
>
> To which the only sane answer was my flippant "it's not the
> same" (and, of course the very first thing that's not the same is who
> the purported winner was).  I don't think either contest is worth a
> hoot, but I do find it interesting that you found it necessary to pen
> a long response to my flippant response, yet found it acceptable to
> ignore the statement about the C vs. ADA contest.
>
> Regards,
> Pat


Article: 147162
Subject: Re: I'd rather switch than fight!
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 16 Apr 2010 11:38:50 +0200
Links: << >>  << T >>  << A >>
On 15/04/2010 23:27, Patrick Maupin wrote:
> On Apr 15, 2:23 pm, Andy<jonesa...@comcast.net>  wrote:
>> The benefits of a "strongly typed" language, with bounds checks, etc.
>> are somewhat different between the first time you write/use the code,
>> and the Nth time reuse and revise it. Strong typeing and bounds
>> checking let you know quickly the possibly hidden side effects of
>> making changes in the code, especially when it may have been a few
>> days/weeks/months since the last time you worked with it.
>
> For this usage, a good testbench will catch more bugs and make strong
> type and bounds checking redundant.
>

A testbench does not make checks redundant, for two reasons.  First, the 
earlier in the process that you find the mistakes, the better - its 
easier to find the cause of the mistake, and it's faster to find them, 
fix them, and re-compile.

Secondly, a testbench does not check everything.  It is only as good as 
the work put into it, and can be flawed in the same way as the code 
itself.  A testbench's scope for non-trivial projects is always limited 
- it is not practical to test everything.  If you have some code that 
has a counter, your testbench may not go through the entire range of the 
counter - perhaps doing so would take simulation times of years.  Your 
testbench will then not do bounds checking on the counter.

The old joke about Ada is that when you get your code to compile, it's 
ready to ship.  I certainly wouldn't go that far, but testing is 
something you do in cooperation with static checking, not as an alternative.


mvh.,

David

Article: 147163
Subject: Re: I'd rather switch than fight!
From: Symon <symon_brewer@hotmail.com>
Date: Fri, 16 Apr 2010 11:30:25 +0100
Links: << >>  << T >>  << A >>
On 4/15/2010 3:33 PM, Patrick Maupin wrote:
> On Apr 15, 12:20 am, Matthew Hicks<mdhic...@uiuc.edu>  wrote:
>>> In comp.arch.fpga rickman<gnu...@gmail.com>  wrote: (snip)
>>
>>>> People say that strong typing catches bugs, but I've never seen any
>>>> real proof of that.  There are all sorts of anecdotal evidence, but
>>>> nothing concrete.  Sure, wearing a seat belt helps to save lives, but
>>>> at what point do we draw the line?  Should we have four point
>>>> harnesses, helmets, fireproof suits...?
>>
>>> Seatbelts may save lives, but statistically many other safety
>>> improvements don't.  When people know that their car has air bags,
>>> they compensate and drive less safely.  (Corner a little faster, etc.)
>>> Enough to mostly remove the life saving effect of the air bags.
>>
>>> It does seem likely that people will let down their guard and code
>>> more sloppily knowing that the compiler will catch errors.
>>
>>> One of my least favorite is the Java check on variable initialization.
>>> If the compiler can't be sure that it is initialized then it is
>>> a fatal compilation error.  There are just too many cases that
>>> the compiler can't get right.
>>
>> Sorry, but I have to call BS on this whole line og "logic".  Unless you can
>> point to some studies that prove this, my experiences are contrary to your
>> assertions.  I don't change the way I code when I code in Verilog vs. VHDL
>> or C vs. Java, the compiler just does a better job of catching my stupid
>> mistakes, allowing me to get things done faster.
>>
>> ---Matthew Hicks
>
Pat,
If your email client was less agile and performed better 'typing 
checking' you wouldn't have sent this blank post.
HTH, Syms. ;-)

Article: 147164
Subject: Help needed regarding Vertex2 FPGA
From: vinay p v <vinay.delta@gmail.com>
Date: Fri, 16 Apr 2010 03:37:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
i'm currently working on Vertex-II pro using simulink for JTAG
hardware cosimlation.. so i want to interface a CRO to the FPGA to
visualize the real time output of FPGA.. so can anyone plz help me to
find out how to do it...

Article: 147165
Subject: Re: I'd rather switch than fight!
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 16 Apr 2010 12:22:16 +0100
Links: << >>  << T >>  << A >>
On Fri, 16 Apr 2010 11:15:35 +0200, David Brown
<david@westcontrol.removethisbit.com> wrote:

>On 15/04/2010 23:31, Muzaffer Kal wrote:
>> On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin
>> <pmaupin@gmail.com>  wrote:
>>
>>> On Apr 15, 3:12 pm, David Brown<da...@westcontrol.removethisbit.com>
>>> wrote:
>>>
>>>> Another famous contest involved a C and Ada comparison.  It took the Ada
>>>> more than twice as long as the C team to write their code, but it took
>>>> the C team more than ten times as long to debug their code.
>>>
>>> Well, this isn't at all the same then.  The Verilog teams got working
>>> designs, and the VHDL teams didn't.
>>
>> There are two issues to consider. One is the relative times of writing
>> the codes vs debugging ie if writing took 5 hours and debugging 10
>> minutes (unlikely) then C still wins. Which brings the second issue:
>> it is very likely that the programming contest involved a "larger"
>> design to be finished. If I am remembering correctly RTL was  an async
>> reset, synchronously loadable up-down counter which is a "smallish"
>> project. If programming contest involved something more "involved" it
>> still points to the benefit of strong typing and other features of
>> Ada/VHDL etc.
>
>The contest in question was a substantial programming project over a 
>longer period - weeks rather than hours.  I don't remember how much time 
>was actually spend on debugging rather than coding, but it certainly 
>worked out that the Ada team were finished long before the C team.

Was it John McCormick's model railroad?

http://www.adaic.org/atwork/trains.html

Possibly not - the C students apparently never did deliver.

- Brian


Article: 147166
Subject: Re: I'd rather switch than fight!
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 16 Apr 2010 13:30:39 +0200
Links: << >>  << T >>  << A >>
On 16/04/2010 13:22, Brian Drummond wrote:
> On Fri, 16 Apr 2010 11:15:35 +0200, David Brown
> <david@westcontrol.removethisbit.com>  wrote:
>
>> On 15/04/2010 23:31, Muzaffer Kal wrote:
>>> On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin
>>> <pmaupin@gmail.com>   wrote:
>>>
>>>> On Apr 15, 3:12 pm, David Brown<da...@westcontrol.removethisbit.com>
>>>> wrote:
>>>>
>>>>> Another famous contest involved a C and Ada comparison.  It took the Ada
>>>>> more than twice as long as the C team to write their code, but it took
>>>>> the C team more than ten times as long to debug their code.
>>>>
>>>> Well, this isn't at all the same then.  The Verilog teams got working
>>>> designs, and the VHDL teams didn't.
>>>
>>> There are two issues to consider. One is the relative times of writing
>>> the codes vs debugging ie if writing took 5 hours and debugging 10
>>> minutes (unlikely) then C still wins. Which brings the second issue:
>>> it is very likely that the programming contest involved a "larger"
>>> design to be finished. If I am remembering correctly RTL was  an async
>>> reset, synchronously loadable up-down counter which is a "smallish"
>>> project. If programming contest involved something more "involved" it
>>> still points to the benefit of strong typing and other features of
>>> Ada/VHDL etc.
>>
>> The contest in question was a substantial programming project over a
>> longer period - weeks rather than hours.  I don't remember how much time
>> was actually spend on debugging rather than coding, but it certainly
>> worked out that the Ada team were finished long before the C team.
>
> Was it John McCormick's model railroad?
>
> http://www.adaic.org/atwork/trains.html
>
> Possibly not - the C students apparently never did deliver.
>

I suppose there have been many such studies through the ages.  The one I 
remember was a real project rather than a student project (I think it 
was a large commercial company, but it may have been some sort of 
government organisation).

Article: 147167
Subject: Clock Mux by software ...
From: Kappa <secureasm@gmail.com>
Date: Fri, 16 Apr 2010 05:20:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I have Spartan 3A DSP 3400. My board have two clocks, first clock is
TXCO, sencond clock is VCXO+PLL generator with external reference. The
two clocks have the same frequency. I wondered how it is possible to
exchange via software between the two clocks on Microblaze while the
software is running, without causing problems.

(1) Power up board, FPGA configure with default first clock (TXCO).
All wotks ok.

(2) Configure second clock (VCXO+PLL), waiting lock.

(3) Switch to second clock. How ?

With one IPcore on EDK projects it's possible this behavior ?

I guess should use a BUFGMUX controlled by a director software,
right ?

Thanks.

Kappasm

Article: 147168
Subject: Re: Read from the compact flash
From: Kappa <secureasm@gmail.com>
Date: Fri, 16 Apr 2010 05:26:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

If you change idea on CP and you decide to use USB storage, this chip
is very helpfull:

http://www.vinculum.com/

Manage USB drive FAT12/FAT16/FAT32, read/write file (well binary) from
UART.

Kappasm

Article: 147169
Subject: Re: Help needed regarding Vertex2 FPGA
From: Gabor <gabor@alacron.com>
Date: Fri, 16 Apr 2010 05:26:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 16, 6:37=A0am, vinay p v <vinay.de...@gmail.com> wrote:
> i'm currently working on Vertex-II pro using simulink for JTAG
> hardware cosimlation.. so i want to interface a CRO to the FPGA to
> visualize the real time output of FPGA.. so can anyone plz help me to
> find out how to do it...

You might get more help if you describe what the output of
your FPGA is supposed to represent.  Also I think more people
know what an oscilloscope or "scope" is in this context than
a "CRO".  Or perhaps by "CRO" you meant "Chief Records Officer?"
or possibly "Contract research organization?"

What other hardware is on your board with the FPGA?  do you
have a DAC (digital to analog converter) to create an analog
waveform for the scope?

Article: 147170
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 16 Apr 2010 10:50:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 16, 5:30=A0am, Symon <symon_bre...@hotmail.com> wrote:

> Pat,
> If your email client was less agile and performed better 'typing
> checking' you wouldn't have sent this blank post.
> HTH, Syms. ;-)

Absolutely true!

But it keeps me young trying to keep up with it.

Pat

Article: 147171
Subject: Re: I'd rather switch than fight!
From: whygee <yg@yg.yg>
Date: Fri, 16 Apr 2010 19:53:44 +0200
Links: << >>  << T >>  << A >>
rickman wrote:
> Hmmm...  The date on that article is 04/07/2003 11:28 AM EDT.  Seven
> years later I still don't see any sign that VHDL is going away... or
> did I miss something?

I had the same thought.

Furthermore it was about only one company who wanted to push one
technology. Bold statements followed, and... 7 years later,
VHDL and Verilog are still the Vi vs Emacs of EDA.

> Rick
yg
-- 
http://ygdes.com / http://yasep.org

Article: 147172
Subject: Re: I'd rather switch than fight!
From: rickman <gnuarm@gmail.com>
Date: Fri, 16 Apr 2010 10:56:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 14, 10:07=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:
> In comp.arch.fpga rickman <gnu...@gmail.com> wrote:
> (snip)
>
> > People say that strong typing catches bugs, but I've never seen any
> > real proof of that. =A0There are all sorts of anecdotal evidence, but
> > nothing concrete. =A0Sure, wearing a seat belt helps to save lives, but
> > at what point do we draw the line? =A0Should we have four point
> > harnesses, helmets, fireproof suits...?
>
> Seatbelts may save lives, but statistically many other safety
> improvements don't. =A0When people know that their car has air bags,
> they compensate and drive less safely. =A0(Corner a little faster, etc.)
> Enough to mostly remove the life saving effect of the air bags.

Are you making this up?  I have never heard that any of the other
added safety features don't save lives overall.  I have heard that
driving a sportier car does allow you to drive more aggressively, but
this is likely not actually the result of any real analysis, but just
an urban myth.  Where did you hear that air bags don't save lives
after considering all?


> It does seem likely that people will let down their guard and
> code more sloppily knowing that the compiler will catch errors.

If you can show me something that shows this, fine, but otherwise this
is just speculation.


> One of my least favorite is the Java check on variable initialization.
> If the compiler can't be sure that it is initialized then it is
> a fatal compilation error. =A0There are just too many cases that
> the compiler can't get right.

I saw a warning the other day that my VHDL signal initialization "is
not synthesizable".  I checked and it was appropriately initialized on
async reset, it was just complaining that I also used an
initialization in the declaration to keep the simulator from giving me
warnings in library functions.  You just can't please everyone!

Then again I had to make a second trip to the customer yesterday
because of an output that got disconnected in a change and I didn't
see the warning in the ocean of warnings and notes that the tools
generate.  Then I spent half an hour going through all of it in detail
and found a second disconnected signal.  Reminds me of the moon
landing where there was a warning about a loss of sync which kept
happening so much it overloaded the guidance computer and they had to
land manually.  TMI!

Rick

Article: 147173
Subject: Re: I'd rather switch than fight!
From: rickman <gnuarm@gmail.com>
Date: Fri, 16 Apr 2010 10:58:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 15, 10:37=A0am, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 15, 12:20=A0am, Matthew Hicks <mdhic...@uiuc.edu> wrote:
>
>
>
> > > In comp.arch.fpga rickman <gnu...@gmail.com> wrote: (snip)
>
> > >> People say that strong typing catches bugs, but I've never seen any
> > >> real proof of that. =A0There are all sorts of anecdotal evidence, bu=
t
> > >> nothing concrete. =A0Sure, wearing a seat belt helps to save lives, =
but
> > >> at what point do we draw the line? =A0Should we have four point
> > >> harnesses, helmets, fireproof suits...?
>
> > > Seatbelts may save lives, but statistically many other safety
> > > improvements don't. =A0When people know that their car has air bags,
> > > they compensate and drive less safely. =A0(Corner a little faster, et=
c.)
> > > Enough to mostly remove the life saving effect of the air bags.
>
> > > It does seem likely that people will let down their guard and code
> > > more sloppily knowing that the compiler will catch errors.
>
> > > One of my least favorite is the Java check on variable initialization=
.
> > > If the compiler can't be sure that it is initialized then it is
> > > a fatal compilation error. =A0There are just too many cases that
> > > the compiler can't get right.
>
> > Sorry, but I have to call BS on this whole line og "logic". =A0Unless y=
ou can
> > point to some studies that prove this, my experiences are contrary to y=
our
> > assertions. =A0I don't change the way I code when I code in Verilog vs.=
 VHDL
> > or C vs. Java, the compiler just does a better job of catching my stupi=
d
> > mistakes, allowing me to get things done faster.
>
> You can "call BS" all you want, but the fact that you don't change the
> way you code in Verilog vs. VHDL or or C vs. Java indicates that your
> experiences are antithetical to mine, so I have to discard your
> datapoint.
>
> Regards,
> Pat

That is certainly a great way to prove a theory.  Toss out every data
point that disagrees with your theory!

Rick

Article: 147174
Subject: Re: I'd rather switch than fight!
From: rickman <gnuarm@gmail.com>
Date: Fri, 16 Apr 2010 11:05:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 15, 3:23=A0pm, Andy <jonesa...@comcast.net> wrote:
> The benefits of a "strongly typed" language, with bounds checks, etc.
> are somewhat different between the first time you write/use the code,
> and the Nth time reuse and revise it. Strong typeing and bounds
> checking let you know quickly the possibly hidden side effects of
> making changes in the code, especially when it may have been a few
> days/weeks/months since the last time you worked with it.
>
> A long time ago there was a famous contest for designing a simple
> circuit in verilog vs. vhdl to see which language was better. The
> requirements were provided on paper, and the contestents were given an
> hour or two (don't remember how long, but it was certainly not even a
> day), and whoever got the fastest and the smallest (two winners)
> correct synthesized circuit, their chosen language won. Verilog won
> both, and I don't think vhdl even finished.

Maybe this was repeated, but the first time they tried this *NO ONE*
finished in time which is likely much more realistic compared to real
assignments in the real world.  If you think it will take a couple of
hours, allocate a couple of days!

Rick



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search