<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
John Ford wrote:<br>
<blockquote type="cite"
cite="mid16444.45378.82148.387484@gargle.gargle.HOWL">
<pre wrap="">I sent a message to cesys to ask about the usb issue. Here's their
response:
</pre>
<br>
<hr width="90%" size="4"><br>
<table border="0" cellspacing="0" cellpadding="0" width="100%"
class="header-part1">
<tbody>
<tr>
<td>
<div class="headerdisplayname" style="display: inline;">Subject:
</div>
AW: Linux interface for USB2FPGA</td>
</tr>
<tr>
<td>
<div class="headerdisplayname" style="display: inline;">From: </div>
"Ersin OEZALP" <a class="moz-txt-link-rfc2396E"
href="mailto:eozalp@cesys.com"><eozalp@cesys.com></a></td>
</tr>
<tr>
<td>
<div class="headerdisplayname" style="display: inline;">Date: </div>
Wed, 25 Feb 2004 15:15:58 +0100</td>
</tr>
<tr>
<td>
<div class="headerdisplayname" style="display: inline;">To: </div>
<a class="moz-txt-link-rfc2396E" href="mailto:jford@nrao.edu"><jford@nrao.edu></a></td>
</tr>
</tbody>
</table>
<br>
<pre wrap="">Hello Mr.Ford,
I am the designer of our USB1.1 and USB2.0 drivers for Windows and
Linux. You can find the answers embedded into your questions below.
Best regards,
/*********************************
Ersin OEZALP
Software & Hardware Design Engineer
Cesys GmbH
Tel: +49 9132 733404
Mobile: +49 177 7079176
E-Mail: <a
class="moz-txt-link-abbreviated" href="mailto:eozalp@cesys.com">eozalp@cesys.com</a>
Address: Zeppelinstr. 6a 91074
Herzogenaurach, Germany
*********************************/
Hello.
We are considering embedding 4 of your usb2fpga boards in a DSP system.
One of our software people is concerned that the USB2 support for the
cypress chip is difficult and clumsy to implement. His experience with
the Cypress chip on another company's product is included below.
-- This is why we wrote our own driver. Moreover, Cypress drivers have a
lot of bugs.
Our system needs to be able to seamlessly boot up, configure, and run.
What is your experience with the USB2fpga product and the Linux device
drivers?
-- I wrote the driver on Linux SuSE and tested it also on Redhat Linux.
Upto now I didn't realize any problems.
I *really* want to use your product if possible, as it will save us much
effort and the cost is reasonable. We are looking at buying either 10
or 11 boards total this year.
Thanks for any advice you can give me!
John Ford
Electronics Division Head
National Radio Astronomy Observatory
-- included comments on the CESYS USB interface:
* I have been reading documentation on the Cypress USB interface that
is used by the FPGA development board. The stuff available on
Cesys' web-site is dominated by documentation of Windows
software. As far as I can see, they don't give any specifics about
the FPGA interface to the USB module. I ended up going to Cypress
semicondutor's web-site, to look at the documentation of the USB
module itself, separate from the FPGA board.
-------------------------------------------
-- This is not true. We documented the interface between the FPGA and
the FX2 USB controller chip. Associated documents are generic firmware
specifications (CeUsb2gfw.pdf) and its extension (CeUsb2gfw_ex.pdf).
-------------------------------------------
It appears that to use this interface, I would not only have to
program the FPGA to talk to the Cypress USB interface module, but
also write specific firmware for the 8051 microproccessor within
the Cypress USB module, and write a specific USB 2.0 device driver.
This is clearly orders of magnitude more complicated than the
simple FIFO to virtual-serial-port interface that I was going to
use before.
-------------------------------------------
-- Not really. Our firmware uses the GPIF engine of the FX2 chip. Its
signalling to externals components is handled with waveforms which can
be changed by the upper level software (CeUsb2 API). So mostly what you
need is to copy the GPIF interface VHDL entities from our test designs
and connect your own external logic to them (FIFOs state machines etc.).
-------------------------------------------
* It turns out that the Cypress USB interface module that this board
uses is the same as the USB interface of an external USB 24-bit
soundcard that I use with my laptop. This was a pain in the neck to
get working. The problem is that the Cypress USB interface does
something unusual (they patented the technique, so probably nobody
else dares do anything similar). Whenever devices that use this
module are newly plugged in to the USB bus, the Cypress USB module
does the following.
A. It identifies itself to the USB host controller as a simple USB
peripheral with little functionality.
B. The device driver on the host is then expected to send the
Cypress module its firmware. This is a 200K file for my audio
card.
C. The Cypress USB module then disconnects itself from the USB bus,
then immediately reconnects itself, this time identifying itself
as a different USB device, with specifics taken from the new
firmware.
-------------------------------------------
-- This whole dynamic booting process is handled in our Windows and
Linux software for the USB2FPGA. We supply two drivers one of which is
the loader executable on both platforms.
-------------------------------------------
On my laptop, under RedHat, I managed to get this to work using
free software, and a copy of the firmware file, but it takes 15
seconds for the above process to complete, and after a reboot, it
only works if I manually unplug it then replug it in. If I leave
the device plugged in at boot time. Probably the boot-time poll of
the USB bus occurs before the host's USB interface is fully
initialized, so the immediate disconnect and reconnect confuses
it. Other than manually unplugging and replugging in the device
after each boot, I haven't found a solution for this problem. We
may have similar problems with the CCB if we use this development
board.
-------------------------------------------
-- Our booting process is faster since we handle everything in kernel
mode.
Therefore the problem you stated above doesn't appear in our software.
-------------------------------------------
</pre>
</blockquote>
All,<br>
<br>
I had already downloaded and studied the various documents that Ersin is<br>
referring to several days ago... And I tend to agree with his
responses to <br>
Martin's concerns and John's inquiries as follows...<br>
<br>
Level and quality of documentation...<br>
<br>
In general, if you're willing to dig a bit, there does seem to be
sufficient<br>
documentation available in support of hardware, firmware, and software<br>
(driver) concerns. At times, their documentation can be a bit cryptic
and<br>
there does seem to be a bit of a language (German) translation
aftertaste <br>
present as well; but, all in all, it's not too bad. And there seems to
be <br>
plenty of code snippets (in C++, VHDL, etc.) to serve as useful
examples...<br>
<br>
Interface to the FPGA's...<br>
<br>
The FX2's General Purpose Interface (GPIF engine) seems to be pretty <br>
well documented and should be rather straightforward to utilize. And as<br>
Ersin has indicated, the interaction of this interface with our FPGA's,
FIFO's,<br>
etc. can be tailored to our specific application by means of what's
called <br>
a "waveform descriptor" which is maintained in the internal RAM of the<br>
FX2 USB 2.0 controller chip and can be re-defined at download time.<br>
This descriptor is utilized by the FX2 controller chip in establishing
the <br>
hardware handshaking and timing used to manage external FIFO's, etc.<br>
Actually, I think this is a pretty clever (and cool) concept...<br>
<br>
General usability, etc....<br>
<br>
It appears that the FX2 USB 2.0 controller chip handles all of the
initial USB <br>
enumeration and
device ID tasks in a "transparent" fashion, leaving us to then<br>
deal with our initial application-specific configuration download.
Following this, <br>
we should be able to directly use the (automatically established)
ENDPOINT 0 <br>
(along with its associated "control pipe") for subsequent control
functions and <br>
the (automatically established) ENDPOINT 2 and ENDPOINT 6 (along with <br>
their associated "pipes") for optimized bulk data transfers, etc.
These last two<br>
endpoints (and pipes) allow for single, double, triple, and quad
buffering with<br>
buffer sizes that can range up to a maximum of 1024 bytes (under USB
2.0).
<br>
In this sense, once the initial USB enumeration and ID tasks are all
completed,
<br>
the FX2 USB 2.0 controller chip assumes the role of a control / data
conduit.<br>
To me, this functionality seems to be <u>very</u> well suited for our
application...<br>
<br>
There is one caveat however... <br>
<br>
Apparently, all CESYS USB 2.0 implementations ("CeUsb2") categorically <br>
DON'T support (permit) USB interrupt transfer types. Martin, I'm not
sure<br>
if you've even considered using this type of transfer over the USB. If
so, then<br>
we've got a problem. If not, then never mind...<br>
<br>
And in the same vein...<br>
<br>
I would recommend the (almost) exclusive use of bulk data transfers
used in<br>
conjucntion with occasional (very infrequent) requisite control
transfers. In<br>
any event, we should avoid any temptation to use Isochronous transfers
since<br>
they inherently don't support error handling and could lead to data
corruption<br>
problems...<br>
<br>
Randy<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>