Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 156575

Article: 156575
Subject: Re: Free alternatives to Xilinx iMPACT?
From: "mnentwig" <24789@embeddedrelated>
Date: Sat, 03 May 2014 17:49:37 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 156576
Subject: Re: Initializing color bars on CH7301
From: harsha.s.udupa@gmail.com
Date: Sat, 3 May 2014 22:11:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
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: 156577
Subject: Re: Free alternatives to Xilinx iMPACT?
From: Philipp Klaus Krause <pkk@spth.de>
Date: Sun, 04 May 2014 10:02:30 +0200
Links: << >>  << T >>  << A >>
On 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.

Philipp


Article: 156578
Subject: Re: Free alternatives to Xilinx iMPACT?
From: "mnentwig" <24789@embeddedrelated>
Date: Sun, 04 May 2014 04:08:17 -0500
Links: << >>  << T >>  << A >>
Hi,

the "Xilinx platform cable USB" works with "-c xpc" cable driver option.

Cheers

Markus	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 156579
Subject: The USB FPGA?
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 04 May 2014 16:02:44 +0100 (BST)
Links: << >>  << T >>  << A >>
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

Article: 156580
Subject: Re: The USB FPGA?
From: "mnentwig" <24789@embeddedrelated>
Date: Sun, 04 May 2014 12:02:13 -0500
Links: << >>  << T >>  << A >>
licensing, maybe?	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 156581
Subject: in my xps implementaion elf file is not generated only the linker
From: George D <grg.levi@gmail.com>
Date: Sun, 4 May 2014 12:01:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 me 

Article: 156582
Subject: Re: in my xps implementaion elf file is not generated only the
From: Brian Drummond <brian3@shapes.demon.co.uk>
Date: Sun, 04 May 2014 19:13:54 GMT
Links: << >>  << T >>  << A >>
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.

- Brian

Article: 156583
Subject: Re: The USB FPGA?
From: Brane2 <brankob@avtomatika.com>
Date: Sun, 4 May 2014 12:50:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: unclear tcl error
From: al.basili@gmail.com (alb)
Date: 5 May 2014 06:27:22 GMT
Links: << >>  << T >>  << A >>
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...

Al



Article: 156585
Subject: Re: The USB FPGA?
From: Allan Herriman <allanherriman@hotmail.com>
Date: 05 May 2014 11:51:19 GMT
Links: << >>  << T >>  << A >>
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,
Allan

Article: 156586
Subject: Re: The USB FPGA?
From: John Speth <johnspeth@yahoo.com>
Date: Mon, 05 May 2014 09:57:24 -0700
Links: << >>  << T >>  << A >>
> 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.

JJS



Article: 156587
Subject: Re: The USB FPGA?
From: Brane2 <brankob@avtomatika.com>
Date: Mon, 5 May 2014 10:35:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: The USB FPGA?
From: rickman <gnuarm@gmail.com>
Date: Mon, 05 May 2014 16:40:42 -0400
Links: << >>  << T >>  << A >>
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...

-- 

Rick

Article: 156589
Subject: Re: The USB FPGA?
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 06 May 2014 01:12:34 +0100 (BST)
Links: << >>  << T >>  << A >>
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).

Theo

Article: 156590
Subject: Re: The USB FPGA?
From: Rob Doyle <radioengr@gmail.com>
Date: Mon, 05 May 2014 18:29:46 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: The USB FPGA?
From: =?UTF-8?B?QWRhbSBHw7Nyc2tp?= <gorskiamalpa@wpkropkapl>
Date: Tue, 06 May 2014 10:21:31 +0200
Links: << >>  << T >>  << A >>
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


Adam

Article: 156592
Subject: Re: The USB FPGA?
From: Allan Herriman <allanherriman@hotmail.com>
Date: 06 May 2014 13:17:25 GMT
Links: << >>  << T >>  << A >>
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,
Allan

Article: 156593
Subject: Re: The USB FPGA?
From: KJ <kkjennings@sbcglobal.net>
Date: Tue, 6 May 2014 08:24:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 Jennings


Article: 156594
Subject: Re: The USB FPGA?
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 07 May 2014 00:38:26 +0100 (BST)
Links: << >>  << T >>  << A >>
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
Subject: Re: The USB FPGA?
From: David Brown <david.brown@hesbynett.no>
Date: Wed, 07 May 2014 10:18:41 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: The USB FPGA?
From: already5chosen@yahoo.com
Date: Wed, 7 May 2014 06:15:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: DDR speed of the XUPV2P Board from Digilent
From: impanaeng@gmail.com
Date: Wed, 7 May 2014 09:21:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 advance

Article: 156598
Subject: Re: The USB FPGA?
From: John Miles <jmiles@gmail.com>
Date: Wed, 7 May 2014 17:12:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: DDR speed of the XUPV2P Board from Digilent
From: GaborSzakacs <gabor@alacron.com>
Date: Thu, 08 May 2014 10:40:49 -0400
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search