Jack Gassett

The next generation Papilio - help me shape it.

226 posts in this topic

Hey everyone! We've learned a lot from the Papilio One and the Papilio Pro, its time to take those lessons and apply them to a next generation Papilio board. I mentioned a new board earlier, similar to the never released Papilio Logic, and many of you privately provided some great feedback. My head is swimming with new ideas and I wanted to take some time to write it all down and ask for feedback, help, and ideas.

 

The goal with this new board is to make it useful and appealing to all electronics enthusiasts, not just those into FPGA's. I want it to be the first thing you pick up when you have an idea you want to try out, the most useful electronics multi-tool on the desk. That's why I'm code naming it - Papilio Benchy - to convey that goal.

 

What we have learned from the Papilio One, Papilio Pro, and Papilio Logic

  1. Probably the most often heard request is for the Arduino footprint. People really want to use the vast library of Arduino shields that are out there.
  2. I learned with the Papilio Logic that one of the headaches of the Arduino footprint is the analog pins. Using an SPI ADC was a mistake...
  3. The next often heard request is to provide lots of external RAM, and SRAM instead of SDRAM. SDRAM is hard to interface while SRAM is a piece of cake.
  4. Not fully connecting the SRAM chip severely cripples is usefulness. Connecting BLE and BHE to ground is a mistake...
  5. We need high speed USB, the FT2232D is only capable of 3Mb/s the way we have it connected. Lets upgrade to 480Mb/s...
  6. It sucks that we can only use one of the two FT2232 channels in our FPGA designs. I often wish I could have one serial channel for sketch output and another for logic analyzer output.
  7. Not having a full FT2232 MPSSE channel connected limits what we can do.
  8. Connecting to a computer and loading a bit file when you change shields is tedious. Selling a solution such as the RetroCade Synth as a kit that someone has to download all the Papilio software and program a bit file before they can use it is not user friendly. Many people who buy the synth want to use it as a synth, they don't care about the FPGA stuff...
  9. Switching power supplies are the way to go, the extra cost is worth it. Putting a Papilio One in a case with those linear regulators isn't going to fly.
  10. Eliminate through hole parts, the more through hole soldering is done the dirtier the board is after assembly.
  11. HDMI!!!!!!!!!!!!!

How to apply those lessons to the Papilio Benchy

  1. If you can't beat 'em, join 'em. The next Papilio board will use the Arduino Mega footprint, pins 30-55 on the right side of the board will be modified to allow Wings to be connected to them. People can plug Arduino Shields in and still add ala carte functionality using the Wing slots on the right instead of stacking shields. MegaWings will be replaced by shields going forward.
  2. On the Papilio Logic, which was an Arduino Mega footprint Papilio board I made in 2011 I used an SPI ADC chip to implement the analog pins. This was one of the reasons I never brought this board to market, the price of SPI ADC chips shot up drastically after I finished the design... I also shared the pins with 53-55 on the Arduino footprint which I didn't like. Logxen pointed out a much more elegant solution that kills several birds with one stone. Use an AVR for the analog pins... Well, why stop there, the Atmega32u4 used in the Arduino Leonardo is just about the same price as the SPI ADC that I used. We can add a full blown Arduino to the design for about the same price. If we have the FPGA pins and the Arduino pins both connected to the Arduino footprint then we can run fully compatible Arduino sketches on the Atmega32u4 and use the FPGA as a Logic Analyzer or debugger. We also get all the benefits of the Arduino Leonardo, such as more flexible USB types... This is going to be a routing challenge, but if we need to go to a multi-layer board then it is worth it.
  3. All of the SDRAM on the Papilio Pro is nice, but it is hard to use. With the Papilio Benchy we should use SRAM instead. The reasons for using SDRAM over SRAM were: 1) cost 2) fewer pins. After doing more research on the Chinese parts market I was able to determine which SRAM parts are plentiful and cheap. I noticed that there are plenty of 8 bit parts out there for very affordable prices. If we move from the 16 bit part to an 8 bit part then we will free up some critical pins and might be able to squeeze SRAM and a full speed FT2232 MPSSE channel into the design. One such chip is the IS61WV20488, if you look at it on digikey it is scary expensive $14. But a search on Taoboa shows it for around $8. If that is too expensive then we can always fall back to a 512Kx8 chip which is around $4 on digikey and $1.64 on Taoboa.
  4. Moving to an 8 bit part should allow us to fully connect it.
  5. We will upgrade from an FT2232D to the FT2232H, which is actually a cheaper and more capable chip! It does 2.0 480Mb/s and has two full MPSSE channels. The FT2232D only had one MPSSE channel.
  6. I want to connect both channels to the FPGA this time. Channel A will still be connected to JTAG for programming, but the rx and tx pins will also be connected to the FPGA for a low speed, 3Mb/s, serial channel. There are some question marks here, but I suspect that if we keep cts disabled, which is connected to the FPGA JTAG TMS pin, while we use the channel A rx and tx pins it will never activate the JTAG programming on the FPGA. Worst case scenario we need to add some kind of switch to disconnect the TMS pin. Channel B will hopefully be fully connected to the FPGA. Worst case scenario we can only connect the first 4 MPSSE pins and will not be able to achieve full 480Mb/s.
  7. The FT2232H, unlike the FT2232D, has MPSSE on both channels! Yeah!
  8. I would like to embed some kind of one wire identifier chip on the shields and have all of the Papilio bit files stored in SPI Flash and controlled by multi-boot. When a shield is connected to the Papilio Benchy the golden image will read the identifier chip and multi-boot to the correct bit file. This will take some work but will go a long way toward end user convenience. Imagine connecting a Logic Analyzer shield and the Sump logic analyzer bit file is automatically loaded. Then we can have software that reads the ID when you plug the board into a computer and will automatically start up the Sump Logic Analyzer client. Or how about a shield with a ZIF socket that loads a bit file that connects the MPSSE pins in a way that allows the Flashrom project to work... That will go a long way towards making the Benchy the first tool you would grab when you need something...
  9. Not much to say here, upgrading to the power supply used on the Papilio Pro is a no brainer.
  10. Not much to say either...

