Daughter card proposal

[Folknology]

I have spent quite a bit of time over the years designing interfaces and expansion modules for various projects which has provided me with some really interesting experiences on both sides of the fence, I have also often had thoughts like "If I was designing this I would consider..." on many occasions. With the extraordinary Parallella board we have a unique opportunity to shape it's interfacing and expansion and take it places where its predecessors' could not easily venture. Thus I have written up a short piece with this in mind describing how we could build a sophisticated expansion ecosystem worthy of the Parallela's ground breaking offering. The is merely an outline, the start of a conversation around how we can create the best possible expansion system in the opensource hardware market place, so please take a look and use this thread to discuss where we can take this.

Thoughts?

regards
Al

[tnt]

Interesting idea.

It would be interesting to test the routing needed remap the ports, see if "it works out" even on 2 layer board.

It could also be possible to have an I2C EEPROM connected to the PEC POWER i2c bus to have auto enumeration. We'd need two more GPIO (could be LED0/LED1 abused) connected to a chain of D flip flop (one on each card) whose Q output would be used to select the I2C eeprom address. This way, you can know which card is which and what position it's in the stack, allowing for full auto detection. That would cost less than the connectors most likely

[Folknology]

@tnt your auto enumeration idea is a good one, the possibility had crossed my mind also. I am not sure what the circuit (or runtime use) is behind LED0/1 to make any concrete assumptions as to if these could be easily reused (maybe via a couple of bias transistors perhaps), but if we can find a way of using your clever rippling D-Types on these lines as you suggest it is a distinct possibility, would we also need a reset line, that seems to be missing on the Power connector (PG could be used to generate a local reset pulse)?

regards
Al

[tnt]

For the autodetect itself, no need for a reset line.

This is what I had in mind :


So to "start", the FPGA just output '0' on the D line and then clocks like 30 times to 'flush' the chain. Then clocks out a '1'. It then reads the eeprom at address '1' (only the first board has this address, the other at at address 0). Then the fpga clocks out a '0', which puts back the first card eeprom to address 0 and puts the second card eeprom on address 1 by itself, and so on ...

Now, do daugther card need a global reset ... no idea. Could definitely be useful, I have to read the serdes chips datasheet more closely to see how to use them.

EDIT: There is even SOT23 EEPROM that could do (beware though, not all sot23 ones have address lines ! but some do). So that would make this circuit a total of 2 SOT23 component. Even if we can't use LED0/1, I think it'd be worth using 2 gpios of PEC FPGA for this. It might be possible to do it with a single one if really needed with a more complex circuitry on the daughterboards.

[gbulmer]

The proposal for "Parallella Stackable Daughter Boards – Tabs" is very impressive. With that much processing power (which will grow in the future) it is highly desirable to enable very high-bandwidth communication.

However, I wonder if it is more sophisticated than some use-cases require to complete them? I envisage many folks will get the high-bandwidth boards 'ready made' but may have projects which need lower-bandwidth signals too in order to complete them.

After all, Parallella is less than 3x a Raspberry-Pi or Arduino Due. So I think Parallella is within the budget of undergraduate and hobbyist 'embedded' projects. Hence the ability to easily add simple hardware may be an important attraction to a wider user community.

I am assuming there will be a very broad range of interest and capability, with many people having stronger software capabilities and less experience in making hardware. Designing and building a ziport may be more than they feel comfortable doing; for some people it may be an insurmountable obstacle preventing them from applying Parallella.

So, as well as Ziports, also offer something simple, widely available and familiar.

How about SPI? It is simple and fast enough for many simple I/O needs, and much faster than I2C. Using a few of the FPGA PEC's to provide something as 'cheap and cheerful' as SPI may enable folks to get onto the 'Parallella train' and make a more diverse range of 'add-ons' and projects. Most microcontrollers (MCUs) support SPI 'out of the packet', and using an MCU to interface to the 'outside world' may enhance Parallella's flexibility.

For example, a Cortex-M0/3/4 is enough horsepower for simple I/O. Some have as much as 20msps 12-bit ADC, and so could provide interesting data volumes. Cortex microcontrollers start at about $1, so hardware based on those types of devices should be within most projects' student and hackers hardware budgets. Further, the Parallella itself may run the development toolchain for ARM based MCUs.

Even a single SPI would have useful throughput. An Arduino's AVR can handle quite a lot of 'dumb stuff', and it is highly unlikely that it could saturate SPI. Cortex-Mx has more than enough horsepower for a few stepper motors, Brushless DC motors, or closed loop control for DC motors with encoders (using MCU intelligence); some 9+DOF inertial measurement units (IMU) use a Cortex-class processor. Parallella may then be free to handle video, LIDAR, analysis, strategy, etc.

A very simple interface like SPI might enable Parallella to be embedded into a wider variety of projects, while requiring less expertise and time. To get folks started, we might produce a 'skeleton' PCB (e.g. using Eagle), or even one with a low-cost MCU, so folks could easily build the lower-throughput interfaces. For example, someone might add a small LCD display, a few buttons and a LiPo battery charger and monitor, so that Parallella could be embedded in a battery powered device, and used 'in the field'.

The actual use of PEC signals is soft, because of the FPGA, but it would help to recommend a connection strategy to complement the ziport. For example, SPI might start on the left, i.e. the opposite end from ziport, and the signal pin assignments need to be defined.

[tnt]

I was thinking as well that having a fixed SPI port (there is already I2C) would be a good idea.

It can even be a single port and just use the same 'D-ripple' + NAND gate mechanism to generate the CS# signal so that the same port can be shared by multiple boards.

[theover]

Come on, you can do a better, more robust digital design than that, which also allows for setup-time correct input, can you ?

[Folknology]

[gbulmer]

[Folknology]