The next generation Papilio - help me shape it.


Jack Gassett

Recommended Posts

  • Replies 225
  • Created
  • Last Reply

Mike: we can expose the SDRAM/DDR as a "normal" device within the FPGA. It's not that hard, and you know it. My idea is to have the full speed DDR, and expose it to users like an ordinary RAM internally, but allowing for extra bw for DDR-aware designs.

 

We can do that easily, you know it :)

 

james1095: you still have the chance of not using the memory. That's why I am proposing a device with no populated RAM, cheaper, and you can solder it yourself afterwards if you feel like you will need it.

 

Alvie

Link to comment
Share on other sites

Mike: we can expose the SDRAM/DDR as a "normal" device within the FPGA. It's not that hard, and you know it. My idea is to have the full speed DDR, and expose it to users like an ordinary RAM internally, but allowing for extra bw for DDR-aware designs.

 

We can do that easily, you know it :)

 

Now you really have got me confused :)

 

After bringing up a MCB based design, a hand-coded SDR controller on a (non-Papilio) prototype board, with two solder bridges on it, moving that to the Papilio Pro, and then help remotely debug another board where the FPGA end of DQ7 wasn't correctly soldered, I have to decalre that I have enough SDR SDRAM scars experience to last me for a while. 

 

I hear that DDR cuts twice as deep - I've just been looking at http://download.micron.com/pdf/datasheets/dram/ddr/512MBDDRx4x8x16.pdf

 

I am worried that we then get into difficult problems like if the DQ lines are split between banks then there may be skew in the I/O clocks to both banks that need to be accounted for, and there is only a 2.5ns data out window making it harder to hit.,

 

Gosh, All my posts are filled with worries and fears, (power, timing, connectors...)

 

Jack, Have you looked at what the physical issues there is with dropping a DDR part onto a Papilio Pro and see if it can be made to work? 

 

=== side issue ===

 

I've come up with an analogy for SDRAM - if you slow it down a billion time it is like that bank in Harry Potter, with 8192 rooms each with 512 boxes in it. And a vacuum tube system to get things to/from the rooms.

 

It is all manned by one goblin, who takes 60 seconds to go between rooms, needs to take regular 70 second breaks to drink magic tea, otherwise starts causing trouble.

 

It also explains the startup sequence.

 

- Wake the goblin (power up)

- Wait for him to get ready for work (10us pause)

- Tell him to leave which ever room he was sleeping in. (PRECHARGE)

- Give him two cups of magic tea to make him behave nicely (REFRESH, REFRESH)

- Tell him the rules for the day (LOAD MODE REGISTER)

 

All fired up, ready for work!

Link to comment
Share on other sites

Wow! What a great discussion, I didn't realize people would be so passionate about the next Papilio board. :) Thank you all for your support and participation.

 

Let me work on replying to as much as I can here, I'll do a series of replies.

 

The biggest thing that comes up is the question of BGA vs TQFP. I absolutely plan on making a BGA board too, and that is going to be much more fun for us to develop. :) The problem is that there are a lot of uncertainties and question marks around manufacturing that board. In order to ensure that I can keep Gadget Factory afloat I have to stick with what I know will work and move cautiously into uncharted territory. I have full confidence that we can do a BGA design, but there is a whole new level of very real dangers and risks involved. If I make a batch of 100 boards and there is a horrible yield or something where I have to eat the expense then I could go out of business. With a TQFP design you can easily fix manufacturing problems, with BGA rework is not very realistic...So think of the TQFP design as the safety net. If something goes wrong with the BGA side then hopefully sales of the new TQFP design will keep me afloat long enough to recover.

 

The other thing with the BGA design is that I expect it to be more expensive, I expect any BGA design to come in between $100-150.

I think there is a market there but it is much smaller then the market for the TQFP design which will hopefully come in at the same price as the Papilio Pro.

 

So basically, it is not as simple as deciding on a BGA vs TQFP design. There are outside influences that are driving two designs... If it was purely a technical decision then I would go for BGA in a hearbeat.

 

It's easy to become paralyzed by all the fears associated with doing a BGA design. The trick is to manage the risks so that if those fears do become reality it will cause minimal damage. It's tempting to jump all into a BGA design because it solves all of the technical problems, but that would be irresponsible because if things went south it would put me out of business...

 

Jack.

Link to comment
Share on other sites

 

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.

 

 

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.

 

