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 139300

Article: 139300
Subject: Re: USB PHY
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 25 Mar 2009 11:18:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 8:15=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
> On Wed, 25 Mar 2009 09:39:01 -0700 (PDT), bhavanire...@gmail.com
> wrote:
>
> >Hi,
>
> >While searching for USB IP resources on the net I came across USB PHY
> >cores in verilog.
>
> >1) Why is it neessary to seperate USB controller and PHY in two
> >different cores? It may be necessary for 3.0 due to higher speeds but
> >what is the need for 1.1 and 2.0?
>
> The difference is the speed. USB 1.1 is 12 Mb/s and the "PHY" is
> basically three CMOS receivers (two single ended and one differential)
> and a tri-state CMOS drive so implementing the digital portion of the
> PHY in RTL is feasible. The analog portion of the PHY can be
> implemented by the standard IOs one can find on an FPGA in most cases
> even though it may not be fully compliant.
> USB 2.0 (at least =A0high speed portion thereof) is 480 Mb/s and need
> special IO for both receiver and transmitter and this IO doesn't exist
> on any FPGA I know of. Also there are quite challenging clock recovery
> requirements which make even implementation of the "digital" portion
> of the PHY challenging.
> Interestingly USB 3.0 is quite similar to PCI Express and we may see
> full implementations in FPGAs.
> --
> Muzaffer Kal
>
> DSPIA INC.
> ASIC/FPGA Design Serviceshttp://www.dspia.com

Virtex-5 is fully USB-3 compliant, PLDA had live demo
on EW2009

Antti


Article: 139301
Subject: Re: Looking for a low-cost development kit
From: News123 <news123@free.fr>
Date: Wed, 25 Mar 2009 20:35:56 +0100
Links: << >>  << T >>  << A >>
Lattice seems to have several FPGA development kits.

Do you have by any chance the reference number of your kit or a URL?


LittleAlex wrote:
> I just got an FPGA development kit from Lattice - 2200 CLB's, USB
> (FX2) Interface, a software starter kit, and an 8-bit embedded
> processor.
> 
> $75 including tax & Shipping.
> 
> Software license expires every 6 months; I'm guessing that they will
> renew it.  Software is reminiscent of Xilinx back in the ISE-4.2 days
> (clumsy, but functional).  The embedded processor (Mico8) looks -very-
> interesting: if I'm seeing things correctly, they chose 'wishbone' for
> their on-chip bus.
> 
> AL
> 



Article: 139302
Subject: Re: Looking for a low-cost development kit
From: "Johnson L" <gpsabove@yahoo.com>
Date: Wed, 25 Mar 2009 16:14:06 -0600
Links: << >>  << T >>  << A >>
Thank you for sharing! As for the Arduino, does it support c-programming? 
Does it have an IDE for c-programming? How much does it cost (hardware + 
development tools  + IDE)?
Johnson


"mng" <michael.jh.ng@gmail.com> wrote in message 
news:7ddfe4d9-75f9-4749-a682-7800ae1f0ce0@v38g2000yqb.googlegroups.com...
On Mar 24, 12:12 pm, "Johnson L" <gpsab...@yahoo.com> wrote:
> I found the PIC microcontroller, and it includes free IDE. From the link
> below, it seems the costs are minimum. Any objection or suggestion?
>
> http://www.sparkfun.com/tutorial/ARM/ARM_Cross_Development_with_Eclip...
>
> "Johnson L" <gpsab...@yahoo.com> wrote in message
>
> news:FPExl.73664$FI5.25671@newsfe07.iad...
>
> > For my hobby work, I am looking for a low-cost development kit to
> > develope a simple embedded system. This system will measure the
> > temperature
> > and heart beat rate, compare them with a predefined table which 
> > implements
> > some health-care knowledge, then provide some useful information. This
> > development kit should be low-cost, support C programming, debugging,
> > better
> > with JTAG or other on-site debugging. It should support at least one 
> > type
> > of
> > popular microprocessors, or a mainstream FPGA,
> > and easy to use. Could anybody recommend me some? Thank you in advance.
>
> > Johnson

Yeah, if you go with a PIC-based dev kit, Microchip provides MPLAB and
a limited C compiler for free.

You may want to consider the Arduino, which has gotten to be pretty
popular in the hobbyist community. There's a lot of examples and
resources on the web. The software toolchain is all free.

http://www.arduino.cc/

As for DSP, here's a free book.

http://www.dspguide.com/

Good luck,
Mike 



Article: 139303
Subject: Re: USB PHY
From: leevv <leevv@mail.ru>
Date: Wed, 25 Mar 2009 15:29:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 2:18=A0pm, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Mar 25, 8:15=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
>
>
>
>
>
> > On Wed, 25 Mar 2009 09:39:01 -0700 (PDT), bhavanire...@gmail.com
> > wrote:
>
> > >Hi,
>
> > >While searching for USB IP resources on the net I came across USB PHY
> > >cores in verilog.
>
> > >1) Why is it neessary to seperate USB controller and PHY in two
> > >different cores? It may be necessary for 3.0 due to higher speeds but
> > >what is the need for 1.1 and 2.0?
>
> > The difference is the speed. USB 1.1 is 12 Mb/s and the "PHY" is
> > basically three CMOS receivers (two single ended and one differential)
> > and a tri-state CMOS drive so implementing the digital portion of the
> > PHY in RTL is feasible. The analog portion of the PHY can be
> > implemented by the standard IOs one can find on an FPGA in most cases
> > even though it may not be fully compliant.
> > USB 2.0 (at least =A0high speed portion thereof) is 480 Mb/s and need
> > special IO for both receiver and transmitter and this IO doesn't exist
> > on any FPGA I know of. Also there are quite challenging clock recovery
> > requirements which make even implementation of the "digital" portion
> > of the PHY challenging.
> > Interestingly USB 3.0 is quite similar to PCI Express and we may see
> > full implementations in FPGAs.
> > --
> > Muzaffer Kal
>
> > DSPIA INC.
> > ASIC/FPGA Design Serviceshttp://www.dspia.com
>
> Virtex-5 is fully USB-3 compliant, PLDA had live demo
> on EW2009
>
> Antti- Hide quoted text -
>
> - Show quoted text -


