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
hi, rickman wrote: > I would guess that they picked the LUT6 rather than a LUT5 because it > allows a 4:1 mux with no wasted inputs. I'm not sure that it is "the" reason but it certainly counts. > Muxes are real LUT eaters in many designs, including CPUs. I agree. It's one of my main issues ... Well, there were no MUX issues in the antifuse-based Actel families :-) I once used the A1020 that is based on a 4-MUX structure, it was fun but the other functions were not as easy... > Rick yg -- http://ygdes.com / http://yasep.orgArticle: 139426
On Mar 28, 3:27=A0pm, Kolja <ksuli...@googlemail.com> wrote: > On 28 Mrz., 06:45, "Antti.Luk...@googlemail.com" > > <Antti.Luk...@googlemail.com> wrote: > > =A0if I use MicroBlaze(tm) > > Last time I checked there was no registered "microblaze" trademark. > Neither in > the US nor in Germany. > And if there was, it would only prevent you from calling your product > "Microblaze". > You could still be 100% compatible. > > > clone on Altera, Lattice > > then I suppose it may get unwanted attention, or if not it will get > > absolute nil support from the vendors where soft-core marketed > > by direct competitor is used. > > The Microblaze clone is not marketed by Xilinx but by open cores. > > ISAs can't be protected and the simple single issue implementations > hardly use anything that has been patented in the last 25 years. > > > > regarding i8080 clones, I assume that neither Xilinx, Altera, Lattice= , > > et others > > would not mind, as Intel is not FPGA vendor. > > and i do not think intel would send C&D either > > And if they to ignore it. Any patents covering 8080 are long expired > and > copyright law does not apply (as long as you did not copy any HDL or > schematics from them) > > Please everybody: Don't believe the FUD of the vendors. > They try to spread incorrect views on the legal situation. > > And if I should ever get a C&D from Xilinx I would immediately answer > with a > C&D regarding the incorrect use of the GPL in the ISE distribution. > Well that is a major copyrigh violation on their side. > > As a side note to extend you list: > What about LEON and the other open source versions of SPARC? > Did not SUN open source their design? > And doesn't openRISC have C-Compiler support? > > Have fun, > > Kolja Kolja good comments eh when Altera asked me to stop offering NIOX (clean room NIOS-II core) i just did what they asked. It was not yet legal C&D thing, very polite well it wonder me a lot why they bothered? NIOS-I open source codes exist and Altera doesnt mind that. Why did they wanted NIOX off? as of LEON and openrisc - sure they are on the list if LARGE CORES are included, well I seem to be VERY biased agains openrisc and see now reason why use it and not LEON3 if the resource usage allows. well, actually smallest LEON soc can fit spartan3-400 what so maybe I should really increase the small-large trip margin for 32 bit cores eh need run some more synthesis for more comparison data AnttiArticle: 139427
On a sunny day (Sat, 28 Mar 2009 17:38:50 -0700) it happened Joerg <notthisjoergsch@removethispacbell.net> wrote in <Dqzzl.27297$ZP4.3376@nlpi067.nbdc.sbc.com>: >> How are you going to get an edge on your competition unless you use >> stuff that they don't know? >> > >Oh, I do a lot of unorthodox stuff. Using 74HCU or CD4000 in analog >circuits, switcher FETs in servos, RF parts for digital functions and so >on. I am just curious what can be done with an FPGA in that respect. Although I am by no means an FPGA expert, I have done some funny things with my Spartan 2 FPGA board. For example did video out with a simple R2R network connected to some output pins (8 bits), video conversion from 50Hz V and 15625Hz H to 50Hz V and 31250Hz H, for display on a VGA monitor, (with an ADC for input), and similar stuff. Of course using a real DAC (I have now) is much better. Simple pulse things, like John does in that example to charge an integrator, work, but analog is not the field for FPGAs, the 'right' way is to digitise, process digitally, and then convert to analog again. Like for filters, for example a nice lowpass in Verilog for video is only a few lines of code, etc. It seems Altera has a _lot_ of real nice video stuff, compete codecs, etc. For sure I would go Altera if I needed something like that for video again. Also Xilinx stuff is either not there, and cannot be bought from their online shop (at least it was that way a while ago). >A long time ago I was looking into using the old Intel CPLD series that >way because of they microamp capabilities. Boy was I glad I didn't, >shortly after they ditched the whole line. Thing is, most of my designs >are targeted for more than a decade in production. And no trimpots or >calibration allowed unless that can be automated. That is the nice thing about digital processing, no trimmers, no tolerances, no monte carlos. You may want an FPGA with onboard flash.. Just make sure you can actually get the chips from several sources, watch the price too. The Altera soft runs in MS windows and in Linux in Wine. The Xilinx stuff has a Linux version that also works, and the tools have a command line interface that can be used from a script, Packages are small, you need a development (or more then one) board for each FPGA. And learning a HDL, Verilog or VHDL, or both, will take a lot of your time. That needs to be calculated in too.Article: 139428
glen herrmannsfeldt wrote: > In comp.arch.fpga Joerg <notthisjoergsch@removethispacbell.net> wrote: > >> Oh, I do a lot of unorthodox stuff. Using 74HCU or CD4000 in analog >> circuits, switcher FETs in servos, RF parts for digital functions and so >> on. I am just curious what can be done with an FPGA in that respect. > > I once knew someone who built an FM radio transmitter > using a 74S04 as the output stage. I suppose > cheaper than RF transistors at the time. > If this was 20 or more years ago, yes, RF power transistors that could be used above 50MHz were painfully expensive. So I just used tubes. -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.Article: 139429
Jan Panteltje wrote: [...] > That is the nice thing about digital processing, no trimmers, no tolerances, > no monte carlos. Don't need Monte Carlo, there's an Indian gambling place down the road but I don't gamble anyhow. Oh, wait ... > You may want an FPGA with onboard flash.. Flash? That's frowned upon as morally indecent in the more conservative regions out here :-) > Just make sure you can actually get the chips from several sources, watch > the price too. ... That's the two main problems. FPGA are usually all single-sourced (having several distributors doesn't count) and expensive. Seen too many purchasing nightmares there. [...] -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.Article: 139430
On Sun, 29 Mar 2009 14:38:26 -0700, Joerg <notthisjoergsch@removethispacbell.net> wrote: >Jan Panteltje wrote: > >[...] > >> That is the nice thing about digital processing, no trimmers, no tolerances, >> no monte carlos. > > >Don't need Monte Carlo, there's an Indian gambling place down the road >but I don't gamble anyhow. > >Oh, wait ... > > >> You may want an FPGA with onboard flash.. > > >Flash? That's frowned upon as morally indecent in the more conservative >regions out here :-) > > >> Just make sure you can actually get the chips from several sources, watch >> the price too. ... > > >That's the two main problems. FPGA are usually all single-sourced >(having several distributors doesn't count) and expensive. Seen too many >purchasing nightmares there. Technically single-sourced, yes. As long as you stay away from the quirks (LVDS performance can be considered a "quirk" ;), unique features, and IP cores, they're pretty easy to substitute. The costs have come *way* down, as well. $5-$20 buys a lot of logic these days.Article: 139431
I am newbie in using FPGA and while using spartan3E starter kit I have two doubts. 1.I am making a simple ADC to DAC system using on board ADC and DAC chips.Do I have to provide 3.3 volt( for creating reference voltage) to header J5 through external power supply, or does the board has its our circuitry to provide that internally(from its own power)?I think same will go for GND too. 2.I have to store samples coming from ADC ,store in memory and do processing on them.what will be of better use, FIFO or RAM?and how much memory is available,because it seems I must obtain more than 1 Mega samples per cycle for my purpose.Article: 139432
Hi everyone, I'm currently working on a project which involves a Virtex 5 board with USB port (and Cypress FX2 MicroController). My goal is to connect a webcam to the FPGA board and process that input data with an algorithm which should detect movement (a simple one). From the forums I found on the web I understood that this is not an easy task - connecting the webcam to the FPGA and processing the video signal - and I'm now searching for any relevant information regarding this. I'm using an UVC (USB Video Class) compatible webcam, and I have the documentation for this from usb.org, but still can't figure out exactly how the video signal is transmitted (how do you initialize the webcam, how does the host ask for data, and how is the received data structured). By the way, I'm working in verilog. Is there any link/documentation or example which could possibly help me? Thank you in advance, ChrisArticle: 139433
krw wrote: > On Sun, 29 Mar 2009 14:38:26 -0700, Joerg > <notthisjoergsch@removethispacbell.net> wrote: > >> Jan Panteltje wrote: >> >> [...] >> >>> That is the nice thing about digital processing, no trimmers, no tolerances, >>> no monte carlos. >> >> Don't need Monte Carlo, there's an Indian gambling place down the road >> but I don't gamble anyhow. >> >> Oh, wait ... >> >> >>> You may want an FPGA with onboard flash.. >> >> Flash? That's frowned upon as morally indecent in the more conservative >> regions out here :-) >> >> >>> Just make sure you can actually get the chips from several sources, watch >>> the price too. ... >> >> That's the two main problems. FPGA are usually all single-sourced >> (having several distributors doesn't count) and expensive. Seen too many >> purchasing nightmares there. > > Technically single-sourced, yes. As long as you stay away from the > quirks (LVDS performance can be considered a "quirk" ;), unique > features, and IP cores, they're pretty easy to substitute. The costs > have come *way* down, as well. $5-$20 buys a lot of logic these days. That's true, but a lot of times my whole design including board and assembly can't cost nearly as much as that (in large quantities). -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.Article: 139434
On Sun, 29 Mar 2009 02:39:04 +0100, "Symon" <symon_brewer@hotmail.com> wrote: > >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >news:s8cts4d6jcmvbk2tu3cd3tua362o6gtde7@4ax.com... >> >> We did some playing with FPGA-based PLLs. The classic charge-pump PDs >> didn't work very well. This works... >> >> >> fpga_up------ak----R-----+-------opamp >> | >> | >> | >> fpga_dn------ka----R-----+ >> >> >> where AK and KA are schottky diodes feeding an opamp integrator (P+I >> control) thing, and the up/down things pulse in the obvious >> polarities. The fpga outputs are hard and fast, not tri-state, and >> overlap a good bit. No deadband, fast as all getout, low phase noise. >> >> John >> >Even better is :- > > V+ > | > R > | >fpga_up------ka----ak-----+-------opamp > | > | > | >fpga_dn------ak----ka-----+ > | > R > | > 0V > >Syms. > > Why is that better? Loop gain and tempco are about the same, and you've slowed down the drive edges by adding unnecessary hi-Z nodes. And added a bit of power dissipation. And more parts. Grrrrr. JohnArticle: 139435
On Mar 27, 10:45=A0pm, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > YARI, hm i am interested too, if even the caches could be disabled > it maybe small enough Getting rid of the D$ is easy, but running without at least a minimal directly mapped I$ hardly makes sense (you'd be limited by the external memory bandwidth). You don't have _any_ memory blocks at all? The register file requires two 32x32 dual port memory blocks. If you know you don't need certain instructions like div, rem, mul, etc, you can save lots of LEs. TommyArticle: 139436
On Mar 27, 11:24 pm, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > the goal is to find best CPU for minimal SoC that should be > possible to fit to widest possible selection of FPGA's thats > why the huge ones are not listed. L8080 fits into smaller > end of FPGAs where 32 bit Cores do no longer fit. Also > some smaller FPGAs may have too small BRAM so > the 32 bit CPUs would just have too small instruction memory > for the C compiler to be useable at all. I guess I should have read this part before replying. Can you site the memory and LE/LC budget? Will there be external memory? It's trivial to make YARI run entirely out of BRAM (and get rid of the tags and the associativity), but MIPS-I obviously isn't the most compact ISA. If I was obsessed with space, I would take b16 as a starting point, work it until it would be feasible to write a compiler for, and then do that, but I think I'd rather stab myself in the eye with a chop stick. FPGA are getting bigger & cheaper at a faster rate than I can write compiler backends. The very smallest Spartan 6 has 3,400 LC and 32 Kib + 144 Kib of memory. I suspect these minimal core will be less appealing as time progresses. IMHO TommyArticle: 139437
On Mar 30, 12:40=A0pm, Tommy Thorn <tommy.th...@gmail.com> wrote: > > If you know you don't need certain instructions like div, rem, mul, > etc, you can save lots of LEs. Being 100% sure is not easy, but I have wondered about Cores that trap such opcodes, and vector to a library call ?. They could also include a simple sticky-bit hardware flag, so you can check if you are actually needing those opcodes. -jgArticle: 139438
[Self-follow up is bad form, I know ...] A 10 min experiment to change YARI to an MCU configuration (Harvard style split instruction and data memory, and delete multiply and divide support) slimmed it down to 2,700 LE on an Altera EP1C12. I suspect it would be easy to get it down < 2,400 LE. Note, size was never a priority in the original design. TommyArticle: 139439
On Mar 29, 6:15=A0pm, -jg <Jim.Granvi...@gmail.com> wrote: > Being 100% sure is not easy, but I have wondered about Cores that trap > such opcodes, and vector to a library call ?. They could also include > a simple sticky-bit hardware flag, so you can check if you are > actually needing those opcodes. That would be trivially easy to add. Also, if the FPGA has a hardware multiplier (most these days), the multiply really doesn't cost that much. Deleting more dead code got it down to 1,960 LC (caveat, I haven't _tested_ it). TommyArticle: 139440
On Sun, 29 Mar 2009 17:02:47 -0700, Joerg <notthisjoergsch@removethispacbell.net> wrote: >krw wrote: >> On Sun, 29 Mar 2009 14:38:26 -0700, Joerg >> <notthisjoergsch@removethispacbell.net> wrote: >> >>> Jan Panteltje wrote: >>> >>> [...] >>> >>>> That is the nice thing about digital processing, no trimmers, no tolerances, >>>> no monte carlos. >>> >>> Don't need Monte Carlo, there's an Indian gambling place down the road >>> but I don't gamble anyhow. >>> >>> Oh, wait ... >>> >>> >>>> You may want an FPGA with onboard flash.. >>> >>> Flash? That's frowned upon as morally indecent in the more conservative >>> regions out here :-) >>> >>> >>>> Just make sure you can actually get the chips from several sources, watch >>>> the price too. ... >>> >>> That's the two main problems. FPGA are usually all single-sourced >>> (having several distributors doesn't count) and expensive. Seen too many >>> purchasing nightmares there. >> >> Technically single-sourced, yes. As long as you stay away from the >> quirks (LVDS performance can be considered a "quirk" ;), unique >> features, and IP cores, they're pretty easy to substitute. The costs >> have come *way* down, as well. $5-$20 buys a lot of logic these days. > > >That's true, but a lot of times my whole design including board and >assembly can't cost nearly as much as that (in large quantities). No, FPGAs aren't the right answer for every question but you're not going to buy that function, or anything near it, for less. We have a pile of crap logic that I'd *love* to sweep into a FPGA. It would save a lot of money and grief. If I was convinced I could do a decent delta sigma modulator I'd do even more.Article: 139441
On Sun, 29 Mar 2009 21:00:48 -0500, krw <krw@att.bizzzzzzzzzzz> wrote: >On Sun, 29 Mar 2009 17:02:47 -0700, Joerg ><notthisjoergsch@removethispacbell.net> wrote: > >>krw wrote: >>> On Sun, 29 Mar 2009 14:38:26 -0700, Joerg >>> <notthisjoergsch@removethispacbell.net> wrote: >>> >>>> Jan Panteltje wrote: >>>> >>>> [...] >>>> >>>>> That is the nice thing about digital processing, no trimmers, no tolerances, >>>>> no monte carlos. >>>> >>>> Don't need Monte Carlo, there's an Indian gambling place down the road >>>> but I don't gamble anyhow. >>>> >>>> Oh, wait ... >>>> >>>> >>>>> You may want an FPGA with onboard flash.. >>>> >>>> Flash? That's frowned upon as morally indecent in the more conservative >>>> regions out here :-) >>>> >>>> >>>>> Just make sure you can actually get the chips from several sources, watch >>>>> the price too. ... >>>> >>>> That's the two main problems. FPGA are usually all single-sourced >>>> (having several distributors doesn't count) and expensive. Seen too many >>>> purchasing nightmares there. >>> >>> Technically single-sourced, yes. As long as you stay away from the >>> quirks (LVDS performance can be considered a "quirk" ;), unique >>> features, and IP cores, they're pretty easy to substitute. The costs >>> have come *way* down, as well. $5-$20 buys a lot of logic these days. >> >> >>That's true, but a lot of times my whole design including board and >>assembly can't cost nearly as much as that (in large quantities). > >No, FPGAs aren't the right answer for every question but you're not >going to buy that function, or anything near it, for less. We have a >pile of crap logic that I'd *love* to sweep into a FPGA. It would >save a lot of money and grief. If I was convinced I could do a decent >delta sigma modulator I'd do even more. D-S dacs work just fine in FPGAs. They're especially handy for slow trims, like dc offset, vcxo freq, stuff like that. One FPGA pin and one external RC makes a pretty good dac. JohnArticle: 139442
Hi, I am working on a project on two different computers that have different installation paths for Altera software. The system originally developed on one machine, when copied, new include paths added, cannot find header files. Somehow, the directories are not being properly searched in Eclipse. A file has: #include "myheaderfile.h" where myheaderfile.h is in the directory that is listed under the includes. To add the path, I use Project->Properties->C/C++ include paths...->Add external include path... I have cleaned and re-built the project. Please let me know what I could be missing. Thank youArticle: 139443
Hello, I have built an Application Note for newbies (& students !) who want to understand and implement RS232 (UART) in an FPGA. Especially when it's an assignement, they should follow this document instead of asking for the UART code (which I give away only in the context of larger educational projects). I have also built a nice (I think) Tutorial to implement and test a simple UART in the new Igloo nano Kit (49 $!), complete with all steps from installing the (free) development software to building the design, programming the kit and testing the RS232 on a PC. These are available at : http://www.alse-fr.com/UART/ALSE_RS232.pdf http://www.alse-fr.com/Actel/ALSE_Igloo_nano.exe As I state in this document, do not expect tech support for free stuff, though I welcome useful remarks and suggestions. Hope it helps (and will reduce the amount of requests for the UART), Bert Cuzeau CTO ALSE (can be reached at info@ the website in the links above)Article: 139444
On Sun, 29 Mar 2009 19:12:58 -0700, John Larkin wrote: > On Sun, 29 Mar 2009 21:00:48 -0500, krw <krw@att.bizzzzzzzzzzz> wrote: > >>On Sun, 29 Mar 2009 17:02:47 -0700, Joerg >><notthisjoergsch@removethispacbell.net> wrote: >> >>>krw wrote: >>>> On Sun, 29 Mar 2009 14:38:26 -0700, Joerg >>>> <notthisjoergsch@removethispacbell.net> wrote: >>>> >>>>> Jan Panteltje wrote: >>>>> >>>>> [...] >>>>> >>>>>> That is the nice thing about digital processing, no trimmers, no >>>>>> tolerances, no monte carlos. >>>>> >>>>> Don't need Monte Carlo, there's an Indian gambling place down the >>>>> road but I don't gamble anyhow. >>>>> >>>>> Oh, wait ... >>>>> >>>>> >>>>>> You may want an FPGA with onboard flash.. >>>>> >>>>> Flash? That's frowned upon as morally indecent in the more >>>>> conservative regions out here :-) >>>>> >>>>> >>>>>> Just make sure you can actually get the chips from several sources, >>>>>> watch the price too. ... >>>>> >>>>> That's the two main problems. FPGA are usually all single-sourced >>>>> (having several distributors doesn't count) and expensive. Seen too >>>>> many purchasing nightmares there. >>>> >>>> Technically single-sourced, yes. As long as you stay away from the >>>> quirks (LVDS performance can be considered a "quirk" ;), unique >>>> features, and IP cores, they're pretty easy to substitute. The costs >>>> have come *way* down, as well. $5-$20 buys a lot of logic these >>>> days. >>> >>> >>>That's true, but a lot of times my whole design including board and >>>assembly can't cost nearly as much as that (in large quantities). >> >>No, FPGAs aren't the right answer for every question but you're not >>going to buy that function, or anything near it, for less. We have a >>pile of crap logic that I'd *love* to sweep into a FPGA. It would save >>a lot of money and grief. If I was convinced I could do a decent delta >>sigma modulator I'd do even more. > > D-S dacs work just fine in FPGAs. They're especially handy for slow > trims, like dc offset, vcxo freq, stuff like that. One FPGA pin and one > external RC makes a pretty good dac. > > John I've used external CMOS buffers to give a noise-free Voh for this application. FPGA outputs can have quite a lot of noise on them, coupled from other outputs on the same bank. (The numbers vary from family to family, etc.) Regards, AllanArticle: 139445
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:5330t4hf57cnve65p8gqm5civ8l5gecrni@4ax.com... > On Sun, 29 Mar 2009 02:39:04 +0100, "Symon" <symon_brewer@hotmail.com> > wrote: > >> >>"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in >>message >>news:s8cts4d6jcmvbk2tu3cd3tua362o6gtde7@4ax.com... >>> >>> We did some playing with FPGA-based PLLs. The classic charge-pump PDs >>> didn't work very well. This works... >>> >>> >>> fpga_up------ak----R-----+-------opamp >>> | >>> | >>> | >>> fpga_dn------ka----R-----+ >>> >>> >>> where AK and KA are schottky diodes feeding an opamp integrator (P+I >>> control) thing, and the up/down things pulse in the obvious >>> polarities. The fpga outputs are hard and fast, not tri-state, and >>> overlap a good bit. No deadband, fast as all getout, low phase noise. >>> >>> John >>> >>Even better is :- >> >> V+ >> | >> R >> | >>fpga_up------ka----ak-----+-------opamp >> | >> | >> | >>fpga_dn------ak----ka-----+ >> | >> R >> | >> 0V >> >>Syms. >> >> > > Why is that better? Loop gain and tempco are about the same, and > you've slowed down the drive edges by adding unnecessary hi-Z nodes. > And added a bit of power dissipation. And more parts. > > Grrrrr. > > John > John, Easy tiger! :-) I don't see any more 'hi-Z' nodes than the circuit you suggested. The circuit I posted has the same number of nodes as yours, unless you're counting power supply nodes? The drive edges are the same. It's better because the V+ signal doesn't have to have the noise of the FPGAs power supply on it. For sure with a type II phase detector this time is small when the PLL is locked, but it's there, nonetheless. Especially as you apparently specifically designed your phase detector to have a 'good bit' of overlap. But well done on the counting front. There are more parts. :-) Syms.Article: 139446
On Mar 20, 1:23=A0pm, Antti <Antti.Luk...@googlemail.com> wrote: > Hi > > I know this is too much to hope solution, but maybe.. > > the winter 2008 SBT tools seem to generate a multi boot header for > cold boot only (works ok) > > trying warm-boot with the same multiboot applet doesnt seem to work > however :( > > any help? > (yes i have submitted help request to SBT) > > Antti Ok confirmed WARMBOOT works too there doesnt seem to be a way to disable coldboot pins however so if the CBSELx are left connected and multiboot is enabled then image_3 is started at cold boot, what however isnt a problem as the start addresses can be assigned as needed (only the boot applet itself needs to be at addr 0) AnttiArticle: 139447
On 30 Mar 2009 09:48:25 GMT, Allan Herriman <allanherriman@hotmail.com> wrote: >On Sun, 29 Mar 2009 19:12:58 -0700, John Larkin wrote: > >> On Sun, 29 Mar 2009 21:00:48 -0500, krw <krw@att.bizzzzzzzzzzz> wrote: >> >>>On Sun, 29 Mar 2009 17:02:47 -0700, Joerg >>><notthisjoergsch@removethispacbell.net> wrote: >>> >>>>krw wrote: >>>>> On Sun, 29 Mar 2009 14:38:26 -0700, Joerg >>>>> <notthisjoergsch@removethispacbell.net> wrote: >>>>> >>>>>> Jan Panteltje wrote: >>>>>> >>>>>> [...] >>>>>> >>>>>>> That is the nice thing about digital processing, no trimmers, no >>>>>>> tolerances, no monte carlos. >>>>>> >>>>>> Don't need Monte Carlo, there's an Indian gambling place down the >>>>>> road but I don't gamble anyhow. >>>>>> >>>>>> Oh, wait ... >>>>>> >>>>>> >>>>>>> You may want an FPGA with onboard flash.. >>>>>> >>>>>> Flash? That's frowned upon as morally indecent in the more >>>>>> conservative regions out here :-) >>>>>> >>>>>> >>>>>>> Just make sure you can actually get the chips from several sources, >>>>>>> watch the price too. ... >>>>>> >>>>>> That's the two main problems. FPGA are usually all single-sourced >>>>>> (having several distributors doesn't count) and expensive. Seen too >>>>>> many purchasing nightmares there. >>>>> >>>>> Technically single-sourced, yes. As long as you stay away from the >>>>> quirks (LVDS performance can be considered a "quirk" ;), unique >>>>> features, and IP cores, they're pretty easy to substitute. The costs >>>>> have come *way* down, as well. $5-$20 buys a lot of logic these >>>>> days. >>>> >>>> >>>>That's true, but a lot of times my whole design including board and >>>>assembly can't cost nearly as much as that (in large quantities). >>> >>>No, FPGAs aren't the right answer for every question but you're not >>>going to buy that function, or anything near it, for less. We have a >>>pile of crap logic that I'd *love* to sweep into a FPGA. It would save >>>a lot of money and grief. If I was convinced I could do a decent delta >>>sigma modulator I'd do even more. >> >> D-S dacs work just fine in FPGAs. They're especially handy for slow >> trims, like dc offset, vcxo freq, stuff like that. One FPGA pin and one >> external RC makes a pretty good dac. >> >> John > >I've used external CMOS buffers to give a noise-free Voh for this >application. FPGA outputs can have quite a lot of noise on them, coupled >from other outputs on the same bank. (The numbers vary from family to >family, etc.) > >Regards, >Allan A delta-sigma dac needs a ton of lowpass filtering anyhow, so the only noise that matters is slow stuff on the +3.3 rail, which is usually easy to control. Most fpga's bank Vcc_out anyhow, so only the "dac bank" supply needs to be quiet at low frequencies. JohnArticle: 139448
Hi, I want to network multiple embedded processors using optical fiber as physical layer. This network is realised with point to point connections. At the moment, the network is established using RS232. To get higher data rates (around 100Mb/s) and better protection against EMI the electrical RS232 should be exchanged with optical data transfer. In order to realise this change, I'm searching for a technology similar to Fiber Channel (FC). The only, difficulty with FC is that the speed is too high, the slowest speed for fiber channel is 1Gb/s. Furthermore, fiber channels use sophisticated IO (Xilinx rocket IO) , for cost effectiveness I don't want to invest in these expensive IOs. I looked around on the net for some possible solutions, but fiber channel was the closest solution to my problem I could find. My question is therefore: Did I overlook something? Is there an IP-core or external chip which allows me to establish a 100Mb/s data communication link between two embedded processors using fiber optic. Thank you in advance for your help. Oliver FaustArticle: 139449
>On Sun, 29 Mar 2009 18:34:04 -0500, "dts4theworld" ><dts4theworld@gmail.com> wrote: > >>Hi everyone, >> >>I'm currently working on a project which involves a Virtex 5 board with >>USB port (and Cypress FX2 MicroController). >>My goal is to connect a webcam to the FPGA board and process that input >>data with an algorithm which should detect movement (a simple one). >> >>From the forums I found on the web I understood that this is not an easy >>task - connecting the webcam to the FPGA and processing the video signal - >>and I'm now searching for any relevant information regarding this. >> >>I'm using an UVC (USB Video Class) compatible webcam, and I have the >>documentation for this from usb.org, but still can't figure out exactly how >>the video signal is transmitted (how do you initialize the webcam, how does >>the host ask for data, and how is the received data structured). By the >>way, I'm working in verilog. >> >>Is there any link/documentation or example which could possibly help me? >> >>Thank you in advance, >>Chris >> > >This is a significant project as you have figured out. It is not >advisable to try to implement the UVC portion in hardware. My >suggestion would be to get the linux UVC stack and port the relevant >portions of it to a processor (soft-core or otherwise) implemented in >your fpga design. >Very simplistically, you need a host controller and a UVC driver to >talk to the webcam. When the webcam is attached, the host controller >sends it USB packets to enumerate the device to find what kind of >end-point(s) it supports and hand it off to the UVC stack for video >related packet processing. You really don't want to (re)do this in >hardware. Get a processor and port enough of linux UVC stack to it, >which is a significant task by itself but much smaller than doing all >of it yourself. >There is also the problem of convincing the fx2 to act as a usb host. >It's usually used in peripheral device implementations but it might be >possible to hack it to behave like a host in a limited way which >should be enough for your purposes. >-- >Muzaffer Kal > >DSPIA INC. >ASIC/FPGA Design Services >http://www.dspia.com > Dear Mr. Kal, Thank you very much for your input, such advice is just what I need right now. I'm trying now to figure out what I need to know in order to get some results. First off, I now need a processor design which can support this UVC driver (parts of it) - Can I use here an open-core design? The signal processing has to be hardware.. i'm not sure how to get these together. You advised me not to try a hardware implementation of the UVC.. but then wouldn't my driver need to control the signal processing part as well? About the FX2 - the manual sais it's no problem to run it as host. It's a Virtex 5-LX board from Avnet. Are there any alternatives which might allow me to skip the USB communication nightmare? I found some attempts to tap directly into the camera's signal coming from the image sensor. Would that be a good/feasible idea? I was also thinking if it would be easier to get the data from the webcam through the laptop, which would then feed the FPGA board through some other interface. Thank you, Chris
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