This is a tough decision here, with the BGA board it's an easy decision. I think that as long as we can implement at least 48 pins then we should use the extra pins for the most sensible additional features. HDMI, uSD and stuff that 80% of the designs out there can use. Things like ps/2 ports are going too far I think...

 

For the TQFP design we are faced with whether we should share some of the IO pins to implement HDMI. I'm opposed to sharing pins, but I think that if HDMI is an important part of the "Vision" for what the next generation Papilio board is going to be then it is a valid exception. So let's talk about exactly what the vision is in the next reply.

 

****UPDATE**** I got halfway through writing the "Vision" post and it started getting late and I was losing focus. You can't lose focus when writing about your "Vision". :) I'm going to call it a night and finish up tomorrow.

Link to comment
Share on other sites

If I was to approach this like developing an FPGA design, where rather than jumping all the way in the deep end and do everything at once I do things incrementally.

 

How is this for a roadmap:

 

1. Papilio Technology Transition One (TT1) 

- End of life the Papilio One 250/500 and replace it with a TT1 without the SDRAM.

- Keep Papilio Pro form-factor

- Move to a four layer board

- Add PMOD connectors at ether end of existing wing connectors.

- Use 54-ball BGA footprint for the SDRAM, (try to make it compatible for DDR for experimentation)

- Route differential pairs to wings 

- Implement USB interface changes (high B/W FIFO)

- Add an additional four power pins between the high/low eight bit wings, giving a middle wing position.

 

Benefits for GadgetFactory:

- Build up four-layer PCB design skills

- Build up BGA experience

- Platform to prototype a DDR platform without using an MCB - decide after a few test boards to go DDR or not

- Minimal schematic changes from existing Papilio Pro design

- Rework on BGA SDRAM is far cheaper less risky than rework on the larger more expensive FPGA

- More freedom for signal routing

- EOLing the Papilio One design should reduce the number of configs stock and support (e.g. RMAs, new-user startup issues, EDA tooling)

- If BGA proves a difficult nut to crack then you still get to update the PapOne and experience

- Solves the eventual problem with Xilinx EOLing the Spartan 3E parts.

- adding another 4 pins to the power rails replaces 6x4pin connectors with 4x12 pin connectors, maybe helping out with assembly

 

Benefits for us end users:

- Plug and play for the vast range of PMODs (maybe 40 or 50 devices)

- Maybe twice the memory SDRAM bandwidth if DDR works out

- All existing Papilio Projects should work with a UCF file update, unless they use the SDRAM

- Better signal integrity due to more freedom in PCB design

- Ability to use differential wings 

- Access to a higher speed USB host Interface

- Removes a bit of the the Papilio One/Papilio Pro divide, as all are now Spartan 6 LX9

- Could use up to 6 PMODs and three 8-bit wings because of the middle wing position.

- PMODs are more stripboard / protoboard friendly

- MegaWings still work

- Just like the Papilio Pro, but even better!
 

2. Papilio Technology Transition Two (TT2) 

- Physically same form-factor as the Papilio TT1.

- Move to a BGA FPGA as well as BGA SDRAM

- Add LX25 options

- Wire for using the on-die MCB

- use extra I/O and space on PCB for HDMI and uSD card

 

Benefits for GadgetFactory:

- No major technology changes - can focus on BGA issues

- Leverage built up BGA experience on the TT1

- Minimal software changes required to support

- Migration off of TQFP - they won't be available forever

- Place Papilio Boards back above the competition 

 

Benefits for us end users (over the Papilio TT1):

- On board HDMI,

- On board uSD

- Able to use the higher performance / more flexible MCB in designs

- More FPGA logic (due to larger FPGA and use of MCB freeing up resources)

 

You'll notice that I've dropped off the whole Arduino / AVR part of the design. Why?

 

- Most modules/sensors I get require four or five jumpers and don't use the full shield form factor (eg Power + I2C + an interrupt). 

 

- PMODs cover nearly all of the Arduino Shields I could see being used. Sure, they cost a little bit more, but where else can you get a 4 channel 4.8 kHz 24-bit A/D converter for an Arduino that you can use for sensing ULF waves? Or an I2S DAC?

 

- All Arduino wings and shields are made to be used by an 8 or 16 MHz MCU. They don't need the power of an FPGA to support them. Nearly any design that the FPGA enables can also be achieved with one of the new 80MHz ARM based Arduino.

 

- You can't use an Arduino to drive HDMI, a high speed serial interface, a CMOS camera, a LVDS display, this is where you need wings or PMODs, and they don't need the Arduino headers

 

