Cyclone III development board and USB FT245BL

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

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

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

@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

--- 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.

--- 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

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.

--- 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.

--- 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.

--- 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?