Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

USB Softcore for FPGA

Status
Not open for further replies.
@KlausST

This is for personal experiment and fun. Therefore, I am not going to involve my computer USB port.

What I plan to do at most is writing very small amount of data into a cheap USB pendrive and read the same data back from it.

So, FPGA <--> pendrive

However, given that my current ability does not allow me to boot linux on my FPGA (which means FPGA could only be a USB DEVICE), I could only do FPGA <-- pendrive , but not FPGA --> pendrive

Please correct me if wrong.
 

Hi,

eventually a clear requirement:

FPGA <--> pendrive

--> The FPGA is the USB_HOST (Master), the pendrive is the USB_DEVICE (Slave).

--> You clearly need to design a USB_MASTER! (No HUB, no USB_DEVICE!)

Klaus

Added:
For the pullup / pulldown question this means, you need:
* a 15k pulldown at D+
* a 15k pulldown at D-
* no pullup

Added:
However, given that my current ability does not allow me to boot linux on my FPGA (which means FPGA could only be a USB DEVICE), I could only do FPGA <-- pendrive , but not FPGA --> pendrive

Please correct me if wrong.
As already written it does not depend on an operating system (LINUX).

I could only do FPGA <-- pendrive , but not FPGA --> pendrive
This is READ and WRITE and has nothing to do with HOST or DEVICE.

****

You really, really need to read about USB basics.

Klaus
 

@KlausST

As in figure 7-20 at post #10, Why no pullup at D+ line to indicate full-speed mode ?

USB_HOST requires software driver (libusb). I do not get why FPGA without any OS support for software driver could ever become a HOST ?

- - - Updated - - -

I'm not sure what pull-up and down resistors have to do with bidirectional operation. Different resistor values shall be implemented for down- and up-stream ports, as shown in your post #10. I was suggesting tri-state drivers in case you want to switch resistors, e.g. to signal activation/deactivation of an upstream (device) port or change speed. Otherwise you can use fixed resistor.

@FvM

1) How do tri-state drivers switch resistors ? I believe tri-state outputs are either the input or Z

See this intel verilog code example of bidirectional pin, bidirec.v


Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
module bidirec (oe, clk, inp, outp, bidir);
 
// Port Declaration
 
input   oe;
input   clk;
input   [7:0] inp;
output  [7:0] outp;
inout   [7:0] bidir;
 
reg     [7:0] a;
reg     [7:0] b;
 
assign bidir = oe ? a : 8'bZ ;
assign outp  = b;
 
// Always Construct
 
always @ (posedge clk)
begin
    b <= bidir;
    a <= inp;
end
 
endmodule



With Intel FPGA, there's no calibrated series termination that matches the USB FS requirement of 28 - 44 ohm driver impedance. You are probably able to achieve the impedance by choosing a suitable drive strength in uncalibrated mode, but the impedance will be subjected to type and temperature variation. Thus it's probably better to use a low driver impedance along with series resistors.

2) Suitable drive strength ? Could you elaborate with example in this current context of USB FS mode?

3) I could only choose on-chip termination of 25 ohm (cyclone IV fpga IO allows only 25 ohm or 50 ohm on-chip termination) and add external discrete 10 ohm resistors to both D+ and D- FPGA pins. Do I get this right ?

x8jaaaF.png
 

Hi,