- I sort of agree with Alex that moving to an FPGA+Arduino confuses things. If you jump over the Arduino fence I fear you will land in a pool full of sharks and alligators

 

- I would hate to see the forum filled with "I have brand X shield, and it doesn't work right - can you help?" posts. At least with Wings and PMODs it gives a limited set of well known hardware with good documentation (well, some Digilent documentation is patchy in places) that people can leverage 

 

- I hate 5V-only Arduino shields with a passion.

 

If you need to include Arduino to improve marketability then I think it is looking in the wrong direction. What you want to be doing is hitting products like the http://www.xess.com/shop/product/xula2-lx25. I think that the TT2 works because it is 'more friendly' than the 40 pin form factor as you can just plug in PMODS/Wings and play.

 

It would also scores over the $230 Digilent Nexys3 in my book - I can use the I/O for what I want to use it for. Why would I want three different sorts of memory? Where is my HDMI? Where is my uSD card?

Link to comment
Share on other sites

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.

 

This is a great lead into the "Vision" of the Papilio, what exactly is it meant to be?

 

First, some history, the Papilio started out simply as a board that I could use to build inventions with. My intention was to start making cool Open Source Hardware projects and I wanted a single board that was all my own to base those projects on. I was fed up with the corporate world and wanted to spend my time working on projects that brought meaning to my life... This ended up in a very frustrating and unsuccessful first year in business! I had to turn to business books in order to discover the fundamental mistake I was making. The problem was that I was motivated by my needs, but in order to make something that other people find useful you have to be motivated by their needs... It was an epiphany, if I want to have a successful project then I need to figure out what people want and make that, just making a board for my inventions isn't useful to anyone...

 

So I set out to figure out what would be useful to people and I figured that people would have use for an FPGA board patterned after the Arduino. The first thing that I could deliver was the learning aspect of the Arduino, people use the Arduino to start learning about c++ programming and microcontrollers. I understood the frustrations with getting started with FPGA's because I just recently went through it myself. I could make the Papilio into a board that would get you past the initial learning curve by addressing the early problems with other boards. The biggest glaring problem I saw was that a beginner quickly hits a brick wall with VHDL. Most FPGA boards get you blinking lights, interfacing to low level hardware, and converting data flows from one format to another pretty easily. But implementing a real world solution such as the Retrocade is a nightmare in VHDL. Trying to implement a file system, MIDI controller and all the logic to control everything is something only a VHDL guru can do... I thought that providing Arduino compatible soft processors and lots of examples to learn from would get people over the initial learning hump and make FPGA's useful to them. Along the way Alvaro jumped in with the ZPUino, Mike wrote his great VHDL book, and the Papilio community was born providing a kind and helpful forum to help people out and lots of interesting projects to learn from. All of these things have made the Papilio a success in one aspect of what the Arduino is, a friendly path to get started with learning what can be an intimidating technology.

 

But trying to emulate the other aspects of the Arduino has been a complete failure... I have not been able to deliver on making the Papilio as easy to use as an Arduino. My idea was to provide a bunch of pre-canned bit files that you could load to the Papilio that would turn it into an Arduino, or a synthesizer, or an Arcade machine. Hence the "You tell an Arduino what to do, but you tell a Papilio what to be.". The first problem is, why would anyone want a more expensive and complicated Arduino running on an FPGA? People don't they would rather just use an Arduino, if it gets the job done they will stick with an Arduino. Ok, but you can do things with the Arduino running on an FPGA that you cannot with an Arduino such as a VGA controller, or classic audio chips. Oh, did I say you can do those things? Well you can after you learn VHDL, and that isn't very easy... Doesn't sound useful to you? OK, then we will provide bit files for you that you can just load to the Papilio but you can't really modify to your needs. This leads to the second deal breaker of a problem which is that I simply cannot keep up with all the needs that people have. I cannot make bit files fast enough to satisfy peoples needs and they are faced with learning VHDL for themselves in order to make the Papilio useful to them. By trying to provide pre-canned bit files I am completely missing the mark and creating an unsustainable situation that is not very useful to anyone. As you can see there are two major flaws with the goal of emulating the Arduino, people don't want an Arduino on an FPGA in the first place, it just doesn't make sense to them. Second, making bit files for people is like catching fish for them, it's not sustainable, instead we need to teach them to fish, ie make their own bit files. It's time to learn from the mistakes and update the Papilio message, trying to be an FPGA Arduino has not proven to be useful to people.

 

