External Peripheral Interface (EPI) and USB

Kevin Taberski1 said:

I was disappointed to learn that I can't have High-Speed USB and EPI simultaneously on this device.

 Hi Kevin, I am also disappointed on how pin are assigned to EPI distributed over the 4 side of chip carrier, this is a nightmare to do equalization.

 If no alternate pin are available and you cannot reassing them so no way to use both option.

 EPI has some alternate assignment, USB not.

 Transferring data @12Mbit IMHO is not a so big load and just a GPIO driven or thru SPI can be enough so also a more cheap 123 series can do the job. EPI can be useful at full USB or ETH or LCD refresh from large memory.

 USB port also collide if EPI size is reduced?

Roberto,

The reason for the TM4C129X is that we would like to include Ethernet as well - plus the 129X supports ULPI (if one does not need EPI).

The EPI pins that conflict with ULPI on this device are EPIS016, 17, 18, 19, 26, 27, 28 and 33.  The only EPI Mode that "might" support the exclusion of these pins is Host Bus Mode 16 (HB16 Signal) with Mode=XFIFO - see Table 11-9 in the data sheet - with the exception of EPI0S28 which is still assigned to RDn.  Would this mode work?  The hope, is to use uDMA for both USB (using ULPI) and and EPI to transfer data from an FPGA connected to the EPI pins.  Presently, I have no experience with this so I was planning on using the General-Purpose Mode which seems like a better choice for the FPGA interface, but precludes the use of ULPI.   The problem is, I need to choose prior to board layout.

The nature of my original question is - what data rate does the USB OTG port (in Device Mode) actually achieve?  Does it really support 12Mbps?  I've been burned by this in the past.  If we can't get High-Speed, we want to at least get a sense of what data rate we can achieve.

What would be ideal is a demo of EPI coupled with USB.

Thank you,

Kevin

 Hi Kevin, I see you selected a BGA part with LCD on board, so I understand board is expensive and I am still delaying board design, remember is a very fine pitch (100um or 4 mils track) to escape from a so small package.

 In my design I also selected HOST Bus mode for EPI, I am sorry I cannot test till prototype is ready and this moment I delayed to when sure all is working.

 About FPGA, you can use some wire to connect a demo board to test full code. This is the way I am using too, DK-tm4c129, DE0_Nano and the one MAXV on an adapter with .1 dual row pin.

 A lot of cheap male-male male-female and f-f wiring aids exist to do a proto in a short time.

Roberto,

Unfortunately, I do not have adequate time in the schedule to prototype and test this interface.  To some extent, that is the purpose of the first PCB - so I'm trying to choose carefully.

The current plan is to route all 36 EPI pins to the FPGA.  I may add the ULPI interface using zero-ohm resistors as jumpers - just to see if I can support ULPI and EPI Host-Mode.  I just don't like adding any kind of jumpers to USB signals.  I may just add the ULPI PHY and leave it as an optional stuff - then I can place series termination resistors in the EPI interface (which I will likely do anyway) so that I can test a couple different scenarios.

As for the BGA and ball-pitch, etc., we have that aspect covered.  The FPGA is similar - but bigger.

Kevin

Hi Kevin,

Kevin Taberski1 said:

My question is, what data throughput can I reasonably expect to achieve with the USB OTG port in Device Mode?  Will I achieve close to 12Mbps?  I plan on using Mass Storage Class.

USB MSC (Mass-Storage Class) is bad option, when you move data from device to host regularly. Host file system doesn’t suppose "file" on the device is overwritten outside of its regulation. To overwrite a file, a sequence, unmount/overwrite/re-mount of media, is required. Every time your device sends a block of data (file), this sequence should be repeated. As re-mount of media (readout of FAT and directory) takes so long time, regular data transfer over MSC is not realistic.

Instead, simple data exchange over bulk endpoints, like usb_dev_bulk example on the TivaWare, is recommended. Over a double-buffered bulk endpoint of full-speed (12Mbps) OTG, you may expect transfer speed of 16-18 full-size packets (64bytes) / 1ms USB frame (around 1M bytes/sec).

