Parts list (rough design, options)

[ian]

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

[ian]

The eagle files that go with it.

[jack.gassett]

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.

[jack.gassett]

Excel spreadsheets.

[ian]

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/DkSearch/dksus.dll?Detail&name=576-1259-1-ND
2.5V
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=576-1257-1-ND
ADJ (1.8/1.2?)
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.

[ian]

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.

[IPenguin]

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:



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:



from Spartan-3 Generation Configuration User Guide - p. 103

[jack.gassett]

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.

[jack.gassett]

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

Jack.

[jack.gassett]

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

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.

[jack.gassett]

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/

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

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
• User name = anonymous, leave the password blank

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

Jack.

[jack.gassett]

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

[IPenguin]

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):



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

[ian]

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

[ian]

I forgot to add: fantastic diagrams Uwe!