So how do we move the Papilio forward and make it more useful to people? I think I can finally see how it can be done and that has me very excited and is the motivation for the new Papilio boards. This new "Vision" for the Papilio starts with a new and easy to understand message. What is the Papilio? The Papilio lets you draw circuits on a chip. How is that useful to you? If you can drag and drop chips onto a schematic and draw connections between them then you can make custom circuits to run on the Papilio without any need for soldering, breadboards, or wires. You can drag and drop Arduino chips, classic audio chips, serial port chips, VGA controller chips, stepper motor chips, and many more from our schematic library. You can even drag and drop tools such as a Logic Analyzer or Arduino ICE debugger to debug your circuit! All without touching any wires, doing any soldering, or learning any new programming languages, just drag and drop what you need and draw connections between the "chips".

 

As you can see we stop trying to be an Arduino and instead focus on letting people draw circuits using the Papilio Schematic Library. It's still VHDL under the hood, so advanced users can still feel at home, but people don't have to learn VHDL in order to make useful bit files for themselves. Advanced users can package up their work so beginners can make use of their work by dragging and dropping their "chips", ie cores, and connecting them in the schematic editor. It's like making a library for the Arduino with a simplified interface that beginners can grok and use immediately.

 

How do these new boards fit into this new direction? The focus for these boards is, "What can we do that will make these new boards as useful as possible?" Going forward the easy to understand message of what the Papilio does is that it lets you draw circuits on a chip. I think that easily captures and conveys what an FPGA can do for you. A critical part of that message is that we need to let people easily define circuits to run on the chip, but we can also take advantage of the multi-boot capability and implement some pre-canned bit files for useful test bench functionality such as a Logic Analyzer. As long as everything can be tied up into an easy to understand and convey message we can do things that will be useful, and test bench functionality such as a Logic Analyzer is extremely useful... So the two usability goals that I have are to allow people to draw their own circuits on a chip and allow shields to be connected to the board and have pre-canned test bench bit files be loaded to the board.

 

Alex asked about adding the Arduino chip, is it worth the effort? I say yes, because it makes the board more useful to have a full blown arduino on the board. The truth is that the ZPUino and the AVR8 are not completely compatible with Arduino libraries, we usually have to convert a library before it can be used with either soft processor. It is going to be useful to someone to be able to run their existing sketch and be able to extend it with a circuit that they drew in the FPGA. Yes, it can all be made to run completely in the FPGA with the ZPUino, but they might not have the ability to convert the libraries themselves and we may not have the time to do it for them. Arduino users will be guaranteed a working Arduino and will be able to connect a Logic Analyzer, custom circuits, and if I am right, an ICE debugger. Sounds like it is very useful for every Arduino user out there...

 

It also brings two big things to the table that we cannot accomplish on our own with the FPGA. It implements the Analog pins and a flexible USB controller that can become any type of USB device. The FT2232H cannot change what type of device it is, it cannot be a MIDI controller, a hard drive, or any other USB type. The leonardo's USB chip is very flexible in what it can do.

 

Well, I need to wrap this up, I hope this helps better define the direction that the Papilio is heading. It's late and I will probably need to go back through and edit this post tomorrow, but I'm posting it as is for now.

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)

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

 

The FT2232H has two MPSSE channels so that is definitely something we are doing. The FT2232 will be able to be used as a JTAG programmer or anything else we want it to do.

 

I like your idea about programming from a USB core, if we could implement a core that is small enough it would be a killer idea to bring the cost of the board down.

 

Jack.

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

Yes, this is an absolutely killer idea, it all depends on the size of the USB core though.

Link to comment
Share on other sites

Now you really have got me confused :)

 

After bringing up a MCB based design, a hand-coded SDR controller on a (non-Papilio) prototype board, with two solder bridges on it, moving that to the Papilio Pro, and then help remotely debug another board where the FPGA end of DQ7 wasn't correctly soldered, I have to decalre that I have enough SDR SDRAM scars experience to last me for a while. 

 

I hear that DDR cuts twice as deep - I've just been looking at http://download.micron.com/pdf/datasheets/dram/ddr/512MBDDRx4x8x16.pdf

 

I am worried that we then get into difficult problems like if the DQ lines are split between banks then there may be skew in the I/O clocks to both banks that need to be accounted for, and there is only a 2.5ns data out window making it harder to hit.,

 

