Parallella $99 board now open hardware on Github

Morgaine Dinova wrote:

 

The FPGA in the Zynq undoubtedly has a maximum throughput vastly exceeding that of the ARM cores, based on our background knowledge of typical FPGAs.  This means that the Zynq's dual Cortex-A9 cannot be anywhere near optimum for feeding data through the  interface at the highest rate the FPGA can probably sustain.  Because of the Zynq's AXI Bus (shown on the whitepaper I linked in post #24), the Zynq is probably very efficient at this, but in the end the data is still being generated by a pair of lowly Cortex-A9 cores clocked at 800MHz.  The AXI Bus reduces bottlenecks but it can't speed up the ARMs.

I believe you can also use the the FPGA fabric to talk to the system buses directly without going through the ARM cores, i.e., the FPGA can DMA to shared DRAM and also to peripheral devices like Gigabit Ethernet.  This way you can build very high performance data processing beyond what an ARM core can handle, and basically use the ARM to run control software with modest processing requirements.

John Beetem wrote:

 

I believe you can also use the the FPGA fabric to talk to the system buses directly without going through the ARM cores, i.e., the FPGA can DMA to shared DRAM and also to peripheral devices like Gigabit Ethernet.

While true, the Zynq doesn't have a monopoly on DMA.  Any reasonable ARM system can be expected to feed its DMA controllers at close to memory rate, and even Cortex-M* microcontrollers commonly feature crossbar-type internal buses so that different types of data transfer can occur in parallel and DMA controllers aren't starved by bus arbitration.  In other words, far cheaper ARMs could keep the Epiphany eLinks equally busy through DMA.

Regarding Ethernet, that really comes down to DMA again.  There is no room in Epiphany core local memory (just 32KB per core) for full TCP/IP stacks, so the host will have to handle the networking, extract the data out of the protocol payload, and DMA can then fish it out of memory for feeding Epiphany.  But again, the Zynq doesn't have any special advantage for this since gigabit MACs are quite common in modern ARM SoCs (less so gigabit PHY, sadly).

Morgaine Dinova wrote:

 

Regarding Ethernet, that really comes down to DMA again.  There is no room in Epiphany core local memory (just 32KB per core) for full TCP/IP stacks, so the host will have to handle networking, extract the data  out of the protocol payload, and DMA can then fish it out of memory for feeding Epiphany.  But again, the Zynq doesn't have any special advantage for this since gigabit MACs are quite common in modern ARM SoCs (less so gigabit PHY, sadly).

You could probably do wire-speed TCP/IP in the FPGA fabric, using block RAM for table look-up.

How's the power consumption for GBE PHYs these days?  Maybe it's better to leave them off SoC so the chips don't get too hot.

John Beetem wrote:

 

You could probably do wire-speed TCP/IP in the FPGA fabric, using block RAM for table look-up.

TCP/IP protocol implemented entirely in FPGA block RAM?  You jest ... I hope.

No doubt small and well-defined auxiliary functions could be implemented in the FPGA fabric as part of a TCP offload engine (which are quite common nowadays), but to implement the whole thing in hardware simply doesn't make engineering sense because most parts of TCP/IP are not in the high-speed pathway or are rarely executed.

How's the power consumption for GBE PHYs these days?  Maybe it's better to leave them off SoC so the chips don't get too hot.

That was just poor phrasing on my part.  I meant that gigabit PHY are less common on ARM boards even when the host SoC provides gigabit MAC.  Your point about heat is a good one.  Gen0 Parallella recipients were complaining quite a lot about heat.

Morgaine Dinova wrote:

 

John Beetem wrote:

 

You could probably do wire-speed TCP/IP in the FPGA fabric, using block RAM for table look-up.

TCP/IP protocol implemented entirely in FPGA block RAM?  You jest ... I hope.

 

No doubt small and well-defined auxiliary functions could be implemented in the FPGA fabric as part of a TCP offload engine (which are quite common nowadays), but to implement the whole thing in hardware simply doesn't make engineering sense because most parts of TCP/IP are not in the high-speed pathway or are rarely executed.

I'm talking about the core packet processing functions like CRC checksum and port numbers and window management.  I'm also talking about IPv4 since I don't have experience with IPv6.  However, since modern wire-speed routers are implemented in hardware, there's no reason you can't do this with a decent FPGA since managing an end-point is a lot easier than routing.  In fact, you can buy TCP/IP IP for various Xilinx FPGAs.

John Beetem wrote:

 

However, since modern wire-speed routers are implemented in hardware, there's no reason you can't do this with a decent FPGA since managing an end-point is a lot easier than routing.

I think you meant the opposite, that routing is a lot easier than managing an endpoint.  Routing in hardware needs to handle only the IP layer and can ignore all higher-level detail, which is just payload data at the IP level --- that's why good routers can route frames back-to-back even on 10gig.  The routing management protocols and ICMP only come into play at exception or change points, so that's typically left to CPUs to handle at their leisure in all but the highest end backbone routers.

At the endpoints, the entire protocol stack comes into play, which is a heavy burden indeed.  TCP offload engines commonly dedicate an embedded CPU to the task rather than hardware, although as we both mentioned, simple functions like CRC are very commonly implemented in hardware, often as a dedicated instruction in the SoC.

That iTOE Verilog for Virtex and Spartan doesn't look like open source to me.

@Morgaine and John,

I haven't quite got to full TCP/IP in the fpga yet but I'm currently using a Lattice ECP3 to generate multi fragment UDPs sent out at wire speed to GBE, (external Marvell phy and it runs pretty hot  - which answers an other question). I can't see that it would ever make sense to do all of the work in the FPGA  - things like ARP don't need that kind of speed.

I would love to get my teeth into some TCP acceleration in the FPGA but it is very expensive in terms of development time and we have already hit issues with common GBE network components (like switches) which cant actually handle wire speed data unconditionally - and the conditions are not well specified.

One of the problems you hit with sharing the network stack between processor and FPGA is that you end up writing the entire stack, parts in C and parts in VHDL or Verilog - that's why so far we've kept our end very simple with support for UDP, IP, ARP and not much else.

The phy uses more power than the FPGA and the processor (STM32F407).

MK

John Beetem wrote:

 

I'm actually quite amused (not ROFL -- more like rocking back and forth holding my knees chuckling) at the idea that US$99 is expensive for a Zynq board in 2013.  Parallella was originally prototyped with a 7020-based ZedBoard, which is still US$395 (US$319 for academics).  [FYI: ZedBoard is now 1 year old and has sold over 3,000 units.]  There's now a 7010-based MicroZed board for US$199.   IMO getting the cost with Epiphany down to US$99 is pretty impressive, even if that's pre-order pricing.

Digilent has announced a Zynq 7010-based board called ZYBO for US$149.  Much friendlier I/O than Parallella, including bidirectional HDMI, 16 bit/pixel VGA, 10/100/1G Ethernet, 512 MB DDR3, and five Digilent PMOD connectors for various I/O cards.  I don't think it has any high-density GPIO connectors, so if you need a lot of GPIO you're probably better off with a MicroZed.  It is nice to see Zynq boards coming down to a reasonable price range.

I suspect that Zynq will never have a reasonable price, meaning the price of mass-market Chinese SoCs.  Like Intel, Xilinx seems to believe that keeping prices sky-high is intrinsic to its self-respect and/or survival, and so the company is not playing the game described by that famous saying "The natural price of all semiconductors is the price of their packaging."

Published on October 3rd, I missed this Parallella update until now:

Adapteva writes:

 

"Secret Epiphany Multicore Features Released"

 

New “Secret” Multicore Features:

• Multicore multicast transactions
• Multicore breakpoints
• Multicore hardware barriers
• eMesh network traffic monitoring
• eMesh detour routing
• Hardware loops
• DMA messaging
• Hardware debugging

 

Here is the new update of the Epiphany Architecture Reference Manual.

"Hardware loops" ... this is getting interesting. (*)

(*) Page 67, a few restrictions but nice enough.