Cyclone III development board and USB FT245BL

[Altera_Forum]

Hi, 

 I currently develop with the cyclone III development board (EP3C120N). The board features two USB chips. The Cypress chip is used for the byteblaster logic and as I understand the documentation I can use the FT245BL for my own communication. Interestingly both chips share the same USB connector. So it must be possible two select either chip. The connections from the Cyclone to the FT245 are routed through the Max EPLD, so there must be some kind of configuration. I haven't found any documentation on that. So does anyone know, how to use the FTDI chip on this board?  Cheers, Alex

[Altera_Forum]

Hi, 

 I'm still a bit in favor of a combination between USB and uart --> the USB to serial converter. It's cheap, easy to implement, and if you combine it on your board with the fpga, you don't need the RS232 level converters, so you can use higher speeds (1Mbit for example).  ALso the interfacing with the PC goes through a COM-port interface, so it is easy, no dll's to add...  Even when you can not change your hardware board to add the FTDI-chip, you can use it. Take a standard USB-RS232 converter, open it, remove the level converter and connect it TX, RX and ground directly to some logic inputs (watch out for the correct signal levels).  Note, because of using logic signals, place the systems close togheter.   A good idea can also be to use an isolated USB-serial converter, this removes the ground connection between your system and the PC.  Stefaan

[Altera_Forum]

Hi, 

 @vjalter: I'm currently happy with my UART solution, but I just like to play with the USB chip on the devkit to see whether the latency of a USB connector would be feasible for my application. For now I have to use a USB to RS232 connector with my Notebook anyway, as it doesn't feature RS232 anymore (without docking station), so I have the latency anyway. @Stefaan: There is also a USB-TTL connector cable you get from FTDI, so you don't have to crack up your RS232 converter:  http://www.ftdichip.com/products/evaluationkits/ttl-232r-3v3.htm  Cheers, Alex

[Altera_Forum]

I know, but I used it sometimes to connect to systems with a debug header with some spare pins of the fpga. 

 Indeed, if you have it on the board directly, there is no need to open the converter, and there is no problem at all.  Stefaan

[Altera_Forum]

@svhb: 

Yeah sure. But if you integrate it directly to the board, then I would go for the FTDI with parallel fifo interface. The only drawback is then that you can't use comport software anymore and you've got to write a software that can do bulk transfers. But I think that is not too hard.  Cheer, Alex

[Altera_Forum]

--- Quote Start ---  @vjalter: I'm currently happy with my UART solution, but I just like to play with the USB chip on the devkit to see whether the latency of a USB connector would be feasible for my application.   --- Quote End ---    We pointed several solutions for accessing the USB connector.   The easiest is by far using TCL scripts, but then it is probably the slowest.  A second choice would be to use the unofficially documented (seems more like not officially supported, rather than undocumented) jtag-uart interface using the atlantic DLL. Or you can use one of the undocumented interfaces, including direct access to the USB-Blaster using FTDI DLL API.

[Altera_Forum]

--- Quote Start ---  but I just like to play with the USB chip on the devkit to see whether the latency of a USB connector would be feasible for my application  --- Quote End ---    For an FTDI-fifo application, even for the smallest write or read, you have to incorporate a latency of 1ms for writes, 2 milliseconds for reads. These are the minimum values that can be set in the driver. So you really must transfer big enough chunks of data before you get some interesting bandwidth.  Stefaan

[Altera_Forum]

He is using an FTDI USB-232 converter. I think the latency timer is not specific to FIFO mode. If I'm correct, he is already limited by exactly the same latency. 

 The latency timer affects only small transfers, less than 64 bytes. As soon as the 64 bytes buffer is filled, then the timer is not relelvant.  You still get a significant latency no matter what. USB is not a low latency protocol.

[Altera_Forum]

--- Quote Start ---  The latency timer affects only small transfers, less than 64 bytes. As soon as the 64 bytes buffer is filled, then the timer is not relelvant.   --- Quote End ---    I'm not really sure of this. I think the latency is there anyway, even sending/receiving bigger blocks. But of course with bigger blocks it becomes less importand.   I think it has to do with the oprating system behaviour, more than with the USB-protocol itself.   Stefaan.

[Altera_Forum]

--- Quote Start ---  I'm not really sure of this. I think the latency is there anyway, even sending/receiving bigger blocks. But of course with bigger blocks it becomes less importand.   I think it has to do with the oprating system behaviour, more than with the USB-protocol itself.   --- Quote End ---    The latency timer, the one that you can change with the API, is a timeout value. The idea is to not send a packet immediately after receiving the very first byte, because otherwise it would send single byte packets, very inefficient. It specifies the timeout that once expired, the device will send a packet even when the buffer is not full. Then it doesn't affect packets that fill the 64-bytes buffer.  It has no relation with the operating system behaviour at all. This timeout controls only the transmission from the remote end, where the actual chip is located, to the PC. It doesn't affect transmission from the PC.

[Altera_Forum]

--- Quote Start ---  The problem is, that part of the MAX II logic, particularly the USB Blaster function, must be expected protected Altera IP that unfortunately won't be disclosed. This is a serious obstacle when intending a user defined MAX II logic including the USB Blaster functionality. At best, Altera would find a way to pack the USB Blaster to an encrypted core, that is bound to the Dev Kit.  --- Quote End ---    Is the protocol to program Altera ICs (via JTAG) protected?  I would imagine that the IP in Altera's Cyclone II Kit (MAX 3000 CPLD - EPM3128AT) or the standalone USB Blaster (EPM7064), could be re-written based on the (published?) protocol, no?  For example, something like opencores.org has a JTAG IP, which should implement the same jtag programming that the Blaster does... am I missing something?

