Dangerous Prototypes Open Source Hardware

[arhimed@gedora10 trunk]$ pic32-trunk-20100720/cross-build/
bfd/           config.status  gas/           intl/          libiberty/     opcodes/       sim/           
binutils/      etc/           gcc/           ld/            mmalloc/       readline/      utils/         
[arhimed@gedora10 trunk]$ pic32-trunk-20100720/
cross-build/   install-image/ src/           
[arhimed@gedora10 trunk]$ pic32-trunk-20100720/install-image/
bin/     include/ info/    lib/     man/     pic32mx/ 
[arhimed@gedora10 trunk]$ pic32-trunk-20100720/install-image/bin/
mypic32-addr2line  mypic32-bin2hex    mypic32-gcc        mypic32-ld         mypic32-objdump    mypic32-run        mypic32-strip      
mypic32-ar         mypic32-c++filt    mypic32-gccbug     mypic32-nm         mypic32-ranlib     mypic32-size       pic32mx-gcc-3.4.4  
mypic32-as         mypic32-cpp        mypic32-gcov       mypic32-objcopy    mypic32-readelf    mypic32-strings    
[arhimed@gedora10 trunk]$ pic32-trunk-20100720/install-image/bin/mypic32-gcc --version
mypic32-gcc (GCC) 3.4.4   microchipopen.com ccompiler4pic32 v1.10(B)-20091123
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[arhimed@gedora10 trunk]$ 

[INFO] Compilation failure
/home/arhimed/Dev/OBLS/Alternate/ols/util/src/main/java/nl/lxtreme/ols/util/DisplayUtils.java:[110,18] unmappable character for encoding UTF8
...
[INFO] Compilation failure
/home/arhimed/Dev/OBLS/Alternate/ols/util/src/test/java/nl/lxtreme/ols/util/DisplayUtilsTest.java:[63,25] unmappable character for encoding UTF8

Also, your idea about integrating a counter into a SRAM Wing has really got me thinking. I have some other things I have to wrap up first but I would like to give it a shot when I get the time. In the meantime I've been trying to find an appropriate counter IC since a CPLD will work but a counter IC will be easier. I figure that with the 16 bit Wing header we can use 1 pin for the up clock and 1 pin for the down clock. That leaves 14 pins for data which I think should be a pretty good deal for most people.

I was thinking maybe something like two of these to handle 16 address lines:
http://search.digikey.com/scripts/DkSea ... 69D,602-ND

but there are a couple of LA implementation for Xilinx Coolrunner CPLDs (so most with 8/16 channels only). However, the implementations require CPLD boards with external SRAM (interesting part, the person who implemented a SUMP like LA on a Coolrunner CPLD board did it for an "easy getting started with CPLD/FPGA" project.

For the SRAM part it doesn't matter if you use a Coolrunner CPLD or some other circuitry ... the logic is the essential part and you could describe/synthesize it in VHDL for any configurable logic device with enough gates ... the essential part is the design you want to use for it:
- rsdio pointed at dual-ported SRAMs (real neat stuff for video and other applications that require independent simultaneous access to the memory from two sides)
- FIFO (a FIFO with sufficient buffer could do the job, even better, a FIFO with RLE could allow for endless capture streams provided that you have sufficient bandwith to send the data to the host)
- standard SRAM with the (address) counter you described (first it captures the data in SRAM, then the SUMP engine reads the captured data from the SRAM and transmits it to the host)
- serial SRAM (one chip per channel) - some serial SRAMs have auto-increment adressing driven by a clock signal - and a multiplexer to read the captured date from one channel (serial SRAM) after the other
... just some examples. You can implement/synthesyze each design concept in VHDL and simulate the design without physically implementing the hardware (memory and logic) in hardware (regardless if discrete logic, CPLD or FPGA ...). There are many options, so I doubt there will be many who will actually design and build a capture buffer shield/buffer with memory for the current OLS version. The 100-pin package of the Spartan-3E used in the OLS v1/1.1 design puts a rather stringent limit on the number of I/O lines for an efficient and performant external capture buffer memory. We could actually add memory to the 16 buffered input lines and use the unbuffered header to control the memory ... but then some may look into a redesign of the OLS, a version 2 that may use the 144-pin version of the Spartan-3E or a completely different FPGA (i.e. Actel SmartFusion or ALTERA Cyclone) ....

Hmmm, you could use your HW-SPAR3AN-SK-UNI-G as a SUMP LA ...

This code will need an extension to the standard SUMP command set. A version id and check should rather be implemented in the VHDL code than "post-tag" the version/revision to the bitstream in SPI flash memory.

At this point the OLS is not intended as a low-cost general FPGA development platform

FPGA development boards usually offer different forms of external configuration memory (serial flash, parallel flash), so essentially you can load 4 images in the configuration memory (2 in SPI flash, one forward, one backwards and 2 in parallel flash) - read ug332.pdf for details