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 147125

Article: 147125
Subject: Re: I'd rather switch than fight!
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Wed, 14 Apr 2010 13:23:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 14, 6:43=A0pm, Andy <jonesa...@comcast.net> wrote:

>
> I can't go to my director and tell him I'm going to use a non-
> commercially-supported language/toolset (VHDL/Verilog RTL converter at
> this point) that is at version 0.6 for his next project, and expect to
> still have respect, or even a job afterwards. I suspect the vast
> majority of non-academic HDL professionals are in exactly the same
> boat.

MyHDL has good support for subversive behavior :-)

Seriously, that's why conversion to VHDL/Verilog gets so much
attention. It allows you to view MyHDL simply as a more effective
or fun way to create your trusted VHDL/Verilog design.

Therefore, no need to ask nor tell anyone. If you're intrigued,
just do it, and do it as a good engineer: start with a simple
but relevant module, not with a whole design. After conversion,
few will be able to tell (you may even get praise for the
code quality :-)).

Along the way, you may discover unique features that you want to
share with others, even with directors. You'll know when it's time
to come out.

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: 147126
Subject: Re: I'd rather switch than fight!
From: Bernd Paysan <bernd.paysan@gmx.de>
Date: Wed, 14 Apr 2010 23:39:54 +0200
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:

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

Icarus Verilog (the free simulator) has pretty good checks on this and tells 
you about vector size mismatches - IIRC, it is more pedantic than Cadence's 
original Verilog simulator (they improved in the meantime, but I haven't 
checked if they are as pedantic as Icarus Verilog).  This is IMHO not a 
language problem, but a quality of implementation issue.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself!"
http://www.jwdt.com/~paysan/

Article: 147127
Subject: Re: Implementing bidirectional bus inside the FPGA
From: Pontus <pontus.stenstrom@gmail.com>
Date: Wed, 14 Apr 2010 16:14:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
In case a tristate bus is not driven, the synthesis tool must decide
what value the bus should have (synplify selected '0').
This is not a problem for the bus itself, but if you also have
multiple drivers on a net that is used to acknowledge a request, it
matters if you are using negative logic for the ack!

When porting a design from a device containing "true" tristate
nets to a device which didn't - and using an active low ack to the bus
you will have a problem. Either change to active high ack, or
implement the ack with a wide and-gate.

Yes I spent a few hours around this ...

-- Pontus


Article: 147128
Subject: Re: I'd rather switch than fight!
From: rickman <gnuarm@gmail.com>
Date: Wed, 14 Apr 2010 18:41:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 2:25=A0pm, gabor <ga...@alacron.com> wrote:
> On Apr 9, 10:07=A0am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > I think I have about had it with VHDL. =A0I've been using the
> > numeric_std library and eventually learned how to get around the
> > issues created by strong typing although it can be very arcane at
> > times. =A0I have read about a few suggestions people are making to help
> > with some aspects of the language, like a selection operator like
> > Verilog has. =A0But it just seems like I am always fighting some aspect
> > of the VHDL language.
>
> > 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. =A0My customer uses Verilog and has mentioned several time=
s
> > how he had tried using VHDL and found it too arcane to bother with.
> > He works on a much more practical level than I often do and it seems
> > to work well for him.
>
> > 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. =A0Then I can make a fully
> > informed decision about which I will continue to use. =A0I'd appreciate
> > pointers on good references, web or printed.
>
> > Without starting a major argument, anyone care to share their feelings
> > on the differences in the two languages?
>
> > Rick
>
> At the end of the day, it really comes down to how you can be more
> productive. =A0If you tend to code with many levels of abstraction
> you may do better with VHDL. =A0I find that I am more productive
> with Verilog, but it could be because I tend to look at hardware
> at a fairly detailed level, a bottom-up approach if you will. =A0I
> inherited Verilog projects at my current place of employment and
> just stuck with the language as it grew on me. =A0At one point I
> read Thomas & Moorby's green book from cover to cover. =A0However
> it described Verilog 95, not the more commonly used Verilog 2001,
> and was not a particularly good reference book. =A0I keep a copy
> of the Doulos Golden Reference handy for the bits I don't use
> every day.

I have always used Hardware Description Languages (HDLs) as a way to
describe hardware rather than just a way to code an application.  In
the early days this would pay off in smaller implementations.  But the
tools are better now and you have to work to get an improvement in the
size of your design.  Sometimes the durn language just seems to get in
the way of being able to cleanly express what I want to do.

Rick