[Altera_Forum]

--- Quote Start ---  Is the protocol to program Altera ICs (via JTAG) protected?  --- Quote End ---    No. And it is well documented.    --- Quote Start ---  I would imagine that the IP in Altera's Cyclone II Kit (MAX 3000 CPLD - EPM3128AT) or the standalone USB Blaster (EPM7064), could be re-written based on the (published?) protocol, no?  --- Quote End ---    Yes, you could do that. But then it won't work anymore with Altera tools.  The Altera tools (Programmer, Signal Tap II, etc) all depend on a specific USB Blaster protocol. Is this protocol that it is undisclosed. Otherwise you could make your own Max II IP compatible with the USB Blaster protocol.  And also the jtagserver protocol is undisclosed. If the latter was published, you could replace Altera's jtagserver with your own.

[Altera_Forum]

To access Altera FPGA and CPLD through JTAG, yo have basically two options: 

 - Use third party JTAG tools. All production related actions (programming of CPLD, test by boundary scan can be done by industry standard protocols and are basically documented. Development related actions, e. g. download of temporary JTAG configurations from *.sof files is using proprietary JTAG instructions, but documented as well. The Virtual JTAG protocol involved with most communication between tools and FPGA has been recently documented in virtual JTAG MegaFunction manual, the specific application protocols, e. g. for SignalTap II or In-System Memory Editor are undisclosed, but more or less simple.  - Use Altera JTAG programming hardware through Altera software stack. Only part of the existing interfaces respectively access pathes has been yet documented, particularly access of virtual JTAG through tcl commands and a JTAG UART interface.   If you understand the USB Blaster protocol, you can also combine both methods, perform generic JTAG through USB Blaster. It may be interesting for accessing other vendors devices in the JTAG chain or boundary scan tests of Altera devices through an existing USB Blaster.

[Altera_Forum]

--- Quote Start ---   If you understand the USB Blaster protocol, you can also combine both methods, perform generic JTAG through USB Blaster. It may be interesting for accessing other vendors devices in the JTAG chain or boundary scan tests of Altera devices through an existing USB Blaster.  --- Quote End ---  That would definitely be my goal.. have the Altera FPGA support the ByteBlaster protocol so that any JTAG devices that hang off of it may be programmed via the Quartus software. I use Quartus/USB-Blaster in Windows, but isn't there an (open-source) Linux version?  Doing some poking around, it seems the USB Protocol was once posted, but has since been taken down  (  http://wiki.openchip.org/index.php/altera_usb_blaster  http://wiki.openchip.org/index.php/altera_bitblaster  )  On the bright side, there appears to be one project that might have already done this before, or at least come to close.. http://www.ixo.de/info/usb_jtag/

[Altera_Forum]

--- Quote Start ---  We pointed several solutions for accessing the USB connector.   The easiest is by far using TCL scripts, but then it is probably the slowest.  A second choice would be to use the unofficially documented (seems more like not officially supported, rather than undocumented) jtag-uart interface using the atlantic DLL. Or you can use one of the undocumented interfaces, including direct access to the USB-Blaster using FTDI DLL API.  --- Quote End ---    After reading the topic I am still not sure what's the best way to get FTDI USB to work. Did anybody really try to use FTDI D2XX DLL API for USB to PC communication?

[Altera_Forum]

--- Quote Start ---  After reading the topic I am still not sure what's the best way to get FTDI USB to work. Did anybody really try to use FTDI D2XX DLL API for USB to PC communication?  --- Quote End ---    Well, after all I just took external USB DLP-USB1232H and connected to HSMC. Works good with ~ 80 Mbps throughput.

[Altera_Forum]

>>"I just took external USB DLP-USB1232H and connected to HSMC". 

- How did you do that? I need to do the same, can you please elaborate? My design has a DVI board on the HSMC, is there something I can buy to share that HSMC with the DVI? found5520@yahoo.com Thanks.

[Altera_Forum]

hi everybody 

i recently begin programing uc/os for nios II board, when i run its examples,they run without error, but when i write a new program myself it gets errors for include"includes.h" and for stack functions like os_stk task1[task1_stacksize] and many other functions, so i want to know should change any setting or add any libraries when i begin a new project? thank you  Sepideh

[Altera_Forum]

--- Quote Start ---  >>"I just took external USB DLP-USB1232H and connected to HSMC". - How did you do that? I need to do the same, can you please elaborate? My design has a DVI board on the HSMC, is there something I can buy to share that HSMC with the DVI? found5520@yahoo.com Thanks.  --- Quote End ---    Well, I just took that USB module and connected it to HSMC (through HSMC debug header). I assigned appropriately input, output, inout pins on FPGA with those on USB. Potential issue here is voltage levels on both sides. USB has 3.3V pins and FPGA 2.5V. USB recognizes 2.5V inputs, so that's fine. 3.3V inputs to FPGA also is fine, I just turned off clamping diodes on FPGA inputs to protect them. I am not sure about DVI, you need to understand voltage/current levels to not to burn pins on chips