Summary of proposed features to implement

  • Arduino Mega footprint
  • Arduino Leonardo implementation side by side and sharing the pins with the FPGA. There will be two USB connectors for a total of 3 serial channels to the board. The Atmega32u4 will implement the analog pins which the FPGA can read over a SPI channel.
  • 8 bit SRAM chip
  • FT2232H with Channel A connected to JTAG and rx/tx connected to FPGA pins. Channel B fully connected if possible, if not then just the 4 MPSSE pins.
  • HDMI port

This is a wishlist, it will be a juggling act to pull all of this off and compromises will undoubtedly have to be made. It is ok to go to a 4 layer board instead of a 2 layer board, but for this board I'd like to avoid BGA. There are other ideas for a high end BGA board...

 

Jack.

Share this post


Link to post
Share on other sites

So, to start off the design the existing Papilio Logic design will be used. Since I have already used the name Papilio Benchy in an earlier project I am going to call the older one Papilio Benchy jr..

 

The github repository is here.

 

A pdf of the schematic is here.

A pdf of the board is here.

 

Datasheets:

FT2232H

8-bit SRAM - 2MB

8-bit SRAM - 1MB

8-bit SRAM - 512KB

Share this post


Link to post
Share on other sites

First order of business is to replace the power supply.

 

Here is the old linear power supply:

post-29509-0-38773300-1389051501_thumb.p

 

Here is the new switching power supply:

post-29509-0-97751100-1389051502_thumb.p

 

It's not routed yet the power supply block has just been swapped out.

 

Jack.

Share this post


Link to post
Share on other sites

Next up is changing the FT2232D to a FT2232H. Ian Lesnet at Dangerous Prototypes was kind enough to release a FT2232H reference design with a generous CC-0 license. No point in re-inventing the wheel, its exactly what we need.

 

FT2232D design:

post-29509-0-65815500-1389052090_thumb.p

 

FT2232H design (needs to be shrunk down into our space and routed):

post-29509-0-30121000-1389052092_thumb.p

 

Share this post


Link to post
Share on other sites

And the final piece - adding a condensed version of the Arduino Leonardo design.

post-29509-0-54294100-1389052369_thumb.p

 

Since the Leonardo design is CC-BY-SA we will have to have the same type of license, which sounds good to me...

 

All the pieces are in place, with the exception of changing the SRAM to an 8 bit part. The hard part is seeing if it can all work together...

 

Jack.

 

Share this post


Link to post
Share on other sites

Here is a big question mark, I widened the Arduino Mega board so I can make the highlighted 8-bit I/O groups wings. Is it better to have two more Wing slots and 5V tolerant I/O for the original Arduino footprint or is it better to drop all of that and keep the original width so Arduino Mega cases will fit?

post-29509-0-48103000-1389053229_thumb.p

 

Jack.

Share this post


Link to post
Share on other sites