Article: 147129
Subject: Re: I'd rather switch than fight!
From: rickman <gnuarm@gmail.com>
Date: Wed, 14 Apr 2010 18:44:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 10:50=A0am, Andy <jonesa...@comcast.net> wrote:
>
> In general, strong typing and built-in bounds checking in VHDL catch
> more problems, closer to the source of the problems, with no
> additional code being written, than is possible in Verilog without
> having to write A LOT of extra code. It seems for almost every weak-
> typing-enabled shortcut in verilog, there is also a hidden, often
> silent, "gotcha" to go along with it.

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

Rick

Article: 147130
Subject: Re: I'd rather switch than fight!
From: rickman <gnuarm@gmail.com>
Date: Wed, 14 Apr 2010 18:54:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 3:07=A0pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:
> On Apr 9, 3:07=A0pm, rickman <gnu...@gmail.com> wrote:
>
> How comfortable are you with most-significant bits being
> silently lost when you copy a wide vector into a narrow
> one? =A0How about signed values being silently zero-filled
> to the width of a wider target?

Isn't this just a matter of knowing the rules and following them?  The
same is true with VHDL.  There may be fewer ways to forget, but it is
still the same.


> >=A0My customer uses Verilog and has mentioned several times
> > how he had tried using VHDL and found it too arcane to bother with.
> > He works on a much more practical level than I often do and it seems
> > to work well for him.
>
> Is "practical" here a euphemism?

No, I mean it literally.  He is always focused on getting the job done
and doesn't spend any time on things he isn't sure will pay off in
tangible ways.  When I designed the board, I also designed a test
fixture since the board goes in his chassis that costs a few grand.
It took a while and ended up delaying some of the FPGA work a bit, but
in the end has paid off greatly since I can do so much debugging on my
own without involving him.  He wouldn't have done that.  Oh, it is
also the only way to power the board so the FPGA can be programmed.
He is supposed to develop a download capability in his system, but has
never spent the time to get it working.  Again, he'll do that when he
knows it will pay some return.


> > 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. =A0Then I can make a fully
> > informed decision about which I will continue to use. =A0I'd appreciate
> > pointers on good references, web or printed.
>
> Good luck. =A0As I've pointed out on many occasions, the textbook
> situation is much less satisfactory for Verilog than it is
> for VHDL. =A0Whatever you do, PLEASE get yourself a copy of
> Sutherland's Verilog Gotchas book (much of it is available free
> online). =A0You may not understand all of it at first, but
> you sure will want to revisit it later. =A0It's just a pity
> that it's incomplete and doesn't cover ALL the many ways
> in which Verilog can silently mess you up.

When I started learning VHDL I thought about writing a book from the
"practical" side of the language since so many were more like text
books.  But I was overtaken by the market and it was flooded before I
got comfortable enough to do that.  However, there may be a good
Verilog for the VHDL Designer book in this.  If I find it was a good
thing to switch, I will seriously consider that.


> To be serious for a moment: a training class from a
> reputable independent provider will save you a ton
> of money in the long run. =A0Your time is valuable.

You are assuming my time is worth something.  When I have no work,
there is no point in paying someone big bucks to teach me something I
can learn on my own.  I am expecting to not have a lot of work over
the next few months.


> > Without starting a major argument, anyone care to share their feelings
> > on the differences in the two languages?
>
> Errrrm, I think I just did.

You did what, shared your feelings or started a major argument?

Rick

Article: 147131
Subject: Re: I'd rather switch than fight!
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 15 Apr 2010 02:07:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga rickman <gnuarm@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.

-- glen

Article: 147132
Subject: Re: Module wise FPGA resource utilization report
From: Jim Wu <jimw567@gmail.com>
Date: Wed, 14 Apr 2010 20:45:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 6:57=A0pm, "vragukumar"
<vragukumar@n_o_s_p_a_m.n_o_s_p_a_m.signalogic.com> wrote:
> Hello,
>
> We are trying to determine the number of slices that a specific module in
> the design consumes upon synthesis. Is there a way to generate a report
> that shows resource utilization per module using Xilinx ISE Webpack v11.5
> ?
>
> Thanks and Regards,
> Vikram. =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

