Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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 AnttiArticle: 139301
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
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, MikeArticle: 139303
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
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
"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. KJArticle: 139306
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? noArticle: 139307
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. RickArticle: 139308
"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 KJArticle: 139309
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: 139310On 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. RickArticle: 139311
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, /MHArticle: 139312
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
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. -jgArticle: 139314
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.comArticle: 139315
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, AlesArticle: 139316
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.htmlArticle: 139317
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
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
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.orgArticle: 139320
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. > > JamesArticle: 139321
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.comArticle: 139322
>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
> 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 jackoArticle: 139324
"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:
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