Jack, is BGA technology out of the question for the FPGA?  If you could manage the CSG225 package, it is only $1 more than the TQFP option (digikey, unit 1), and would offer the possibility of having an LX16 option as well as LX9.  If it is possible to route to some of the extra I/Os, you could stick with the x16 SRAM and not make any compromise there.  If you could mange a CSG324 BGA, then LX9, LX16, LX25, LX45 are all possible.  That would be great, even if most of the extra I/Os are not routed out.  I realize that inspection of BGA soldering is probably an even bigger issue than the routing of it.  At least with the routing, it is a one time problem and you know where you stand.

 

Overall, I think SRAM is a lot more approachable than SDRAM design.  On the other hand, some of the xilinx parts have integrated SDRAM controllers, paying attention to the routing and connecting the SDRAM to the right pins and making sure all the right traces have matching length, you get speed and capacity without too much pain.

1 person likes this

Share this post


Link to post
Share on other sites

Oh haha great. I go on holiday and a great topic shows up so I have to check out schematics on my tiny gayphone screen.

Hey one idea I have which should be easy to meet is to make the wing slots PMOD compatible. This means simply adding a gnd and vcc row to each end of the 16 bit data rows so one of them many many single and dual row PMODs can plug in directly without adapters.

                    [5 3.3 - GND]         [5 3.3 - GND][VCC] [GND] [          8 IO pins] [          8 IO pins] [GND] [VCC][VCC] [GND] [          8 IO pins] [          8 IO pins] [GND] [VCC]            [GND - 3.3 5]         [GND - 3.3 5]

Excuse the ASCII fart above, The only drawback is that someone could plug in a wing offset and coonect to the end power pins. The mitigating factor is that because the wings have the power pins offset, by lining them up it should in theory prevent someone plugging in the wing wrong.

 

The PMODs would then plug into the very end 4 IO pins with the power pins towards the outside. Perhaps the outer berg strip pins that correspond to power could use a different color (not black) from the Io pins to signify they are special. Anyway, just an idea to expand the existing base of plug in boards, you could then have arduino shields, wings AND PMODs as directly pluggable.

 

EDIT: Having just looked at the PDF you posted above, i see you are already almose there, since you have a 5v and GND header at each end of the IO pins, you just need to expand on that idea as per my crude diagram above.

 

Also I second Jim Battle's request for BGA. I know it has come up before and it was decided to be too hard/expensive, but I thought I'd re-itterate the benefits of having all the extra pins open a lot of avenues for connecting a lot of stuff. Of course that means moving to 4 layer boards.

 

FINALLY: I know how hard it is to please everyone all of the time, so while it may be more work on your part, you could offer two different board designs, one with SRAM and another with a SDRAM routed in place, then people could purchase whichever they prefer. This would create a bit of fragmentation as some designs targeted at large SDRAM memory would not fit in the SRAM and some designs depending of the very fast access time of the SRAM would not work on SDRAM, but at least the choice is there for people.

Share this post


Link to post
Share on other sites

I love the idea of onboard HDMI, it's one of the reasons I grabbed a Pipistrello a while back. I assume you can put the socket on the bottom right, where A8-A15 would usually be on a Mega.

 

I wouldn't worry about trying to make it fit Mega cases, particularly if it compromises functionality. FWIW, I'd also try to find better places for the mounting holes, whoever did the original placement for the Uno/Mega was an idiot... 3 of the holes can never be used as there's no room for a screw head and another requires a nylon screw unless you're happy with risking a short.

 

+1 for BGA too if you can do it. If you then land up with spare IO, how about routing them to an FPC footprint on the underside of the board so that those that want/need to can add the extra connector?

Share this post


Link to post
Share on other sites

Lots of great ideas and feedback guys. I like the PMOD idea, its something that I had thought about but did not look at yet to see how to make it happen. If it just requires a couple more pins then heck yeah, I'll see if we can make it happen.

 

I lost a little steam when I got towards the end of that first post, I had intended to talk about where this board fits in with the scheme of things. I'm looking at making three new boards, a low end board with the Arduino footprint and no external ram that will be very affordable. A middle board that has external ram and as many features as we can accomplish with the TQFP footprint. A high end board that will be BGA, have every feature we would want, and it will cost what it will cost... This board here is the middle board, the high end BGA board is going to be next and should be much easier... It is going to use the built in memory controller for DDR3 SDRAM and will also be an Arduino Mega footprint. The low end board is going to be a piece of cake so I'm saving it for last. I wanted to do the hardest one first so we can see what kind of ideas shake out and apply them to the easy boards later...

 

Jack.

Share this post


Link to post
Share on other sites