You can use ADEPT (http://mysite.verizon.net/jimwu88/adept/) for this.
The link below has a couple of snapshots and descriptions of the
hierarchical logic utilization view.

http://myadeptblog.blogspot.com/2009/12/logic-utilization-view.html

Cheers,
Jim
http://myfpgablog.blogspot.com/

Article: 147133
Subject: Re: I'd rather switch than fight!
From: Matthew Hicks <mdhicks2@uiuc.edu>
Date: Thu, 15 Apr 2010 05:20:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
> In comp.arch.fpga rickman <gnuarm@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



Article: 147134
Subject: Re: I'd rather switch than fight!
From: David Brown <david@westcontrol.removethisbit.com>
Date: Thu, 15 Apr 2010 10:32:43 +0200
Links: << >>  << T >>  << A >>
On 15/04/2010 04:07, glen herrmannsfeldt wrote:
> In comp.arch.fpga rickman<gnuarm@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...?
>

It is difficult to be concrete about these things, because it is so 
dependent on the programmers involved.  If you see strong typing as a 
useful tool, and write your code accordingly, then you will write 
clearer and neater code and therefore have fewer mistakes - and more of 
these will be caught at compile time.  If you see strong typing as a 
pain that has to be worked around, you will write ugly code that will 
have more mistakes than clearly written code in with a weak typed language.

The main thing is to write your code clearly, and to take advantage of 
whatever typing mechanisms your tool supports - even if it doesn't check 
them (for example, use typedefs and enums in C rather than "int", even 
though the compiler treats them the same).  You can write good code in 
any language, and you certainly can write bad code in any language.  But 
it is easier to write good code if the language and tools make support it.

> 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's a matter of understanding your tools.  The big trouble with air 
bags is that people think they don't need seatbelts because they have 
air bags, without realising that they are designed to work together.

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

I don't use Java, but my C compilers have similar checks.  There are 
very few circumstances that the compiler will get this wrong unless you 
have written particularly convoluted code.  The answer, of course, is to 
avoid writing convoluted code.

Any checking mechanism has a risk of false positives and false negatives 
- the compiler doesn't know everything the programmer knows.  But you 
work with the tool to give the compiler as much knowledge as you can, 
and let it help check that as much as /it/ can.



Article: 147135
Subject: Re: MPEG Reading material
From: Fred <fred__bloggs@lycos.com>
Date: Thu, 15 Apr 2010 02:27:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 12, 2:04=A0pm, Fred <fred__blo...@lycos.com> wrote:
> Can anyone recommend a cross beween reading material and reference
> material for MPEG coding?
>
> I am familiar with JPEG, and the JFIF file structure and would like to
> know more about MPEG, preferably to include MPEG-4 with a view to
> coding MPEG4 streams.

Can anyone suggest an alternative group to ask the question?

Article: 147136
Subject: Re: Implementing bidirectional bus inside the FPGA
From: Manmohan <mmmmec@gmail.com>
Date: Thu, 15 Apr 2010 04:15:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 15, 7:14=A0am, Pontus <pontus.stenst...@gmail.com> wrote:
> In case a tristate bus is not driven, the synthesis tool must decide
> what value the bus should have (synplify selected '0').
> This is not a problem for the bus itself, but if you also have
> multiple drivers on a net that is used to acknowledge a request, it
> matters if you are using negative logic for the ack!
>
> When porting a design from a device containing "true" tristate
> nets to a device which didn't - and using an active low ack to the bus
> you will have a problem. Either change to active high ack, or
> implement the ack with a wide and-gate.
>
> Yes I spent a few hours around this ...
>
> -- Pontus



Welll what about implementing a pullup in the bidirectional bus for
all the non active drivers ?

any idea to implement that ?

Article: 147137
Subject: Re: I'd rather switch than fight!
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 15 Apr 2010 14:03:02 +0100
Links: << >>  << T >>  << A >>
On Thu, 15 Apr 2010 10:32:43 +0200, David Brown
<david@westcontrol.removethisbit.com> wrote:

>On 15/04/2010 04:07, glen herrmannsfeldt wrote:
>> In comp.arch.fpga rickman<gnuarm@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...?

>The main thing is to write your code clearly, and to take advantage of 
>whatever typing mechanisms your tool supports - even if it doesn't check 
>them (for example, use typedefs and enums in C rather than "int", even 
>though the compiler treats them the same).  You can write good code in 
>any language, and you certainly can write bad code in any language.  But 
>it is easier to write good code if the language and tools make support it.

Then (using enums as a simple example), strong typing can either catch
or eliminate errors that may not immediately be considered as type
errors.

Loop count errors or indexing off the end of an array, for example, are
usually type errors, since they use the range of a discrete subtype. In
C you have to build something complex and error prone, simply to
replicate "for i in my_enum'range loop ..." And remember to maintain it
whenever you add a value to the enum...

>
>Any checking mechanism has a risk of false positives and false negatives 
>- the compiler doesn't know everything the programmer knows.  But you 
>work with the tool to give the compiler as much knowledge as you can, 
>and let it help check that as much as /it/ can.
>
Agreed

- Brian

Article: 147138
Subject: Re: MPEG Reading material
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Thu, 15 Apr 2010 15:17:16 +0100
Links: << >>  << T >>  << A >>
Fred <fred__bloggs@lycos.com> writes:

> On Apr 12, 2:04 pm, Fred <fred__blo...@lycos.com> wrote:
>> Can anyone recommend a cross beween reading material and reference
>> material for MPEG coding?
>>
>> I am familiar with JPEG, and the JFIF file structure and would like to
>> know more about MPEG, preferably to include MPEG-4 with a view to
>> coding MPEG4 streams.
>
> Can anyone suggest an alternative group to ask the question?

comp.dsp maybe?

For reference material, the MPEG-4 Wikipedia page has links to all the
ISO standards documents.  More than you could ever want to know I
imagine!  MPEG-4 covers an awful lot of ground!

For something that's a "cross-between reading and reference material"
as you asked, I think you'll have to give more idea as to what level
you want to read at, sorry!

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Article: 147139
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Thu, 15 Apr 2010 07:33:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
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, but
> >> nothing concrete. =A0Sure, wearing a seat belt helps to save lives, bu=
t
> >> 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.
>
> > 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 you=
 can
> point to some studies that prove this, my experiences are contrary to you=
r
> assertions. =A0I don't change the way I code when I code in Verilog vs. V=
HDL
> 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


Article: 147140
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Thu, 15 Apr 2010 07:37:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
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, but
> >> nothing concrete. =A0Sure, wearing a seat belt helps to save lives, bu=
t
> >> 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.
>
> > 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 you=
 can
> point to some studies that prove this, my experiences are contrary to you=
r
> assertions. =A0I don't change the way I code when I code in Verilog vs. V=
HDL
> or C vs. Java, the compiler just does a better job of catching my stupid
> 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

Article: 147141
Subject: Re: MPEG Reading material
From: "Pete Fraser" <pfraser@covad.net>
Date: Thu, 15 Apr 2010 07:42:20 -0700
Links: << >>  << T >>  << A >>
"Fred" <fred__bloggs@lycos.com> wrote in message 
news:e639ddb6-ff7b-4337-a37a-a23d93f35bdc@11g2000yqr.googlegroups.com...
> Can anyone recommend a cross beween reading material and reference
> material for MPEG coding?
>
> I am familiar with JPEG, and the JFIF file structure and would like to
> know more about MPEG, preferably to include MPEG-4 with a view to
> coding MPEG4 streams.

> Can anyone suggest an alternative group to ask the question?

Try comp.compression.

MPEG-4 covers a vast amount of material.
It sounds like you're interested in video coding, so you're
probably interested in MPEG-4 part 2 and / or MPEG-4
part 10 (a.k.a. AVC or H.264).

Each of these offers a variety of tools that can be
used to increase compression efficiency, at the expense
of increased complexity. H.264 is more efficient and
more complex than MPEG-4 part 2.

Are you thinking of building an encoder or decoder in
FPGAs? This is a relatively big deal. The decoder would
be much easier than the encoder, so that might be a good
place to start.

I have H.264 and MPEG-4 Video compression by
Iain Richardson, and The MPEG-4 Book by Pereira
and Ebrahimi. Both are reasonable introductions.

It used to be possible to download some ITU documents
for free from the ITU. It may still be. If so, you should
download the H.264 specification. The ITU doesn't have
a version of MPEG-4 part 2, so you'll have to pay the ISO
for that. You might be able to download a copy of H.263
from the ITU for free. This has a slight overlap with
MPEG-4 part 2 which has a compatability (short header)
mode that is essentially H.263.

Pete 



Article: 147142
Subject: Re: I'd rather switch than fight!
From: Andy <jonesandy@comcast.net>
Date: Thu, 15 Apr 2010 12:23:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

IMHO, they missed the point. Any design that can be completed in a
couple of hours will necessarily favor the language with the least
overhead. Unfortunately, two-hour-solvable designs are not
representative of real life designs, and neither was the contest's
declared winner.

If you just want to hack out the code and get it working by yourself
for the day, a weakly typed language may be the better choice for you.
If you need to be able to reuse/revise/update/extend the design over
time, more strongly typed languages are preferred.

Andy

Article: 147143
Subject: Re: I'd rather switch than fight!
From: David Brown <david@westcontrol.removethisbit.com>
Date: Thu, 15 Apr 2010 22:12:13 +0200
Links: << >>  << T >>  << A >>
On 15/04/2010 21:23, Andy wrote:
> The benefits of a "strongly typed" language, with bounds checks, etc.

This is perhaps a nit-pick, but bounds checks are not directly related 
to type strength.  Bound checks are either run-time (and therefore have 
a cost), or compile-time (or both).  For compile time, this mainly means 
that the compiler must see the full declaration of the array or other 
type when you are using it - modern gcc will do pretty good compile-time 
bounds checking if it has enough information, even with weakly-typed C.

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

Agreed, although this applies to a lot of good programming techniques 
(you can write strongly-typed code even if the language doesn't enforce 
it, and typically the compiler's warnings will give you more help than 
the language standards).  It's faster to write code full of functions 
"test" and "foo" than to think of meaningful names, but it makes a big 
difference when you go back to the code latter.

> 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.
>
> IMHO, they missed the point. Any design that can be completed in a
> couple of hours will necessarily favor the language with the least
> overhead. Unfortunately, two-hour-solvable designs are not
> representative of real life designs, and neither was the contest's
> declared winner.
>
> If you just want to hack out the code and get it working by yourself
> for the day, a weakly typed language may be the better choice for you.
> If you need to be able to reuse/revise/update/extend the design over
> time, more strongly typed languages are preferred.
>
> Andy

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.




Article: 147144
Subject: Re: I'd rather switch than fight!
From: David Brown <david@westcontrol.removethisbit.com>
Date: Thu, 15 Apr 2010 22:19:00 +0200
Links: << >>  << T >>  << A >>
On 15/04/2010 15:03, Brian Drummond wrote:
> On Thu, 15 Apr 2010 10:32:43 +0200, David Brown
> <david@westcontrol.removethisbit.com>  wrote:
>
>> On 15/04/2010 04:07, glen herrmannsfeldt wrote:
>>> In comp.arch.fpga rickman<gnuarm@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...?
>
>> The main thing is to write your code clearly, and to take advantage of
>> whatever typing mechanisms your tool supports - even if it doesn't check
>> them (for example, use typedefs and enums in C rather than "int", even
>> though the compiler treats them the same).  You can write good code in
>> any language, and you certainly can write bad code in any language.  But
>> it is easier to write good code if the language and tools make support it.
>
> Then (using enums as a simple example), strong typing can either catch
> or eliminate errors that may not immediately be considered as type
> errors.
>

Yes - it's one of the advantages of C++ over C (C++ has plenty of 
advantages and plenty of disadvantages) - type checking, including 
enums, is much stronger.  And with a bit of messing around with you can 
make types that are effectively enums but even stronger typed.

