Parts list (rough design, options)

[ian]

The FT2232 has what they call the MPSSE engine which acts as a JTAG programmer, the FT232RL doesn't have that feature. The FT2232 would be able to program any JTAG device, the challenge is to find a project that already supports the device in question so you don't have to write your own program. URJTAG might support the 28pin AVR chip.

We can use a cheaper USB chip if we include SPI Flash with the design. We would just have to include a JTAG header and use a JTAG programmer to put the SUMP design into the flash before it is sold.

There's been a strong push for USB 2.0 support. I'm not sold on it being a requirement because the SUMP client is UART only, someone would have to add support for whatever proprietary USB device driver, just having a USB 2.0 connection won't make 115200bps go any faster.

However, I thought you used the FTDI chip in bitbang mode to JTAG program. I thought all the FTDI-based JTAG programmers did that. Now I see they use the MPSSE, and it's only on the 2232 (H is the USB 2.0 version). I googled around but couldn't find a simple 232R bitbang JTAG programmer to cannibalize, which seems the ideal option to me.

The 'H' (USB 2.0) version of the 2232 has two MPSSEs, so we could route 2 extra wires for the UART and add high-speed SPI data dumps via USB2.0 in a firmware update (assuming someone made the SUMP client compatible as well). Probably don't actually need two units for this, but maybe it's easier to route.

The 2232H looks like a pain to implement. It requires a 3.3volt supply, crystal, and the IO is 3.3volt only (though 5volt tolerant), supply pins everywhere. It's also a 64pin chip, which is a bit more expensive to place and QC. It may also require an external EEPROM for ASYNC uart mode (page 42 of the datasheet), and that will have to be programmed too, but page 20 says it defaults to dual async serial without.

I started preparing a partlist for Seeed based on a 2232H device, but I stopped when I saw all the support parts for the FT2232H. After looking at designs and datasheets, I think we should hash out a few things so we don't have to get an additional quote later.

Maybe we should consider a cheap microcontroller with USB and implement the Xilinx XSFV programmer in the micro for updates? I've implemented an XSFV programmer port for PIC, and I have a Spartan-3 dev-board, I'll test them together. We could make an SPI interface to the FPGA instead of UART, that leaves room for faster IO with updated clients (and might be easier to implement on the FPGA). The whole thing could be upgradable; USB-> bootloader->PIC, USB->XSFV player->FPGA.

USB 2.0 would be sexy, but a full-speed USB PIC has the potential for 12Mbps (I think). If the interface to the FPGA was SPI, then even an emulated serial port interface could be really really fast. A firmware update could implement a different interface (Full-speed, HID, etc) if anyone ever developed a client to support it.


I see few possible design, then:
2232H - USB2.0 connection with on-chip programmer, potential for SPI FPGA data interface via MPSSE2.
232R - USB connection with FPGA bootloader factory programmed, maybe route the IO pins for JTAG programming and hope someone is interested. UART connection to FPGA data.
uC - USB microcontroller with XSFV player for FPGA updates, and bootloader for microcontroller updates.  SPI connection to FPGA data. (I'd start looking at some of the '18fxxjxx' USB pics, they're 3volts and much cheaper than the 5volt parts)

[IPenguin]

I have been thinking of a (true) OS logic analyzer project (and actually been working on a very similar concept as presented above) for some time now. I can see that some members with quite some reputation are interested in such a project by reading the comments/discussion on the blog.

So the approach FT2232H plus Xilinx Spartan 3E (possibly with some external SRAM) jumps to mind immediately (I actually started in this direction) and appears to be the obvious choice it may not be the best  approach for a true OS project!

If we are thinking OS (and that would include the development tools and distribution of firmware and applications) we run into some serious problems (like Ian has found in the #twatch project with the PIC TCP/IP stack license issues and the PIC compiler) regarding the distribution of drivers linked with the FTDI DLL (that is crucial for implementing JTAG functionality in any FT2232 based project).

[site note: I am quite happy to see you moving towards a far more OS friendly environment with your latest project(s) :) )

Let me point you at following discussion regarding the issues the OpenOCB project ran into regarding the distribution of drivers for FT2232 based JTAG interfaces:

http://www.yagarto.de/howto/openocd/note.html
https://lists.berlios.de/pipermail/openocd-development/2009-June/007971.html

