Xilinx project with USB (ULPI PHYs) - Page 1
Forum section: electronics / general

author: dtodorov
author_rank: Contributor
timestamp: August 30, 2021, 09:35:40 am
content: Hi,I am currently exploring the options for USB connection with a Xilinx Artix7 board. Looking at the capabilities of the device, there is anAXI USB2 IPblock that could be instantiated, however it requires external PHY chip over ULPI interface.So far only a few chip candidates are available for this task from my short research:- Microchip'sUSB3300. There are interesting modules sold on aliexpress for circa $10 -Link.- STMicro'sSTULPI01A- TI'sTUSB1210- OnSemi'sFUSB2805Since the project is on the hobby time and capabilities, I'd much prefer a pre-soldered breakout-like board (or a module like the one from AliExpress) or anything in solderable package like SOIC or TQFP. It's just the QFNs and BGAs not my thing.Has anyone encountered the need to use such PHYs?-Dimitar

author: asmi
author_rank: Super Contributor
timestamp: August 30, 2021, 01:40:16 pm
content: You will be much better served long-term by becoming friends with BGAs and QFNs. They are quite easy to solder - you just need a little practice.As for ULPI - as you perhaps know it runs at 80 (correction - 60, thanks ataradov!) MHz, so it's about at a point where signal integrity and length matching becomes important, so making modules becomes more complicated, and usually these modules are designed for a specific main board.Another reason these devices are not popular is complexity of implementing USB protocol, both on HW and SW side. You can somewhat alleviate SW complexity by reusing USB stack in Linux, but that will require implementing HW controller compliant with EHCI specification, which is not an easy feat (though certainly not impossible). That specification requires implementing DMA master as controller is supposed to perform intensive memory operations - it's supposed to walk through various memory descriptor tables in memory and execute commands as per their contents. Also ECHI only covers USB 2.0 (including split transactions used to talk to USB 1.x devices connected to a USB 2.0 hub), so if you want to connect USB 1.x devices directly to your root USB port, you will also need to implement UHCI "companion" controller to cover these.The only FPGA board I know which has ULPI PHY onboard is Digilent's Genesys 2, but it's price of US$1000 is probably beyond typical hobbyist's budget. So the best bet would probably be to roll your own, hence my first recommendation to get familiar with soldering QFNs and BGAs.

author: ataradov
author_rank: Super Contributor
timestamp: August 30, 2021, 03:53:29 pm
content: I worked with USB3300 and USB3343. Not the boards, just the ICs on a custom board. Both worked as expected, ULPI is well defined, so I would not expect issues with other as well.ULPI runs at 60 MHz, but yes, you need to do trace length matching and have a reasonable layout.But you need to be prepared to implement the whole USB controller, those ICs just translate parallel bus to a serial, they don't have any logic at all. It is not impossible to implement it, but it is also not trivial.I just noticed that you want to use existing IP. In this case there should be no issues. Those ICs pretty much work out of the box.

author: asmi
author_rank: Super Contributor
timestamp: August 30, 2021, 04:27:34 pm
content: I would also add that if your goal is to communicate to your own client application on PC, you will be much better served by using any of existing USB-FIFO bridge IC instead of rolling out your own USB implementation. Devices like FT232 support USB 2.0 High Speed protocol, or FT600/FT601 support USB 3.0 5 Gbps protocol, the latter of which can reach up to ~2.6 Gbps of real-life bandwidth according to my tests. These devices have drivers for all major OSes, and provide a well-defined API that your application can use to talk to the board. On FPGA side they provide a simple FIFO-like interface, which makes them trivial to integrate into your design.

author: Bassman59
author_rank: Super Contributor
timestamp: August 30, 2021, 04:54:27 pm
content: Quote from: asmi on August 30, 2021, 04:27:34 pmif only FT600 allowed the use of standard USB classes.

author: ataradov
author_rank: Super Contributor
timestamp: August 30, 2021, 04:57:04 pm
content: Yes, FTDI sucks for really custom stuff. The only somewhat accessible (price and package) solution that I know of is CY7C68013A. And it is not great either with stupid slow 8051 core.

author: asmi
author_rank: Super Contributor
timestamp: August 30, 2021, 05:48:08 pm
content: Quote from: Bassman59 on August 30, 2021, 04:54:27 pmIn that case interfacing it to FPGA would become much more challenging. These devices were designed for a specific use case, and as long as your requirements are consistent with them, integrating them into your design is very simple on both hardware and software sides. For me designing a proof-of-concept took just a few hours, good luck achieving that with full-blown USB implementation.Also you might want to take a look at FT602, which does implement a standard USB Video Class (UVC) with up to 4 input video streams in parallel according to documentation. I didn't use it myself though, so not sure how easy it is to integrate, but I assume it's pretty much the same as for FT601.

author: Bassman59
author_rank: Super Contributor
timestamp: August 30, 2021, 06:11:49 pm
content: Quote from: asmi on August 30, 2021, 05:48:08 pmOh, I understandwhythey are the way they are. But here's an example of something I've been thinking about building: a USB-to-MADI (AES-10) interface.(For those who don't know, MADI is a scheme for sending multiple channels of digital audio over coax or fiber. It uses a 100 Mbit data rate and does 4B/5B encoding, so it's 125 Mbps on the wire. It is trivial to decode and encode in an FPGA.)This requires the thing to enumerate as a standard Audio Class 2.0 device, with however many channels one wants to support.This can be done in an ARM with an external bus interface. But lordy all of the vendors make their USB stacks fairly inscrutable!The Cypress CYUSB3014 looks interesting. It's expensive.

author: asmi
author_rank: Super Contributor
timestamp: August 30, 2021, 07:23:07 pm
content: One way would be to use STM32H7 MCU which can map HyperBus slave device into it's memory space (it's got 256MB address window for each OctoSPI instance), so you can have your FPGA implement HB slave, and this way MCU's DMA can access it directly without CPU involvement, and it's got pretty high bandwidth (depending on exact MCU up to 275 MB/s). ST provides Audio Device Class implementation, but H7 still requires external ULPI PHY for USB High Speed. There are some STM32F7 MCUs which have integrated HS USB PHY, but they only have QuadSPI and so will have lower bandwidth to FPGA. But even H7 + ULPI PHY together will cost a lot less than CYUSB3014, and USB 2.0 HS would be enough for your needs.

author: dolbeau
author_rank: Regular Contributor
timestamp: August 30, 2021, 09:25:56 pm
content: Quote from: dtodorov on August 30, 2021, 09:35:40 amWhich kind, host or device?For host, SpinalHDL includes anOHCI USB Host controller, and the author also hasa pmod to supply power & plugs. It includes a Wishbone interface around its native interface, which has aLitex wrapper. The USB signals are run directly from the FPGA, no additional chip needed (the stuff on the pmod if for the VBus, which can bereplaced by an external self-powered hub).