Gosh, All my posts are filled with worries and fears, (power, timing, connectors...)

 

Jack, Have you looked at what the physical issues there is with dropping a DDR part onto a Papilio Pro and see if it can be made to work? 

 

 

Yes, I think we could successfully add a DDR part. It will be easier if we use a BGA part with the built in DDR controller. If we could write a core that makes it as simple to use as SRAM then I would not even be considering SRAM right now. Maybe this is a challenge for the community, if we can write a controller for the SDRAM chip on the Papilio Pro that people feel is as easy to use as SRAM then I will take on the challenge of a DDR chip on this new board. If we pull it off everyone wins!

 

Jack.

Link to comment
Share on other sites

If I was to approach this like developing an FPGA design, where rather than jumping all the way in the deep end and do everything at once I do things incrementally.

 

How is this for a roadmap:

 

1. Papilio Technology Transition One (TT1) 

- End of life the Papilio One 250/500 and replace it with a TT1 without the SDRAM.

- Keep Papilio Pro form-factor

- Move to a four layer board

- Add PMOD connectors at ether end of existing wing connectors.

- Use 54-ball BGA footprint for the SDRAM, (try to make it compatible for DDR for experimentation)

- Route differential pairs to wings 

- Implement USB interface changes (high B/W FIFO)

- Add an additional four power pins between the high/low eight bit wings, giving a middle wing position.

 

Benefits for GadgetFactory:

- Build up four-layer PCB design skills

- Build up BGA experience

- Platform to prototype a DDR platform without using an MCB - decide after a few test boards to go DDR or not

- Minimal schematic changes from existing Papilio Pro design

- Rework on BGA SDRAM is far cheaper less risky than rework on the larger more expensive FPGA

- More freedom for signal routing

- EOLing the Papilio One design should reduce the number of configs stock and support (e.g. RMAs, new-user startup issues, EDA tooling)

- If BGA proves a difficult nut to crack then you still get to update the PapOne and experience

- Solves the eventual problem with Xilinx EOLing the Spartan 3E parts.

- adding another 4 pins to the power rails replaces 6x4pin connectors with 4x12 pin connectors, maybe helping out with assembly

 

Benefits for us end users:

- Plug and play for the vast range of PMODs (maybe 40 or 50 devices)

- Maybe twice the memory SDRAM bandwidth if DDR works out

- All existing Papilio Projects should work with a UCF file update, unless they use the SDRAM

- Better signal integrity due to more freedom in PCB design

- Ability to use differential wings 

- Access to a higher speed USB host Interface

- Removes a bit of the the Papilio One/Papilio Pro divide, as all are now Spartan 6 LX9

- Could use up to 6 PMODs and three 8-bit wings because of the middle wing position.

- PMODs are more stripboard / protoboard friendly

- MegaWings still work

- Just like the Papilio Pro, but even better!
 

2. Papilio Technology Transition Two (TT2) 

- Physically same form-factor as the Papilio TT1.

- Move to a BGA FPGA as well as BGA SDRAM

- Add LX25 options

- Wire for using the on-die MCB

- use extra I/O and space on PCB for HDMI and uSD card

 

Benefits for GadgetFactory:

- No major technology changes - can focus on BGA issues

- Leverage built up BGA experience on the TT1

- Minimal software changes required to support

- Migration off of TQFP - they won't be available forever

- Place Papilio Boards back above the competition 

 

Benefits for us end users (over the Papilio TT1):

- On board HDMI,

- On board uSD

- Able to use the higher performance / more flexible MCB in designs

- More FPGA logic (due to larger FPGA and use of MCB freeing up resources)

 

You'll notice that I've dropped off the whole Arduino / AVR part of the design. Why?

 

- Most modules/sensors I get require four or five jumpers and don't use the full shield form factor (eg Power + I2C + an interrupt). 

 

- PMODs cover nearly all of the Arduino Shields I could see being used. Sure, they cost a little bit more, but where else can you get a 4 channel 4.8 kHz 24-bit A/D converter for an Arduino that you can use for sensing ULF waves? Or an I2S DAC?

 

- All Arduino wings and shields are made to be used by an 8 or 16 MHz MCU. They don't need the power of an FPGA to support them. Nearly any design that the FPGA enables can also be achieved with one of the new 80MHz ARM based Arduino.

 

- You can't use an Arduino to drive HDMI, a high speed serial interface, a CMOS camera, a LVDS display, this is where you need wings or PMODs, and they don't need the Arduino headers

 

