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 Tue, 16 May 2006 08:13:16 -0500, "Scope" <romaingoron@hotmail.fr> wrote: >I have a problem : I can't download files on the chip because Impact >doesn't recognize my cable. I am using the "Digilent JTAG3 low cost >parallel to JTAG cable" which is included with the starter kit. When I >launch a Cable autodetect on Impact, I have this message : >Connecting to cable (Parallel Port - LPT1). >Checking cable driver. > Driver windrvr6.sys version = 7.0.0.0.Cable connection failed. You say it's a parallel cable ... which parallel port is it on? Do you have any dongles (modules for software licence etc) on that parallel port? I am using Xilinx Parallel Cable 4, and it is not recognised by Impact if I also have the dongle for HDL Designer installed on the same port. So I have to unplug the dongle (and lose HDL Designer) when using the Xilinx PC4. Also, does this parallel cable have another power connection (e.g. to a mouse port) like the Xilinx PC4? That power connection is necessary. - BrianArticle: 102451
This is why I am going the Firewire route; I looked into USB webcams first and found that there is no standardization, unlike Firewire: http://staff.science.uva.nl/~fransve/literature/1394/IIDC_Spec_v1_30.pdf Perhaps Xilinx is working (or collaborating) on a Firewire core, Austin? TomArticle: 102452
the ARM license agreement that Actel has doesnt work at all for 'small guys' the ARM license fee per device is 1USD for qty 100,000 for smaller quantities it scales down. ARM enabled license fee (eg price for the pre-programmed encryption key!) for PA3 in qty <=10 is about 120USD it better than linear scale what would be 100,000 USD but its still ridicilous. But thats the way the ARM deal was made. to my knowledge Actel can not offer the ARM enabled devices in small quantity without the scaled license fee AnttiArticle: 102453
the problem has solved by adding a extra clock cycle between 4 and 5, but I still don't understand why that will work. Maybe need to wait longer for sending the byte. If someone know, please tell me. anyway, thanks Mike~!Article: 102454
Antti, The numbers for the LUT delay differences from the various inputs are not in the data sheet, but they are (and have been for years) in the speeds files used by the software, and are (and have been) thus also reported in any performance reports. Regarding the DSP columns, I do not know where you read the number 10 (please tell me so we can fix that mistake). Far more relevant is the number of such slices, and the max is 192 in the 5VLX330. Peter AlfkeArticle: 102455
>> Does any one have any software (or experience) to share (or sell) >> concerning bringing a USB2 camera image into a XILINX ML401, ML402, or >> ML403 board. >> > I looked into trying to get a USB camera working on the ML402. The > problem is that the ML40x boards are really designed to be USB > peripherals and not masters. The webcams all seem to have proprietary > interfaces (above the USB layer) and the only real way to use them is > with a Windows driver. No webcam manufacturers publish the specs on > talking to the camera. You might have better luck connecting to one of > the cameras with a standard interface. These are much more expensive > though. -Kevin If you can configure the ML402 to behave as a USB master, you can find lots of information regarding the webcam protocols in the Linux kernel sources. Many USB webcams are supported by the spca5xx or pwc drivers, and recent Logitech webcams (Fusion, Pro for Notebook, Pro 5000 and the latest Orbit/Sphere) are supported by the linux-uvc driver. Laurent PinchartArticle: 102456
ug193 page 13 "Virtex-5 family members have one, two, six, or ten DSP48E columns."Article: 102457
soar2morrow@yahoo.com wrote: >This is why I am going the Firewire route; I looked into USB webcams >first and found that there is no standardization, unlike Firewire: >http://staff.science.uva.nl/~fransve/literature/1394/IIDC_Spec_v1_30.pdf My impression of usb is 'toys'. This is esp for electrical if & overhead. >Perhaps Xilinx is working (or collaborating) on a Firewire core, Add a firewire PHY ..?Article: 102458
Antti, that's what happens when we release a family in several installments. As you can imagine, there will be an "SX" subfamily, and it will have more DSP columns, up to ten. Now you guys know one more deep secret... Peter AlfkeArticle: 102459
I did guess that actually. Well the logic in SX doesnt scale with the DSP columns, but still it will be heavy crunching engine :) AnttiArticle: 102460
BigWorm wrote: > Has anyone implemented DDR2 333Mhz (667Mbps) using Altera or Xilinx FPGA's? > > > Thanks For Xilinx, yes. Check out the following link for reference designs and the Memory Interface Generator (MIG) tool. DDR/DDR2 SDRAM http://www.xilinx.com/products/design_resources/mem_corner/resource/xaw_dram_ddr.htm -- Steve KnappArticle: 102461
> This is why I am going the Firewire route; I looked into USB webcams > first and found that there is no standardization, unlike Firewire: > > http://staff.science.uva.nl/~fransve/literature/1394/IIDC_Spec_v1_30.pdf http://www.usb.org/developers/devclass_docs/USB_Video_Class_1_1.zip Laurent PinchartArticle: 102462
We are currently planning on the V4 SX55, but really could use more speed, pins, MACs and less power. Looks like the speed increases slightly, possibly more with the rearranged MAC; the power is down, that's good; will there be an increase in the MACs and pins available? Any indication of a release date for samples? Marco ________________________ Marc Reinig UCO/Lick Observatory Laboratory for Adaptive OpticsArticle: 102463
Marc, not on a public newsgroup. Send me an e-mail for more details... peter@xilinx.comArticle: 102464
Marc, Please contact your local Xilinx FAE. You might be a good candidate for early access. Austin Marc Reinig wrote: > We are currently planning on the V4 SX55, but really could use more speed, > pins, MACs and less power. Looks like the speed increases slightly, > possibly more with the rearranged MAC; the power is down, that's good; will > there be an increase in the MACs and pins available? Any indication of a > release date for samples? > Marco > ________________________ > Marc Reinig > UCO/Lick Observatory > Laboratory for Adaptive Optics > >Article: 102465
On 2006-05-16, Ray Andraka <ray@andraka.com> wrote:
> Kevin Neilson wrote:
>
>>
>> That's pretty impressive. How did you implement the carry-kill chain,
>> or whatever they call the ciruit that finds the location of the leading
>> '1'? This can be made with a carry chain, but I don't know if it would
>> work with a 2.5ns period. -Kevin
>
> A clever use of DSP48 and BRAM blocks. The fabric carry chain
> definitely won't reach 400MHz, especially with 30 bits.
Im just curious on how many pipeline-stages/clock-cycles it takes for
one sample to be processed. And also how many of these pipeline-stages
does the normalization use.
\Per
Article: 102466Antti wrote: > the ARM license agreement that Actel has doesnt work at all for 'small > guys' > > the ARM license fee per device is 1USD for qty 100,000 for smaller > quantities it scales down. > > ARM enabled license fee (eg price for the pre-programmed encryption > key!) for PA3 in qty <=10 is about 120USD > it better than linear scale what would be 100,000 USD but its still > ridicilous. But thats the way the ARM deal was made. > to my knowledge Actel can not offer the ARM enabled devices in small > quantity without the scaled license fee Given these factors a) High cost of license b) high cost of the fabric to deploy the core why would _anyone_ design this into a system ? It seems like someone in marketing's idea, that never hit an engineering or accounting reality check.... There are surely, much better ways for Actel to approach SoftCPUs -jgArticle: 102467
Jim Granville wrote: > > Given these factors > a) High cost of license > b) high cost of the fabric to deploy the core > > why would _anyone_ design this into a system ? > > It seems like someone in marketing's idea, that never hit an > engineering or accounting reality check.... > > There are surely, much better ways for Actel to approach SoftCPUs to add some more examples : ... Such as this item, in todays news ? http://www.eeproductcenter.com/embedded/brief/showArticle.jhtml?articleID=187203441Article: 102468
I am not an expert in DCMs, but I think that multiplication factor times input frequency must not exceed the FPGAs maximum alowable frequency (about 200MHz for Spartan3). Cheers, GuruArticle: 102469
Well Actel is really trying only to fry the big fish only. They dont care about small players at all. PA3/Fusion with ARM in qty may make sense, but... well at those quantities it may as well be ASIC or that thing from ST that offers fixed ARM with user ASIC block. When actel announced the PA+ I immediatly obtained the kit, only to be disappointed, then waited for PA3 for 3 years to come?? And now waiting for Fusion kit, it was ordered DEC 2005 (from stock delivery promise), as of last info it may arrive in June/July. 2007 I hope AnttiArticle: 102470
And you're surprized that they're not giving away their design? Not to rain on your parade, but the typical FPGA engineer has spent a hundred bucks or so on the part, a grand or two on the PCB, and 1/2 a man-year on the code. $38 for a JTAG dongle is down in the noise. If it's hobby use you're after, you can stretch the JTAG signals off of your card to another target. There is an open-JTAG effort on SourceForge. You might want to check it out.Article: 102471
Hi everyone, For my design, which is implemented in Virtex-4 FX12 (speed grade -10) I need to get an adjustable (in operation) clock of frequency 30 to 66 MHz with the smallest possible increments. On the board I have 100MHz oscillator from which I tried to get 400 MHz (the higher the frequency the smaller the clock adjusting increments) using EDK 8.1's DCM (CLKFX 4/1). From this DCM I also power the PPC at 200MHz (CLK2X). I coupled the 400MHz clock to clock divider using rising edge as a process reference and an integer counter. This configuration does NOT work. The first problem is the frequency - EDK can compile my design if I lower the frequency to 200MHz, which is unaceptable. The other problem is a structure of my clock divider - if I make a process with rising edge detection the clock divider can only be even (clock is always divided by a factor of two!). How to build a fast dual edge (DDR) clock divider in VHDL? Is there any other way to solve my problem? Help wanted, GuruArticle: 102472
"Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com> wrote in message news:1147801070.929310.24500@i39g2000cwa.googlegroups.com... > > BigWorm wrote: >> Has anyone implemented DDR2 333Mhz (667Mbps) using Altera or Xilinx >> FPGA's? >> >> >> Thanks > > For Xilinx, yes. Check out the following link for reference designs > and the Memory Interface Generator (MIG) tool. > > DDR/DDR2 SDRAM > http://www.xilinx.com/products/design_resources/mem_corner/resource/xaw_dram_ddr.htm > > -- Steve Knapp > Or even easier use Alteras' DDR2 megafunction http://www.altera.com/products/ip/iup/memory/m-alt-ddr2_sdram.html SlurpArticle: 102473
It's my understanding that CLKFX = CLKIN * (C_CLKFX_MULTIPLY/C_CLKFX_DIVIDE). Therefore, everything should be cool, no?Article: 102474
The best way to create clocks with tiny increments is using Direct Digital Synthesis (DDS), a.k.a. phase accumulation. You just build a long accumulator, clock it from your 100 MHz (200 MHz would be better), and you can get at its MSB any frequency you want with any granularity you want (I built a circuit with 1 Hz resolution, but you can also get 1 millihertz.) The catch is jitter. You will create an unavoidable worst-case jitter of one clock period (10 ns or 5 ns in your case.) Reducing that jitter is very complicated. Peter Alfke, Xilinx Applications
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