Parallella Community

If some of the pins on the Zynq are being freed up, is there any way that the West eLink can be connected to something??
Seems a pity that 25% of the eMesh connectivity is wasted.

Maybe for (sorely needed) extra memory bandwidth..

One for the Epiphany - did you look at piggy-backed memory chips (i.e like the Pi) to provide more "on-chip" memory?

tery

You need quite a few pins to implement eLink.

But in anycase I think the biggest memory bandwidth bottleneck is not the elink itself but rather it's current interface to the AXI.

Yes, lots of pins - but if the Parallella is in Cluster mode there's a load of GPIO and other connection logic that just isn't needed and could be freed up.
For instance, if the change to boot from the SD card instead of flash is made, there's a few data lines made available.
But that really means we would need TWO 2.0 Design Specifications : one for the "Better Pi" market and one for the cluster market.

If there are issues with the AXI interface, then here's an opportuinty to address them (whatever they are) perhaps?

tery

My few cents: I've seen a lot of talks from people asking to "add this feature", or "get this one", which simply doesn't seem to be possible within ONE small sized board.
So, I think It would be rather strong move to somehow make mini Pcie interface on the board, maybe even sacrificing something for this . The electrical interface for mini PCIe doesn't seem to require many lines...

This approach will automatically solve many requests.
For example, for making more Ethernet interfaces:
http://www.pridopia.co.uk/images/8111me-d.jpg
SATA ports:
http://www.hwtools.net/jpg/PM362_2.jpg
SSD drive:
http://www.mydigitaldiscount.com/images/P/FPM32GLSE.jpg
Additional USB 3.0 ports:
http://sgcdn.startech.com/005329/media/ ... 2.Main.jpg
Plug full-sized PCIEx1 board, if somebody ever need to gain access to VERY wide variety of interfaces
available on PCIE boards:
http://www2.multithread.co.uk/linitx.co ... roduct.jpg
And many, many others...

It will also save trouble of programming GPIO or designing custom adapters; overall applications will become much more flexible as well.

PCIe doesn't need many physical pins, but those pins have very strict requirements. Data goes at roughly 2.5 Gbps on those which is faster than what the FPGA on the board can do.

Either you need :
- Select another FPGA. The higher end zynqs have gigabit transceivers that can do PCIe. However they are more expensive and have a completely different pinout so this would mean a fairly significant redesign.
- Use an external PHY. For PCIe 1x you have PIPE interface and some chips available pretty easily. However this requires much more IO lines. It would be doable as an extension board using the PEC_GPIO though for example.

Then you have the software layer. Implementing host PCIe is certainly no small task, especially if you need to implement _all_ the layers from the bare fpga fabric up to the linux support.

my idea was mix epiphany with 3d memory + 3d fpga or mill-cpu.
plus nice case looks like smartphone and lcd and i2c interface.

I would like to see the bootmode select resistors allow booting from the sdcard rather then the qspi flash. This could decrese the cost of the board because you don't need the qspi flash. I am scared at updating the qspi as you can brick the board if you mess it up. I don't have a JTAG setup to recover it. With the boot code on the sdcard, it's a simple copy of boot.bin to the card. I don't quite understand why it was done this way to begin with. The reason is that the u-boot codebase is missing commands like (dhcp, nfs) to allow nfsroot mounting the filesystem. I've done zynq setups this way where I work. It makes it better for development and the gige connection is much faster in "disk" access then the sdcard.