- I sort of agree with Alex that moving to an FPGA+Arduino confuses things. If you jump over the Arduino fence I fear you will land in a pool full of sharks and alligators

 

- I would hate to see the forum filled with "I have brand X shield, and it doesn't work right - can you help?" posts. At least with Wings and PMODs it gives a limited set of well known hardware with good documentation (well, some Digilent documentation is patchy in places) that people can leverage 

 

- I hate 5V-only Arduino shields with a passion.

 

If you need to include Arduino to improve marketability then I think it is looking in the wrong direction. What you want to be doing is hitting products like the http://www.xess.com/shop/product/xula2-lx25. I think that the TT2 works because it is 'more friendly' than the 40 pin form factor as you can just plug in PMODS/Wings and play.

 

It would also scores over the $230 Digilent Nexys3 in my book - I can use the I/O for what I want to use it for. Why would I want three different sorts of memory? Where is my HDMI? Where is my uSD card?

 

There is a lot here, I can't respond to it all but I am taking it all in.

 

My initial gut feeling is that I don't want to make a board that competes with offerings from Digilent, I'm never going to be able to compete in that market. They are heavily subsidized by Xilinx and they are a large company with many highly paid engineers. I have to earn my living doing unique things that don't already exist out there. The Papilio Schematic Library is one of those things and the Arduino footprint board fits into perfectly with the schematic library. It speaks directly to the hobbyist DIY audience. What you are talking about here for is something that speaks to the advanced FPGA user audience, that's not this board, but I do actually have a plan for along those lines. I'm not ready to start talking about it yet though because I cannot execute on it yet and I think it is something unique for the market and do not want someone else doing it before I can. :)

Link to comment
Share on other sites

Any form of DRAM will always be harder to use than SRAM. SRAM has the following benefits

 

- No page structure

- no refresh cycles needed

- Fixed latency to access data.

- no banking 

- no burst transfers needed

- full memory bandwidth available to application

 

It is a shame that Pseudo SRAM  (e.g. MT45W2MW16) reached a dead end

Link to comment
Share on other sites

I don't know if this is the kind of thing you guys are on about (sorry if not), or maybe your already aware of it...?

A while ago I was looking for info on implementing a z80 system on my Pro, I came across a guy's site (http://fpgabee.toptensoftware.com/) who had done almost exactly what I was aiming to do (or the core of it at least). While he started developing on a Nexys3 his final design was on a Xula2 which used SDRAM. However, in his code there is a SDRAM controller written by xess specifically for the SDRAM device they put on the Xula2 and a core he's written called "Z80RamController" which presents the interface of the SDRAM controller as a much simpler interface: data in, data out, address, read, write and wait signal.

 

With minimal modification I managed to get it to work fine on the Pro with it's SDRAM and have tried it on a number of "experiments" (I won't go so far as calling them projects because really I'm just playing around with things and try to learn).

 

Anyway, whether or not it's what your after, it was enough for me to use the SDRAM where I otherwise probably wouldn't, so maybe it'll help someone else too. I found the original files here:

SdramCntl.vhd - https://bitbucket.org/toptensoftware/fpgabee/src/55503cba59bf885ec4ddb3ef6fb82a246942ea76/Hardware/XuLA_lib/SdramCntl.vhd?at=master

Z80RamController.vhd - https://bitbucket.org/toptensoftware/fpgabee/src/55503cba59bf885ec4ddb3ef6fb82a246942ea76/Hardware/Xula2/Z80RamController.vhd?at=master

 

While I don't have a complete copy of my altered version of the Z80RamContoller here at the moment, I have a note of what I changed in that file:

 

from:

ram_addr : in std_logic_vector(17 downto 0); -- 256K

to:

ram_addr : in std_logic_vector(15 downto 0); -- 64K

and

 

from:    

sdram : SdramCntlgeneric map(        FREQ_G        => 100.0,        IN_PHASE_G    => true,        PIPE_EN_G     => false,        MAX_NOP_G     => 10000,        DATA_WIDTH_G  => 16,        NROWS_G       => 8192,        NCOLS_G       => 512,        HADDR_WIDTH_G => 24,        SADDR_WIDTH_G => 13)port map...

to:

sdram : SdramCntlgeneric map(        FREQ_G        => 100.0,        IN_PHASE_G    => true,        PIPE_EN_G     => false,        MAX_NOP_G     => 10000,        DATA_WIDTH_G  => 16,        NROWS_G       => 4096, --8192,        NCOLS_G       => 256, --512,        HADDR_WIDTH_G => 24,        SADDR_WIDTH_G => 13,        T_INIT_G => 200_000.0, -- min initialization interval (ns).        T_RAS_G => 45.0, -- min interval between active to precharge commands (ns).        T_RCD_G => 15.0, -- min interval between active and R/W commands (ns).        T_REF_G      => 64_000_000.0, -- maximum refresh interval (ns).        T_RFC_G => 66.0, -- duration of refresh operation (ns).        T_RP_G => 15.0, -- min precharge command duration (ns).        T_XSR_G => 67.0 -- exit self-refresh time (ns).)port map...

Oh, I just remembered that it took me a while to get the clocking right too. I can't remember what I found tricky, but this I what I got it working with.

clock : entity work.clockingport map (     CLK_IN_32_000 => clk_32,     CLK_OUT_8_000 => clk_8,     CLK_OUT_40_000 => vga_clock,     CLK_OUT_100_000 => sdram_clock,     RESET => '0');sdram_clk_forward : ODDR2generic map(DDR_ALIGNMENT => "NONE", INIT => '0', SRTYPE => "SYNC")port map (     Q => SDRAM_CLK,     C0 => sdram_clock,     C1 => not sdram_clock,     CE => '1',     R => '0',     S => '0',     D0 => '0',     D1 => '1');
Chris

 

Link to comment
Share on other sites

 

I don't know if this is the kind of thing you guys are on about (sorry if not), or maybe your already aware of it...?

A while ago I was looking for info on implementing a z80 system on my Pro, I came across a guy's site (http://fpgabee.toptensoftware.com/) who had done almost exactly what I was aiming to do (or the core of it at least). While he started developing on a Nexys3 his final design was on a Xula2 which used SDRAM. However, in his code there is a SDRAM controller written by xess specifically for the SDRAM device they put on the Xula2 and a core he's written called "Z80RamController" which presents the interface of the SDRAM controller as a much simpler interface: data in, data out, address, read, write and wait signal.

 

With minimal modification I managed to get it to work fine on the Pro with it's SDRAM and have tried it on a number of "experiments" (I won't go so far as calling them projects because really I'm just playing around with things and try to learn).

 

Anyway, whether or not it's what your after, it was enough for me to use the SDRAM where I otherwise probably wouldn't, so maybe it'll help someone else too. I found the original files here:

SdramCntl.vhd - https://bitbucket.org/toptensoftware/fpgabee/src/55503cba59bf885ec4ddb3ef6fb82a246942ea76/Hardware/XuLA_lib/SdramCntl.vhd?at=master

Z80RamController.vhd - https://bitbucket.org/toptensoftware/fpgabee/src/55503cba59bf885ec4ddb3ef6fb82a246942ea76/Hardware/Xula2/Z80RamController.vhd?at=master

 

While I don't have a complete copy of my altered version of the Z80RamContoller here at the moment, I have a note of what I changed in that file:

 

from:

ram_addr : in std_logic_vector(17 downto 0); -- 256K

to:

ram_addr : in std_logic_vector(15 downto 0); -- 64K

and

 

from:    

sdram : SdramCntlgeneric map(        FREQ_G        => 100.0,        IN_PHASE_G    => true,        PIPE_EN_G     => false,        MAX_NOP_G     => 10000,        DATA_WIDTH_G  => 16,        NROWS_G       => 8192,        NCOLS_G       => 512,        HADDR_WIDTH_G => 24,        SADDR_WIDTH_G => 13)port map...

to:

sdram : SdramCntlgeneric map(        FREQ_G        => 100.0,        IN_PHASE_G    => true,        PIPE_EN_G     => false,        MAX_NOP_G     => 10000,        DATA_WIDTH_G  => 16,        NROWS_G       => 4096, --8192,        NCOLS_G       => 256, --512,        HADDR_WIDTH_G => 24,        SADDR_WIDTH_G => 13,        T_INIT_G => 200_000.0, -- min initialization interval (ns).        T_RAS_G => 45.0, -- min interval between active to precharge commands (ns).        T_RCD_G => 15.0, -- min interval between active and R/W commands (ns).        T_REF_G      => 64_000_000.0, -- maximum refresh interval (ns).        T_RFC_G => 66.0, -- duration of refresh operation (ns).        T_RP_G => 15.0, -- min precharge command duration (ns).        T_XSR_G => 67.0 -- exit self-refresh time (ns).)port map...