What about Virtex 4FX? Is it fully USB-3 compiant?


Article: 139304
Subject: Dynamic reconfiguration in Spartan 3
From: "samece" <samece87@gmail.com>
Date: Wed, 25 Mar 2009 19:07:25 -0500
Links: << >>  << T >>  << A >>
hi all,
Is dynamic reconfiguration of microblaze implemented in a Spartan 3 fpga
kit possible? If so may anyone help me in that area.



Article: 139305
Subject: Re: FPGAs in automotive apps
From: "KJ" <kkjennings@sbcglobal.net>
Date: Wed, 25 Mar 2009 20:11:09 -0400
Links: << >>  << T >>  << A >>

"rickman" <gnuarm@gmail.com> wrote in message 
news:55f61edb-8c9e-45bf-9101-6e1d87444f66@j39g2000yqn.googlegroups.com...

>
> Is there some rational for not designing an ASIC for a high volume
> product that is out of development and meets all specs?

One reason could be that the expected return on the addition marginal 
investment to make an ASIC is better off invested elsewhere on other more 
lucrative activities.

The reasons an FPGA may be there in the first place could be
- Possibly a shorter development time which was required to hit a (real or 
imagined) market window
- Possibly reduced development risk

> Don't tell me
> you are doing it, tell me *why* you are doing it.  Companies make
> mistakes all the time.  I would like to know the reason for this
> decision or if it is just a temporary choice and will change as the
> volumes increase.

Any employee that would post their business case for any project on a public 
web site should probably make sure that all the numbers on the lottery 
ticket really do match first.

KJ 



Article: 139306
Subject: Re: USB PHY
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 25 Mar 2009 17:36:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 12:29=A0am, leevv <le...@mail.ru> wrote:
> On Mar 25, 2:18=A0pm, "Antti.Luk...@googlemail.com"
>
>
>
> <Antti.Luk...@googlemail.com> wrote:
> > On Mar 25, 8:15=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
>
> > > On Wed, 25 Mar 2009 09:39:01 -0700 (PDT), bhavanire...@gmail.com
> > > wrote:
>
> > > >Hi,
>
> > > >While searching for USB IP resources on the net I came across USB PH=
Y
> > > >cores in verilog.
>
> > > >1) Why is it neessary to seperate USB controller and PHY in two
> > > >different cores? It may be necessary for 3.0 due to higher speeds bu=
t
> > > >what is the need for 1.1 and 2.0?
>
> > > The difference is the speed. USB 1.1 is 12 Mb/s and the "PHY" is
> > > basically three CMOS receivers (two single ended and one differential=
)
> > > and a tri-state CMOS drive so implementing the digital portion of the
> > > PHY in RTL is feasible. The analog portion of the PHY can be
> > > implemented by the standard IOs one can find on an FPGA in most cases
> > > even though it may not be fully compliant.
> > > USB 2.0 (at least =A0high speed portion thereof) is 480 Mb/s and need
> > > special IO for both receiver and transmitter and this IO doesn't exis=
t
> > > on any FPGA I know of. Also there are quite challenging clock recover=
y
> > > requirements which make even implementation of the "digital" portion
> > > of the PHY challenging.
> > > Interestingly USB 3.0 is quite similar to PCI Express and we may see
> > > full implementations in FPGAs.
> > > --
> > > Muzaffer Kal
>
> > > DSPIA INC.
> > > ASIC/FPGA Design Serviceshttp://www.dspia.com
>
> > Virtex-5 is fully USB-3 compliant, PLDA had live demo
> > on EW2009
>
> > Antti- Hide quoted text -
>
> > - Show quoted text -
>
> What about Virtex 4FX? Is it fully USB-3 compiant?

no

Article: 139307
Subject: Re: FPGAs in automotive apps
From: rickman <gnuarm@gmail.com>
Date: Wed, 25 Mar 2009 19:30:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 8:11 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "rickman" <gnu...@gmail.com> wrote in message
>
> news:55f61edb-8c9e-45bf-9101-6e1d87444f66@j39g2000yqn.googlegroups.com...
>
>
>
> > Is there some rational for not designing an ASIC for a high volume
> > product that is out of development and meets all specs?
>
> One reason could be that the expected return on the addition marginal
> investment to make an ASIC is better off invested elsewhere on other more
> lucrative activities.
>
> The reasons an FPGA may be there in the first place could be
> - Possibly a shorter development time which was required to hit a (real or
> imagined) market window
> - Possibly reduced development risk

Both of these goals are accomplished by prototyping with FPGAs and
even initial production with FPGAs.  But if the product is truly high
volume, it is very inexpensive to transition to an ASIC supplied at a
lower price by the FPGA vendor if nothing else!