I've seen some code to use C++ classes to encapsulate rules about lock 
orders for multi-threaded code (such as "you must not take lock A unless 
you first have lock B, and you must release them in reverse order"). 
The result was that violations of these rules ended up as type errors 
and were therefore caught at compile time.

It's often possible to add features to the language in this way - some 
ugly macros will give you zero-cost static asserts in C, for example.

> Loop count errors or indexing off the end of an array, for example, are
> usually type errors, since they use the range of a discrete subtype. In
> C you have to build something complex and error prone, simply to
> replicate "for i in my_enum'range loop ..." And remember to maintain it
> whenever you add a value to the enum...
>

typedef enum {
	red, blue, green,
	noOfColours
} colours;

for (int i = 0; i < noOfColours; i++) { ... }

But it would be *so* much nicer if it were part of the language as it is 
in Ada or Pascal.

>>
>> Any checking mechanism has a risk of false positives and false negatives
>> - the compiler doesn't know everything the programmer knows.  But you
>> work with the tool to give the compiler as much knowledge as you can,
>> and let it help check that as much as /it/ can.
>>
> Agreed
>
> - Brian


Article: 147145
Subject: Re: Implementing bidirectional bus inside the FPGA
From: Andy Peters <google@latke.net>
Date: Thu, 15 Apr 2010 13:36:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 14, 1:24=A0am, Manmohan <mmm...@gmail.com> wrote:
> On Apr 14, 7:50=A0am, Andy Peters <goo...@latke.net> wrote:
>
>
>
> > On Apr 13, 4:43=A0pm, Manmohan <mmm...@gmail.com> wrote:
>
> > > Hi all,
>
> > > I would like to implement a router mesh (3x3) with bidirectional link=
s
> > > within the FPGA . I am using a Virtex 4 board. Since there are =A0a l=
ot
> > > of bidirectional buses in my design, I would like to know if it is
> > > possible to implement all the buses using tristate logic? when I
> > > snthesised only one single bidirectional bus, it was mapped to the
> > > IOBs and consumed around 15% of the 240 IOBs.
>
> > > I would like to know if there is any other way to implement a
> > > bidirectional bus that does not use the IOBs ?
>
> > No, internal tristates have vanished from Brand X FPGAs after the
> > XC4000 series.
>
> > I don't miss them. I don't see how they can possibly have any
> > advantage over distinct "going this way" and "going that way" buses.
>
> > -a
>
> Hi Thank you for the reply... But actually I am planning to implement
> a single set of 8 bit wide bus for both input and output direction....
> So , I need to have a bidirectional bus .... Is there any other way
> other than tristating to implement such a bus ?

Give up on the idea of using an internal tristate/bidirectional bus
and instead use two unidirectional buses, one for each direction.

-a


Article: 147146
Subject: Re: Implementing bidirectional bus inside the FPGA
From: Pontus <pontus.stenstrom@gmail.com>
Date: Thu, 15 Apr 2010 13:43:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
> Well what about implementing a pullup in the bidirectional bus for
> all the non active drivers ?
>
> any idea to implement that ?


As far as I remember we did instatiate a pullup from unisim (xilinx).
This worked for virtexE (which has internal tristate) but failed when
trying it with Virtex5 (which doesn't). With this I mean that [for V5]
the tri_to_mux conversion is OK if you expect an undriven signal to go
low. If you think that an undriven signal should be high you will be
surprised.
To be explicit, there was an internal bus that several entities could
drive. If an entity "felt adressed" it would provide data and ack.
We had (for whatever reason) chosen negative logic for the ack.
So when no entity felt adressed, no one drove the ack, and since
synplify then put the signal low, the bus ended up beeing ack:ed
all the time.

Try it yourself and tell us about your results.

-- Pontus

Article: 147147
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Thu, 15 Apr 2010 14:21:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 Ad=
a
> 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.

Article: 147148
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Thu, 15 Apr 2010 14:27:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 15, 2: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.

For this usage, a good testbench will catch more bugs and make strong
type and bounds checking redundant.

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

Contest details here:

http://www.see.ed.ac.uk/~gerard/Teach/Verilog/manual/Example/lrgeEx2/cooley=
.html

> IMHO, they missed the point. Any design that can be completed in a
> couple of hours will necessarily favor the language with the least
> overhead. Unfortunately, two-hour-solvable designs are not
> representative of real life designs, and neither was the contest's
> declared winner.

Well, I think the takeaway is a lot more nuanced than that, but
whatever.  Believe what you will.

> If you just want to hack out the code and get it working by yourself
> for the day, a weakly typed language may be the better choice for you.
> If you need to be able to reuse/revise/update/extend the design over
> time, more strongly typed languages are preferred.

Again, IMHO, a really good testbench will more than make up for any
perceived weaknesses in Verilog in this area.  But you are free to
continue to believe that the language is really helping you.

Regards,
Pat

Article: 147149
Subject: Re: Implementing bidirectional bus inside the FPGA
From: Gabor <gabor@alacron.com>
Date: Thu, 15 Apr 2010 14:27:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 15, 4:43=A0pm, Pontus <pontus.stenst...@gmail.com> wrote:
> > Well what about implementing a pullup in the bidirectional bus for
> > all the non active drivers ?
>
> > any idea to implement that ?
>
> As far as I remember we did instatiate a pullup from unisim (xilinx).
> This worked for virtexE (which has internal tristate) but failed when
> trying it with Virtex5 (which doesn't). With this I mean that [for V5]
> the tri_to_mux conversion is OK if you expect an undriven signal to go
> low. If you think that an undriven signal should be high you will be
> surprised.
> To be explicit, there was an internal bus that several entities could
> drive. If an entity "felt adressed" it would provide data and ack.
> We had (for whatever reason) chosen negative logic for the ack.
> So when no entity felt adressed, no one drove the ack, and since
> synplify then put the signal low, the bus ended up beeing ack:ed
> all the time.
>
> Try it yourself and tell us about your results.
>
> -- Pontus

This of course is a simulation mis-match and should be flagged
during synthesis.  If the synthesizer ignores a pullup on a
net it should indicate that as a warning.



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