The next generation Papilio - help me shape it.


Jack Gassett

Recommended Posts

  • Replies 225
  • Created
  • Last Reply

Ok, time for some decisions about how to use those free pins.

 

The goals for those pins are:

  • High speed USB 480Mb/s
  • FTDI channel A rx/tx low speed
  • FTDI channel B MPSSE
  • Connect pin A20 of SRAM so we can support 2MB parts
  • Ability to reset Arduino Atmega32u4 chip

Here is a diagram of the FT2232H pins

post-29509-0-06721800-1389299081_thumb.p

 

If we drop the High speed USB goal then we can easily accomplish the remaining goals:

 

Chan A rx/tx = 2 pins

Chan B MPSSE = 4 pins

A20 of SRAM = 1 pin

Arduino reset = 1 pin

Total of 8 pins.

post-29509-0-98753700-1389305579_thumb.p

 

If we want to go for the High speed USB goal too then it gets really complicated.

We have to implement Synchronous 245 FIFO mode which requires Channel A and 15 pins. We can also do Async 245 FIFO mode on Channel B, and lose some speed, but that still requires 13 pins.

 

We only have 8 pins available and the only way to pull of the High speed USB goal is to share pins with the GPIO pins. We would have to share 9-11 pins to pull it off. Not very attractive option in my opinion. One of the positives that people say about the Papilio is that there is no complicated ucf file or pin sharing scheme that you have to account for when you use the board. You don't have to study the datasheet to figure out how to disable this option or that option. I think that is very important for beginners and I'd like to stick to that.

 

So I think the best bet is to drop the High speed USB goal and save that for the higher end board with a BGA chip and plenty of free IO. For this board we can always slap a FT232H chip on a shield that needs high speed USB, such as a Logic Analzyer shield.

 

Jack.

Link to comment
Share on other sites

I was reviewing all the pins used on the FPGA and I noticed that I used INIT_B as an IO pin and that there is a free IO pin (104) that I did not notice before.

post-29509-0-30073500-1389307403_thumb.p

 

When I made a prototype of 8 Papilio Plus boards a couple years ago several of them had problems which led me to scrap the design. Init_B was one of the potential culprits... However, I have done pretty extensive testing with 3 of these Logic boards and have not had a single hiccup from the init_b pin... I highly suspect that the problems with the 8 Papilio Plus boards came from my cleaning process, I think I probably had the boards in the ultrasonic cleaner for too long...

 

But it is something to think on some more, I could re-arrange everything to free up init_b and use the other free pin. Or I could put a pullup resistor on the init_b pin, or it could be chasing a ghost and the problems I saw was from my manufacturing process.

 

Link to comment
Share on other sites

Ohhhhh, I forgot about HDMI!!!! Ooops, there was no way we could use those 8 free pins for HDMI anyway...

 

We should think about sharing some I/O pins for HDMI and place it in the lower right corner as someone suggested. I know I said I don't like to share pins, but maybe this is the exception...

 

Jack.

Link to comment
Share on other sites

I just remembered another idea I had that that free pin can be used for. I wanted to add a switch that would be used to select "Benchy Mode" or "User Mode".

 

The idea is that there will be a collection of bit files pre-shipped in SPI Flash and a multi-boot golden image will read a id from shields to determine what image to boot. If you want that behavior then you would select "Benchy Mode", but say you made your own custom bit file for the Logic Analyzer shield and you want that to boot instead of the default Logic Analyzer shield image. You would select User Mode and your bit file would be loaded instead. I know this could all be managed in software. But my thinking is that I want to be able to pick up this board at any given time, no matter what code I've been testing on it, and be able to flip a switch and have a reliable Logic Analyzer when I plug the LA shield in. Or a ROM programmer, or whatever shields and bit files are made. I don't want to have to plug into a computer and fiddle around with finding and loading the correct bit file. Or maybe not even plug into a computer at all, if we add HDMI then we might be able to make a LA that displays directly to a HDMI monitor and not rely on a computer at all. It will be a big win to always be able to boot to a reliable LA.

 

Will have to think more on this one. If no other need for that pin comes up then this will be it.

 

Jack.

Link to comment
Share on other sites

Jack,

 

It's a pity to loose the USB 480M speed, but ok we can't have it all :)

 

About the AVR reset, ok for the pin to the Xilinx.

How about the AVR programming? Do you intend to do this via the FPGA, or from the FT2232? 

The native Arduino has a "flaw" in that is uses the DTR signal connected to the AVR reset circuit. DTR is asserted from the moment you open a host connection, which resets the AVR.

This is a big issue - not the very beginner, but for a regular modest user.