I'm not clear why you keep trying to refute the economic facts.  If a
design is intended for moderate volume, the choices are a tradeoff.
But any high volume design will not use an FPGA unless there is a
compelling reason to use some unique feature of them.  The only one I
know of is reconfigurability.


> > Don't tell me
> > you are doing it, tell me *why* you are doing it.  Companies make
> > mistakes all the time.  I would like to know the reason for this
> > decision or if it is just a temporary choice and will change as the
> > volumes increase.
>
> Any employee that would post their business case for any project on a public
> web site should probably make sure that all the numbers on the lottery
> ticket really do match first.

If you can't say why, then please don't try to convince me that there
is an "unspoken" reason to use FPGAs that no one else knows of.

Rick

Article: 139308
Subject: Re: FPGAs in automotive apps
From: "KJ" <kkjennings@sbcglobal.net>
Date: Wed, 25 Mar 2009 23:14:51 -0400
Links: << >>  << T >>  << A >>
"rickman" <gnuarm@gmail.com> wrote in message 
news:0b1739f0-04b7-495a-88ad-7401f3bbe613@c11g2000yqj.googlegroups.com...
> On Mar 25, 8:11 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
>> "rickman" <gnu...@gmail.com> wrote in message
>>
>> news:55f61edb-8c9e-45bf-9101-6e1d87444f66@j39g2000yqn.googlegroups.com...

>
> I'm not clear why you keep trying to refute the economic facts.

I didn't realize that my first posting on this thread would constitute 'keep 
trying' in your book.  In any case, you haven't stated any 'economic facts', 
just your opinion and observations (which is fine).  Actual decisions in the 
real world though are based on perceived realities of the business, politics 
and the markets in which the business operates, in short a business case 
with real people involved.

> If a
> design is intended for moderate volume, the choices are a tradeoff.
> But any high volume design will not use an FPGA unless there is a
> compelling reason to use some unique feature of them.

Here you state an opinion but insist it may be fact.  Given a finite amount 
of R&D dollars to spend, the business case for a particular project (such as 
an FPGA-->ASIC cost reduction, possible product enhancement as well) will 
compete with other projects for funding.  Those projects get prioritized by 
expected return on investment with modifiers for projects that might be 
considered 'strategic' areas for the company.

The other obvious constraint is available dollars which defines the line in 
the list of potential projects.  Projects 'above the line' get funded, ones 
below the line do not, no matter how good they appear to be (because others 
are better).  Words like 'any high volume design will...' mean absolutely 
nothing, in most industries you must back them up with estimates on expected 
return on investment, or have a convincing argument for why the project is 
strategic to the business.  A cost reduction project can probably never fit 
the strategic description since there already is a product (the FPGA one), 
the end user doesn't care generally about the underlying technology 
implementation.