Just having SRAM instead of SDRAM would open up a lot of doors. I find that I rarely fill the FPGA on even the S3500K but BRAM is almost always the limiting factor.

 

For those who want to use the Retrocade Synth out of the box, would it be practical to just offer a pre-loaded ready to run package? I suspect you could charge an additional fee for that service.

Share this post


Link to post
Share on other sites

I forgot to say about your point 6 above. While you can connect both JTAG pins and RS232 pins of channel A to the FPGA be aware that the chip uses MPSSE mode for JTAG and serial mode for RS232.

The mode port A or B runs in must be programmed in the EEPROM and can't be changed on the fly programmatically unfortunately. This means you'd have to reprogram that EEPROM byte to MPSSE then disconnect and reconnect the board to get it into JTAG mode then when you finish uploading code you must reprogram that EEPROM byte to serial mode and disconnect and reconnect the board for it to take effect as a serial port. if the FPGA design was volatile you'd lose it at this point unless you has a second supply connected.

Share this post


Link to post
Share on other sites

Alex, I don't believe this is correct.

 

The only mode selection you can do in the EEPROM is "RS232 UART", "245 FIFO", "CPU FIFO" and "Opto Isolate".  MPSSE mode is selected via software and you can enter that mode independent of how you have set up the mode in EEPROM.  I.e. you can enter it from any of the four modes selected in EEPROM

 

In the Pipstrello EEPROM I program port A to be "245 FIFO" since that prevents the operating system from loading VCP drivers for port A.  However, on a blank EEPROM, port A comes up as a RS232 UART.  In both cases you can enter MPSSE mode via software.  See attached table

post-36465-0-33721700-1389127153_thumb.j

Share this post


Link to post
Share on other sites

I think the issue you are trying to express is caused by a different problem.  If you want to use port A for both serial communication and in MPSSE mode then you will run into driver issues.  Once the OS has loaded VCP drivers (based on UART mode setting and VCP driver setting in EEPROM) then you can no longer talk to the FTDI chip via the ft2xx driver which is needed for MPSSE mode.  So somehow you have to unload the VCP driver from the operating system before you can switch to MPSSE mode. Or use serial communication via the ft2xx driver instead of VCP.

Share this post


Link to post
Share on other sites

Would it be easier to just offer a USB to serial port wing? You can get FT232 type USB to TTL serial converter modules for a few dollars, It might be easier than trying to do everything with one part if you need more serial ports. So far I've gotten by fine with just one.

Share this post


Link to post
Share on other sites

Alex, I don't believe this is correct.

The only mode selection you can do in the EEPROM is "RS232 UART", "245 FIFO", "CPU FIFO" and "Opto Isolate".

Yeah I was going from memory as I don't have the data sheets handy. I noticed that the FTDI EEPROM utility is able to cause the chip to disconnect and reconnect to the bus under software control. I don't know if there's an API for that. if there is it may be possible to reprogram the mode and force a new USB enumeration letting the OS load appropriate drivers for the new mode. some experimentation might be in order here. even if there is no documented API I could reverse engineer the process though that's technically bad programming style relying on undocumented features.

Share this post


Link to post
Share on other sites

Alex, I don't believe this is correct.

 

The only mode selection you can do in the EEPROM is "RS232 UART", "245 FIFO", "CPU FIFO" and "Opto Isolate".  MPSSE mode is selected via software and you can enter that mode independent of how you have set up the mode in EEPROM.  I.e. you can enter it from any of the four modes selected in EEPROM

 

In the Pipstrello EEPROM I program port A to be "245 FIFO" since that prevents the operating system from loading VCP drivers for port A.  However, on a blank EEPROM, port A comes up as a RS232 UART.  In both cases you can enter MPSSE mode via software.  See attached table

Yes, that has been my experience too, it is just certain modes, such as Opto Isolate in my case, that require changing the EEPROM. RS232 UART is the default and we don't need to change the EEPROM to go into MPSSE mode.

 

I think the issue you are trying to express is caused by a different problem.  If you want to use port A for both serial communication and in MPSSE mode then you will run into driver issues.  Once the OS has loaded VCP drivers (based on UART mode setting and VCP driver setting in EEPROM) then you can no longer talk to the FTDI chip via the ft2xx driver which is needed for MPSSE mode.  So somehow you have to unload the VCP driver from the operating system before you can switch to MPSSE mode. Or use serial communication via the ft2xx driver instead of VCP.

Ok, this could be a real problem that I hadn't anticipated at all... Maybe we can have papilio-prog unload VCP when it needs to program a bit file and enable it afterwards...

 

