Custom PCB Design

the devkits can be used as a reference, but do also take a look at the schematic review worksheets and pin connection guidelines as sometimes the devkits are released before the devices are fully characterized and design recommendations are updated.

http://www.altera.com/support/devices/schematic-review-ws/srw-index.jsp

as far as i know the USB Blaster CPLD code is not released with the kits.

--- Quote Start ---

as far as i know the USB Blaster CPLD code is not released with the kits

--- Quote End ---

Unfortunately it isn't. As previously reported, USB Blaster clone designs can be found on the internet, they may or may be not achieve full functional compatibility. Considering the fact, that the basic USB Blaster protocol is more or less common knowledge, Altera may want to open the design one day. Of course you can ask for a license as well.

Thank you both, thepancake and FvM.

I assume what the USB Blaster do is a conversion between USB protocol and JTAG protocol. Is that correct?

Best,

The USB Blaster uses a FT245 USB to parallel FIFO interface. The translation between the FT245 8-Bit parallel intreface and JTAG involves a combination of bit-banging commands, that can set each JTAG and additional AS interface line to arbitrary states and fast SERDES operation, that streams multiple bytes in and out without issuing a new command.

The MPSSE (multi protocol synchronous serial engine) of the newer FT2232 chip offers basically a similar mode of operation. It has been an obvious idea to utilize the FT2232 for an Altera JTAG programmer as well, and Sasco has done it in the BeMicro. (This wasn't possible without Altera support for programming the device driver on top of Altera JTAG Server of course).

As discussed in a previous thread, using this driver (and a respective configuration EEPROM), an FT2232 can be used as an Altera programming interface. http://www.alteraforum.com/forum/showthread.php?t=20490

With the current driver, the BeMicro solution is about 50% of USB Blaster speed in AS programming, but considerably slower in Signal Tap II operation. I think it's rather a driver issue than caused by a more effective USB Blaster protocol, because the raw USB traffic is almost equal with both solutions, but I didn't yet check in detail.

There was at least a downloadable verilog module somewhere on the World Wide Waiting a couple of years ago.

module jtaghelp(clkin, resetn, usbtxen, usbrxfn, usrtdo, nstatus, clkout, usbrdn, usbwr, usrtck, usrtms, nce, ncs, usrtdi, led, tspin, usbd);

Haven't checked it yet, it looks very promising to be right one

But it would be worth to give it a try mostly if there is chance in speeding up the jtag a bit what would increase the overall speed of GDB useage as well as SignalTap.

From the source the "real" TCK is Bit 0 of the raw bit banged data. but the statemachine around it needs at least 3 clock cycles (IDLE GETCMD USECMD) in a loop so the TCK will be 24MHz / 3 = 6MHz

The question is, what are the limits ?

JTAG speed of the target devices and the pcb ? as well as the FTDI interface ...

Possible speed enhancement of an USB Blaster clone is of course limited by the USB FS throughput below 12 MBit/s. Furthermore, some Altera devices have a TCK limitation of 10 MHz (e.g. MAX7000S, MAX9000, ACEX1K). So a faster clock than 6 MHz isn't an option for a universal JTAG programmer, but possible for a dedicated FPGA interface.

Cyclone III could use up to 25 MHz, in principle. JTAG data lines are by design set on TCK falling edge and sampled on rising edge. Cyclone III already consumes up to 15 ns of the 20 ns delay margin on output, so JTAG communication would fail with only 5 ns additional delay. In practice, 24 or 25 MHz would require to change the data sampling phase in the CPLD, too.

Finally, I doubt, if the software driver stack allows for a considerably higher throughput than 6 MBit/s.

Thanks for these informations.

To sum it up, it would be hard to speed up the JTAG and explains why there is no faster JTAG Blaster available.

The JTAG modul itself takes about ~44% of the available logic a EPM240 has, so the rest could be used for example for an SPI interface between the user flash memory the MaxII device has and external components for non volatile data storage.