Dangerous Prototypes

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)

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 (http://http://dangerousprototypes.com/2009/11/18/open-source-logic-analyzer-development/).

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 (http://http://openocd.berlios.de/web/) project ran into regarding the distribution of drivers for FT2232 based JTAG interfaces:

http://www.yagarto.de/howto/openocd/note.html (http://www.yagarto.de/howto/openocd/note.html)
https://lists.berlios.de/pipermail/open ... 07971.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 (http://http://www.xmos.com/) (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 (http://http://www.xmos.com/technology/silicon-technology) 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.

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.

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.

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.

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

A little light reading:

How to configure a Xilinx FPGA from a flash PROM:
http://www.xilinx.com/support/documenta ... torage.htm (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 (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.

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

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/FTD ... EcCA%3d%3d (http://www.mouser.com/ProductDetail/FTDI/FT2232HQ-MINI-MODULE/?qs=PDIOggHaj2xKaUJdpdEcCA%3d%3d)
http://www.mouser.com/ProductDetail/DLP ... 2EMg%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

[quote author="ian"]
I read Xapp445, which I could only find through this spammy site:
http://www.datasheetpro.com/node/120742 (http://www.datasheetpro.com/node/120742)
[/quote]

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

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/ (http://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/ (http://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.n ... 38xx_8.pdf (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/Sea ... e,Nea:True (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.

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 (http://http://www.dlpdesign.com/fpga/fpga.shtml)

Morph-IC product site (http://http://www.morph-ic.com/home.html)
Morph-IC Data Sheet (http://http://www.ftdichip.com/Documents/DataSheets/Morph-IC/DS_Morphic.pdf)

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 (http://http://www.xilinx.com/support/documentation/user_guides/ug332.pdf) - Chapter 1, p. 27 ff - in particular the table on page 31.

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

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/ParamChartSear ... &pageId=74 (http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=111&mid=10&lang=en&pageId=74)

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/108162 ... ssh-b.html (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/DkSea ... 41D-SSU-ND (http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=AT45DB041D-SSU-ND)

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.

Here's a cct with these basic parts and a mock layout on top of the Butterfly. After removing a bunch of the IO headers we'll have room for 0805 capacitors instead of 0402, and the PCB will get a lot smaller.

There are dedicated FPGA pins that need to connect to the SPI ROM, etc.

I used 2, 2x10 pin headers for 32 channels + several ground pins. I also included 2 8 bit buffers, but I think 1 is plenty (maybe a place for a second?).

The eagle files that go with it.

I like the cheap USB microcontroller approach and am ready to get fully behind it but before we completely commit I wanted to do a quick cost analysis of both options.

I got pricing for the parts off digikey and used the 100 units price across the board. I only priced the major components, no resistors/caps etc. The difference in price between the FT2232D option and the Microcontroller option is $2.42. With both options we can accomplish the $30-40 price range. What helps bring this price close is because the FT2232D option does not require a 3.3V power supply.

So knowing that both options fall within the desired price range does that change anyone's mind about which direction to go in?


Jack.

Excel spreadsheets.

I shouldn't give part numbers off the top of my head...

Cheap Vreg, same as the Bus Pirate (MIC5205) in SOT-23-5 @ $0.81 for 1:
3.3V
http://search.digikey.com/scripts/DkSea ... -1259-1-ND (http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=576-1259-1-ND)
2.5V
http://search.digikey.com/scripts/DkSea ... -1257-1-ND (http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=576-1257-1-ND)
ADJ (1.8/1.2?)
http://search.digikey.com/scripts/DkSea ... -1262-1-ND (http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=576-1262-1-ND)

That should shave a buck off. Though if we don't need enable, it could be cheaper to use SOT-223 LD1117 etc.

I think even if we do the FTDI option we should include a ROM so it's more user friendly.

I changed the VREG price, and added a post-markup column for pin placement and QC costs (it was the easiest place to put it).

I compared 2x16bit buffer, 1x16bit buffer (my preference), and 1x8bit buffer, all using the UC option.

Paying US$ 1 or even US$ 2.50 more if I get 16 or even 32 buffered bidirectional channels instead of 8 unidirectional buffered and 24 bidirectional unbuffered lines is worth the extra money for me. However, I may not be the typical user/customer for this device ...

As long as the targeted max sales price can be kept, I'd go for the 1x16 buffered option.

Reading up on the recent activities, it seems like the design is shaping up to something like this:

(http://http://img233.imageshack.us/img233/1109/usbmcufpgalablockdiagra.th.png) (http://http://img233.imageshack.us/i/usbmcufpgalablockdiagra.png/)

Ian seems to be comfortable with the PIC solution and since it helps to save about US$ 2,50 I'd go for it - over 90% of the users will not hack the device. For them 16 or even 32 buffered channels will be more appealing than getting the extra features that come with the FT2232 but will most likely never be used ... 

For those who are interested in the Xilinx SPI Flash configuration interface for the Atmel AT45DB021D Ian is going to use in his design, here are the details:

(http://http://img233.imageshack.us/img233/102/spiflashconfigurationfo.th.png) (http://http://img233.imageshack.us/i/spiflashconfigurationfo.png/)

from Spartan-3 Generation Configuration User Guide - p. 103 (http://http://www.xilinx.com/support/documentation/user_guides/ug332.pdf)

So it sounds like the microcontroller route is the desired direction? If so, I can find a design I have that already has the Atmel SPI flash configured. I haven't tested it yet but I have a board here that I can do some testing with before we commit.

Jack.

Ok, I just released the files for version 2.0 of my S3E Cocoon that includes SPI Flash. I was holding off until I had a chance to do more verification but this seems like an appropriate time. I have a prototype built and I can start verifying that the SPI Flash works. There is a problem with the SOIC footprint, it is just a little too small. You can find the files here:

http://www.gadgetfactory.net/gf/project/s3ecocoon/frs/?action=FrsReleaseBrowse&frs_package_id=2 (http://http://www.gadgetfactory.net/gf/project/s3ecocoon/frs/?action=FrsReleaseBrowse&frs_package_id=2)

Jack.

I just took a look at the Block Diagram and it looks great. The only correction is that the power supply is 1.2V instead of 1.8V.

We should consider including an external clock in pin and the SampleReady LED. Here is a Block Diagram of the Sump core (http://http://www.sump.org/projects/analyzer/fpga/images/schema_0_7_top_full.png)

One other note is that I used an 8Mhz clock for the Butterfly Platform but we should plan on using a 50Mhz clock for a dedicated Logic Analyzer.

Jack.

Ok,

Forget the 2.0 design that I posted earlier, I forgot that I had broken the back annotation. I found a different design that implemented the SPI flash that is working. I merged that design and Ian's schematic sheet together. I created a project space for us that includes svn so we can keep all of our files easily synced.

The project page is http://www.gadgetfactory.net/gf/project/butterflylogic/ (http://http://www.gadgetfactory.net/gf/project/butterflylogic/)

I also posted my SPI Flash design notes if anyone wants to look over them. http://www.gadgetfactory.net/gf/project/butterflylogic/linkedapps/?linkedapp_id=25 (http://http://www.gadgetfactory.net/gf/project/butterflylogic/linkedapps/?linkedapp_id=25)

The updated eagle files are checked into svn.
To access them follow these steps:

• Install a client like tortoisesvn
• Create a new folder
• Right click and choose SVN Checkout
• Enter this URL: http://www.gadgetfactory.net/svn/butterflylogic (http://www.gadgetfactory.net/svn/butterflylogic)
• User name = anonymous, leave the password blank

For linux use this command, "svn checkout --username developername http://www.gadgetfactory.net/svn/butterflylogic (http://www.gadgetfactory.net/svn/butterflylogic)"

Jack.

For those who do not want to use svn here are the eagle files as an attachment.

Ian & Jack, thnx for putting up all the details. I have gone through the info and updated the block diagram accordingly (I hope, I didn't miss anything):

(http://http://img412.imageshack.us/img412/1109/usbmcufpgalablockdiagra.th.png) (http://http://img412.imageshack.us/i/usbmcufpgalablockdiagra.png/)

1. corrected 1.8V --> 1.2V
2. corrected the SPI path PIC --> FPGA --> SPI Flash (saw it in Jacks design that no direct connection PIC --> SPI Flash is needed since it can be accessed through the FPGA - correct me if I am wrong)
3. added Ready/Done LED as suggested by Jack
4. added Trigger_Out signal to the 1st 2x10 header (good suggestion by bdsmith for daisychaining other equipment/devices)!
5. put a 16-Bit transceiver instead of the 8-Bit buffer(s) on the 1st header
    I think the transceiver is really needed to make the device 5V tolerant on all 16 lines
6. added Ext_Clk_In signal to the 2nd header - very important hint by Jack!
7. added Trigger_In signal to 2nd header (suggestion) - so the device can be daisychained and triggered by other equipment/devices/special signal without sacrificing the number of input lines that can be captured (16/32).
i.e. When developing I like to set a port/line in my code to trigger the capture rather than to wait for some pattern on the lines that may never occur.
8. Added +3.3V to the second header becuase I think it will be the best option NOT to buffer the lines of the 2nd header! I suggest the second header to become the expansion and special features header - so it could be used for capturing up to 3.3V signals without an extension. Possible add-ons for the 2nd header are:
- 5V tolerant buffer board
- A/D board for DSO
- D/A board for signal generator
This will keep the cost for the project down and allow for follow up projects/add-ons.
9. added the external SRAM capture buffer from Jacks FPGA design. I doubt there will be place
for the (at least) 60-pin header it would require (if implemented as a 32-Bit interface like in Jacks design) not to speak of the routing issues on a small 2-layer PCB. I see it as an option for a follow-up design/redesign.

I am contemplating the option of spinning off a child project with the FT2232D. I would take the FPGA Cocoon board Jack is designing for Ian and design a "CPU" carrier board with the same foot-print as Ian but with the FT2232D instead of the PIC18F24J50. In the end we would have two boards that would run with identical FPGA configuration bitstream images and could use the same add-ons. Comments?

Uwe

Wow! We're cooking now!

I'm also totally in favor of the 16bit I/O chip, it seems like the best option.

The PIC has 2 SPI modules and 2 UARTS, one of each is fixed to certain pins, the other can be located wherever we want it.

1 SPI module and 1 UART should be reserved for interfacing the FPGA. We can route four wires for a later SPI interface, but just use the UART now. One of the relocatable modules will be helpful here.
1 SPI module should share the ROM programming connections. I'll make a STK500 ISP programmer clone in the PIC that can be used with AVRDude, etc to reflash the ROM. This way it's still an easy dev-board, but without real-time JTAG debugging.
1 UART should probably give a legacy UART I/O option because that interface will be with us forever.

For the FPGA IO, is there a special type of pin for clock output, or is that for clock input only? If so, I'd like to have one of those routed to the unbuffered header because parallel ADCs take a fast clock signal.

I'll start a table of connections between the PIC and FPGA later today so we can start to locate pins:
4 pins for SPI (only 2 used for UART in initial design)
1 interrupt pin from FPGA to PIC (signals complete, ready for dump when we have an SPI interface)
1 clear pin from PIC to FPGA (probably not needed because all commands can be send through the UART or SPI interface).

Also:
4 shared SPI pins for programming, reading the ROM

I forgot to add: fantastic diagrams Uwe!

I'm interested in the ROM and UART/SPI pin connections on the FPGA, here's some good stuff from Jacks notes on ROM:

Checklist
HSWAP - Connected to VCCO for no pullups during configuration.
Mode Select pins - 001 for fast read mode
Variant Select pins - 111 for Fast Read
MOSI -
DIN -
CSO_B - Is supposed to have a 4.7kohm pull up resistor if HSWAP=1.
CCLK -
Voltage 3V3

Nice diagram Uwe, I see spell check is angry with you :)  I feel the clock and trigger in should be buffered.  If you are monitoring logic on a 5V circuit it is very likely you will also want to use a clock off the same circuit to clock the logic analyzer.  If two banks of buffers are not used you could use a small dual sot23-6 or SOIC8 buffer like the NL27WZ126USG.

Congrats on your Hack a Day article for the AVR core!

I arranged the microcontroller side a bit (files attached). I tried to check out the SVN version but I wasn't sure of the user/password.

It seems to make sense to have the JTAG along the top edge, and the ROM where both the FPGA and the uC can access it. I thought about changing the caps to 0805, but I'm going to leave that side alone. I would have added the buffer from your other schematic, but I can't reach your site at the moment.

Oh yeah, you mentioned a problem with the size of the ROM footprint - the one I used is much wider, maybe it will help (from the SparkFun library).

LukeS, thnx & very true ... I didn't pay much attention on the spelling ... will put a diagram with corrections up soon and install spell check. :)

Thanx for the input regarding the missing buffers for the Clk_In and Trigger_In signals on the 2nd header - good point but I did it on purpose ;).

Ian and Jack have been throwing numbers forth and back and to me it seems that they have settled for a stringent budget, a 2-layer PCB ... and low-as-possible parts count. I am just following them kind of. This first design will aim at 16 buffered bidirectional channels on the 1st 2x10 header and 16 unbuffered channels on the 2nd 2x10 header. Anyone connecting the LA to 5V circuitry would be limited to 16 channels w/o Clk_In and Trigger_In ... until an add-on board with the same 16-Bit transceiver we use on the 1st header and (like you suggested) buffers for Clk_In and Trigger_In will become available. (actually this simple add-on board for the 2nd header and a set of probe cables could be the first acessories to be released together with the LA).

I leave it up to Ian and Jack to make the final call if Clk_In and Trig_In shall go on the 1st header and get a buffer (i.e. NL27WZ126USG --> Datasheet (http://http://www.onsemi.com/pub/Collateral/NL27WZ126-D.PDF) - US$ 0.33 for 100 qty @ Digi-Key - not on Stock) ... we would have to go from 2x10 to 2x12 for the header(s) so, I think.

@Ian: Check page 103 ff in the "Spartan-3 Generation Configuration User Guide (http://http://www.xilinx.com/support/documentation/user_guides/ug332.pdf)" for details on the exact configuration of the Spartan 3E --> AT45DB0xxD SPI interface. I think, I mentioned it before:

(http://http://img233.imageshack.us/img233/102/spiflashconfigurationfo.th.png) (http://http://img233.imageshack.us/i/spiflashconfigurationfo.png/)

.. Jack may have an exact example from his previous design ... like you, I was unable to connect to his SVN repository. After a few failed login attempts his server now refuses all and any of my connection attempts. Can't even get on his http pages nor get a ping response from his server. He PMmed me and said he would look into it later.

Looking closer at Ians layout, I see that there is no space for headers with more pins - 2 x 2x10 is the absolute max that will fit on the side of the board ... unless we go for headers with 2mm spacing or Ian resizes the board ...

Ok, sorry about the firewall cutting you guys off. I've had a ton of hacking attempts on the site so I have put pretty strong protection in place. Too many failed password attempts cuts you off for a period of time. But it should let you back in after a while, let me know if it is still blocking you.

I created accounts for both of you and sent the login information to you separately.

Jack.

Please disregard any sdram references in the design I provided, I pulled the design from an untested design that includes SDRAM. The important thing is just that SPI Flash is in place and I should be able to verify it before we commit the design. There were not enough pins left over with the SDRAM design to be practical with this particular chip.

Jack.

I see that there is no space for headers with more pins - 2 x 2x10 is the absolute max that will fit on the side of the board

@Ipenguin - I'm just tossing stuff on there to mull over how the chips should fit on the board. When we decide on the number of pins and solidify the JTAG placement, etc, we can eliminate a bunch of the existing headers on Jack's board and squish everything together. That should make room for the buffers too. I thought I'd route the PIC part, leave the FPGA mostly to Jack, and then we can come up with a net list to meet in the middle.

I updated the first message on the top of this page with the pin number table, but I think I closed the browser without saving the edit...

I enabled edits at everyone's request. I had it off for two reasons: spammers, and because I read the emails and not the posts, so I often miss something if you edit later :)

BTW: I couldn't extend the PCB boundaries. I'm not sure what Eagle function has it locked, but I couldn't extend it to the left at all.

Ian, the PCB boundaries are a part of the GADGETFACTORY_STACK footprint so the library footprint would have to be modified. The Cocoon form was meant to be static...

Easiest thing to do is draw a new border, when we remove the GADGETFACTORY_STACK component the existing boundary will be removed.

Jack.

Block diagram update:

(http://http://img134.imageshack.us/img134/1109/usbmcufpgalablockdiagra.th.png) (http://http://img134.imageshack.us/i/usbmcufpgalablockdiagra.png/)

1. added Clk_Out signal to header A (1st channel header)
2. added buffers to Ext_Clk_In and Ext_Trigger_In on header B (suggested by LukeS) - ON NL27WZ126USG
3. grayed out the external SRAM capture buffer - eventhough we don't have I/O for it on the 100-pin VQFP I didn't remove it yet ...
4. "red-boxed" the SPI interface MCU --> SPI Flash --> FPGA - as this part needs some real careful consideration!
5. changed device name for the SPI Flash to AT45DB041D - 4M bit 2.5-Volt or 2.7-Volt DataFlash


.... 6. activated spell check in Open Office ... now I am angry with spell check (red underlines under signal names). ^^ :D

Beautiful diagram!

I'm leaning against buffering the extra signals. It's possible to have an alternate upload for the FPGA that places these signals on some of the buffered pins, but having them unbuffered by default gives the cleanest, fastest signal path.

In your next update (no need to do it now), could you please add a dashed or grayed line next to PIC UART->FPGA to symbolize the extra signals for a future SPI interface.

Very true, unbuffered is faster and cleaner ... but there is always the issue of 5V signals sending the FPGA to it's grave.

Since you mention loading alternate configuration images into the FPGA to reassign lines or even load an alltogether different functionality (i.e. signal generator) I must admit that I have been brushing up my slightly rusty knowledge of the Spartan-3E architecture over the last couple of days as well ... and trying to establish some details for the PIC - SPI Flash - FPGA configuration, in particular for the FPGA configuartion mode.

If we want to load alternate configurations into the FPGA we will have to use Slave Serial Mode for the configuration - we can't load different configurations from SPI Flash in Master Serial Mode unless we write the new configuration into the SPI Flash before the FPGA can load it. Since we are going to use the 4M Bit chip we will have plenty of room for 3 maybe even 4 configuration images. I am tending towards using Slave Serial mode with the PIC acting as the master ... I did some "patchwork" and came to following (preliminary) concept for the MCU - SPI Flash - FPGA configuration:

(http://http://img233.imageshack.us/img233/7387/slaveserialconfiguratio.th.png) (http://http://img233.imageshack.us/i/slaveserialconfiguratio.png/)

I must admit that I never programmed or even designed with PICs before. Once I received the BP v3.0 like 10 days ago I installed MPLAB and have played around with it a bit since then. So please forgive me for not showing the signals on the PIC side in detail ... I am still reading up on the 18F24J50. So please forgive that I haven't a complete solution ready, yet.

I thought it would be as simple as routing the SPI connection to both the PIC and the FPGA. When the ROM is updated from the PIC, the PIC holds the FPGA in reset via a reset pin (?) or just disabling the MIC power supplies to the core. For normal operation the FPGA would load off the ROM without intervention and the PIC acts like a FTDI232RL USB->serial chip. Updates would replace the whole flash.

If I understand, you seem to propose an intermediary that translates addresses to store multiple images on the rom. That's really cool! I hadn't thought about that.

[quote author="ian"]

I'm leaning against buffering the extra signals. It's possible to have an alternate upload for the FPGA that places these signals on some of the buffered pins, but having them unbuffered by default gives the cleanest, fastest signal path.

[/quote]
How about an external buffer. This would require a second small pcb with the Buffer ( or level translator ). It should not be that expensive, because
of the small size of the required pcb. It would also allow a longer cable between buffer and analyzer. I know that you don't need long data cables if
you can put the analyzer near the target. But this would also allow to substitute the buffer pcb with a level translator pcb if the logic on the target
requires this.

Klaus Leiss

An expansion board is a good solution. My idea to move some of the signals to the buffered pins in a custom synthesis would only work for input pins since there isn't per bit pin direction control.

I uploaded a custom library for the pic 18f24j50 to the SVN. I was going to add the buffer and try to modify the S3 footprint but I didn't see the library at your site or in the S3 cocoon SVN/downloads.

[quote microchip]
Self programming Flash supports 10k erase/write cycles
[/quote]

I dont know much about this project other than it looks good.
but is the write cycle of the 18f24j50 series going to be an issue?

I just exported the library and committed it into svn.

Jack.

I know I'm a bit late, but if you're using the Spartan-3E 250 I'm sure you can implement everything you need in the FPGA.

http://www.xilinx.com/products/ipcenter ... DEVICE.htm (http://www.xilinx.com/products/ipcenter/DO-DI-USB2-DEVICE.htm)
http://www.xilinx.com/products/ipcenter/CIPPICL-X.htm (http://www.xilinx.com/products/ipcenter/CIPPICL-X.htm)

audihacked, thnx for the links ... I think the CIPPICL-X soft-IP has been around for some time but I couldn't find any details on the implementation nor on the license model/cost ... it may not be free ???

This is all I found about the CIPPICL-X/CIPPIC softcore: Cheetah Hi-Tech, Inc. - Products (http://http://www.cheetah-tech.com/products.html) and 2K word instruction ROM - even 8K word instruction ROM for the CIPPIC implementation - may not be enough code space for the project

I think Ian and Jack decided to go for a "hard MCU" for various reasons like

- use Jacks proven LA implementation for the Spartan-3E 250 without any/many changes
- keep the design open for different implementations/different MCUs
- allow for as much as possible of the FPGAs RAM to be used as a capture buffer ...

... the resources of the XC3S250E are kind of limited and the XC3S500E -  the "largest" Spartan-3E available in a 100-VQFP package - would cost about US$ 7 extra ... eating up US$ 20 of a targeted retail price of US$ 40 max.

I made these updates to the PCB and saved it to SVN:

Removed the board outline and Butterfly I/O pins
Added simple 6 pin JTAG header
Changed caps to 0805
Updated CCT to use the new 18FxxJ footprint
Updated my half to be consistent with Jacks power naming (3v3, 2v5, 1v2).
Named connections for bigger rom, ROM connections on programming header
Squished the parts together a bit

Here's what I need to finish a draft:
1. Jack mentioned that the ROM footprint was a little small. I added an alternate to the PCB. Is this the correct size? Which one will work?
2. A footprint for the 16bit buffer IC. If you add a copy of the buffer wing to SVN I'll copy it from there.
3. Where should I connect the 4 pin SPI/UART connection + control pins (how many? 2?)? These will be 3.3volt signals, as will the shared PIC and FPGA connection to the ROM. I imagine this will share bank2 pins?
4. Which pins will we use for the 32 I/O pins?
5. Which/how many additional signals do we want at the pin header for clock in, etc?

Sorry, hit post instead of preview. Here's a PNG of the PCB as it is now. I changed the name of the PCB to a, there was a good reason but I forget now.

[quote author="ian"]
Sorry, hit post instead of preview. Here's a PNG of the PCB as it is now. I changed the name of the PCB to a, there was a good reason but I forget now.
[/quote]
Looks nice. Are this 16Bit  Connectors? If yes, you may be a little short on ground and power Pins. Another  nice addition addition would be an
I2C or SPI bus on the probe connector. Then one could build a software controlled power supply for the buffer board. This way you could change
the I/O voltage of the translator chip from the analyzer software. But you could always do this with a jumper on the buffer board or get the voltage
from the target board.

If you are still using the AT45DB021D there are two variants of the chip, one 0.150" wide and the other 0.209 wide. One could make a footprint
with longer [s:]pins[/s:] pads that  would accommodate both.
 
Klaus Leiss

Looks great!

I checked the Buffer design into SVN, it is a board only design but should be good enough for getting the footprint from. What do you think about having different numbering schemes printed on the PCB like on the checked in buffer design? Changing the FPGA bitstream allows the connectors to be renumbered and might be useful.

(http://http://www.gadgetfactory.net/fckeditor/editor/filemanager/img.php?file=151)


1. Jack mentioned that the ROM footprint was a little small. I added an alternate to the PCB. Is this the correct size? Which one will work?
    It looks like it is going to be correct, once we get the Buffer footprint on the board I will do a 1to1 printout and verify the Atmel Flash and Buffer footprints with the actual parts.

2. A footprint for the 16bit buffer IC. If you add a copy of the buffer wing to SVN I'll copy it from there.
   Checked into SVN now.

3. Where should I connect the 4 pin SPI/UART connection + control pins (how many? 2?)? These will be 3.3volt signals, as will the shared PIC and FPGA connection to the ROM. I imagine this will share bank2 pins?
   I just looked at the datasheet and it looks like the AT45DB041D (2.5V Version) part accepts 2.5V to 3.6V for VCC. (http://www.atmel.com/dyn/resources/prod_documents/doc3595.pdf (http://http://www.atmel.com/dyn/resources/prod_documents/doc3595.pdf)) The schematic should already have them connected to the correct locations on the FPGA. One change I think we can make that might make things easier is to just connect the /CS pin to ground so it is always active. It is currently connected to the FPGA and I noticed that the SPI header does not have a pin for /CS. So if we don't create another pin on the header or make the SPI Flash always active then we won't be able to program it over the SPI header.

4. Which pins will we use for the 32 I/O pins?
   This is the part that gets tricky, we can use any available IO pins (I usually avoid IP, or input only, pins). If we are going to accomplish speeds over 50Mhz though we need to keep the traces as short as possible and route them over an unbroken ground plane. So I usually save determining which pins for the very last step. If we get the design to where we want it we can then make a copy of the board file which will break the forward/back annotation. We can then easily route and reroute the signals to figure out the best configuration. We then update the schematic with what we did on the temporary board file. It is a pain and tedious but its the most effective way I have found, Eagle doesn't have very good support for the back annotation needed in FPGA designs where the pins are really flexible.

5. Which/how many additional signals do we want at the pin header for clock in, etc?
   TBD

I'm going to spend a little time trying to validate the SPI design on some hardware I have here. Once that is done then I will start updating the EAGLE design. I want to get the SPI validation out of the way before we get real serious with routing the design.

Jack.

3....One change I think we can make that might make things easier is to just connect the /CS pin to ground so it is always active. It is currently connected to the FPGA and I noticed that the SPI header does not have a pin for /CS. So if we don't create another pin on the header or make the SPI Flash always active then we won't be able to program it over the SPI header.

The SPI headers (you're talking about the header labeled ROM ISP?) I used are for AVR ISP, CS is just called RESET. I used that header so the pinout would be consistent with common AVR programmers (I think many will program ROM chips through AVRDude, etc). This isn't the best idea because the STK500, etc, work at 5volts which is way beyond specs. We can (should) change it so there's no motivation to even try :)

I've only worked with EEPROMs like the 25AAxxxx, but I thought CS was a required signal. I've been studying the ROM chip datasheet in case I have to make custom programming software for the PIC, I'll check it out.

The reason I mentioned 3.3volts is because the PIC will program the ROM at 3.3volts, so I wanted to make sure that the bank connected to the ROM chip can tolerate it.

Good news,

I just finished validating the SPI Flash configuration portion of the design. I just succeeded in flashing a bitstream to the SPI flash on a S3E Cocoon 2.0 board that I've been working on. The board starts up and loads the bitstream in the amount of time it takes for the USB ports to register. So I feel confident now that the SPI Flash configuration portion of the Sump Pump design should work well.

Now its time to dive into the EAGLE design part of this project. Hopefully we will have a design ready in the next week or so, this is starting to get exciting!

Jack.

If you could add the Wing connector that we discussed earlier, first, that would really help me to be able to route the rest of the PCB.

Ok, that will be my first task.

After a chat with Ian we feel that the best way to enable all of the ideas that have been posted is to include an 8 Bit buffer on the board and a 16 Bit Wing that can accommodate standardized peripherals/addons such as buffered signals, ADC's, Oscope probes etc.

Anyone take a look at this?

http://www.opencores.org/project,openverifla (http://www.opencores.org/project,openverifla)

I've seen this project before, the Sump Java client is much nicer. If I'm not mistaken the Java client for this project just generates a verilog file that you have to load up into Webpack in order to view the waveforms.

Exactly, it's more or less intended as an "on-chip" logic analyzer for FPGA projects.

quoted from the OpenVeriFLA version 1.0.3 Reference Manual:

It helps in on-board testing and debugging of the FPGA projects.
This is done by real-time capturing and then graphically displaying
the signals transitions that happen inside the FPGA chip.

... The java application receives the captured data and saves it on the disk in a
file named capture.v. This file is a behavioural verilog HDL file. An Verilog
HDL simulator with a graphical viewer for the signals is necessary in order to
simulate capture.v and view the captured data.

While the FPGA implementation of the LA logic seems to follow a concept similar to Jacks SUMP LA implementation and even a Java application is used on the PC to receive and convert the captured data, the design is in no way SUMP compatible and relies on the presence of ISE or some other "Verilog HDL simulator with a graphical viewer" on the PC. The project does not appear to be active or well documented - it will take to go through both the Verilog and the Java code to get a full understanding and to make any use of it ...

Are you guys trying to just slap this implementation together without any design? From what I can read, Jack didn't design the LA. And It wouldn't be any work to find/design an USB MCU to go with the LA.

[quote author="jack.gassett"]
I've seen this project before, the Sump Java client is much nicer. If I'm not mistaken the Java client for this project just generates a verilog file that you have to load up into Webpack in order to view the waveforms.
[/quote]

Someone could take it and convert it to be SUMP compatible.

I already have a MCU design that we could expand and use, I did it for a Digital Design Project my second semester in College.

[quote author="IPenguin"]
The project does not appear to be active or well documented - it will take to go through both the Verilog and the Java code to get a full understanding and to make any use of it ...
[/quote]

Sounds to me that you're too lazy to take 20 minutes to read the code.

... you are right, Jack did not design the "FPGA Based Logic Analyzer (http://http://www.sump.org/projects/analyzer/)". Indeed, some details about the SUMP LA project
got never mentioned in this discussion. Lets pay due respect to those who deserve it (in chronological order)
... along the lines better too late than never ... and use this opportunity to give some essential links as well:

The original Logic Analyzer VHDL model (http://http://www.sump.org/projects/analyzer/fpga/), the Communication Protocol (http://http://www.sump.org/projects/analyzer/protocol/) and the Java Logic Analyzer Client (http://http://www.sump.org/projects/analyzer/client) were specified,
designed, implemented, documented and made available as an open source project by Michael Poppitz.

The port of the VHDL code (http://http://www.sump.org/projects/analyzer/downloads/la-src-0.8.1-test-s3e.zip) to the Spartan-3E Starter Kit (http://http://www.xilinx.com/products/devkits/HW-SPAR3E-SK-US-G.htm) was done by Jonas Diemer.

There is even a "Logic Analyser mit Pollin CPLD Board" (http://http://www.mikrocontroller.net/topic/132506) port for a € 24,95 (~ US$ 37) CPLD evaluation board (http://http://www.pollin.de/shop/dt/MTM5OTgxOTk-/Bausaetze/Diverse/Bausatz_CPLD_Evaluation_Board.html) by befro (?).
Unfortunatley it's all in German, spread over 3 threads and not really documented ...

Oak Micros (http://http://oakmicros.com/content/Home.html) has improved the Java Client for the SUMP LA and written a great "Logic Analyzer User Guide" for the sump
logic analyzer built around the Digilent Spartan3 FPGA development board (http://http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,799&Prod=S3BOARD), their omla32 interface card (http://http://oakmicros.com/shop/product_info.php?cPath=28&products_id=50), and a Java User
Interface - the files can be downloaded here (http://http://oakmicros.com/content/downloads/View-category/Other-Oak-Micros-Downloads/).

Jack Gassett has ported the SUMP LA design to his Butterfly Platform (http://http://www.gadgetfactory.net/gf/project/lax/), implemented some improvements to the LA VHDL
design as well as the SUMP Java Client and prepared some nice tutorials (http://http://www.gadgetfactory.net/gf/tutorials/#Logic_Analyzer) (Jack, please forgive, if I missed something).

Ian came up with the great idea of putting (or you may say "slapping") the SUMP LA design on a very low cost board
(US$ 30-40) and Jack offered his cooperation and support for this project by bringing in the FPGA side of the design
and his experience.

To my knowledge this will be the first application specific implementation of the SUMP Logic Analyzer on a single PCB
that will allow users to get their hands on a low cost, open source, FPGA based logic analyzer they can put to use out
of the box without having to install and get familiar with FPGA development environments and overfeatured FPGA boards.

All comparable previous LA implementations seem to have used standard FPGA evaluation/development boards with
adapter boards (starting at around US$ 100) and relied on (at least parts of) FPGA development environments for
loading the FPGA configuration before the application could be used ...

P.S. ... and yes, you may call me lazy. :D   Most of this information (and far more) can be found on the Logic Analyzer project pages (http://http://www.gadgetfactory.net/gf/project/lax/) at Jack's Gadget Factory site.

Thanks for the project summary, I'll use those links in the eventual project writeup.

RE:documentation - this is somewhere we can excel. I try to keep things well documented, both in terms of the hardware writeup, but also a 'manual' with links to interesting stuff.

Indeed, my methodology is probably best described as 'slapping together'. I refer any complaints to the name of my website :) Just kidding :)

I'm Sorry.

I'm the kind of "engineer" who likes to get things as correct as can be, before sharing what I have. Which I know I don't do sometimes if I'm excited about my particular project.

I'll share what my idea is, and show screenshot and ask for opinion, and yes, everyone's opinion matters to me.

I just checked in some updates to the FPGA side. Included is a 16 Bit Wing footprint. I've been toying with the idea of adding an anchor point so that Wings can use standoffs for additional stability. I included the anchor point with the footprint but it can be easily removed if people don't like it.

Are the connections to 13...16 on the wing set in stone?

Is it possible to rotate the FPGA so the ROM is closer to the PIC? Right now it looks like the ROM SPI connections will be routed under the primary 8 input pins. I included three scenarios, none seem to be ideal.

Is there a clear or reset pin on the FPGA that the PIC can manipulate to hold the FPGA in reset while the PIC updates the ROM?

I'd like 2 extra connections on the PIC->FPGA serial connection for a possible future update to faster SPI. Since the PIC, ROM, and FPGA already share an SPI connection, could we recycle the ROM connection for the UART/SPI connection? They'll never be in use at the same time, but there might be an issue with garbage data on the PIC UART while the ROM loads unless the FPGA indicates 'ready/loaded' on one of the other pins before we start the UART. For the future SPI connection I thought the FPGA could indicate the end of capture by changing SDI while CS is disabled instead of a dedicated interrupt pin.

Changes:
Separate ground plain for the PIC side
Fixed USB supply pin to 3v3 for 18Fxxjxx PIC VUSB supply style
Changed from 2x3 ROM header to 1x6 header
Added 74xx573 SOIC
Added 1x9 (Saleae logic style) and 2x6 header (cheap ribbon cable)
Renamed IC2A -> IC2
Added pin for FPGA 4 wire connection
Added pin for UART connection
Added pin for vreg enable

I routed some power traces to learn more about the FPGA power supply, please don't consider it anything but a doodle.

What do you think, 9 pin straight header like on the saleae logic (nice cables available), or cheap 2x ribbon cable header?

Jack - I edited your image and added it to the post because it was breaking the page width on my netbook. Sorry about that.

[quote author="ian"]
Is there a clear or reset pin on the FPGA that the PIC can manipulate to hold the FPGA in reset while the PIC updates the ROM?
[/quote]
Pulling the PROG_B pin low tristates the FPGA pins. When it will go high again the FPGA starts its configuration. Figure 54 in the datasheet
describes how to connect an Atmel SPI prom for configuration. It also describes the standard programming header to program the SPI prom
with Impact and a Xilinx Jtag adapter.
[quote author="ian "]
I'd like 2 extra connections on the PIC->FPGA serial connection for a possible future update to faster SPI. Since the PIC, ROM, and FPGA already share an SPI connection, could we recycle the ROM connection for the UART/SPI connection? They'll never be in use at the same time, but there might be an issue with garbage data on the PIC UART while the ROM loads unless the FPGA indicates 'ready/loaded' on one of the other pins before we start the UART.
[/quote]
The Done pin indicates a successful configuration

A suggestion, Ian,  how about checking with SEEED  about cases they migh be able to supply for the LA.  This might influence the exact PCB dimensions.  I would hate to have to use a larger case, when a small adjustment now would solve the issue.  
I agree 100% with the idea of minimizing the cost of the base LA.  If I understand the present design, the buffered I/Os have been scaled back from the original 16 to 8.  Might I suggest that the base PCB be layed out for 16 channels but depopulated to 8 for the base offering( no chips / header).  The cost impact on the PCB I would guess be negligible.  In Ian's latest post I think there is room if the buffer IC are slide up a bit .

Currently all I/O connections on the FPGA are purely incidental and will be moved and sorted out once we establish all of our desired connections. I will work on cleaning up the incidental connections, once that is done then just make any open connection that you need on the schematic. Since all of the I/O is generally interchangeable we will establish the final connections based on what is easiest to route and the initial schematic connections will just indicate a desired connection. The final schematic design will be corrected to show the correct connections.

I'll play around with some alternative orientations of the FPGA chip that makes the SPI chip more accessible. We need to strike a balance for easy routing of the Power, SPI Flash, and I/O lines. Maybe a 45 degree orientation will make things easier.

Thank you LeissKG for looking up the reset and done pins, I concur that those are the correct pins to do the required job. Hold PROG_B low to put the pins in highZ and program the SPI Flash chip.

Lets do the 9 pin straight header with possibility of nice cables. As long as it does not present a routing challenge.

A nice case would be great, assuming it does not affect the overall cost much. Maybe we can sell a barebones circuit and one with a case for a little more?

BTW: All three of those designs are in the SVN.

Thanks so much for the pin names. I'll add those next time I check out the files. I'm not super familiar with FPGA, and I really appreciate the help getting started.

For my 'side', I think I'm going to flip the PIC like in the last image (pumpc). That way I don't have to route the USB signals under or around the 20mhz crystal. That's also the FPGA orientation I like the most, but I don't know how feasible it is. It's unfortunate that the JTAG and ROM pins both stretch over entire sides like that.

It might be possible to route the 2 ROM traces on the bottom layer under the FPGA. They should (might? depends on the pin) both be @ ground when the analyzer is active.

Here's the justification for small steps (and starting with and maintaining open source files):
http://blog.makezine.com/archive/2009/1 ... the_c.html (http://blog.makezine.com/archive/2009/11/hardware_is_hard_-_the_end_of_the_c.html)

We can move the oscillator to any global clock input so we have flexibility there. What do you think about getting rid of the JTAG port? That would make routing over an unbroken ground plane much easier.

[quote author="jack.gassett"]
We can move the oscillator to any global clock input so we have flexibility there. What do you think about getting rid of the JTAG port? That would make routing over an unbroken ground plane much easier.
[/quote]

For the clocks I would suggest you follow the design note on page 59 of the data sheet.

Design Note
Avoid using global clock input GCLK1 as it is always shared with the M2 mode select pin. Global clock inputs GCLK0,
GCLK2, GCLK3, GCLK12, GCLK13, GCLK14, and GCLK15 have shared functionality in some configuration modes.

If I read Table 55 on page 80 right, the latter clock pins should be no problem in SPI configuration mode

Regarding the JTAG connector i would say omit it only if the design is otherwise impossible. If you have it, you can debug
the LA design inside the FPGA with chipscope if you have a license.


Klaus

I just checked in an update to the layout of the components on the FPGA side. I updated Ian's preferred 'C' layout, I think this should work for the FPGA side. Still up in the air is the location of the oscillator and which Global Clock will be used. Thank you for sharing the Design Note Klaus, and it looks like the JTAG port will probably not cause too much of an issue for routing so at this point lets leave it in.

The JTAG works well there, if we don't try to move it to the edge of the PCB I think it will be fine. It's just for debugging.

Is there any reason the PIC needs to switch the 2.5v and 1.2v power supplies? I have the PIC connected to the /enable pin, but it would be nice to not route that trace. I'm not sure what good it is considering A) PROG_B resets for programming, and B)is it even ok to partially power the FPGA (3.3v to banks, 2.5v and 1.2v unpowered)?

I made a few minor updates and checked the PCB into SVN:
*Moved auxiliary UART I/O to 5volt tolerant pins. Makes it tolerant to old 5v MAX232 transceivers.
*Changed to smaller xtal, not sure this is permanent.

More importantly, I assembled a list of PIC->FPGA connections that I'll use to assign PIC pins:

*FLASH_CS
Shared chip select signal for ROM chip. Connects to ROM, FPGA, PIC, programming header. Uses PIC general IO pin.

*MOSI
Shared SPI data pin for ROM chip, SUMP UART TX, future SPI connection to FPGA. Connects to ROM, FPGA, PIC, programming header. Uses PIC SPI module 2, UART module 2 (module pin location is programmable).

*MISO
Shared SPI data pin for ROM chip, SUMP UART RX, future SPI connection to FPGA (also an interrupt from FPGA to PIC when FPGA_CS is disabled). Connects to ROM, FPGA, PIC, programming header. Uses PIC SPI module 2, UART module 2 (module pin location is programmable).

*CLK
Shared SPI clock pin for ROM chip, future SPI connection to FPGA. Connects to ROM, FPGA, PIC, programming header. Uses PIC SPI module 2 (module pin location is programmable).

*FPGA_CS
Chip select pin to future FPGA SPI interface. Connects to PIC, FPGA. PIC general IO pin.

*FPGA_DONE
Indicates FPGA loading is complete. Connect to PIC, FPGA. PIC general IO pin (needs pullup). PIC general IO pin.

*FPGA_PROG_B
Holds FPGA ROM pins HiZ while PIC writes an update to the ROM. Connect to PIC, FPGA (needs pullup). PIC general IO pin.


That's 3 reprogrammable RPx pins, and 4 general I/O pins.

Other non-required peripheral connections:
*MODE LED to show RX/TX activity and bootloader entry (probably FPGA should have a LED for armed/trigger/error).
*2 pins to 5volt tolerant external UART (uses fixed UART1 module).
*Vregulator enable (?)
*2 ADCs to measure 2v5 and 1v2 output(??)

Are the FPGA pins 3v3 tolerant, or are they only intended for use with the same voltage as the IO input voltage?

If the pins are 3v3 tolerant, we could eliminate a lot of power supply stuff on the FPGA side by running the I/Os at 2v5.

We can't get rid of the 3v3 supply because the PIC needs an external regulator to supply the 3v3 USB voltage. We could run the PIC at 2.5volts too, but it still needs the 3v3 supply on the VUSB pin. If the FPGA pins are 3v3tolerant when running at 2v5, then we could have the PIC at 3v3 or 2v5, whatever is easiest to route.

I looked through the datasheet and it appears that you can go above VDD, up to 4.x volts in some situations, but really Vdd+0.5volts is the max recommended voltage.

If the PIC and buffer were both 2v5, then this might be possible, but for expansion wings we'd probably do well to make sure the pins are 3v3 tolerant.

I checked in an update to the PCB.

Changes:
*Chose pins to connect to FLASH SPI, DONE, PROG_B, and routed them to get a feel for the layout.
*The two bottom-layer routed traces are NOT high speed nor do they change in normal modes (FLASH_CS, DONE).
*Chose PIC pin for FPGA_CS. (not routed)
*Named 3 FPGA_AUXx pins to connect between the PIC and FPGA for future development.
*Did some routing to get a feel for my side of the PCB. Nothing's set in stone.
*Reordered ROM header for easiest routing
*Moved ROM slightly away from FPGA for easier routing and soldering.
*Removed VREGEN connection, power supplies hard-wired on.
*Changed license to noncommercial to limit use of the design before we finish.

Still needed:
*Power routing on PIC side (and to FPGA side)
*MCLR pin routing
*FPGA_CS, and FPGA_AUX1-3 route to FPGA (choose FPGA pins)

One last post for the day...

My to do list:
*How to activate ROM update (add jumper or button)?
*Check port B pullup resistor isn't hurting the 2v5 pins (DONE, PROG_B)
*Add resistors for DONE, PROG_B as indicated in the datasheet
*Add pull-downs/ups to SPI FLASH configuration pins as indicated in the datasheet
*Check buffer supply.
*Add LED for USB power to PIC side
*Add armed, error LEDs to FPGA
---
*Power routing on PIC side (and to FPGA side)
*MCLR pin routing
*FPGA_CS, and FPGA_AUX1-3 route to FPGA (choose FPGA pins)

Jack mentioned not finding the buffer I used, it made me nervous about supply problems. There are a number of high-speed, 3v3 supply 5v tolerant input 573 buffers, but I used this one from Fairchild:
http://www.mouser.com/Search/ProductDet ... 74LVT573WM (http://www.mouser.com/Search/ProductDetail.aspx?R=74LVT573WMvirtualkey51210000virtualkey512-74LVT573WM)

Couldn't leave it alone.

*Moved DONE to RA5 out of concern for internal PORTB pull-up violating the 2v5 limit on DONE during programming and debugging.
*Verified that RA5 will detect 2v5 as a high level (TTL H = 0.25vdd + 0.8 =  1.625)
*Added power LED
*Added ROM update button
*Added 2 LEDs to FPGA side (current sink)
*Added DONE, PROG_B resistors to 2v5
*Added INIT_B resistor (as in diagram, ??????) Will move ROM over when I have verification this is needed.

New TO DO:
*Add pull-downs/ups (?) to SPI FLASH configuration pins as indicated in the datasheet
*Check buffer chip supply.
*Power routing on PIC side (and to FPGA side)
*MCLR pin routing
*FPGA_CS, and FPGA_AUX1-3 route to FPGA (choose FPGA pins)
*Need INIT_B resistor to 3v3?
*Need HSWAP pull-down?
*How to place ROM in manual in manual programming mode without PIC pin on PROG_B (through jumper, as in datasheet diagram?)

Still can't leave it alone:
*MCLR pin routing
*FPGA_CS, and FPGA_AUX1-4 route to FPGA (didn't attach, just chose NC pins)
*Added PROG_B pulldown jumper for manual ROM programming
*Moved ICSP to bottom for much nicer, cleaner routing.
*Messed up power supply area a bit for now.

New TO DO:
*Add pull-downs/ups (?) to SPI FLASH configuration pins as indicated in the datasheet
*Check buffer chip supply.
*Power routing on PIC side (and to FPGA side)
*determine and connect FPGA_CS, and FPGA_AUX1-4 pins
*Need INIT_B resistor to 3v3?
*Need HSWAP pull-down?

[quote author="ian"]
*Added PROG_B pulldown jumper for manual ROM programming
[/quote]
If you connect your programmer first and than set the jumper to programming you could get problems (BTDT). I would  add two pins to the programming header, one for a ground pin and the other for PROG_B. A bridge in the connector would switch automatically to manual programming when you insert the connector.

Klaus Leiss

Today I found a low cost Spartan-3A evalauation kit by Avnet - Xilinx® Spartan®-3A Evaluation Kit (http://http://www.em.avnet.com/evk/home/0,1719,RID%253D%2526CID%253D46501%2526CAT%253D0%2526CCD%253DUSA%2526SID%253D32214%2526DID%253DDF2%2526SRT%253D1%2526LID%253D32232%2526PRT%253D0%2526PVW%253D%2526PNT%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html) with a surprisingly similar concept of Ian's and Jack's current design approach.

USB MCU (Cypress PSoC), SPI Flash, Spartan-3A FPGA for less than US$ 50. Now the really interesting part is the documentation on how they have interfaced the MCU, SPI Flash and FPGA and how the MCU controlls everything. On top of that the MCU acts as an intelligent communication interface and there is a quite extensive API for application software development on the PC side (so only for Windows) ... lots of good and detailed documentation (schematics, API reference, user interface ...).

Maybe the most interesting reads (explaining in detail how to implement the MCU/SPI/FPGA/JTAG interface) on the Xilinx Spartan-3A Evaluation Kit's design resource page (http://https://www.em.avnet.com/common/filetree/0,2740,RID%253D%2526CID%253D46501%2526CAT%253D0%2526CCD%253DUSA%2526SID%253D32214%2526DID%253DDF2%2526SRT%253D1%2526LID%253D32232%2526PRT%253D0%2526PVW%253D%2526PNT%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html) are:

- Xilinx Spartan-3A Evaluation Kit - User Guide
- Application Programmer Implementation Guide
- Serial Flash (SPI) Configuration
- Slave Serial Configuration from a Processor
- Schematics for Xilinx Spartan-3A Evaluation Kit ;)

The MCU on their bord controlls the FPGA - unless a JTAG interface is attached. The MCU controlls the FPGA "configuration" pins thus allowing various configuration options - Master SPI Mode (from SPI Flash), Slave SPI mode (direct load from PC via MCU into the FPGA) and Parallel Flash (BPI) Mode (not of interest in this project).

Eventhough it's a Spartan-3A based design most if not all details apply to the Spartan-3E as well.

I like the Spartan 3A Evaluation kit, whenever I get some time to make a Spartan 3A based Cocoon that kit is what I will pattern it after. They actually have a really good webinar about how they accomplished their low cost power supply, I think it is on the TI website. Luckily for us the only two modes of programming that we support is SPI Slave and JTAG. We have the config pins set for SPI Slave and JTAG is always active on the Spartan 3E. Maybe for version 2 we will see what tricks we can adopt from this kit.

On another note, I just routed all of the IO pins for the Buffer and the Wing and have checked them into SVN.

What happened to the use of •M74LCX16245 16 Bit buffers.?  
The M74lcx16245  was a bidirectional buffer where as th 74lvtx573 is a  Latch, I don't recacll a discussion on why a latch was required  Note 74LCX245 is an 8 bit version altough the savings are small

If still planning to support 100mhtz, I suggest adding 22ohm serial termination resistors as was mentioned in  an earilier post/

I'd like to add the termination resistors, especially if we use the 8 channel buffer.

Here's an update, files checked into SVN:
*Moved MCLR trace
*Cleaned up power supplies
*cleaned up ROM, moved, routed power
*Cleaned up a few tight areas on the PIC side
*Assigned and connected the 5 FPGA_AUX connections between the PIC and FPGA.

New TO DO:
*Check buffer chip supply.
*Power routing on PIC side (and to FPGA side)


Jack, have you already connected the FPGA SPI FLASH mode configuration pins?
Do we need the INIT_B pull-up resistor to 3v3 (it is on the CCT)?
I don't think we need the HSWAP pull-down (is not on the CCT), but I'm not sure.

wow, this is coming together quite nicely and faster than I thought ... :)

One more suggestion (for now): I'd add a pin for +5V (in) on the UART (legacy) header ... the +5V trace from the USB connector to the power converters runs right by the connector ... to allow for use of the LA without connecting it to a USB device ... and (so this will require an extra jumper to select between USB power and external power) to allow for external powering in case the LA is used via USB on a laptop i.e. that can't provide sufficient power via USB or if header boards will be used that would kick up total power drain beyond what can be drawn from/provided by USB.

Yes, that's a really good idea.

*Add 5v pin to UART header.

I didn't get much chance to work on the design today but I was able to rotate the JTAG port to make routing a little nicer.

That's much nicer there.

I just finished routing most of the power lines using a trace size of 16 mils. I figured that 800mA is the most power we will ever supply and according to the trace width calculator http://www.circuitcalculator.com/wordpress/2006/01/31/pcb-trace-width-calculator/ (http://http://www.circuitcalculator.com/wordpress/2006/01/31/pcb-trace-width-calculator/) we only need a trace width of 4.35 mils. I bumped it up to 16 mils to give us headroom.

Jack.

I am getting excited about this.  I have a few questions  ideas.

1) Is there any plans to break out the unused IO pins on the top of the FPGA to a separate header, there seems to be space for routing and header placement.  For example pins 2-5, 9-12, 15-18, 22, 23, this could add more options for future wings, and expansion.

2) It seems there should be a mounting hole at the top of the board for a standoff to give people more options in future expansion, it would be used to stabilize shields that would sit over the board instead of sticking out as the wings would.

3) On the series termination resistors, I think they would be a really good idea, ring could get nasty with test leads coming off the board.  They sell SMD resistors arrays with 8 resistors.  You could also go to a smaller package size buffer if placement and routing becomes and issue.  It doesn't look like there is enough space to add them on the other datelines without moving up the fpga.

For #3 Jack is actually doing some simulations and tests to determine the characteristics of the series termination resistors.

My goal for this week is to have the PIC side completely routed, DRC'd, and ready to etch. I probably won't get to it today, but probably tomorrow.

I created a new topic because this one is getting long, and the design isn't so rough anymore.
http://whereisian.com/forum/index.php?topic=184.0 (http://whereisian.com/forum/index.php?topic=184.0)

Also posted in the new thread...

PIC side is tentatively routed, files checked into SVN. Will do DRC and cleanup tomorrow.

Changed:
*Routed PIC power.
*Moved MCLR resistor.
*Moved, cleaned up power supply.
*Added 5volt supply pin to UART connection
*Added ground VIAs to all ground pins.
*Moved a few traces here and there for cleaner routing.

Need to do:
*Connect buffer control pins, power.
*Route FPGA DONE pullup
*Choose pins for FPGA ARMED/TRIGGER LEDs

I have asked the question before but didn't get an answer:

What happened to the use of •M74LCX16245 16 Bit buffers.?  
The M74lcx16245  was a bidirectional buffer where as the 74lvtx573 is a  latch, I don't recall a discussion on why a latch was required  Note 74LCX245 is an 8 bit version altough the savings are small

It seems to me using the 74LCX16245MEA, that 16 bits could be incorporated for a few pennies more. Mouser quotes  74LCX16245@$.654 verse 74HC573D @$.174   As for the additional header I suggest  using a stackd one like the USBee uses. 

Hi Rich,
Our goal is cheapest possible, fastest possible, logic analyzer. We tossed anything that costs extra that doesn't support those narrow requirements. Jack and I went with the 573 for a couple reasons:

The unidirectional input is more consistent with the purpose-built logic analyzer goal.
We're not using the latch feature, it's a cheap 5volt tolerant input buffer. 
The 8bit chip is cheaper to buy, place, and QC.
8bits was a lot easier to route cleanly on the first version/try.

The 'wing' connector provides an additional 16bits of 3v3 I/O that can be used for any purpose. A future version may have more buffered channels.

Sorry for such a delayed response, there have been some very good suggestions and questions that deserved a well thought out response. I needed some time to really look into the series resistor suggestion.

First off I just wanted to review our stated goals:
   1) Logic Analyzer for $30-40 US dollars
   2) 70Mhz+ speeds (We revised this to 50Mhz for the first revision)
   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.

These goals were intended to limit the scope of the first revision in order to make it something that we can accomplish in a timely manner. While there is a lot of potential for improvement a first revision with the above features and a 50Mhz speed is still going to be an incredibly useful device. I think it is in this projects best interests to focus on getting a workable first revision finished and then work on improvements in future revisions. So with these scope limiting goals in mind lets talk about some of the excellent suggestions we have received.

"1) Is there any plans to break out the unused IO pins on the top of the FPGA to a separate header, there seems to be space for routing and header placement.  For example pins 2-5, 9-12, 15-18, 22, 23, this could add more options for future wings, and expansion."
The reason I didn't place a header here is because any traces coming off the top of the chip will not be routed over an unbroken ground plane and will be have a greater likelihood of suffering crosstalk at speeds over 50Mhz. I think if we make that header the last 8 channels of 32 channels and only use it for speeds under 50Mhz then this is a great suggestion to implement.

"2) It seems there should be a mounting hole at the top of the board for a standoff to give people more options in future expansion, it would be used to stabilize shields that would sit over the board instead of sticking out as the wings would."
Space permitting with the header mentioned above we will try to squeeze one in.

"3) On the series termination resistors, I think they would be a really good idea, ring could get nasty with test leads coming off the board.  They sell SMD resistors arrays with 8 resistors.  You could also go to a smaller package size buffer if placement and routing becomes and issue.  It doesn't look like there is enough space to add them on the other datelines without moving up the fpga."
This was the tough one that had me thinking non-stop over the weekend. I'm leaning towards not including series termination resistors with revision 1. Here are my arguments against including them:

1) Our stated goal is 50Mhz, the reason for choosing 50Mhz is because proper SI analysis is time consuming. Lets save a proper SI analysis for the next revision and make sure we really do it right.
2) Something that really gives me pause in regards to adding series termination resistors is the fact that of all the dev boards I looked at that the Sump project has been implemented on none of them had series termination resistors. The VHDL core supports speeds up to 200Mhz and I assume people have been successful with these other boards at these speeds without series termination resistors. I think for the first revision we need to stick with the standard blueprint that has worked for others.
3) So how are people sampling at 200Mhz? I suspect that people might be using high end probes from Agilent or some other vendors that have series resistors or RLC networks built into the probe. If we add our own series resistors we are going to change the impedance of any probes that are connected.
4) The Wing connector was added to provide a path for us to develop high speed addons, we always have the option to experiment with series termination resistors on a Wing. The reason that a 16 Bit Wing was selected is because the VHDL core only supports 16 channels at 200Mhz. So we are well situated with a 16 Bit Wing to make a 16 Bit Buffered, 200Mhz capable addon Wing.
5) As far as the Wing connections go, if we presume that most Wing boards are going to provide some kind of buffer then series termination resistors on the Sump Pump board will not provide any benefit. Any series resistors would need to be on the other side of the buffer, which would be on the Wing, and series resistors on the Sump Pump circuit board will only make the board less DIY which is against one of our stated goals.

So these are the thoughts kicking around in my head that are making me lean towards not including series termination resistors. As with anything I am very open to the possibility that I am either missing something important or that there are compelling reasons that outweigh the above. So if after reading the above anyone still feels that series termination resistors are the way to go then lets continue to have a discussion about it so we can hear the compelling reasons to go the other direction.

Thanks,
Jack.

I feel like I'm beating a dead horse, but let me kick the horse one last time and see if I can get it rise from the dead/

Although I really feel a single 16 bit tranceiver is well worth the additional cost  I would like to suggest a compromize.  That would be a)use 8bit transceirers, b) do the routing for 2 chips but depopulate to one in base offering.
It would be great if enhanced versions are forth coming but I have seen too many projects dead end after the initial go.  
The additional  buffer opens many possiblity, with only programing additions,external clocks,triggers,function generator.   I don't like the use of a latch where a bi-directional tranceiver culd be used just as well.
 I took a stab at the incorporation of the second chip to see if the roouting would be a nightmare, but it looks straight forward.  Take a look at my snapshot.

I would be more than happy to donate my effort to contribe this portion, if Jack is pressed for time.

As to the termination resistors, from my experience they are highly desireable, again a cheap addition.  I don't think a detail analysis is needed from my years experience a 22ohm will solve most ringing. If you really think its necessary to save pennies leave the pads and add bridges that can be cut.   If you add the pads now the user has the option without requiring exspensive probes or clugging up a solution.

Sorry to be a pain, but I think it is best to bring up these issues while it easy to take care of..

Rich,

If you want to post the design files we will incorporate it, looks like a good compromise to me. Assuming Ian agrees of course, it does require increasing the size of the board. Ian has a better handle on how that will impact the final cost than I do, SeeedStudio is a big question mark for me.

Jack.

Attached are the zip files for the 16 bit buffer  option
note the following changes
    I moved the termination resistors to minimize the added board length.
    I slid inputs 1-9 down a pin on the FPGA to accomodate the direction control pin  routing
    The input0-7 order has been reversed on the connections to the FPGA
    inputs 8-15  have been attached to the FPGA's pins  2-5 & 9-12  The direction control for port b was attached to FPGA pin 15.  I wasn't sure if pin 13 (IP) could be used?  Was it okay to use these pins for the second port?
 
I am not a FPGA expert so let me know if I screwed up the FPGA connections 

Here an image of the 16bit buffer version 
This board is 4.4in long verse 3.65in for the original.  If this concept is accept by all  I will work to shrink it a little   

Before commenting on the buffer/transceiver/resistor discussion, I'd like to make one more suggestion to the PIC <----> FPGA serial (asynchronous) interface - no change, rather a minor add-on:

I suggest to add pads/vias for a .100 spaced 2 pin header on the serial interface (TX, RX) between the PIC and the FPGA. This would allow

a) to monitor the interface between the PIC and the FPGA (i.e. with two Bus Pirates or more sophisticated line analyzers) during development and for debugging should anyone chose to develop different designs/enhancements for the FPGA. GND is available from the legacy UART connector. In production the header would not be populated and it will be up to the user to add the header ...

b) connect the FPGA directly to a PC (using a USB/RS232 converter cable) or some other MCU/interface instead of the PIC (so it may require a "ignore FPGA" mode for the PIC).

By now I have a SUMP LA implementation running on the Pollin CPLD board and I experienced sporadic communication problems at 9600 Baud. First I wasn't sure what caused the problems but by putting a Saleae Logic LA on the serial output of the FPGA I was able to establish that the problem was caused by a bad oscillator (runing almost 5% slower than specified ... well outside the tolerance). Now I have the Saleae hanging on the serial interface of the CPLD all the time and can check the communication between the PC and the CPLD whenever I want. So I have a JTAG interface connected as well, I prefer to use the line monitor whenever I experience communication problems.

(while writing this, Jack posted the latest PCB update ... looks better every day :) To my surprise I found a 2 pin header between the FPGA and the PIC, first I thought he was able to read my mind until I realized it is the header for Ext_Trigger_In and Ext_Clock_In ... taking up the place I thought the "monitor" header could have fit in ... now it will become more difficult to fit this header on the board).

(http://http://img709.imageshack.us/img709/7784/lapcb09122009txdxheader.th.png) (http://http://img709.imageshack.us/i/lapcb09122009txdxheader.png/)

Now for the buffer/transceiver/resistor (probe header) discussion:

I am inclined to agree with RichF and Jack - sounds like a contradiction? Not necessarily ...
Right after entering this discussion, I accepted that this is Ian's and Jack's project. Since someone has decided "to beat a dead horse" it won't make much difference if the dead horse gets beaten even more ... so here we go :D

1. 22 Ohm resistors for serial terminators sound ok from my experience, too (39 Ohm did well in some other design) but experience isn't everything. I am against terminators on the "primary" header. Jack's arguments - in particular the following - can't be dismissed:
   - it will make the design (even) less DIY, require a larger PCB and kick manufacturing cost up
   - if people want to use R or RLC terminated high-end probes the resistors will mess with the impedance
   - the goal is 50MHz and I don't expect the need for termination to suppress crosstalk at up to 50MHz
   - if anyone wants to terminate the lines he/she can go for the other 16 channels on the unbuffered Wing header - the plan is to develop a buffered/terminated 16 addon Wing anyway - use RLC  probes or add a small board with terminators/filters to the "primary" header (not sure if that will help much and not add more problems, so).

2. For the 8 vs 16 buffered lines on the "primary" header and the question of using buffers or transceivers:

  - It looks like there is space for 16 buffered but not terminated lines - take RichF's idea and make it a 1x18 (maybe 1x20 - 2x GND, +5V, +3.3V) header instead of a 2x9 header - routing should not be too difficult if following RichFs general concept, keep the resistors out  ... there would be no need to route traces to the edge side of the header ...
  - make the "primary" header 16 buffered (input only) lines - most people will use the device as a LA (and isn't that primarily what this project is about anyway?) only and may never use the wing header but they would love to have more than 8 channels for sure ... those who want 32 channels will have to use the wing header as well (32-bit will work only up to 100MHz anyway)
   - at above 100MHz the VHDL design is 16-bit only and will serve the Wing header only - allowing for the use of customized Wing boards - that's the place to put bidirectional lines/transceivers, level shifters, filters, terminators ....

In short: "primary" header (Port A) 16 buffered (input only) non-terminated lines.

Updated the block diagram according to the latest schematics (almost ;) :

(http://http://img137.imageshack.us/img137/5665/lablockdiagramrev02cs.th.png) (http://http://img137.imageshack.us/i/lablockdiagramrev02cs.png/)

If anyone is interested, we're starting discussion of a DSO (digital sampling oscilloscope) wing here:
http://whereisian.com/forum/index.php?topic=233.0 (http://whereisian.com/forum/index.php?topic=233.0)