Oh, I just remembered that it took me a while to get the clocking right too. I can't remember what I found tricky, but this I what I got it working with.

clock : entity work.clockingport map (     CLK_IN_32_000 => clk_32,     CLK_OUT_8_000 => clk_8,     CLK_OUT_40_000 => vga_clock,     CLK_OUT_100_000 => sdram_clock,     RESET => '0');sdram_clk_forward : ODDR2generic map(DDR_ALIGNMENT => "NONE", INIT => '0', SRTYPE => "SYNC")port map (     Q => SDRAM_CLK,     C0 => sdram_clock,     C1 => not sdram_clock,     CE => '1',     R => '0',     S => '0',     D0 => '0',     D1 => '1');
Chris

 

 

Hmmm, now this is interesting, will have to take a look.

 

Jack.

Link to comment
Share on other sites

Couple of unrelated issues:

  • Great idea about using fpga to create 'circuits' attached to Arduino as a stepping stone.
  • Instead of unpopulated BGA area for SDRAM - how about an unpopulated SO-DIMM laptop RAM connector ?
  • The vortex86 has a cute arduino add-on with a breadboard attached. The breadboard can help with connecting devices like PMOD etc. Just an idea for form factor.
Link to comment
Share on other sites

 

Couple of unrelated issues:

  • Great idea about using fpga to create 'circuits' attached to Arduino as a stepping stone.
  • Instead of unpopulated BGA area for SDRAM - how about an unpopulated SO-DIMM laptop RAM connector ?
  • The vortex86 has a cute arduino add-on with a breadboard attached. The breadboard can help with connecting devices like PMOD etc. Just an idea for form factor.

 

 

FreeSOC, that's the PSOC based board. Pretty cool, I had considered doing a PSOC board too.

 

That vortex86 thing is freaking cool! I don't have any idea how they pulled it off though, looks like a custom made case... I don't know how I would be able to do something like it without spending some big bucks on a custom case.

 

Jack.

Link to comment
Share on other sites

Ok, so I've got some more work done today:

 

  • Connected all pins on Arduino and FT2232H.
  • The Leonardo only has 5 Analog pins so I modified the Arduino Mega footprints to have 5 Analog pins.

 

I did a quick mockup of what HDMI would look like. I used the HDMI section from the Pipistrello design, I don't think the license lets me proceed with that in the final design but it was good for a quick look to see if everything fits.

 

It's going to be real tight, I'm not sure if we can pull it off... You can see that the components will have to go on the bottom of the board and I'm not sure there is enough board space for the signals to be routed.

post-29509-0-98909400-1389894861_thumb.p

 

The four differential pairs that would be needed are conveniently close:

post-29509-0-97788200-1389894928_thumb.p

post-29509-0-90640900-1389895084_thumb.p

 

At this point I'm up in the air whether the HDMI is doable...

Link to comment
Share on other sites

Jack, no problem using the Pipistrello HDMI interface for your new board :)

 

I do agree with alvieboy that the HDMI lines needs special attention since they carry up to 1 Gb/s signals, sharing them in the layout with other connectors might not be a good idea (but I might be wrong on this).

 

Magnus

Link to comment
Share on other sites

Jack: beware. These are high-speed links, they need proper impedance matching and interference avoidance.

 

 

Jack, no problem using the Pipistrello HDMI interface for your new board :)

 

I do agree with alvieboy that the HDMI lines needs special attention since they carry up to 1 Gb/s signals, sharing them in the layout with other connectors might not be a good idea (but I might be wrong on this).

 

Magnus

 

Thank you Magnus for letting me use your HDMI design, it is greatly appreciated.

 

I will pay extra attention to those lines and use the new differential routing capability of EAGLE. I think that as long as the lengths are matched, including the lines that go to GPIO, then we will be ok. But only testing will tell for sure, if it doesn't work out then we won't populate the footprint.

 

Jack.

Link to comment
Share on other sites

  • 2 weeks later...

A comment from a newbie here.

 

If the "golden images" for shields is on the base board, then that means that:

1) only the number of shields that fits in the golden image space will ever be supported

2) if I want to ship a new kind of shield, how would the code for that shield get into the image?

 

Wouldn't it make more sense to put the code for the shield into a smaller flash chip on the actual shield? Like game console cartridges, or PC expansion card boot ROMs?

Link to comment
Share on other sites

Archived

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