In any case, the details of why a particular company's automotive product 
could not justify an ASIC really can't be bandied about in a newsgroup so 
your particular need to know why will likely be unmet...and with good reason 
(proprietary information shouldn't be publicly disclosed).

> The only one I
> know of is reconfigurability.
>

See, there you've got another good reason to keep the FPGA.

>
>> > Don't tell me
>> > you are doing it, tell me *why* you are doing it.  Companies make
>> > mistakes all the time.  I would like to know the reason for this
>> > decision or if it is just a temporary choice and will change as the
>> > volumes increase.
>>
>> Any employee that would post their business case for any project on a 
>> public
>> web site should probably make sure that all the numbers on the lottery
>> ticket really do match first.
>
> If you can't say why, then please don't try to convince me that there
> is an "unspoken" reason to use FPGAs that no one else knows of.
>

I wasn't trying to convince you of anything, I don't know anything about the 
product, just stating some possibilities that could be reasons behind why a 
product might continue with an FPGA and not an ASIC (you even came up with 
one yourself).  Your insistence on having having to know *why* some business 
made a particular business decision is a bit self-serving, did it ever occur 
to you that a reason can be "unspoken" simply because it is the company's 
business and not yours?

Done with this thread

KJ 



Article: 139309
Subject: some nibz decoding ?
From: AliBama@gmail.com
Date: Wed, 25 Mar 2009 22:41:30 -0500
Links: << >>  << T >>  << A >>
The following is much easier for me to understand, with my 
ETH-oberon system, where I colour/font the 'conceptual groups' 
of text, better than you can mark a paper-text with 
multi-coloured pens.

Since I've spent the labour [now for the 2nd time to recheck]
you are free to benefit too. PS. I've perhaps mis-quoted what 
Jacko wrote with what I've deduced.  This is 'hand made', not
just generated by Micro$loth !

>> Let's try to work backwards:-
>>  (R)->P should move #$222 to address $666
>>  ==> P  == address $666
>>     and
>> R pointed to mem-containing #$222

>> So, how did    $lit ,    $222 [ push    $222] get
>> $222 into mem pointed to by R ?

---------- Jacko explained:-
> RI FI SO RO BA where SO RO commutes to RO SO as a duplicate 
> expression for same function.

 A->(S);Q->(R)   commutes to Q->(R); A->(S)
== order is irrelevant 
==> RI FI RO SO BA ==
(R)->Q; (Q)->A; Q->(R); A->(S); (R)->P
==  (R)->Q; (Q)->A;A->(S),Q->(R),(R)->P

> (R)->Q,(Q)->A,A->(S),Q->(R),(R)->P
> get return address and get indirect next address following return
> address, and save this on stack, 

== (R)->Q,(Q)->A,A->(S)
? doesnext address following return address contain #$222,
perhaps code format is 2 words: lit, #$222  ?
If so, lit must push the next-word.
I.e. starting from: lit knows its own adr., and S knows TOS,
and lit's  adr. gives the subroutine's return.

> and put incremented return address
> back on return stack 

Q->(R) 

BTW I disagree with your wording: 'put back';
which implies that it 'move away'. 
AFAIK the data doesn't 'move'.
It copies ? [ IMO intel/Motorola used 'move',
because the 'other' had already 'copyrighted'
'load']
So the apparent reason why you'd copy from 
Q to R, when you had previously copied from
R to Q, would be that the data had been
'stepped', so that an updated data replaces
the original data. 
The mental acrobatics required for a newby
without a simulator, is considerable ?

> and get return address (modified by +1) into
> program counter 

(R)->P == return

> to execute a return to the address following the
> literal value.
----------
Wow ! Very interesting. I supose when you've been
doing it for a few hundred hours, it's natural, but
I think the 'primitive instruction routeing' to acheive
the subroutine goal, would make a nice exercise for
an AI utility.  It maps directly to various AI techniques.
----------
Rather than search for Rick's verbatum crit., I'll try
to paraphrase my understanding of it, and add my 
own [perhaps wrong] understanding:
1. nibz instruction's are inefficient because
* you have to have 20-bit wide to get 64K adr-space.
    AdrSpace = 2^ (wordWidth - 4). 
   And that's 64K 20bit-words.    
* and then since there are only 16 primitives, these
use only 4 of the 16 bits.

I wonder what the typical ratio is of primitives to
subroutines + literals  ?

The 16 primitives almost sound as if they are at
a lower-level in microcoding, but apparently not ?

2. The common optimisation of small literals is not
possible.

Well, the common inc(tos) and dec(tos) [I don't
know the forth words off-hand] would be subroutines,
and as Jacko writes, any literals which appear in the 
code more than once, are just all fetched from the
same memory location, using 2 words of code.
[These are memory-size 'words'  NOT 'forth words'.]

And then could you optimise for space with less speed,
from: [literal] [pointer to the value] = 2 words
      to
[subroutine of literal of value] = 1 word;
where, again 'the value' is in memory to be accessed
in multiple sections of the code, by the same subroutine ?
--------------
Since Jacko made the common/natural mistake of
'branching off' to mention optimisation issues, while
describing the basics of eg. the instruction set, IMO
it's naiive to think that he hasn't already considered
all the 'problems' that Rick has raised.
Let's play the ball, not the player ?

Yes, this is a time-sink, but I want to go on to see
if I can 'decode' the SD-driver info in the wiki.

Without deep though on it yet, the ability to have
the same code for different word, memory sizes
seems to have great merit - Java-ish ?

BTW, how are such fpgaS for power consumption
compared to eg. an ARM ?
Does anybody think that ePaper will ever be viable ?

Thanks,

== Chris Glur.


Article: 139310
Subject: Re: FPGAs in automotive apps
From: rickman <gnuarm@gmail.com>
Date: Wed, 25 Mar 2009 21:29:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 11:14=A0pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "rickman" <gnu...@gmail.com> wrote in message
>
> news:0b1739f0-04b7-495a-88ad-7401f3bbe613@c11g2000yqj.googlegroups.com...
>
> > On Mar 25, 8:11 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> >> "rickman" <gnu...@gmail.com> wrote in message
>
> >>news:55f61edb-8c9e-45bf-9101-6e1d87444f66@j39g2000yqn.googlegroups.com.=
..
>
> > I'm not clear why you keep trying to refute the economic facts.
>
> I didn't realize that my first posting on this thread would constitute 'k=
eep
> trying' in your book. =A0In any case, you haven't stated any 'economic fa=
cts',
> just your opinion and observations (which is fine). =A0Actual decisions i=
n the
> real world though are based on perceived realities of the business, polit=
ics
> and the markets in which the business operates, in short a business case
> with real people involved.

My appologies.  I confused you with Martin.

My "opinions" are factual as far as I can tell.  Perhaps we have not
explored all the details, but the economics are clear.


> > If a
> > design is intended for moderate volume, the choices are a tradeoff.
> > But any high volume design will not use an FPGA unless there is a
> > compelling reason to use some unique feature of them.
>
> Here you state an opinion but insist it may be fact. =A0Given a finite am=
ount
> of R&D dollars to spend, the business case for a particular project (such=
 as
> an FPGA-->ASIC cost reduction, possible product enhancement as well) will
> compete with other projects for funding. =A0Those projects get prioritize=
d by
> expected return on investment with modifiers for projects that might be
> considered 'strategic' areas for the company.
>
> The other obvious constraint is available dollars which defines the line =
in
> the list of potential projects. =A0Projects 'above the line' get funded, =
ones
> below the line do not, no matter how good they appear to be (because othe=
rs
> are better). =A0Words like 'any high volume design will...' mean absolute=
ly
> nothing, in most industries you must back them up with estimates on expec=
ted
> return on investment, or have a convincing argument for why the project i=
s
> strategic to the business. =A0A cost reduction project can probably never=
 fit
> the strategic description since there already is a product (the FPGA one)=
,
> the end user doesn't care generally about the underlying technology
> implementation.

Unless the cost is nearly zero, as is the case of having your FPGA
vendor provide you with an ASIC based on the FPGA bit file.  If you
buy a minimum quantity, they will not charge NRE at all.  Your only
expense is in discussing this with your management and getting a
signoff.  So if you are talking about a product in *high volume*
production, the trade off is trivial.


> In any case, the details of why a particular company's automotive product
> could not justify an ASIC really can't be bandied about in a newsgroup so
> your particular need to know why will likely be unmet...and with good rea=
son
> (proprietary information shouldn't be publicly disclosed).

Ok, so you say you know a "secret" reason.  If there is a reason that
is not based on basic engineering and economic principles, then it
would be a new one indeed.  The FPGA companies have explored pretty
much every single one and have shouted them from the rooftops.


> > The only one I
> > know of is reconfigurability.
>
> See, there you've got another good reason to keep the FPGA.

I have said this several times before.  There is only one advantage of
an FPGA in a high volume product, reconfigurability.  If this is
important enough in your product to warrant the extra cost then FPGAs
are an option.  But few auto products ever need upgraded hardware.
Perhaps this will change as even basic autos get more and more
complex, but I don't see this coming in any way.


> >> > Don't tell me
> >> > you are doing it, tell me *why* you are doing it. =A0Companies make
> >> > mistakes all the time. =A0I would like to know the reason for this
> >> > decision or if it is just a temporary choice and will change as the
> >> > volumes increase.
>
> >> Any employee that would post their business case for any project on a
> >> public
> >> web site should probably make sure that all the numbers on the lottery
> >> ticket really do match first.
>
> > If you can't say why, then please don't try to convince me that there
> > is an "unspoken" reason to use FPGAs that no one else knows of.
>
> I wasn't trying to convince you of anything, I don't know anything about =
the
> product, just stating some possibilities that could be reasons behind why=
 a
> product might continue with an FPGA and not an ASIC (you even came up wit=
h
> one yourself). =A0Your insistence on having having to know *why* some bus=
iness
> made a particular business decision is a bit self-serving, did it ever oc=
cur
> to you that a reason can be "unspoken" simply because it is the company's
> business and not yours?

As I said, I confused you with Martin.  I have not asked *why* any
company made any decision.  I stated that FPGAs are designed for the
comms market since that is the market where they make sense.  Their
advantages are important and the disadvantages not so much.  I am
discussing a general issue, not one of any particular product or
company.  So far the only example mentioned is from Martin's company
for a product that is not even available yet.  I suspect that even
this product will be using an ASIC by the time it goes to volume
production.  It just does not make sense to leave money laying on the
table.  No CEO would do that.

> Done with this thread

Yes, I agree.  It started as a discussion of engineering and economic
principles and has turned into something else.

Rick

Article: 139311
Subject: Re: Dynamic reconfiguration in Spartan 3
From: Moazzam <moazzamhussain@gmail.com>
Date: Wed, 25 Mar 2009 22:22:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 5:07=A0am, "samece" <samec...@gmail.com> wrote:
> hi all,
> Is dynamic reconfiguration of microblaze implemented in a Spartan 3 fpga
> kit possible? If so may anyone help me in that area.

Samece,
Dynamic (Self) reconfiguration is usually performed by the usage of
ICAP with soft processor core.  I don't think that there is any ICAP
in Spartan-3 FPGA. The only available option is through the JTAG
interface. I learnt from a post on this group that Spartan-3 may
exhibit some glitchy behaviour during the process of dynamic
reconfiguration, so it is not recommended for partially reconfigurable
designs.

Hope this helps,

/MH

Article: 139312
Subject: Avnet FX12 module, OLED example / problem
From: iovanalex <iovanalex@gmail.com>
Date: Wed, 25 Mar 2009 23:58:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello

I have an Avnet ADS-XLX-V4FX-EVL12-G (Virtex4 Evaluation Board) with
OLED display. I used Xilinx EDK 10.1 with Xilinx Platform Studio 10.1
and succeded to upload some basic app to the board (serial
communication).

Now I would like to use the OLED display mounted on the board but I
have no ideea how to begin. I found the uCLinux distro for FX12
(http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux/Downloads/
platforms.html#avnet_lx25) and I tried to folow the steps descibed in
the documentation. When I try to download the .img file to the the
specified address it does not work. I get the following error MDM
Peripheral Not Detected on Hardware. They say that I should use EDK
7.1 but I have 10.1. Could that be a problem ? (I used xmd.exe from
10.1). There is a support answer on Xilinx (http://www.xilinx.com/
support/answers/20060.htm) where I have to recompile the netlist but I
cannot open the project file in 10.1.

Anyway could you point me a resource where I can find some basic
example of using the OLED? Even lighting-up a pixel could be a good
starting point ...


Article: 139313
Subject: Re: Looking for a low-cost development kit
From: -jg <Jim.Granville@gmail.com>
Date: Thu, 26 Mar 2009 00:57:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 23, 5:08=A0pm, "Johnson L" <gpsab...@yahoo.com> wrote:
> For my hobby work, I am looking for a low-cost development kit to
> develope a simple embedded system. This system will measure the temperatu=
re
> and heart beat rate, compare them with a predefined table which implement=
s
> some health-care knowledge, then provide some useful information. This
> development kit should be low-cost, support C programming, debugging, bet=
ter
> with JTAG or other on-site debugging. It should support at least one type=
 of
> popular microprocessors, or a mainstream FPGA,
> and easy to use. Could anybody recommend me some? Thank you in advance.
>
> Johnson

Are you sure that needs a FPGA ?
Heart rates are very low, so you might be better to work from a Size/
Power viewpoint.
ie what display will this have, user controls, and how will it be
powered ?

There are small uC around, that will power off a single-cell. SiLabs
C8051F9xx
and Atmel have a sub 1V AVR member (less code space than SiLabs).

Both have free tools and good Debug systems.

-jg


Article: 139314
Subject: virtex-5 lvds termination issue?
From: Muzaffer Kal <kal@dspia.com>
Date: Thu, 26 Mar 2009 00:58:01 -0700
Links: << >>  << T >>  << A >>
Hi,
I've been working on a high speed ADC board which has a LVDS outputs
connected to a virtex-5 lx 50. The ADC board has 100 ohm differential
lines but no receiver termination so I configured the IOs on the FPGA
side to be LVDS_25 with DIFF_TERM option on. I connected the ADC board
to the FPGA board and did a capture with a chipscope block and the
data was what we'd expect. The problem started after we replaced the
-1 speed V5 with a -3 speed chip on the FPGA board. The captured data
changed significantly and even changing the sampling points on the
FPGA didn't help at all. 
I looked at the ADC/FPGA interface with a DSO and there are large
over/undershoots which seem to be caused by significant reflections.
Initially I thought this could be the result of the FPGA replacement
but I had the board x-ray'ed and there seems to be no alignment or
ball short problems. Also everything else seems to work as before on
the board so now the suspicion is more towards the on chip termination
of the FPGA not being quite right. 
Does anyone have any experience with Virtex-5 on-chip lvds
termination? Is there anything we can do to play with the value of the
termination resistor? I'm assuming these are calibrated termination
resistors, so maybe we can get some access to the calibration
circuitry and see if we can find a value which works better for us?
Obviously turning of the diff_term makes the result significantly
worse so it maybe just that the value is not right at a high speed
chip for some reason. I'd appreciate any comments/suggestions.

Thanks.

Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com

Article: 139315
Subject: Re: R/A FX2 connectors for S3A board - anyone have a couple spare?
From: ales.gorkic@gmail.com
Date: Thu, 26 Mar 2009 01:55:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 20, 11:42=A0am, Mike Harrison <m...@whitewing.co.uk> wrote:
> I wonder if anyone happens to have a couple of the right-angled version o=
f the FX2 connector to mate
> with the expansion connector on the XIlinx S3A board ( or knows someone w=
ho stocks them for small
> qty buyers)
> The Hirose part no. is FX2-100S-1.27DS
> Digikey only stock the straight version =A0(-DSA)
> m...@whitewing.co.uk

No problem, you can get it here.
http://shop.trenz-electronic.de/catalog/default.php?cPath=3D1_47&osCsid=3D2=
368cf69f86a355cb79cc15c694c2711
You can buy PCB or flat cable option.

Cheers,

Ales

Article: 139316
Subject: Re: FPGAs in automotive apps
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Thu, 26 Mar 2009 09:07:43 +0000
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> writes:

>
> You miss the point.  Flash micros are in production products because
> there is very little price differential with metal layer ROM devices.
> Otherwise the ROM parts would "abound" in high volume products.
>

Yes.  That wasn't always the case.  Things develop.

>
>> By the time these driver assistance features are on the *really*
>> high-volume vehicles FPGAs will be even cheaper than they are now.
>
> Yes, and the bean counters at every company will be beating you
> mercilessly to cut every penny from the cost.  When you are facing the
> loss of a $10M contract because you need to cut the cost by another
> $1, the decision will be made to go with an ASIC.  How else are you
> going to cut the cost of this product otherwise?
>
> You can say you "know what you are doing", but the economics are what
> they are.  If your company sells a high volume product using an FPGA
> instead of an ASIC, when you don't need reconfigurability, you are
> leaving money on the table.  Not many CEOs like that idea.
>
> Is there some rational for not designing an ASIC for a high volume
> product that is out of development and meets all specs?  Don't tell me
> you are doing it, tell me *why* you are doing it.  Companies make
> mistakes all the time.  I would like to know the reason for this
> decision or if it is just a temporary choice and will change as the
> volumes increase.
>

I think KJ wrote quite nicely why I'm not going to explain all that in
a public forum - sorry!  (And I don't do the lottery, so that's not
likely to change :)

Cheers,
Martin

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

Article: 139317
Subject: Re: virtex-5 lvds termination issue?
From: Sean Durkin <news_MONTH@tuxroot.de>
Date: Thu, 26 Mar 2009 10:55:53 +0100
Links: << >>  << T >>  << A >>
Muzaffer Kal wrote:
> Does anyone have any experience with Virtex-5 on-chip lvds
> termination? Is there anything we can do to play with the value of the
> termination resistor? I'm assuming these are calibrated termination
> resistors, so maybe we can get some access to the calibration
> circuitry and see if we can find a value which works better for us?
> Obviously turning of the diff_term makes the result significantly
> worse so it maybe just that the value is not right at a high speed
> chip for some reason. I'd appreciate any comments/suggestions.

Not sure if this helps you any, but I had a similar problem with Virtex4.
As it turns out, the differential termination givs you 100 Ohms only if
the VCCO of the bank the IO is in is 2.5V, anything else will give you
"unspecified" values for the termination. That I overlooked designing
the board, because I figured the LVDS input buffers are powered by
VCCAUX, which is 2.5V in all cases, so it doesn't really matter what
VCCO is.

You can put LVDS inputs in all banks regardless of their VCCO, but the
differential termination will then be off. When I was designing the
board, this was a footnote in some table in the data sheet, in the
meantime it's been moved to the text somewhere.

Don't know if it's still the same in Virtex5.

HTH,
Sean

-- 
Replace MONTH with the three-letter-abbreviation for the current
month. Simple, eh?

Article: 139318
Subject: Re: virtex-5 lvds termination issue?
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 26 Mar 2009 11:15:41 -0000
Links: << >>  << T >>  << A >>
Which ADC?
Sampling rate?
How did you probe the signals with your DSO?
What DSO?
What 'scope probe?
In what way did the captured data change?
How did you change the FPGA sampling points?

Syms. 



Article: 139319
Subject: Re: FPGAs in automotive apps
From: whygee <whygee@yg.yg>
Date: Thu, 26 Mar 2009 14:24:41 +0100
Links: << >>  << T >>  << A >>
Hello,

I think that KJ has some valid points, though
they could be stated more clearly.
I'm not in the automotive branch but I know that today,
automakers don't want stock, they work with very short
supplies to reduce costs and risks.

Hence auto parts makers don't work with a visibility
of more than months, sometimes weeks,
and volumes below the 10K units range.
Too low and short for ASICs,
a fundry needs 6 to 12 weeks at the very least.


Furthermore, what if a critical element has a bug
that causes accidents ? Does the part maker remakes
masks, then makes new PCBs for the chip ? No.
Recall all the driving units in auto repair shops,
plug a probe on the FPGA and that's all.
It does not make a big difference, which in fact makes
a big difference for the parts maker that
won't have to finance and build new PCB modules wich contains
more than a single $2 chip on it.

rickman wrote:
> My "opinions" are factual as far as I can tell.  Perhaps we have not
> explored all the details, but the economics are clear.
but incomplete, you only accounted for 1 part of a larger assembly.
and in cars, ASICs are not socketed...

> Unless the cost is nearly zero, as is the case of having your FPGA
> vendor provide you with an ASIC based on the FPGA bit file.  If you
> buy a minimum quantity, they will not charge NRE at all.  Your only
> expense is in discussing this with your management and getting a
> signoff.  So if you are talking about a product in *high volume*
> production, the trade off is trivial.
however, high volume is not the norm anymore, as this means huge stocks
and investments that nobody wants to do anymore. And with the current
crisis, no accountant will hear your argument : they will prefer to pay
a bit more per unit, just to not have to buy huge quantities of stuff that they
have no assurance to resell to the automaker...
And by the time you have sold the last ASICs of your stock,
your product is already in rev.2 or 3.

IMHO the problem is not FPGA but ASICs :
too slow to build, too expensive and too large volumes
for today's markets, despite technical advantages.

> The FPGA companies have explored pretty
> much every single one and have shouted them from the rooftops.
And I recently heard Actel claiming success (?) in the automotive branch.
I leave the marketspeech analysis as an exercise,
BUT the fact is that they have (some) happy clients.

>  But few auto products ever need upgraded hardware.
Now think about the Pentium FDIV bug in your brake or injection system.
Think accidents, lawsuits, huge costs for recalling all the cars
and changing the critical element.
Given the complexity and stakes, I believe that the decision
to use FPGA in certain places is not stupid for some bosses.
If the dev team ever tell the CEO that there is this option
(which does not necessarily happens).

> It just does not make sense to leave money laying on the
> table.  No CEO would do that.
The CEO may have constraints that you don't know, like time,
availability, projected and actual shipped quantities, whatever...
It depends on a many more parameters than only the unit price
in huge quantities.

regards,

> Rick
yg

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

Article: 139320
Subject: Re: FPGA users, Please take a few seconds to report SPAM
From: VAX9000@gmail.com
Date: Thu, 26 Mar 2009 07:08:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 20, 7:14=A0pm, James Harris <james.harri...@googlemail.com>
wrote:
> I have been reportingspamon other groups and, after a long time, the
> senders Google accounts were removed. I think it took about four to
> eight weeks. I send this to reassure that they do seem to take notice
> eventually but patience is required.

As of today, it seems Google is taking action. The board is much
cleaner now.

>
> James


Article: 139321
Subject: Re: virtex-5 lvds termination issue?
From: Muzaffer Kal <kal@dspia.com>
Date: Thu, 26 Mar 2009 07:22:35 -0700
Links: << >>  << T >>  << A >>
On Thu, 26 Mar 2009 11:15:41 -0000, "Symon" <symon_brewer@hotmail.com>
wrote:

>Which ADC?
>Sampling rate?
>How did you probe the signals with your DSO?
>What DSO?
>What 'scope probe?
>In what way did the captured data change?
>How did you change the FPGA sampling points?
>
>Syms. 
>
I'm using an AD9480 at 250 MHz supplied by V5 using an LVPECL output.
For my purposes the quality of the output clock from the fpga is
adequate. The DSO is an Agilent rental with a whole set of probes and
I looked at the ADC outputs with both a single ended probe and an
active differential probe with 91 ohm termination. 
The data I observed on the board has significant over/undershoots and
the captured data shows the same. I'm using a slew controlled pulse
driver at the input (coming differentially through a transformer) of
the ADC and I'm seeing bumps and dips in the captured data at the
locations where there are over/undershoots on the line as expected.
In the fpga I have a PLL which receives the clock output from the ADC
and generates clock for my internal logic. I generated another output
from the PLL which has 4 swept phases (ie 0, pi/2, pi and 3pi/2
delays) from the incoming clock and used it to capture the incoming
data. If it were a sampling time issue, one of the phases would be
good to sample.

Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com

Article: 139322
Subject: Re: Fm digital baseband demodulation
From: "RCIngham" <robert.ingham@gmail.com>
Date: Thu, 26 Mar 2009 09:41:42 -0500
Links: << >>  << T >>  << A >>
>Hi
>I am a final year engineering student. 

>2.Does the differentiation in digital domain means difference between
>two consecutive samples?


You ought to ask for your Course fees back if you don't know that one!


Article: 139323
Subject: Re: some nibz decoding ?
From: Jacko <jackokring@gmail.com>
Date: Thu, 26 Mar 2009 07:47:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
> Wow ! Very interesting. I supose when you've been
> doing it for a few hundred hours, it's natural, but
> I think the 'primitive instruction routeing' to acheive
> the subroutine goal, would make a nice exercise for
> an AI utility. =A0It maps directly to various AI techniques.
> ----------
> Rather than search for Rick's verbatum crit., I'll try
> to paraphrase my understanding of it, and add my
> own [perhaps wrong] understanding:
> 1. nibz instruction's are inefficient because
> * you have to have 20-bit wide to get 64K adr-space.
> =A0 =A0 AdrSpace =3D 2^ (wordWidth - 4).
> =A0 =A0And that's 64K 20bit-words. =A0 =A0
> * and then since there are only 16 primitives, these
> use only 4 of the 16 bits.

No 16 bit wide =3D 16 bit (the first 16 locations can not be used to
store subrotines, as the code addresses are the basic instructions)

> I wonder what the typical ratio is of primitives to
> subroutines + literals =A0?

As programs grow the ratio of sub/lit to primitive gets larger in
favour of sub/lit code.

> The 16 primitives almost sound as if they are at
> a lower-level in microcoding, but apparently not ?

They are simple enough to be microcode, but can be used in any code.

> 2. The common optimisation of small literals is not
> possible.
>
> Well, the common inc(tos) and dec(tos) [I don't
> know the forth words off-hand] would be subroutines,
> and as Jacko writes, any literals which appear in the
> code more than once, are just all fetched from the
> same memory location, using 2 words of code.
> [These are memory-size 'words' =A0NOT 'forth words'.]
>
> And then could you optimise for space with less speed,
> from: [literal] [pointer to the value] =3D 2 words
> =A0 =A0 =A0 to
> [subroutine of literal of value] =3D 1 word;
> where, again 'the value' is in memory to be accessed
> in multiple sections of the code, by the same subroutine ?
> --------------
> Since Jacko made the common/natural mistake of
> 'branching off' to mention optimisation issues, while
> describing the basics of eg. the instruction set, IMO
> it's naiive to think that he hasn't already considered
> all the 'problems' that Rick has raised.
> Let's play the ball, not the player ?
>
> Yes, this is a time-sink, but I want to go on to see
> if I can 'decode' the SD-driver info in the wiki.
>
> Without deep though on it yet, the ability to have
> the same code for different word, memory sizes
> seems to have great merit - Java-ish ?
>
> BTW, how are such fpgaS for power consumption
> compared to eg. an ARM ?
> Does anybody think that ePaper will ever be viable ?

Some of the cpld/fpga have a very low power figure, I have no figures
for the ARM, but nibz is small and hence in full ASIC would have a
very low stanby current, and possibly even a lower dynamic operation
current (using on chip RAM), per effective code executed. Although
this depends heavily on the clock speed and ratio of static to dynamic
signal lines averaged over many cycles.

FPGA versions of the ARM are available at quite a high cost and logic
area.

Epaper is closest to OLED displays at present, in terms of print
technology. Epapers main problem would be printing a uniform substrate
layer, and developing soluable semiconductor inks which set an dry to
a controlled thickness for gate oxide layers, for suitable FET/CMOS
voltage.

cheers jacko

Article: 139324
Subject: Re: virtex-5 lvds termination issue?
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 26 Mar 2009 14:48:46 -0000
Links: << >>  << T >>  << A >>
"Muzaffer Kal" <kal@dspia.com> wrote in message 
news:pe3ns4djft0dbsniu2223snu8cmfisc04j@4ax.com...

> I'm using an AD9480 at 250 MHz supplied by V5 using an LVPECL output.
> For my purposes the quality of the output clock from the fpga is
> adequate. The DSO is an Agilent rental with a whole set of probes and
> I looked at the ADC outputs with both a single ended probe and an
> active differential probe with 91 ohm termination.
> The data I observed on the board has significant over/undershoots and
> the captured data shows the same. I'm using a slew controlled pulse
> driver at the input (coming differentially through a transformer) of
> the ADC and I'm seeing bumps and dips in the captured data at the
> locations where there are over/undershoots on the line as expected.
> In the fpga I have a PLL which receives the clock output from the ADC
> and generates clock for my internal logic. I generated another output
> from the PLL which has 4 swept phases (ie 0, pi/2, pi and 3pi/2
> delays) from the incoming clock and used it to capture the incoming
> data. If it were a sampling time issue, one of the phases would be
> good to sample.
>
The ADC has high impedance current source outputs, so the LVDS termination 
in the FPGA is important. However, I've always found the DIFF_TERM to be 
just fine. Is your ADC close to the FPGA?

I can't quite work out from your posts what you are looking at with the DSO. 
Sometimes it seems you are referring to the analog input signal, and other 
times the LVDS signals from the ADC to the FPGA. Perhaps you can clarify 
that. FWIW it's very hard to probe high speed LVDS differential signals. 
Looking at the source pins won't give a nice 'scope picture. Much better is 
to use a simulator like HyperLynx to work out what's going on.
Are you saying that the overshoots you see on the LVDS lines are somehow 
being coupled to the analog signal? I hope you haven't split your ground 
plane into analog and digital sections.

HTH, Syms. 





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