Multi-chip support?

Seairth

At one point, there was discussion about the P2 having built-in support for efficient chip-to-chip communication. Does anyone recall the current state of this capability?

evanh

I'm pretty certain Chip hasn't said anything on this matter. It's one of those "it'll be addressed when he gets there" type features. People have speculated on a fancy SERDES that the DMA engine could feed but that's all wishful thinking with no proposed implementations.

kwinn

Wasn't this suppose to be part of the smart pins?

Seairth

evanh wrote: »

I'm pretty certain Chip hasn't said anything on this matter. It's one of those "it'll be addressed when he gets there" type features. People have speculated on a fancy SERDES that the DMA engine could feed but that's all wishful thinking with no proposed implementations.

Yeah, I remember the SERDES conversations. The truth is that I am not particularly concerned about bandwidth in this case. With the smart pins, it should be possible to manually implement a high-bandwidth solution when necessary (e.g. dedicate a cog or two on each side for (Q)SPI/HyperBus/etc.). When bandwidth is not necessary, it would be nice to simply enable a smart pin mode that reduce cog resource overhead to just a few instructions, like:

• WRPINB reg, pin [WC] - write a register to a 32-bit buffer. If WC is not set, the instruction blocks if the buffer is not empty. If WC is set, returns immediately with C flag set if the buffer wasn't empty.
• RDPINB reg, pin [WC] [NZ] - read a 32-bit buffer into a register. If WC is not set, the instruction blocks until the buffer is full (or a receive error occurs). If WC is set, returns immediate with C flag set if the buffer wasn't full. If NZ is not set, Z flag is set if a receive error occurs.

Again, bandwidth isn't the most important thing here. The most important thing (as I see it), is minimizing the impact on cog resources. I still expect that a cog will be dedicate to this communication, but most of it's time should be dedicated to the data/message processing/generation, not the bit-level transfer stuff.

(No, I don't expect this to influence design. Just thinking through some ideas I intend to try out on the P2. And killing some time while we all wait. )

evanh

Something like that is likely ... but I doubt Chip has got that far yet.

jmg

IIRC the Smart Pins are getting a simpler UART (ie no HW handshake lines and no FIFO )

The Video streaming can go both ways (out and in) and has DDS clock control, and that was going to support LCDs of various widths.  DDS is also useful for Baud timing.

Logical in that width choice would be 4 bits for QuadSPI (1 wide spi can come from UART)

All of that should give a lot of choices for Multi-chip support.

Seairth

All of that should give a lot of choices for Multi-chip support.



Agreed! As tantalizing as the current instruction set has been, I'm excited to see what the smart pins will be capable of!

Beau Schwabe

256 QAM communication could be used to do some very fast and interesting chip to chip communication but not limited just to chip to chip.  QAM is essentially what comes into your house as Cable or Satellite ... BEFORE... it gets to your converter box.  So the throughput to carry ALL of your TV channels before decoding and picking off a single channel you want to watch is rather amazing.  Rectangular QAM would probably be easier to implement, but concentric QAM might have greater throughput.  This all depends though on the speed of this ever changing Propeller 2 design effort.  A derivative of QAM could be extremely useful though.

rjo__

Beau,
"In other words, do not believe what you are told and what you
immediately perceive until you find out the absolute truth for yourself
from all possible angles. "

I wish you would say more.  Your experience is probably not unique and might save someone else from the same misery.

If you start I'll jump in with supporting evidence.

Or maybe we should wait until Parallax has re-opened the playground:)

Heater.

This QAM thing might need some explaining.
XMOS chips manage to communicate between each other at pretty high rates with out any of that. Single programs comprising of many parallel tasks can be distributed over networks of such devices and at run time those links provide channels between processes.
  

jmg

This QAM thing might need some explaining.
XMOS chips manage to communicate between each other at pretty high rates with out any of that. Single programs comprising of many parallel tasks can be distributed over networks of such devices and at run time those links provide channels between processes.

QAM is also how the Colour signal works in Analog TVs'
It needs good DAC and ADC, and is not really the lowest power way to link 2 adjacent chips.

I could see some niche use cases (depending on how the Prop 2 DAC/ADC actually spec out ) for limited bandwidth data transfer.

For local Chip-Chip a SPI/QuadSPI/HyperBUS with Double Edge support would be enough.
All of those are CLK + Data transfers, differing only in the pin-spread and mux.

Leon

This how XMOS links work:

XMOS links use a transition based signalling scheme. A single transition on a wiretransmits one symbol. XMOS links have two operating modes, 2 wire (serial mode)and 5 wire (fast mode).
A 2-wire (2w) link has two signal wires in each direction. A data byte is transmit-ted as a series of ten transitions on wire 0 and/or 1.
A 5-wire (5w) link has five signal wires in each direction. A data byte is transmit-ted as a sequence of four transitions on the 5 wires.

jmg

A 5-wire (5w) link has five signal wires in each direction. A data byte is transmit-ted as a sequence of four transitions on the 5 wires.


Any links to the details ?  Seems strangely custom ?
A QuadSPI with Dual Edge/DDR can transfer a Byte in 2 transitions over 5 wires.

[Oh look, yet another way the new forum editor can mangle posts ]

jmg

[deleted-meant to edit]

Heater.

jmg,
Yes, the XMOS scheme is a one off that I have never heard of before.
I have sometimes wondered why they do that. I did not wonder hard enough to ask though.