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, I'm using "Scientific Linux", up-to-date version, xc3sprog with Xilinx Spartan 6 LX9, LX25, LX45 and attached SPI flash. It supports the "cheap" Xilinx platform cable using "-c xpc" cable driver (just "USB", without "II", got mine from ebay for USD 30). I had to fix a lowercase error in some config file in /etc/somewhere to "fxload" the firmware, can't' remember the details. I've used also xverve "Signalyzer H4" (a boxed FTDI chip) and the FTDI chip on the Papilio Pro board. The FTDI-based cables usually need setting product / vendor ID in xc3sprog (dmesg, lsusb), sometimes I have to remove the USB-serial driver (rmmod). xc3sprog/Linux is pretty fast, and for some cables I can increase the cable rate, making it even faster. It can also to put chunks of data to an arbitrary location on the SPI flash via command line, which seems pretty useful (discaimer, haven't used this in "production" yet but it worked as expected in a small test) --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156576
On Monday, November 23, 2009 11:22:52 PM UTC+5:30, mmcshmi11 wrote:
> I'm working with a xilinx virtex 5 board (with the VLX110T) and have been
> trying to get any kind of output to a DVI monitor. I'm using the IIC core
> in XPS to try and program the CH7301. I'm using a clock generator to send a
> 25MHz clock to the xclk pin, sending a high value to the xclk*, and not
> sending any of the 12 data bits because I'm assuming they aren't needed for
> color bars...
>
> I can talk to the CH7301 over the I2C bus and I'm not sure if I am
> programming the control registers wrong or possibly my code is written
> wrong and not programming them at all. Can anybody help me with this? The
> code is below:
>
> #define write_CH7301 0xEC //device address 0x76 shifted left 1 bit
>
> /* Register Declarations */
> #define GIE (*((volatile unsigned long*)(XPAR_IIC_BASEADDR + 0x01C)))
> #define ISR (*((volatile unsigned long*)(XPAR_IIC_BASEADDR + 0x020)))
> #define IER (*((volatile unsigned long*)(XPAR_IIC_BASEADDR + 0x028)))
> #define SOFTR (*((volatile unsigned long*)(XPAR_IIC_BASEADDR + 0x040)))
> #define CR (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
> 0x100)))
> #define SR (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
> 0x104)))
> #define TX_FIFO (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
> 0x108)))
> #define RC_FIFO (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
> 0x10C)))
> #define ADR (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
> 0x110)))
> #define TX_FIFO_OCY (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
> 0x114)))
> #define RC_FIFO_OCY (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
> 0x118)))
> #define TEN_ADR (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
> 0x11C)))
> #define RC_FIFO_PIRQ (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
> 0x120)))
> #define GPO (*((volatile unsigned long*)(XPAR_IIC_BASEADDR +
> 0x124)))
>
> void init_CH7301()
> {
> GIE = 0x80000000; //enable global interrupts for iic bus
> IER = 0x4; //enable Tx FIFO Empty Interrupt [Int(2)]
> CR = 0x01; //enable iic controller
>
> /* IIC Master Transmitter with repeated START */
> /* 1) Write IIC device @ to Tx_FIFO */
> TX_FIFO = write_CH7301;
>
> /* 2) Write data to Tx_FIFO */
> TX_FIFO = 0x9C;
>
> /* 3) Write to Control Register to set MSMS=1 and TX=1 */
> CR = 0x0D; //TX, MSMS, EN = 1
>
> /* 4) Continue writing data to Tx_FIFO */
> TX_FIFO = 0x01;
>
> /* 5) Wait for Transmit FIFO empty interrupt. */
> while(!(ISR & 0x04)); //wait until TX_FIFO empty interrupt
>
> /* 6) Write to CR to set RSTA=1 */
> CR = 0x2D; //TX, MSMS, EN, RSTA = 1
>
> /* 7) Write IIC device @ to Tx_FIFO */
> TX_FIFO = write_CH7301;
>
> /* 8) Write all data except last byte to Tx_FIFO */
> TX_FIFO = 0x9F;
> TX_FIFO = 0x84;
>
> TX_FIFO = 0xEC;
> TX_FIFO = 0xA1;
> TX_FIFO = 0x0D;
>
> TX_FIFO = 0xEC;
> TX_FIFO = 0xC8;
> TX_FIFO = 0x19;
>
> TX_FIFO = 0xEC;
> TX_FIFO = 0xC9;
> TX_FIFO = 0xC0; //0x00 for bypass mode
>
> TX_FIFO = 0xEC;
> TX_FIFO = 0xD6;
>
> /* 9) Wait for Transmit FIFO empty interrupt. */
> while(!(ISR & 0x04)); //wait until TX_FIFO empty interrupt
>
> /* 10) Write to CR to set MSMS=0. */
> CR = 0x29; //RSTA, TX, EN = 1
>
> /* 11) Write last byte of data to Tx_FIFO */
> TX_FIFO = 0x01;
> }
hello.. can any1 send me the verilog code of this ??? plz
Article: 156577On 03.05.2014 12:10, Torfinn Ingolfsen wrote: > On 05/03/2014 10:16, Philipp Klaus Krause wrote: >> I have a Xilinx Platform Cable USB. With Xilinx iMPACT I can use it to >> program CPLDs. Is there a free alternative (preferably some command-line >> tool that works on Linux)? > > I don't have any Xilinx hardware, so I haven't tested, but perhaps > xc3sprog might work? > http://xc3sprog.sourceforge.net/ > > HTH-- > Torfinn Ingolfsen, > Norway Thanks. This one looks good, but it seems the Xilinx Platform Cable USB is not in the list of supported hardware, so I'll have to get another cable. PhilippArticle: 156578
Hi, the "Xilinx platform cable USB" works with "-c xpc" cable driver option. Cheers Markus --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156579
I've been pondering... When it comes to attaching an FPGA to a PC, there are lots of options. First there's JTAG, then there's RS232, then there's ethernet, and PCIe. But there's an elephant in this room: why is USB on FPGA so hard? Sure, every FPGA can be connected to a PC with USB, but it's usually through a dumb bridge chip that does RS232, or maybe uses USB to bitbang JTAG. USB2 is in 'easy' territory for FPGAs at 480Mbps, while USB3 5Gbps is the same bitrate as PCIe Gen 2. Every PC made in the last 15 years has USB. Meanwhile, being stuck behind a bridge chip we manage single-figures Mbps. Now there are dev boards out there with USB PHY or USB MAC chips on them, which is all very nice, but all very painful to program. Plus they're never there when you need them. But why should this be necessary? Any $2 junk gadget comes with a USB2 device interface these days - I don't know what fab process they use, but it can't be too fancy. Likewise USB microcontrollers are a few dollars. I realise the USB stack isn't the most friendly to implementation on FPGA - it doesn't play nicely with FPGA SERDES for example. But if a $2 gadget can have all the functions of a USB device on an antique process node, why don't modern FPGAs have at least native USB2 device mode? TheoArticle: 156580
licensing, maybe? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156581
these are my errors /cygdrive/c/Xilinx/12.1/ISE_DS/EDK/gnu/microblaze/nt/bin/../lib/gcc/microblaze-xilinx-elf/4.1.2/../../../../microblaze-xilinx-elf/bin/ld: region ilmb_cntlr_dlmb_cntlr is full (take/executable.elf section .bss) collect2: ld returned 1 exit status make: *** [take/executable.elf] Error 1 how to rectify this and where the problem actually is?? help meArticle: 156582
On Sun, 04 May 2014 12:01:13 -0700, George D wrote: > these are my errors > > /cygdrive/c/Xilinx/12.1/ISE_DS/EDK/gnu/microblaze/nt/bin/../lib/gcc/ microblaze-xilinx-elf/4.1.2/../../../../microblaze-xilinx-elf/bin/ld: > region ilmb_cntlr_dlmb_cntlr is full (take/executable.elf section .bss) Your code is too big to fit in that memory space. > how to rectify this and where the problem actually is?? Increase the memory size or write smaller code. - BrianArticle: 156583
Dne nedelja, 04. maj 2014 15:02:44 UTC je oseba Theo Markettos napisala: <SNIP> > But there's an elephant in this room: why is USB on FPGA so hard? First, USB is crap. Second, you need license from USB consortium in order to get you manufacturer ID code spans etc. And IIRC it was on the order of EURO 4-5K If your inteface was a hard macro or built into a microcontroller, you might be able to get an ID or two free of charge from the producer of the chip, but without it you have to plunge the dough by yourself if you want to sell the thing as USB compatible. Ethernet MAC span is both cheaper and less neccessary.Article: 156584
Hi Harnhua, harnhua@plunify.com wrote: [] > I think Make assumes that an exit code of 0 means success, and > anything else implies failure. That seems to be why there is an error. > From your log, it doesn't look like the Tcl script exited with an > error. >From 'make' manual: Errors in Recipes. After each shell invocation returns, make looks at its exit status. If the shell completed successfully (the exit status is zero), the next line in the recipe is executed in a new shell; after the last line is finished, the rule is finished. If you look carefully to the code (re-posted here for convenience) I posted it is pretty clear the tcl script has flagged an error, but it doesn't seem to me clear what type of error it might be: > while executing >"exec designer SCRIPT:designer.tcl LOGFILE:report.log" > (procedure "run_designer" line 6) > invoked from within >"run_designer "Generating timing reports" " > open_design $proj_name.adb > report \ > -type timing \ > -analysis max \ > -print_summary yes \ > -..." > (file "report.tcl" line 18) >Command exited with non-zero status 1 Still wandering in the dark... AlArticle: 156585
On Sun, 04 May 2014 12:50:28 -0700, Brane2 wrote: > Dne nedelja, 04. maj 2014 15:02:44 UTC je oseba Theo Markettos napisala: > > <SNIP> > >> But there's an elephant in this room: why is USB on FPGA so hard? > > First, USB is crap. > > Second, you need license from USB consortium in order to get you > manufacturer ID code spans etc. And IIRC it was on the order of EURO > 4-5K > > If your inteface was a hard macro or built into a microcontroller, you > might be able to get an ID or two free of charge from the producer of > the chip, but without it you have to plunge the dough by yourself if you > want to sell the thing as USB compatible. > > Ethernet MAC span is both cheaper and less neccessary. I'll second the "USB is crap" comment. If you must use USB2, I recommend using external PHY parts. I know of three "standards" for interfacing controller chips to PHYs: - UTMI+ (60MHz parallel) - ULPI (60MHz parallel) - HSIC (240MHz DDR) You can buy PHY chips from Microchip (nee SMSC), TI, etc. I've only used ULPI ones from SMSC. BTW, there's a USB3.1 standard on the way, giving around 10Mb/s, with 5V / 2A power. It uses similar connections to USB3.0, but with different signalling. Regards, AllanArticle: 156586
> I'll second the "USB is crap" comment. What a strange comment. It is what it is, not perfect, but nothing is perfect. You could say everything we do or use is crap if you don't state why. USB is usually a requirement for implementers. For users it's a cheap interface for connecting their gadgets. Think of all the revenue generated for companies through the application of USB. JJSArticle: 156587
Dne ponedeljek, 05. maj 2014 16:57:24 UTC je oseba John Speth napisala: > > I'll second the "USB is crap" comment. > > > > What a strange comment. It is what it is, not perfect, but nothing is > > perfect. Crap is also not perfect, so no collision there. > You could say everything we do or use is crap if you don't > > state why. > It would be far to tedious. But in short - collective intelligence of its implementing body ranges from braindead to level of average moron. Its standard haven't so much evolved as it caught tumor which has during the course of its growth simply eaten original intentions and implementation. It's like one of those news we keep reading about "Doctors removed 100lb tumor". Except that this patient haven't had the courage to go lie under scalpel yet. When tumor overgrows you, "benign" means just that it prefers having you around as a carrier instead as food...Article: 156588
On 5/5/2014 1:35 PM, Brane2 wrote: > Dne ponedeljek, 05. maj 2014 16:57:24 UTC je oseba John Speth napisala: >>> I'll second the "USB is crap" comment. >> >> >> >> What a strange comment. It is what it is, not perfect, but nothing is >> >> perfect. > > Crap is also not perfect, so no collision there. > > >> You could say everything we do or use is crap if you don't >> >> state why. >> > > It would be far to tedious. > > But in short - collective intelligence of its implementing body ranges from braindead to level of average moron. > > Its standard haven't so much evolved as it caught tumor which has during the course of its growth simply eaten original intentions and implementation. > > It's like one of those news we keep reading about "Doctors removed 100lb tumor". > > Except that this patient haven't had the courage to go lie under scalpel yet. > When tumor overgrows you, "benign" means just that it prefers having you around as a carrier instead as food... Yes, that is much better. I understand perfectly what you don't like about USB now. Thanks for the huge clarity in explanation... ;) Meanwhile the rest of us get on with our work using USB... -- RickArticle: 156589
Allan Herriman <allanherriman@hotmail.com> wrote: > I'll second the "USB is crap" comment. It may be. But look at your FPGA. How do you connect it to your PC? It might have ethernet or PCIe, but almost invariably what comes first is USB. > If you must use USB2, I recommend using external PHY parts. This is the wrong solution because those chips are never there when you need them. If you're doing your own board you can put on one, but many dev boards don't have them. Then you need to program the PHY chip, and then you need a softcore MAC on the FPGA. The FPGA vendors don't provide this for free, so it's $30K to thirdparty vendors before you're started. And it'll take you a very long time to get started because you need to understand it first. Meanwhile a USB2 microcontroller with flexible endpoint support is $6. Why can't this functionality fit on an FPGA? Why does every dev board have a dumb FTDI chip on it as a bridge to RS232 or JTAG? Why isn't USB2 an FPGA programming option (in addition to JTAG)? After all, plenty of consumer kit these days has USB2 reprogram/recovery/firmware update modes. > BTW, there's a USB3.1 standard on the way, giving around 10Mb/s, with > 5V / 2A power. It uses similar connections to USB3.0, but with different > signalling. Do you know if the signalling is more amenable to FPGA transceivers than current USB2? I admit I haven't looked at the USB3.0 signalling standard either. (It's at least not trying to drive wires bidirectionally). TheoArticle: 156590
On 5/5/2014 1:40 PM, rickman wrote: > > Yes, that is much better. I understand perfectly what you don't like > about USB now. Thanks for the huge clarity in explanation... ;) > > Meanwhile the rest of us get on with our work using USB... > Yup. It's the worst interface there is - except for the alternatives... Rob.Article: 156591
W dniu 2014-05-04 17:02, Theo Markettos pisze: > I've been pondering... > > When it comes to attaching an FPGA to a PC, there are lots of options. > First there's JTAG, then there's RS232, then there's ethernet, and PCIe. > But there's an elephant in this room: why is USB on FPGA so hard? > > Sure, every FPGA can be connected to a PC with USB, but it's usually through > a dumb bridge chip that does RS232, or maybe uses USB to bitbang JTAG. USB2 > is in 'easy' territory for FPGAs at 480Mbps, while USB3 5Gbps is the same > bitrate as PCIe Gen 2. Every PC made in the last 15 years has USB. > Meanwhile, being stuck behind a bridge chip we manage single-figures Mbps. > > Now there are dev boards out there with USB PHY or USB MAC chips on them, > which is all very nice, but all very painful to program. Plus they're never > there when you need them. But why should this be necessary? Any $2 junk > gadget comes with a USB2 device interface these days - I don't know what fab > process they use, but it can't be too fancy. Likewise USB microcontrollers > are a few dollars. > > I realise the USB stack isn't the most friendly to implementation on FPGA - > it doesn't play nicely with FPGA SERDES for example. But if a $2 gadget can > have all the functions of a USB device on an antique process node, why don't > modern FPGAs have at least native USB2 device mode? > > Theo > Use first from the row FPGA SoC kit with linux on board. Then you have not only FPGA but also almost standard ARM subsystem with all ethernet, usb, rs232 and so on. Typically you can start ready to use linux image from sd card. This way you have solved problem with interfacing PC to fpga cause ARM system has pretty wide access to FPGA resources. Take a look here: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=816&PartNo=2 AdamArticle: 156592
On Tue, 06 May 2014 01:12:34 +0100, Theo Markettos wrote: > Allan Herriman <allanherriman@hotmail.com> wrote: >> I'll second the "USB is crap" comment. > > It may be. I should clarify. I've made many boards over the years, using a variety of interface standards. USB has never struck me as being elegant or efficient. Its ubiquity, low cost (in volume), a robust connector and power on the same cable as the signals seem to be its biggest plusses. The USB physical layer isn't too bad, IMO. Most of the issues encountered during development are to do with the (software) drivers. That and the reuse of VID / PID values by cheap knock-off clone gizmos that don't quite match the functionality of the original, yet are still expected to work. (That isn't the fault of the USB standard though.) Other posters mentioned the need to purchase an official VID / PID. The process is too expensive for low volume or hobby projects. USB isn't alone there - for example my current employer owns an Ethernet OUI (a big block of MAC addresses) as well as an Ethertype (protocol specifier). Both of those cost money, but it's a modest once-off cost unlike the annual charge from USB-IF. Another thing to consider is that for (e.g.) Ethernet, there are MAC addresses and Ethertypes that you can use for your hobby projects and experimental protocols that won't get you into trouble. The USB-IF don't provide VID / PID values intended for a similar purpose. (I understand that if you buy a VID with the purpose of making it "free" they will come after you.) > But look at your FPGA. How do you connect it to your PC? > It might have ethernet or PCIe, but almost invariably what comes first > is USB. It's the opposite for me. If one of my boards with an FPGA on it is connecting to a PC, it'll be via Ethernet. During debugging, I might rarely use USB to connect a JTAG pod to my PC though. >> If you must use USB2, I recommend using external PHY parts. > > This is the wrong solution I respectfully disagree. One thing that you might like to consider is the I/O required for USB2. It matches well to the sort of process that you would use for a $2 microcontroller, but not so well to the low voltage I/O that you'd find on a 28nm FPGA. There are also analog functions that are needed that you will not find on an FPGA. FPGA vendors don't like including anything that doesn't have wide applicability. OTOH USB3 uses serial signalling that might be a good match for FPGA transceivers. I haven't looked closely enough at the standard to know for sure, but I suspect there will be problems with idle or sleep (or something like that). OTOH, FPGA transceivers now have support for the analog signalling for SATA, so if there's enough demand in the marketplace, anything can happen. I only put a USB3 controller into a product once - a (then new) NEC / Renesas part that connected to my system using PCIe, so I can't claim to be a USB3 expert. I'm also aware that low speed (1.5Mb/s) USB can be bit-bashed in software on a cheap microcontroller. I don't think it would be compliant with the spec but it does seem to work and is extremely cheap. That really sounds like it could easily fit into an FPGA, possibly with the addition of some external level translators. > because those [PHY] chips are never there when you > need them. I know you're talking about boards, but if you were talking about part availability, that would be a good point. USB is used in consumer products, and this means that the parts sometimes have short production lives. Some years ago I designed a USB2 hub from ST-Ericcson into a product. They had been made obsolete before our second production run. Now there's an SMSC one in its place. Since then, SMSC has been bought by Microchip and who knows what's going to happen. Those issues can apply to any part on your board though, and aren't unique to USB. (Has anyone tried to get DDR3 RAM chips when some company in China is manufacturing a large batch of tablets?) > If you're doing your own board you can put on one, but many > dev boards don't have them. I don't use dev boards, so I really shouldn't comment. > Why isn't USB2 an FPGA programming option (in addition to JTAG)? Substitute the string "PCIe" for "USB2" and you have a question I asked of the local Altera and Xilinx reps about five years ago. I'm still waiting for a good solution to that problem that doesn't involve putting a "bootloader" NVM on the board to configure the FPGA just so it can talk PCIe to get the rest of the configuration. My guess: USB2 - never. USB3 - a very remote possibility. Regards, AllanArticle: 156593
On Tuesday, May 6, 2014 9:17:25 AM UTC-4, Allan Herriman wrote: > USB isn't alone there - for example my current employer owns an Ethernet= =20 > OUI (a big block of MAC addresses) as well as an Ethertype (protocol=20 > specifier). Both of those cost money, but it's a modest once-off cost=20 > unlike the annual charge from USB-IF. >=20 The annual charge is not mandatory, it is only to allow you to license use = of their logos on new products. You can simply pay the first year (which g= ets you your VID) and never pay again. If having the USB logo is important= to your product marketing, then you do have to pay for that privilege. Bo= ttom line is that the first year $$ gets you the VID (and the use of logos = if you choose); subsequent year's $$ allows you to continue to use logos. > Another thing to consider is that for (e.g.) Ethernet, there are MAC=20 > addresses and Ethertypes that you can use for your hobby projects and=20 > experimental protocols that won't get you into trouble. The USB-IF don't= =20 > provide VID / PID values intended for a similar purpose. (I understand= =20 > that if you buy a VID with the purpose of making it "free" they will come= =20 >=20 A hobby project can use any VID since they do not need to worry about inter= operability with anything that the hobbyist doesn't already know about. Pr= oviding something for 'free' takes it a bit outside of the realm of a stric= t 'hobby' which may open you up to folks coming after you as you say. Kevin JenningsArticle: 156594
Allan Herriman <allanherriman@hotmail.com> wrote: > I should clarify. I've made many boards over the years, using a variety > of interface standards. USB has never struck me as being elegant or > efficient. Its ubiquity, low cost (in volume), a robust connector and > power on the same cable as the signals seem to be its biggest plusses. I agree. It's the ubiquity that makes it really hard to ignore. (looks at laptop: available ports are Thunderbolt - an obfuscated version of PCI Express that's impossible for normal mortals to use[1] - and USB3.) > Other posters mentioned the need to purchase an official VID / PID. The > process is too expensive for low volume or hobby projects. Presumably an FPGA could come with a default manufacturer VID/PID, which is device class FF and has a higher level protocol for arbitrating functionality. If you then want to sell it as a product that implements a standard device class then you need apply for a VID/PID. But you have flexibility to do other things (eg ship the first version of your product as an FPGA, then switch to ASIC using the same driver and VID/PID code. Or impersonate another device for interoperability). > It's the opposite for me. If one of my boards with an FPGA on it is > connecting to a PC, it'll be via Ethernet. How do you program it? Do you have an onboard Ethernet to JTAG converter? > I respectfully disagree. One thing that you might like to consider is > the I/O required for USB2. It matches well to the sort of process that > you would use for a $2 microcontroller, but not so well to the low > voltage I/O that you'd find on a 28nm FPGA. That sounds plausible. Except every phone SoC has a USB OTG port - and some of those are 28nm and not exactly low performance. > There are also analog functions that are needed that you will not find on > an FPGA. FPGA vendors don't like including anything that doesn't have > wide applicability. Looking at die shots, USB on the Tegra 2 takes up about 1% of die area on a 40nm process (couldn't find any labelled 28nm photos) - that's roughly 0.5mm2. I suppose that could be too high a price to pay, though I wonder how hard PCIe compares? OTOH a USB hard core wouldn't necessarily have all the features of Tegra's, because you'd want the backend of it to be in configurable soft logic. > OTOH USB3 uses serial signalling that might be a good match for FPGA > transceivers. I haven't looked closely enough at the standard to know > for sure, but I suspect there will be problems with idle or sleep (or > something like that). OTOH, FPGA transceivers now have support for the > analog signalling for SATA, so if there's enough demand in the > marketplace, anything can happen. That would be interesting. Is USB3 generally more sane in your opinion? > I'm also aware that low speed (1.5Mb/s) USB can be bit-bashed in software > on a cheap microcontroller. I don't think it would be compliant with the > spec but it does seem to work and is extremely cheap. > That really sounds like it could easily fit into an FPGA, possibly with > the addition of some external level translators. I've been wondering about that - is there a reference for the minimal spec that needs to be implemented? It might be a nice way of stripping down USB to something easier to understand. At least the FPGA shouldn't have the timing awkwardness of microcontrollers. > I know you're talking about boards, but if you were talking about part > availability, that would be a good point. USB is used in consumer > products, and this means that the parts sometimes have short production > lives. > Those issues can apply to any part on your board though, and aren't > unique to USB. (Has anyone tried to get DDR3 RAM chips when some company > in China is manufacturing a large batch of tablets?) BTDT, for very similar 'fun'... > > Why isn't USB2 an FPGA programming option (in addition to JTAG)? > > Substitute the string "PCIe" for "USB2" and you have a question I asked > of the local Altera and Xilinx reps about five years ago. > > I'm still waiting for a good solution to that problem that doesn't > involve putting a "bootloader" NVM on the board to configure the FPGA > just so it can talk PCIe to get the rest of the configuration. Likewise, I have similar bringup tedium. Do any motherboards wire up the PCIe JTAG lines in a sensible manner? > My guess: USB2 - never. USB3 - a very remote possibility. I'm all in favour of shooting USB2 and moving on... Theo [1] I have evil plans in the Thunderbolt department...Article: 156595
On 06/05/14 15:17, Allan Herriman wrote: > On Tue, 06 May 2014 01:12:34 +0100, Theo Markettos wrote: > >> Allan Herriman <allanherriman@hotmail.com> wrote: >>> I'll second the "USB is crap" comment. >> >> It may be. > > I should clarify. I've made many boards over the years, using a variety > of interface standards. USB has never struck me as being elegant or > efficient. Its ubiquity, low cost (in volume), a robust connector and > power on the same cable as the signals seem to be its biggest plusses. > > The USB physical layer isn't too bad, IMO. Most of the issues > encountered during development are to do with the (software) drivers. > That and the reuse of VID / PID values by cheap knock-off clone gizmos > that don't quite match the functionality of the original, yet are still > expected to work. (That isn't the fault of the USB standard though.) Drivers /can/ be a problem with USB, but they don't have to be. If you need your device to integrate with the operating system (such as happens for mice, printers, USB speakers, mass storage devices, etc.), then it is easy if you can re-use existing standardised drivers (such as the OS's own HID or MSD drivers). If you need to make your own specialised drivers, then it is a tough job on Linux - you need to learn the details of how USB works on the OS as well as the details for the USB class you are implementing, and distributing the drivers can be a challenge. On Windows, even if you understand everything and can do all the windows driver development, it is still a nightmare of signing, certification, etc. But if your device only needs to talk to programs /you/ write, or libraries/dlls/so's that /you/ write, then it is a lot easier. On Linux, libusb lets your application have direct access to the endpoints on your USB device - you have full control without any drivers in the middle. Until a few years ago, it was still hard on Windows - but someone helpfully ported libusb from Linux to Windows as WinUSB, and with the simple installer "zadig" you can avoid almost all issues with drivers on Windows too. > > > Other posters mentioned the need to purchase an official VID / PID. The > process is too expensive for low volume or hobby projects. > > USB isn't alone there - for example my current employer owns an Ethernet > OUI (a big block of MAC addresses) as well as an Ethertype (protocol > specifier). Both of those cost money, but it's a modest once-off cost > unlike the annual charge from USB-IF. The charge for a USB VID is one-off. The charge to use the USB logo, trademarks, etc., is annual. For a hobby project, there is no problem - pick a VID of a company you would never use, or an unassigned VID, and use that. For any professional product, the $2000 (IIRC) charge to buy a VID is annoying but if you budget it as though it were a piece of development equipment, it is not going to be an issue. > Another thing to consider is that for (e.g.) Ethernet, there are MAC > addresses and Ethertypes that you can use for your hobby projects and > experimental protocols that won't get you into trouble. The USB-IF don't > provide VID / PID values intended for a similar purpose. (I understand > that if you buy a VID with the purpose of making it "free" they will come > after you.) > >> But look at your FPGA. How do you connect it to your PC? >> It might have ethernet or PCIe, but almost invariably what comes first >> is USB. > > It's the opposite for me. If one of my boards with an FPGA on it is > connecting to a PC, it'll be via Ethernet. > > During debugging, I might rarely use USB to connect a JTAG pod to my PC > though. > >>> If you must use USB2, I recommend using external PHY parts. >> >> This is the wrong solution > > I respectfully disagree. One thing that you might like to consider is > the I/O required for USB2. It matches well to the sort of process that > you would use for a $2 microcontroller, but not so well to the low > voltage I/O that you'd find on a 28nm FPGA. > There are also analog functions that are needed that you will not find on > an FPGA. FPGA vendors don't like including anything that doesn't have > wide applicability. > > OTOH USB3 uses serial signalling that might be a good match for FPGA > transceivers. I haven't looked closely enough at the standard to know > for sure, but I suspect there will be problems with idle or sleep (or > something like that). OTOH, FPGA transceivers now have support for the > analog signalling for SATA, so if there's enough demand in the > marketplace, anything can happen. > I only put a USB3 controller into a product once - a (then new) NEC / > Renesas part that connected to my system using PCIe, so I can't claim to > be a USB3 expert. > > I'm also aware that low speed (1.5Mb/s) USB can be bit-bashed in software > on a cheap microcontroller. I don't think it would be compliant with the > spec but it does seem to work and is extremely cheap. Bit-banging low speed USB should be perfectly compliant with the specs (if it is done right, of course). On an FPGA there should be no problem implementing 12 Mb/s USB directly, or 480 Mb/s using an external PHY (the XMOS devices do that, with the 480 Mb/s USB device running in software). The USB protocol is not /that/ complicated. > That really sounds like it could easily fit into an FPGA, possibly with > the addition of some external level translators. > >> because those [PHY] chips are never there when you >> need them. > > I know you're talking about boards, but if you were talking about part > availability, that would be a good point. USB is used in consumer > products, and this means that the parts sometimes have short production > lives. > Some years ago I designed a USB2 hub from ST-Ericcson into a product. > They had been made obsolete before our second production run. Now > there's an SMSC one in its place. Since then, SMSC has been bought by > Microchip and who knows what's going to happen. > > Those issues can apply to any part on your board though, and aren't > unique to USB. (Has anyone tried to get DDR3 RAM chips when some company > in China is manufacturing a large batch of tablets?) > >> If you're doing your own board you can put on one, but many >> dev boards don't have them. > > I don't use dev boards, so I really shouldn't comment. > >> Why isn't USB2 an FPGA programming option (in addition to JTAG)? > > Substitute the string "PCIe" for "USB2" and you have a question I asked > of the local Altera and Xilinx reps about five years ago. > > I'm still waiting for a good solution to that problem that doesn't > involve putting a "bootloader" NVM on the board to configure the FPGA > just so it can talk PCIe to get the rest of the configuration. > > My guess: USB2 - never. USB3 - a very remote possibility. > > Regards, > Allan >Article: 156596
On Wednesday, May 7, 2014 2:38:26 AM UTC+3, Theo Markettos wrote: > Allan Herriman <allanherriman@hotmail.com> wrote: > > > > > > I respectfully disagree. One thing that you might like to consider is > > the I/O required for USB2. It matches well to the sort of process that > > you would use for a $2 microcontroller, but not so well to the low > > voltage I/O that you'd find on a 28nm FPGA. > > That sounds plausible. Except every phone SoC has a USB OTG port - and some > of those are 28nm and not exactly low performance. > I'd guess that at least some of 28nm SOCs require external level-shifter. Actually I'd expect it to be true starting from 65nm. Unfortunately, it's damn hard to get detailed datasheets for SOCs from Quallcomm, Mediatek, Apple or Samsung. But we can take a look at USB controllers of Xilinx Zync, Altera Cyclon-V SE/SX/ST, Freescale i.MX 6 series and QorIQ and TI OMAP4 and OMAP5. They use virtually the same technology, but not as secretive as high-volume folks. Both Altera and Xilinx export UTMI+ ULPI interface and need external PHY. Both Freescale families implement PHY on chip. TI OMAP4 needs external PHY. TI OMAP5 implements both interface to external phy and on-chip USB 2/3 PHY. On chip PPY has few limitations, but they are probably irrelevant in your use case.Article: 156597
sir=20 i am working on image processing project with deals with implementation of = it on xc2vp30 device but to to run my code on board i need to set pins AC11= and AD11 can you please tell can i find the pin on board . i have searched= in all data sheets and cannot find the pin location. thank you in advanceArticle: 156598
On Tuesday, May 6, 2014 8:24:45 AM UTC-7, KJ wrote: > On Tuesday, May 6, 2014 9:17:25 AM UTC-4, Allan Herriman wrote: >=20 > > USB isn't alone there - for example my current employer owns an Etherne= t=20 >=20 > > OUI (a big block of MAC addresses) as well as an Ethertype (protocol=20 >=20 > > specifier). Both of those cost money, but it's a modest once-off cost= =20 >=20 > > unlike the annual charge from USB-IF. >=20 > >=20 >=20 >=20 >=20 > The annual charge is not mandatory, it is only to allow you to license us= e of their logos on new products. You can simply pay the first year (which= gets you your VID) and never pay again. If having the USB logo is importa= nt to your product marketing, then you do have to pay for that privilege. = Bottom line is that the first year $$ gets you the VID (and the use of logo= s if you choose); subsequent year's $$ allows you to continue to use logos. >=20 If you don't care about logos, you can always license a subset of=20 VID 16D0 from MCS Electronics for around 10 Euros each. They bought their = VID before the USB-IF cracked down on resellers. =20 http://www.mcselec.com/index.php?page=3Dshop.product_details&flypage=3Dshop= .flypage&product_id=3D92&option=3Dcom_phpshop&Itemid=3D1 I'm not sure if this would keep you from getting WHQL certified or not, and= I'd assume it would rule out your ability to use the official USB logo. B= ut for many/most products, nobody gives much of a hoot about either of thes= e. -- john, KE5FX (no relationship with MCS other than as a satisfied customer= )Article: 156599
impanaeng@gmail.com wrote: > sir > i am working on image processing project with deals with implementation of it on xc2vp30 > device but to to run my code on board i need to set pins AC11 and AD11 can you please tell > can i find the pin on board . i have searched in all data sheets and cannot find the pin location. > > thank you in advance The schematics are at: http://www.xilinx.com/univ/XUPV2P/Documentation/EXTERNAL_REV_C_SCHEMATICS.pdf The two pins you mentioned connect to DIP switch SW7. I'm not sure what that has to do with the DDR speed. Did you expect these pins to supply a clock? -- Gabor
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