Why aren't you using the FT2232?

Posted by: Dave Vandenbout 6 years, 5 months ago

(1 comment)

I recently received an email which contained the following question:

Well, despite the great choices you have made making the XuLA, I was wondering why you did not use a Cypress (e.g. cy7c67300) chipset (but instead you used a PIC) for the virtual JTAG over the USB. The Cypress would have given to the board the possibility of having a full fledged USB 2.0 comm. port after the FPGA is programmed, am I wrong? With the Cypress you could have used firmware available around the internet...

Also, if I do not mistake, instead of the PIC you could have used a FT2232D which next to the virtual JTAG it would have given a serial RS232, which is quite a good thing for FPGA. Did you consider this lack of serial comm.?

In response, I provided a concise comparison of the PIC 18F14K50, FT2232D and CY7C67300 with respect to the requirements of the XuLA Board (edited a bit to make me look more erudite):

  • Component cost is of primary importance in order keep the price of XuLA low. For a quantity of 100, the PIC is $1.74, the FT2232D is $5.17 and the CY7C67300 is $14.21. I don't mind people making money, I just don't want it to be my money.
  • The XuLA form factor is only 51mm x 25mm, so the chips it uses must be small to fit onto the PCB. The PIC comes in a 20-pin SSOP (56 sq-mm), the FT2232D is in a 48-pin LQFP (81 sq-mm) and the CY7C67300 is in a 100-pin TQFP (256 sq-mm). Even if I get more I/O pins with the other chips, there aren't any more I/O pins on the FPGA to connect to them so what good is that?
  • The PIC performs several support functions like handling board reset and generating a clock for the FPGA. The FT2232D can handle the reset function, but I don't see that it will provide an external clock signal that can drive the FPGA, so an external oscillator for the FPGA would be needed (more board space, more money). The CY7C67300 has a built-in PWM so it could generate the FPGA clock, and it could also handle the board reset.
  • XuLA is intended to run at 3.3V in stand-alone mode. The PIC can operate anywhere between 2V and 5V. And while the CY7C67300 does operate at 3.3V, the FT2232D only operates at 5V.
  • To adapt to new applications, the ability to change the firmware is important. The PIC firmware is open-source and stored in reprogrammable flash in the chip. The FT2232D has no user-alterable firmware. The CY7C67300 firmware is changeable but needs to be stored in an external flash for stand-alone operation (i.e., when the USB is not connected), thus adding cost and using more board space.
  • In order for users to create new firmware, they need a freely-available programming environment. There is a free IDE and C compiler for the PIC. The FT2232D has no changeable firmware, so obviously there are no programming tools for it. As for the CY7C67300, I honestly don't even know what programming tools exist for that chip.
  • The PIC has two analog I/O pins that go to the XuLA prototyping header. I haven't used them for anything yet, but they've gotta be good for something. Neither the FT2232D or CY7C67300 have any analog sampling functions.
  • In regards to speed, the PIC and FT2232D both support USB 2.0 FS (12 Mbps), while the CY7C67300 supports USB 2.0 HS (480 Mbps). On the XuLA, the communication between the USB and the FPGA occurs through the JTAG pins which have a maximum clock freq of 50 MHz, so most of the 480 Mbps bandwidth of the Cypress chip would be wasted. The 12 Mbps bandwidth is still pretty fast when uploading/downloading to the XuLA.
  • As for doing serial COM over the USB link, the PIC firmware can be changed to support that. I don't see any particular benefit since we already use the commonly-available libusb driver and I'm getting ready to release a library that makes it easy to get data to/from the XuLA. But being open source, people can implement whatever interface they want.

The above comparison is not meant to imply that the 18F14K50 doesn't have any faults. It only has 16 KB of program flash, 2 KB of which is already used for the flash bootloader (which manages the reprogramming of the chip over the USB link). And the Microchip C18 compiler, combined with the PIC 18F architecture, really eats up the program memory quickly. And the chip only has 256 bytes of RAM for the USB buffers, which makes it impossible to use full-size, 64-byte, ping-pong, transmit & receive buffers. So that reduces the USB bandwidth. But, so far, these flaws haven't been deal killers.

Now, did I make the right choice? I don't know. What I do know is that, eventually, you have to jump off the fence and go pick a horse to ride or else you'll never get anywhere. The 18F14K50 is my horse, now the journey will show if she's a nag or not.


Current rating: 3.5


  • There are currently no comments

New Comment

required (not published)

Recent Posts






RSS / Atom