Secondly many Arduino users use the serial monitor (or any other kind of host-slave serial connection, like SerPro). Will this functionality be maintained? If it can be done transparently via the FPGA, no problem.

 

 

-Dan

Link to comment
Share on other sites

Jack,

 

It's a pity to loose the USB 480M speed, but ok we can't have it all :)

 

About the AVR reset, ok for the pin to the Xilinx.

How about the AVR programming? Do you intend to do this via the FPGA, or from the FT2232? 

The native Arduino has a "flaw" in that is uses the DTR signal connected to the AVR reset circuit. DTR is asserted from the moment you open a host connection, which resets the AVR.

This is a big issue - not the very beginner, but for a regular modest user.

Secondly many Arduino users use the serial monitor (or any other kind of host-slave serial connection, like SerPro). Will this functionality be maintained? If it can be done transparently via the FPGA, no problem.

 

 

-Dan

 

I want to allow circuits in the FPGA to control the AVR reset, if the AVR is not being used then the reset line can be asserted so the AVR does not interfere with pins 0-13.

 

AVR programming, I intend to connect the icsp pins to the FPGA, I guess it will have to be 14,15,16, 17... I researched it a couple years ago and I was pretty sure that we should be able to use the AVR8 as an ICE debugger for the Arduino... I need to look into it again but I think that must happen with the ICSP pins, we can't go wrong with connecting them because then the FT2232 MPSSE pins can be connected to the ICSP pins through the FPGA.

 

Automatic reset - It appears that the Leonardo behaves differently, instead of using DTR it will reset if you connect at 1200 baud and disconnect. Refer to the automatic reset section of the Leonardo product page.

 

Serial Monitor - Since we are basing this on the Atmega32u4 which has its own USB integrated this should be taken care of. This board will have two USB connectors - one for FT2232h and another through Atmega32u4. Arduino users will connect to the Arduino usb connector and have a normal Arduino available to them with the added bonus of having an FPGA fully connected to it.

Link to comment
Share on other sites

Jack,

 

Re the auto-reset, yes I was referring to the other boards, like the Arduino-Mega board I used to work with a lot.

Indeed the Leonardo is different, with reset trigger at 1200 baud and bootloader 8' wait, where alternatively the reset button can be pushed.

 

Given you are using a 2nd USB port for the Atmega32u4 (which is great), the programming could also happen that way, IF the Arduino bootloader is installed.

 

The ICSP pins are 9, 10, 11, 13

 

Dan

Link to comment
Share on other sites

I don't like arduino formfactor, I suppose it could be ok with compability for shields, but then you have issues with voltage tolerances, most of the shields I have is 5v, then Due came and destroyed the game, since it's not tollerant for other than 3v3.. so shields render useless anyhow.