So this applies to Windows implementations only, the Linux support for FTDI based JTAG interfaces lags performance and has some other issues. However, an OS logic analyzer should have the poetential to support all major OS (operating systems in this case).

An other problem I can see is the Xilinx ISE Development suite (and any other dev environment for FPGAs like Altera, Lattice or Actel). They all come with commercial licenses, so you may get the basic editions for free but some for a limited time only (i.e. Actel).

For me both issues (FTDI DLL distribution and FPGA development environment licenses) were the reason to abandon the FTD2232(H)/FPGA based concept and to look for a completly different, true OS friendly approach.

A few month ago I ran into XMOS (there's life in the old dog (INMOS Transputer) yet^^) and their concept of event-driven processor seems just perfect for a most flexible, low-cost, yet powerful logic analyzer, JTAG controller and far more fancy stuff included.

Their "event-driven multi-threaded processor engine with tightly integrated pin I/O, which is the building block of XMOS event-driven devices" comes with true OS development tools and more than plenty of I/0 bandwith for a LA with 100 MHz bandwith and 32 channels even in their low end devices, USB 2.0 (only a USB PHY is required), Ethernet (!) and JTAG support among other nice stuff is available for free and for free distribution.

One or multiple XCore chips (XS1-L1, XS1-L2 or XS1-L4 would offer anything and far more than the combination of a FT2232 and a Spartan 3E!

If anyone is interested, I am open to take the discussion XMOS XS1 vs FT2232/Spartan 3E further and draft a raw concept for a basic XMOS based LA/JTAG design.

P.S. Together with some friends I developed a low cost logic analyzer for Aplle II and PC in the early 80s (may take a pic when I can find it) and would love to get involved into such a project again.

[IPenguin]

Afterthought - since the design will require assembly of a rather complex SMD chip (FPGA) it won't make a difference if an FPGA or a 2 core XS1-G2 (or 2 XS1-G1 - one for the channels and the other for the USB and JTAG interface), maybe even a 4 core XS1-G4 will be used in the design - neither in cost for the chip nor the assembly.

The whole design would be easily scalable (16, 32, even 64 channels), firmware development would be all in C/C++ (no VHDL, Verilog), protocol analysis and decoding could be easily implemented in the device and even far more complex features like real-time FFTs or an add-on with a fast AD/DA for an OSD/signal generator etc. would become possible - options that would make the device more versatile than existing commercial low-cost devices like the Salea Logic, Usbee or Zeroplus LAP at a real low-cost budget.

[ian]

The chips are cool, but the thing that gets me is the OTP (one time programmable). Starting from scratch is hard, I'd really like to have PCBs to fab in a few weeks time :)

My goal is to use as many open tools as possible, but I won't sacrifice a cool, convenient design because of the license. As long as someone can (legally and physically) reproduce it, I'm OK. Only a small percent of users upgrade at all, and one or two of those will compile the code. The Bus Pirate has 2-3 thousand users, but only one person besides myself has compiled the code (AFAIK).

I read a lot about the FTDI driver/GPL linking problem when I researched adding Bus Pirate support to OpenOCD. If we used a PIC microcontroller for the USB interface we'd get a mixed bag. On one hand it we could use an open USB specification supported by open drivers on all systems (CDC-class, virtual com port), but I'd use the Microchip USB stack on the chip which is not redistributable (because I'm lazy, and there's no open alternative that I've found). However, getting the stack is as easy as downloading the free source from Microchip and copying the project folder into it. I think that's a fair compromise until there's something better. The PIC USB specs, and the CDC protocol, are all available so there's no reason a determined individual couldn't write an open replacement.

To tell the truth, there's all sorts of people redistributing the USB stack if you google it, so maybe it's not the same as the TCPIP stack. But, I have decided not to redistribute any code that isn't explicitly under an OSI license like GPL. I release most of my work into the public domain so you don't have to worry about invented problems like license incompatibilities.

[bdsmith]

Since it will probably have the capability to define a triggering condition based on the states of several signals, then also having that resulting trigger come out on a pin might be useful.  This would allow this device to be daisychained and used to trigger another device - like a second logic analyzer operating at different capture rate or like a scope to look at some analog signal at that point in time.

[ian]

IPenguin pointed out in a PM that we'll need to:
1. Load the design into the FPGA every time,
2. Put the design in an EEPROM and use the automatic bootloader in the XILINX chips to read the design out at power-up,
3. Use a non-volatile FPGA.

I'd like to hear from Jack on this one, how do you do it on the Butterfly? I didn't see an EEPROM (and I noticed you only need an 8MHz chip with the PLL). If we put the design in an EEPROM, then we could easily write an EEPROM programmer for the 232R or USB PIC which is a ton easier than messing around with the XSFV programmer (or we can do both, options are good!).

[ian]

A little light reading:

How to configure a Xilinx FPGA from a flash PROM:
http://www.xilinx.com/support/documentation/prom_programming_and_data_storage.htm

I read Xapp445, which I could only find through this spammy site:
http://www.datasheetpro.com/node/120742

This is great. Programming a ROM is a lot easier than JTAG or a variant like XSFV programming.

After a few hours of mulling I really feel like a UC (28 pin SOIC pic) would be a good interface chip. We can add faster USB transfer modes via bootloader, and read data out of the FPGA by SPI. Update the FPGA design by programming the ROM chip. Still connect the JTAG pins to the PIC if we decide if implementing an XSFV programming is ever attractive. An interrupt from the FPGA to the PIC could trigger data transfer when the memory is full.

[ian]

Last thing for the day, a rough sketch. Hope you can read my scrawls.

[LukeS]

Another option you could to do greatly reduce the complexity of layout, development time, and cost is have the board interface with a standard mass produced FTDI module like these:
http://www.mouser.com/ProductDetail/FTDI/FT2232HQ-MINI-MODULE/?qs=PDIOggHaj2xKaUJdpdEcCA%3d%3d
http://www.mouser.com/ProductDetail/DLP-Design/DLP-USB1232H/?qs=d4LE%252bqfehajimTRmAo2EMg%3d%3d

You could put a pin header for the UART on the board so users could use a FTDI 2232H or lower cost FT232R module.  As you know the lower cost FT232R does not support MPSSE so you would have to use some other method for JTAG programing

[LukeS]

I read Xapp445, which I could only find through this spammy site:
http://www.datasheetpro.com/node/120742

I found this on the xilinx site which is very similar: http://www.xilinx.com/support/documentation/application_notes/xapp951.pdf

[jack.gassett]

Wow, there is a lot to reply to here. I feel at a disadvantage living in the US timezone here.

So I'll dive right in, I think we can easily adapt my existing design and just make it a lot cheaper. The Butterfly Light hardware is designed as a dev kit so it has much more functionality then we need for a Logic Analyzer application.

I love all the great alternative design ideas but I wonder if it would be reinventing the wheel? I already have a working hardware design (http://www.gadgetfactory.net/gf/project/lax/) that works great and the Sump project has been proven for years. It would be a shame to abandon all of that pre-existing work.

Maybe we should define what our primary goals are:
   1) Logic Analyzer for $30-40 US dollars
   2) 70Mhz+ speeds
   3) 16-32 channels

Secondary goals:
   1) Add a Voltage Buffer
   2) Make it as DIY as possible.
   3) Make it as Open Source as possible.