But wait, this doesn't seem to fit, the Papilio One and Pro does not have anything programmed to the EEPROM so it goes to the default, which is to load channel A as a rs232 with VCP. The VCP drivers are up and running but papilio-prog is still able to program a bit file in spite of that... Hmmm, needs more research, maybe I will just solder some wires on a P1 to some FPGA pins and see how things work.

 

Anyway, this information and feedback is like gold! Thank you all for sharing.

 

Jack.

Share this post


Link to post
Share on other sites

I ran a quick test on windows and it it seems that I was wrong. 

 

I plugged in my Pro and it showed up as COM88 and COM89.  However, I could still access to board via ft2xx driver and ask for the scan chain info etc.  If I opened a putty terminal on port 88 I then got the dreaded "Could not access USB device 0403:6010" when I asked for the chain info but once I closed the putty terminal I can access it again.  So this looks like not a problem.

 

Don't know about Linux though...

Share this post


Link to post
Share on other sites

Hi,

 

Now this is only a thought. There seems to be no shortage of FPGA boards on the market, the market is quite well covered. I wouldn't try to compete with that.

But maybe there is an opportunity for some open-source synth platform. At least I don't know of any competitor.

 

Personally, I'd be more thrilled about sound quality than control options (rather "vintage" than "retro").

 

The hardware itself is fairly capable, one DSP slice can do about 100 million multiplications per second! Try that in a VST plugin.

 

One could probably make a fairly convincing ROMpler even by streaming from the EPROM. Need more polyphony? Copy and paste the RTL, and put some more EPROMs to the board (I actually ordered some, may hot-glue some to the top of the FPGA if I have time)

 

Or, organ emulation. The 16 analog inputs have "Hammond drawbars" written all over them. The challenge is not so much the hardware, but the RTL implementation.

Share this post


Link to post
Share on other sites

y In my experience, VCP and FTDI DLL modes coexist peacefully. I have often set VCP to the wrong FTDI chip, but it doesn't break anything.

 

My Papilio shows as two COM ports in Teraterm. If I open the wrong one, Papilio loader won't work until I disconnect the terminal connection (which is IMO the correct response as the port resource is busy).

Share this post


Link to post
Share on other sites

I did some digging into this.  It works on Windows because of the CDM driver which includes both VCP and d2xx driver.

 

This is what I found for Linux:

 

In Linux, the VCP driver and D2XX driver are incompatible with each other. When a FTDI device is
plugged in, the VCP driver must be unloaded
before a D2XX application can be run.
 
Use the remove module (rmmod) command to do this:
 
sudo rmmod ftdi_sio <ret>
sudo rmmod usbserial <ret>
 
When the FTDI device is power cycled or reset the VCP driver will be reloaded.
 
The rmmod process must be repeated each time this occurs. It is possible to write a simple script that unloads the VCP driver before running the D2XX application

Share this post


Link to post
Share on other sites

My 2 cents:

 

- definitely yes to SRAM; 8-bit is fine

- any chance of variants with larger Spartan-6 chips? Even a LX16 or LX25 would increase the range of projects substantially.

- no more megawings? :(

Share this post


Link to post
Share on other sites

My 2 cents:

 

- definitely yes to SRAM; 8-bit is fine

- any chance of variants with larger Spartan-6 chips? Even a LX16 or LX25 would increase the range of projects substantially.

- no more megawings? :(

 

The tqfp footprint only comes in LX4 and LX9 so we are stuck for this mid level board. But the BGA board will allow the full range of chips up to LX25.

 

I might make future addon boards in both the MegaWing and Shield format depending on what the demand looks like. If the Arduino footprint sells a lot more then the Papilio One and Papilio Pro then I will probably phase out the MegaWing.

 

Jack.

Share this post


Link to post
Share on other sites

Hi Jack,

 

We had some offline emails on this, but I just noticed you have a forum topic on this subject.

3 boards to support (low, mid and high-end) might be lots of work, but depends on the demand and return you get.

 

IMHO, the mid-end board will still be targeted at high-end Arduino users, who want a lot more, but in the same footprint, so my feeling is maybe bes tto stick to the Arduino size (though you could make it fully rectangular, avoiding the wierd 'curved' Arduino shape).

 

Cost will be an issue, so SRAM 512kx8 should do it. (if people want more, there is the high-end board for that, plus other extras).

 

As already offered, if you need help on the Eagle design, once your functional requirements are set, let me know.

 

best,

-Dan

Share this post


Link to post
Share on other sites

forgot to ask:

Did you ever get the requirement to add a socket for (micro) SD card?

 

-D

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now