Tsuneo

Tsuneo,

If I understand what you are saying, the host PC will not recognize that a file has appeared (or has changed) on the target device unless the device is unmounted/mounted - is that what you claim?

I will investigate this further along with Bulk Transfer, but regardless my concern of data transfer rates remains the same.  Have you actually experienced transfer speeds of ~1MByte/sec using these (or a one of the Tiva family devices?

Thank you,

Kevin

Kevin Taberski1 said:

If I understand what you are saying, the host PC will not recognize that a file has appeared (or has changed) on the target device unless the device is unmounted/mounted - is that what you claim?

 Good point, yes pc scan attached hardware and flag as non removable media. Also if removable media mounted partition are considered on USB as single user so never checked for concurrent access. Only unmount mount refresh the disk image freeing up the cache too.

Kevin Taberski1 said:

Have you actually experienced transfer speeds of ~1MByte/sec using these (or a one of the Tiva family devices?

 Tsuneo is more expert than me and can confirm, I use USB  to read in host mode from a USB2 pendrive the speed is very close to 1MBps, this is enough for me transferring file of few tens of KB.

 Just curious about what vendor is from FPGA? A simple setup with wires require no more than two hour and is done all around DK boards.

Kevin Taberski1 said:

then I can place series termination resistors in the EPI interface (which I will likely do anyway) so that I can test a couple different scenarios.

 Series terminator? Are not meaning to 22Ohm series resistor? I am not sure EPI require termination, on documentation and board I seen manufactured it was simply coonnected to devicces.

Roberto,

We are using a Xilinx Kintex-7.  The intent is for an application to store data to SDRAM (attached to the FPGA), then transfer the data to the MCU via EPI and to a host PC via USB.

Both the FPGA and MCU have more responsibilities then this, but this is the piece that I'm focusing on for the purpose of this discussion.  A couple of hours may be adequate, but I suspect that you are faster than me - but that is merely just one step.  I would first need to acquire an FPGA dev board - with attached memory, wire up the 2 boards and also write the firmware for the FPGA, the MCU and possibly an application on the PC.  I will get to that, but unfortunately later rather than sooner.

Tsuneo,

Yes - series resistors - possibly 22 ohms.  It may not be required, but for SI reasons we'll likely add them.  Eval boards almost never use them, but at 120MHz they can make a difference.  Plus it makes a handy way to isolate signals and probe if required.

Kevin

Kevin Taberski1 said:

Yes - series resistors - possibly 22 ohms.  It may not be required, but for SI reasons we'll likely add them.  Eval boards almost never use them, but at 120MHz they can make a difference.  Plus it makes a handy way to isolate signals and probe if required.

 Good way, I am not driving so fast EPI and resistor are still a good practice, again as you stated a good way to isolate signals and rewire. Remember EPI is limited to max 60MHz not 120! Still enough to drive ENET @full speed and leaving space to access the sdram fro Display controller.

 FPGA can be available in a few day from DIGILENT

http://www.digilentinc.com/Products/Catalog.cfm?NavPath=2,400&Cat=10&FPGA7

  I fear this product is not so prone to be wired , the cost of the demo board approach the pcb manufacturing so your choice is right.

I am running into the same problem in that EPIOS28 signal is shared between EPI and ULPI interfaces. The EPI interface is configured for General Purpose mode with 8-bit data and address busses. EPISO28 is the WR signal for EPI Interface and the CLOCK signals for ULPI Interface. 

A possible solution is to derive WR signal from processing RD and FRAME in the FPGA. 

Has anyone done this before to verify if this method may work. 

Thanks

Manie

Hi Amit,

Just to let you know that I have tested the concept of generating WR from RD and FRAME on a prototype board and it works fine. 

This allows me to have a General Purpose bus interface to the FPGA (8-bit data and 8-bit address) while adding a TI USB PHY to the processor ULPI interface for High speed USB.

Regards

Manie