What is kinda nice, is that there exist some prototyping shields, but they are more expensive than buying an stripboard that would fit on the card if one take care when placing the IO pins.. (Where Arduino screwed it up, so you cannot stick an arduino in an breadboard.. 

 

if one absolutely need ardiuno compability, make the board somewhat like Arduino Tre, so you can keep wings, and such around the board.

Link to comment
Share on other sites

Hi,

 

there are of course pros and cons to any format, including the Arduino.

There are sooooo many formats out there. Every product has its own format and size. There is no standard, and interfacing those is always making different boards.

The nice thing about Arduino is that it is to some extend a de-facto standard. It's better to have something imperfect, rather than having nothing.

 

The 3.3V or 5V is a false problem, as that problem is there for any of the other boards/formats as well.

And since there is layout v3, pin IOref is used todetermine the voltage used. I use that successfully with several self-developed high-end shields.

 

It's not about having the old Arduino-shields being compatible with this FPGA board, but the huge potential for new shield development.

I think Jack has perfectly understood this in terms of marketability.

 

best,

-Dan

Link to comment
Share on other sites

I haven't really had many thoughts on features I would like - I'm not really an ideas guy...

 

However here is my five cents worth.

  • I would prefer HDMI & uSD card to be a wing, as some day somebody will want HDMI-in and HDMI-out in the same project. It also seems to go against the idea of the FPGA board having no personality, allowing you to customise it with wings to meet your needs.
  • I (most likely needlessly) worry about the power demands of shields and the additional I/O
  • I love the idea of the PMOD compatible wings.sockets by adding GND+3V3 on the end of the connector.
  • If you are going to go Arduino form factor and not have ADC on board then don't put the ADC header on. I'm sure people will get confused if you put a header, market as "Arduino compatible" and none of the analogue shields or sensors work Or at least add pads so the ADC signals could be jumpered to a ADC wing.
  • I (most likely needlessly) worry that the 0.1" headers will become an increasing limitation due to signal integrity issues with more advanced add-ons (which conflicts to me wanting HDMI as a wing :) ).
  • Decent mounting holes are a must-have.
  • Has anybody ever got the differential input as a usable one-bit ADC to work? I've tried a couple of times with no useful results. It would be cheap and easy if a couple of pins could be made into a workable low-bandwidth/low rez ADC. An inexpensive all-passive 4-channel ADC wing might be possible using 4 differential pairs.
Link to comment
Share on other sites

Some interesting points you make Mike. Food for thought for sure. I'm not sure I fully agree with you on the first point, though I don't really disagree either. Let me elaborate on that, I agree that an FPGA board priding itself on having interchangeable wings should not waste precious pins on having a lot of "built in" features. therefore allowing for maximum flexibility for the user. On the other hand, I have on several occasions appreciated the Pipistrello approach where the audio/video/uSD are built in leaving the full 48 pins available for wings or allowing for a minimalistic (no wings) but still fully functional in many respects board. I fully acknowledge that the Pipi having used a BGA package can afford to have the built in luxuries as there is no shortage of pins.

 

Another thought I had, and don't take this as a criticism Jack, is that originally the Papilio's FPGA was being promoted "you don't tell it what to do, you tell it what to be" or somesuch, the idea behind it being that you could make it into an arduino simply by uploading a design. The awesome work that went into the ZPUino is the proof of that. So to then go an put an actual arduino on the board seems almost like a .. I don't want to say fail, but at least seems like giving up and admitting defeat. Also the work involved in adding the arduino design in the space limited dual layer board seems kind of too much effort to be honest. I do however fully see your point that a multichannel ADC chip alone is as expensive as a full arduino setup. What a conundrum.

 

Mike talking about 100mil headers and signal integrity reminded me that if at all possible, the pins of the FPGA should be routed to the wing pins as differential pairs, I don't neccesarily mean as a controlled impedance pair but bring the positive and negative of each pair to the same wing slot. The same differential pattern should be followed for all wings allowing any differential wings to be plugged into any slot (interchangeability). I know this puts more pressure on the routing side... sorry but I think it would have definite advantages if you start producing HDMI wings etc. As for your worry Mike about SI issues, at least with a HDMI monitor, this hasn't seemed to be a major problem so far, we may well be able to get away with it in the future without moving to an incompatible header style.

 

Finally I'm not convinced about the approach of having a medium board based on a TQFP chip, then a more advanced board with more featured based on a BGA package. Personally, it seems like too much work again. Would it not make sense to simply decide on a BGA board and pour all the PCB design effort into that alone, then you can simply have versions of that in terms of what is populated, eg the pro version has everyting, the medium version has no headers, uSD slot, whatever populated on the board, then the low end cheapo maybe doesn't have the RAM chip and other bits populated. That way you can target different price points and you still have the same board form factor to deal with but just with different features populated on depending on cost. Again, just an idea to ponder on.

Link to comment
Share on other sites

A few comments, which I believe I already discuss with you.

 

First: allow the FT2232 to expose the JTAG to other devices. This should only imply a jumper, and we can use the board as a JTAG programmer (addition: megawings can take advantage of this)

Second: I would not be much worried about Arduino, but more about rPI and other more powerful devices. Arduino will be dead soon, unless they rethink it.

Third: Switch to DDR, not to 8-bit SRAM. The current 16-bit SDRAM is already imposing speed restrictions, and if you want to go HDMI you need fast memory, not slower one. IMHO it's better to ditch one 8-bit wing and have DDR on-board than to use a, albeit simpler, but with lower throuput RAM. If easier, sell the boards with no populated DDR - we can find many in old modules, and they are almost free, and it's not that hard to solder them.

 

For many wings the speed is not that important, so we can eventually add a multiplexer or CPLD to handle larger IO. Of course this would eventually make the board price rise a bit, but would allow for more interesting projects. Also, a high-speed interface would be excellent (USB 2), perhaphs we can use a CPLD to allow for JTAG programming while using a COTS USB controller ? That would ditch the FTDI chip, which is somehow expensive.

 

Alvie

Link to comment
Share on other sites

Sorry, I just though of something....

 

As far as I understand it, Xilinx devices can boot (load bitfile) from different sources and positions (multiboot).

 

If we could have a "master" bitfile which implements the USB logic, and use it at reset to "load" the final bitfile, and if we could lock the first bitfile so it should be hard to become corrupted, we could ditch the FT2232 device at all, and with a simple USB PHY have all the external logic we need for programming and communication.

 

This has the added effort of developing the master design, but might pay off in the future.

 

Just thoughts.

Alvie

Link to comment
Share on other sites

I agree about exposing the JTAG interface. I would definitely NOT go with DDR SDRAM though. It is nightmarishly complex to use even compared to SDRAM, and for the vast majority of people I suspect it would largely sit there unused as does the SDRAM on my Papilio Pro. The Papilio in general is a hobbyist product geared towards beginners and SRAM is very easy to use and there are a lot of FPGA based projects out there that use SRAM. There are already high end FPGA boards with DDR SDRAM out there for those who outgrow the Papilio. Of course if a market does exist, it would certainly be possible to create a version with DDR SDRAM, I'd just hate to see this be the only option.

 

Regarding Arduino vs Raspberry Pi, they cover two different purposes with some overlap. If you're building something simple it often makes more sense to use a microcontroller running your code bare-metal rather than a fully featured microcomputer with an operating system. I personally use bare AVRs and never really "got" the Arduino thing, but it has caught on none the less and provides a convenient way for beginners to get going with microcontrollers. I would never think of incorporating a Raspberry Pi in a clock, thermometer, temperature controller, event counter, or any number of other things I've used microcontrollers for. They power up instantly requiring no time to boot, they use less power, they are far simpler and easier to understand, far cheaper, assuming bare chip and not a fancy dev board. On the other hand, anything involving networking, internet, large graphical interfaces, etc is more practical on something like the Pi. While it's possible to do some of this on a microcontroller, and I have done some, it's also very tedious and rather limited.

Link to comment
Share on other sites

james1095: Regarding the DDR, my idea is to provide all users with a prebuilt (IP-like) interface to the DDR, so that no one needs to really care about how the DDR interface works.

 

 

and for the vast majority of people I suspect it would largely sit there unused as does the SDRAM on my Papilio Pro

 

Well, that is mostly untrue for all ZPUino users. Everything is on SDRAM, and this becomes more important as you use large buffers of memory (such as HDMI framebuffers).

 

Regarding rPI, you just not used to have a simple environment as it exists for AVR. ARM is way more clean, and way more performant, and you actually do not need a fancy OS to deal with it. You do need to have proper "drivers" for your devices, but that's also true for AVR.

 

I guess most people are afraid of ARM and how ARM works. But guess what, all are very similar. Don't be afraid - even barebones can work on ARM, and work very well. I've quite some experience with even more complex ARM chips (quad-core A9), and I have them running barebone ...

 

Alvie

Link to comment
Share on other sites

Aside from the (totally cool) Retrocade Synth, I've never used ZPUino and frankly I have no interest in using it. Even the Retrocade I've never messed with the "guts", I just load the file and it works, but the existing Papilio Pro has plenty of resources for that.

 

I'm not "afraid" of ARM, but why use such a vastly powerful chip when you only need something simple? With an AVR I can buy a chip for $1-$3 in single quantities and I have something designed as a controller. They are available in tiny packages with only a few pins, they come in DIPs that plug into breadboards, there are analog inputs, hardware interrupt pins, low power sleep modes, I can clock it all the way down to DC and up to the max depending on my performance and power consumption needs. It's just a matter of selecting the most appropriate tool for the job. Yes you could use an ARM to build a simple controller. You could also use a CPLD to replace to 25 cent 74xx logic chip, but aside from a learning exercise why would you?

Link to comment
Share on other sites

I agree about exposing the JTAG interface. I would definitely NOT go with DDR SDRAM though. It is nightmarishly complex to use even compared to SDRAM, and for the vast majority of people I suspect it would largely sit there unused as does the SDRAM on my Papilio Pro. The Papilio in general is a hobbyist product geared towards beginners and SRAM is very easy to use and there are a lot of FPGA based projects out there that use SRAM. There are already high end FPGA boards with DDR SDRAM out there for those who outgrow the Papilio. Of course if a market does exist, it would certainly be possible to create a version with DDR SDRAM, I'd just hate to see this be the only option.

 

 

Completely agree, unless you have a FPGA that has been engineered to use the on-die MCB. It that is the case all the problems with DDR only have to be done once by the layout / PCB designer and are invisible to the FPGA user - as it is on the Pipi. But that currently requires a BGA part.

 

SDRAM (either DDR or SDR) doesn't work when it comes to emulating old arcade games either. :(

 

The memory bandwifth is a problem too. An x8 133MHz SDR SDRAM has about 100MB/s of usable bandwdith, A HDMI output of 640x480x24 will consume 75MB/s of this during the active display region, even 800x600x24 needs more 100MB/s.

 

I guess what I'm trying to say (and what everybody already knows) is that not being able to use BGA FPGAs is a real thorn in having any sort of advanced features.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.