Of the 3 Primary goals the existing design already accomplishes two of them.  The design just needs to be streamlined to see if we can get it into the $30-40 price range. A lot of that equation depends on what Seeed Studio quotes us for parts. I think we should take the path of least resistance and streamline the existing design as much as possible and see where we end up price wise. If we are not in the $30-40 range then we can start exploring our alternatives to get the price down and meet some of our secondary goals.

I'm wrapping up on an AVR instruction set compatible Soft Processor project that I'm trying to submit to hackaday right now. (http://www.gadgetfactory.net/gf/project/avr_core/) Once that is finished I will be focusing all of my energies on this streamlined logic analyzer project. My first task will be to take the existing design and rework it into a streamlined design with the bare minimum required parts to work. I think I should be able to accomplish that in the next couple of days depending on what happens with the Soft Processor project.


In anticipation that the final streamlined design is not going to fall into the $30-40 price range then here are my responses to some of the comments below.

I think we can make a lot of cost saving in the power supply. We can use chips that supply much less current then the 1A used in the existing design.

If we determine that the FTDI2232 is too expensive then we have the option of implementing the simplest and cheapest option to program the Xilinx chip which is the Atmel SPI Flash option. That leaves us free to use the cheapest USB solution we can find or even a MAX232 option, which I'm not thrilled about but would be cheap. The cheapest USB option I know of is the Cypress CY7c638 family that has a built in oscillator. (http://download.cypress.com.edgesuite.net/design_resources/datasheets/contents/cy7c638xx_8.pdf) It is available for 2.06 in quantities of 1 and $1.6 in bulk. (http://www.futureelectronics.com/en/Search.aspx?dsNav=Ntk:PlainTextSearch|3700911|3|,Ny:True,Nea:True) It requires minimal external components because of the built in oscillator. I've never personally used it but I've heard good things about it.

So in response to some of the other concerns/issues raised:

My existing design uses the FT2232D rather than the FT2232H. The FT2232D is USB 2.0 but it is capable of USB 2.0 Full Speed (12M bits/second) while the FT2232H implements USB 2.0 High Speed (480Mbits/second) and Full Speed (12Mbits/second) compatible. Interestingly enough the FT2232H is available for a couple dollars less than the FT2232D.

SPI transfers, if we routed the appropriate signals then theoretically the MPSSE port could be easily re-purposed for SPI communications after the Xilinx part is programmed. There would be no need to use a second MPSSE, the same MPSSE could be reconfigured as SPI.

Requirement for ISE Webpack:
The design is synthesized to an svf file and loaded by URJTAG. There is no need for the end user to install ISE Webpack. OpenOCD is not used.

Loading the design every time:
Since the nature of the Logic Analyzer is a tethered application it is no big deal to load the design every time the device loses power. It takes less than 2 seconds to load the design. If the cost requirement makes us go the SPI Flash route to load the design then this becomes a moot point.

Xilinx Flash Proms are more expensive than SPI Flash.

Phew! That was a lot of typing.

Jack.

[IPenguin]

Ian and I have thrown some ideas forth and back in the background and I agree that the FT2232(H)/FPGA or USB MCU/FPGA concept is the one to be pursued for this project. The XMOS idea still needs quite a bit of evaluation and testing first.

After going over Jacks Butterfly concept it becomes obvious that he's got the essential design /and far more) already done and implemented quite nicely.

Ian's rough sketch is right on and gives a good idea of the concept (so the (configuration) ROM will not be needed).

Considering that the LA/JTAG will be connected to a PC via USB (or Ethernet) when in use and draw its power from the USB port (if possible) there is no need for on-device configuration memory.

I agree with Jack's goals and priorities - keep it low-cost, simple and make it as DIY as possible.

FT2232H/D or low-cost USB MCU: so the price for the FT2232 will be about 2-3 times of the cheapest USB MCUa many arguments speak for the FT2232:

- good JTAG support without the need of reinventing the wheel (full OpenOCD support as a JTAG debugger if that's still a wanted option)
- "build-in" UART, SPI, I²S, JTAG, bitbang and parallel FIFO capability (mode can be switched on-the-go from the PC)
- well documented DLLs (Windows) and open source code (Linux) for MPSEE utilization
- high (FT2232D)/very high (FT2232H) bandwith
- de facto standard for JTAG programmers/debuggers

Other simple FT2232/FPGA examples with very similar concepts (for general purpose use) are:

DLP-FPGA - Xilinx Spartan 3E and FTDI FT2232D prototyping/educational module

Morph-IC product site
Morph-IC Data Sheet

For those interested in all the different device configuration options available for the different devices of the Spartan 3 family I suggest following Xilinx document - i.e. there is a parallel mode and JTAG mode besides the serial mode if an MCU is used to load the configuration:

Spartan-3 Generation Configuration Options - Chapter 1, p. 27 ff - in particular the table on page 31.

My first attempt for a project name: LAbug ,,,

[ian]

I really like these ideas:
1. An EEPROM. I'd prefer not to load it separately every time. I haven't looked at compatible ROMs though, so I'm not sure how much extra that adds to the cost and what the supplier options are.
2. SPI interface between the FPGA and the USB chip (whatever that is) for faster than 115200bps transfers later. SPI works at whatever speed, faster uart output from the FPGA would need configuration or a software change.
3. A buffer. The M74LCX16245DTR2G buffer has better features (I/O) and is also really cheap, it's probably the better choice. The 74LVT573 is smaller and is input only, but not a TSSOP48 package. If we do the 16bit buffer, I think it's important to have at least 8 extra channels for direct IO and connecting an ADC. Though I also like the idea of 16 channels with 8 buffered. This device is competing in the Saleae Logic and BusBee price range (cheap...), they only have 8 channels.

I go back and forth between the FT2232H or a USB microcontroller.  I've been considering the H part for availability and price, but I'm open to either. I'm not thrilled about learning and prototyping the H chip with so much else going on in this design:

FT2232H -
+Widely supported by utilities that can program the FPGA by JTAG or the EEPROM by SPI,
+ Jack's existing tool chain
+ USB JTAG debugging (?)
+Existing layout (for D, not H)
+No firmware troubleshooting (but maybe driver and utilities)
- Faster (SPI) interface will require some major updates (SUMP to use FTDI driver)
- Big chip to route & prototype, expensive to place and QC (64 TQFP ~ $1.20 to place, + support parts)
- Requires various drivers, and we'll be dependent on them if we use the MPSEE

Microcontroller-
+ Small chip to route and prototype, cheaper to place and QC (28 pin SOIC). Maybe cheaper parts.
+ Emulated virtual serial port is an open standard available on every system, usually without drivers. Even USB-OTG hosts like WinCE organizers support it.
+ Implement high-speed transfers on all platforms with minimal changes (read by fast SPI with uC but send as serial port over USB FS (12M bits/s), change SUMP to have higher serial port speed settings).
+ EEPROM updates via STK500 clone firmware. Isn't that supported by everything?
+ Upgradable to other protocols, to do FPGA support functions, etc.
- No JTAG debugging
- Not a proven design, firmware to support (but that's my thing!)
- No existing design uploader tool chain

I'm a microcontroller guy, so if we go that route I'll commit to designing and coding the uC portion. I'm not advocating that, though, just say'n that I'll get'r done if we choose that. As a developer, I have a hard time letting go of the JTAG debugging features of the FTDI option.

The PIC 18F24J50 is an interesting option (probably $2-$3, $1.86 according to the volume pricing). It's a 3.3volt chip, FS USB 2.0, 10K times reprogrammable, and 28pin SOIC.  I like that it has 2 SPI modules (FPGA, EEPROM), one is even assignable by peripheral pin select for no-nonsense routing. It has a parallel data bus too, if SPI isn't fast enough. It needs 4 caps, a crystal, and a resistor. There's also a GPL USB bootloader tool chain for the 18F chips.

USB PICs:
http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=111&mid=10&lang=en&pageId=74

[ian]

Looking at the last link from Ipenguin:
the 250 needs a 2Mbit flash, the 500 needs 4Mbit

The recommended 2M parts are:
STMicro(Mumonyx) MP25P20 and Atmel AT45DB021D

Cool, 8pin SOIC for $1 @ 1
http://parts.digikey.com/1/parts/1081622-ic-flash-2mbit-66mhz-8soic-at45db021d-ssh-b.html


Except it's not available, and the 4mbit is only a few cents more:
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=AT45DB041D-SSU-ND

[ian]

After some gumbo for lunch, I'm going to go out on a limb and advocate for the microcontroller approach.

The biggest sacrifice I see by going with the uC is that it won't have USB jtag debugging. But, this is supposed to be a cheap and easy logic analyzer. If you (metaphorical you, not anyone here) want an all-in-one FPGA development board then buy Jack's awesome Butterfly platform, or any number of dev boards, or get a Wiggler and use the JTAG header.

I don't see how we get to the $30-$40 range without shaving every penny. Low pin count chips (28 pin PIC, 8bit buffer) are how I planned to do that when I was working on my own. SOIC chips (where possible) make it a more friendly DIY or kit, and make it easier for us to route and prototype.

A minimalist design, 16 channels, 8 buffered:
3-250 FPGA (144 TQFP)
2Mbit ROM (8 SOIC)
USB PIC (28 SOIC)
8bit buffer (20 SOIC)
3 x MIC5201 (1.8, 2.5, 3.3)

Support:
0.1uF capacitors - PIC:1, Buffer:1, ROM:1, FPGA:?
0.22uF capacitors - PIC:1 (or 2x0.1uF usually works)
10uF caps - Power: 3, PIC 1 (?)
27pF capacitors - PIC:2, FPGA:2
8MHz crystal - FPGA:1
20MHz crystal - PIC:1
Resistors: PIC:1, LEDs:3
LEDs: power, armed, trigger (3)
USB jack

Headers:
PIC ICSP
FPGA JTAG
ROM ISP
16+ channels
PIC serial port for legacy IO

Edit: removed some parts that weren't needed for the J chip.