there is so much lack of understanding, I´m not sure it makes sense to go on this way....
A forum can´t replace school, can`t replace reading tutorials, can´t teach all the electronic basics...

*****
As in figure 7-20 at post #10, Why no pullup at D+ line to indicate full-speed mode ?
Because a HOST can not decide the sppeed, this is the job of the DEVICE to show it´s capabilities.
Again: this is simple USB understanding and is written in every basic USB tutorial.

*****
USB_HOST requires software driver (libusb). I do not get why FPGA without any OS support for software driver could ever become a HOST ?
A HOST does not need software. You may implement all the USB_HOST functions in HW. It´s your decision how to do this.

As an example:
If you want to cook fish, then the receipt will tell you to use an oven. But indeed it´s not the oven that is needed, it´s the heat that is needed.
It´s on you how to "create" that heat. You may use the oven, you may use campfire ... even a dishwasher can be used...

USB examples: FTDI chip "Vinculum" does not need an OS to be used as USB_HOST.

I assume you are not aware that you need to handle FAT16/FAT32 on your pendrive. You need to read/modify/write file allocation tables, to be able to write data to the pendrive.
Or do you decide to use your own file system on the pendrive? Decide how to do this.

*****
1) How do tri-state drivers switch resistors ? I believe tri-state outputs are either the input or Z
"tri" state means "3" state. Here the three states of a logic output.
1) HIGH
2) LOW
3) HIGH-Z

I´ll come back after I see that you have a basic understanding of what you try to design.

Klaus
 

I could only choose on-chip termination of 25 ohm (cyclone IV fpga IO allows only 25 ohm or 50 ohm on-chip termination) and add external discrete 10 ohm resistors to both D+ and D- FPGA pins. Do I get this right ?
Yes. I don't think however, that exact driver impedance is a problem for your application. It only matters if you need to utilize the maximum USB cable length of 5 m.

What I plan to do at most is writing very small amount of data into a cheap USB pendrive and read the same data back from it.

So, FPGA <--> pendrive
As already explained by KlausST, this involves implementing the host function to control the pen drive. The required protocol is specified by the MSC (mass storage device class) documents. This is a relative complex specification comprised of several parts and referencing other industry standard storage device protocols like ATAPI and SCSI.

USB host operation involves a setup ("device enumeration") phase which manages e.g. the addressing of multiple devices connected to an USB host port through hubs. A mini host accessing only a single device can possibly bypass some of these functions, but there's still complex action required during device attachment, that's the reason why hosts are mostly relying on a microcontroller to perform it. It's surely possible to implement it completely in FPGA hardware.
 
@FvM

Since acting as a USB host requires **broken link removed** , would you be able to suggest another simpler project where I could still experiment with the usbcorev softcore without involving my computer USB port ?

I believe I need to pause the FPGA <--> pendrive design for a while until I am very familiar with the MSC (mass storage device class) documents.
 

would you be able to suggest another simpler project where I could still experiment with the usbcorev softcore without involving my computer USB port ?

usbcorev is described "A full-speed device-side USB peripheral core written in Verilog". In so far it can only implement USB devices, not hosts. A simple device function that can be used by many hosts without specific driver software would be e.g. HID (human interface device) like mouse or keyboard. But you need an USB host to operate it.

I don't expect to find an open-source "pure hardware" (operating without processor) USB host project.
 
Hi,

in my eyes it´s a good idea to stop this project now.
It´s over your current knowledge and you may encounter so much difficulties that you are not satisfied with the task for a long time.

Now you want to design a HOST. I find a HOST way more difficult than a DEVICE. From hardware (power supply....) as well as for the functions.

I also agree with FvM that a HID USB DEVICE maybe is the easiest.

May I ask why you don´t want to use a PC as HOST? Maybe start with LOW SPEED.


Klaus
 
I find a HOST way more difficult than a DEVICE.

Yes.

I will try with PC as a host. I will read more first on USB spec. It really requires reading and patience.
 

x8jaaaF.png


As discussed in previous post, for Cyclone IV, there's no calibrated series termination that matches the USB FS requirement of 28 - 44 ohm driver impedance.

I wish to know how does this 28 -- 44 ohm driver impedance relate to the typical 90 ohm USB transmission line ?
 

I wish to know how does this 28 -- 44 ohm driver impedance relate to the typical 90 ohm USB transmission line ?
See post #15. The exact single ended driver impedance matching the cable would be 45 ohm. There's no reasoning in the USB spec for the 28 - 44 ohm range of the full speed driver. In case of a combined FS/HS driver, the specification is changed to 45 ohm +/- 10%.
 
Technically configuring Tx outputs as tri-stated CMOS3.3 with 6 mA drive strength should give a decent 50-Ohm impedance match, so no resistors might be needed

3.3V / 6mA = 550 ohm

I am a bit confused by the statement above by others.

Could you comment about it ?
 

You forgot to mention where you picked up the statement.. It's not from this thread.

You apparently misunderstand the meaning of drive strength specifications. 6mA drive strength means that the maximal Vol and Vcc-Voh value is kept with 6 mA Io. If we assume ΔVo of 0.4V for CMOS3.3 (the Xilinx specification, Altera/Intel has different level margins) , the driver output impedance calculates as 67 ohm, that's however an upper margin. Actual output I/V curves have usually a 1:2 type variation, thus an uncalibrated output impedance is never giving accurate impedance matching.

Also consider that output driver have nonlinear MOSFET I/V characteristics with saturation. You can review ibis files for the respective device and IO standard to get the complete characteristic with variation range.
 
See https://electronics.stackexchange.c...tput-impedance-of-stm32h743-mcu/402819#402819

I need to check for cyclone IV instead of STM MCU as discussed below

UoB1xS7.png


- - - Updated - - -

@FvM

See page 9 and 10 of https://www.intel.cn/content/dam/al...terature/hb/cyclone-iv/cyiv-5v1-02.pdf#page=9 for Ioh and Iol.

jKLEDt0.png


30PGn5f.png


- - - Updated - - -

@FvM

See page 24 and 25 (for differential IO since usb is differential wiring ?) of https://www.intel.com/content/dam/w...literature/hb/cyclone-iv/cyiv-5v3.pdf#page=24 which states the respective Vid and Vod instead of Voh and Vol. I am not quite sure which table to be used though.
 

I'm not sure what you are specifically asking.

Consider that FPGA IOs will never met the USB driver spec exactly, you need to use a dedicated USB PHY if you need to fulfill the specifications. But as previously mentioned, it's hardly necessary to implement a 100 % USB compliant driver for your project. In so far, the discussion is pretty useless.

Modern FPGA IO's are not 5V tolerant, USB LS and FS interfaces are however required to withstand 5V Vbus shorts without damage.

You see that recent Altera/Intel FPGAs have limited choice of 3.3V IO standards, particularly they don't offer calibrated internal termination and differential Rx and Tx. All you can do is to use the available standard and add external termination resistors if appropriate.
 
Regarding the voltage divider used to generate 3.3V from 5V line for Vbus detection as well as for the pull-up (to 3.3V) 1.5k resistor on D+ line, someone told me this:

Passive "deriving" from VBUS has a lot of problems. If the divider has low resistance and "equivalent" pull-up meets the minimum relaxation time of 2.5 us, the device will likely fail the suspend current limit. If the divider has high-value resistors, it may fail either 2.5 us, or 15k pull-downs on host side will lead to invalid pull-up level. I recommend the pull-up to be "controlled" through another GPIO

Any comment ?
 

Yeah, I think you should think about these problems if you plan a commercial product that has to pass USB compliance tests. Do you?
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top