gigglebits - separate wan and lan?

[giggle....@gmail.com]

dear krtkl guys,

i love the project - i just have a security related concern about the gigglebits board.

all ethernet ports (ETH_P5/ETH_P6) seem to go through the same switch (88E635), so how is it
ensured, that the WAN and LAN ports are kept isolated during bootup / in case of misconfiguration?

thanks,

[krtkl inc.]

Thanks for the kind words - and that's a good question... We're currently tossing around the idea of tweaking the giggleBits architecture away from the AVB switch and toward a 'true' SDN arrangement. We'll be reaching out to the current giggleBits customers (and posting something in the forum) in the coming weeks to get some feedback and input to determine the best path forward with all that...

-Ryan

[zama...@gmail.com]

Hey, I'm a network engineer that hobbies with FPGAs. I was looking at getting the snickerdoodle+gigglebits but would love to have more direct control of the traffic flows. Look forward to and am curious about what you guys are thinking of offering.

[weath...@krtkl.com]

Hi,

Just an update on this.  We are currently evaluating changing the switch out for this device: http://www.marvell.com/transceivers/assets/Marvell-Alaska-88E1548-48P-Product-Brief.pdf
The issue of course is that there are only two hard GigE ethernet IPs in the Zynq and the Xilinx TEMAC IP is not freely available: http://www.xilinx.com/products/intellectual-property/temac.html
So we need a solution there to make the product feasible on a unit by unit basis since a project license for that IP runs around $500: http://www.digikey.com/product-search/en?keywords=EF-DI-TEMAC-PROJ
That's no big deal for someone buying large volumes of gigglebits for a commercial project but it is an issue for the SDN experimenter that is just going to have 1 or 2 boards.

Any thoughts on this from the community would be welcome.

-Jamil

[giggle....@gmail.com]

hi,

what would be the system architecture? connecting the 2 hard GE IPs, and 2 soft TEMACs to the quad phy
via 4 * SGMII?

on the hw side: would the TEMACs use regular SERDESes? SGMII needs 1.25Gbit/s, i think that is zynq speed
grade -2/-3, so what speed grade is on the snickerdoodle?

on the sw side: is there any driver or documentation (without NDA) available for this PHY? or can you get it working
using only the generic PHY MII registers?

other than these, i think this could work, on many different levels:
- people on low budget could start working using only the 2 hard IPs and some external switch (what people tend
  to have lying around anyway, or buy for a couple of bucks),
- people with more budget could buy the IP license,
- research projects could get it as a donation through the Xilinx University Program (XUP) - they have been quite
  generous in the past, and TEMAC is not that of a hot thing this days anyways,
- for pure FPGA based switching / routing (and i think these are the most interesting SDN applications) you could
  probably go with an open source MAC (see netfpga) / without any MAC.

i don't know about PCB real estate and parts pricing, but any chance to have both the quad phy and the switch
on the board? or maybe 2 half boards, one for each (does the pinout on the samtec connectors allow that)? but
this is just brainstorming, even the quad phy alone is fine.

[weath...@krtkl.com]

The one question I can answer right away is the the snickerdoodle black is -3 speed so the LVDS do support the data rates needed for SGMII.

I'm not sure how to respond to the NDA question right now because as you may know Marvell is pretty tight with their detailed specifications.   That's something we would have to likely find out as we go.  Another option would be to not use a Marvell PHY but rather 4xRGMII PHYs.  We have access then to pretty openly documented hardware like:

http://ww1.microchip.com/downloads/en/DeviceDoc/KSZ9031RNX.pdf

This still doesn't solve the TEMAC issue and you give up a number of more advanced PHY features.

The system architecture is the concern.   It limits your audience to require a paid TEMAC core that's why we did the switch in the first place but on the other hand the switch has an entire API that is closed and under NDA although it is capable of being configured and functioning standalone.

-Jamil

[giggle....@gmail.com]

hi jamil,

2016. július 9., szombat 2:38:51 UTC+2 időpontban weath...@krtkl.com a következőt írta:

The one question I can answer right away is the the snickerdoodle black is -3 speed so the LVDS do support the data rates needed for SGMII.

very good. i've seen the -3E marking on the crowdsupply page, and also references to speed grade 3,
but thanks for the confirmation.

 

I'm not sure how to respond to the NDA question right now because as you may know Marvell is pretty tight with their detailed specifications.   That's something we would have to likely find out as we go.  Another option would be to not use a Marvell PHY but rather 4xRGMII PHYs.  We have access then to pretty openly documented hardware like:

http://ww1.microchip.com/downloads/en/DeviceDoc/KSZ9031RNX.pdf

you could probably get the basic functionality working on the marvell phy with the standard MII registers,
without NDA docs. that wouldn't be unusual. as you said: you find that out by reading a lot, and then along
the way.

 

This still doesn't solve the TEMAC issue and you give up a number of more advanced PHY features.

i would not worry too much about this. i think people considering snickerdoodle for SDN will not miss it.
actually the board become more attractive to me when you mentioned the quad PHY, and i realized that
2 ports would be connected to the dedicated GE hard IPs of the ZYNQ PS, but the other 2 ports would go
directly to the PL.

with this 2 "raw" ports i don't have to worry about putting the MAC into transparent mode (= promiscuous
mode, disable any filtering, etc), and about transferring the network traffic between the PS and the PL
(which would need a DMA, possibly taking away resources in PL, would add big, nondeterministic latencies),
like it's the case with the PS's GE hard IP.

so the quad phy in this 2 + 2 configuration would be the best i've seen. you could do "soft" processing only
(PHY + GE hard IP + linux, you could probably have an almost empty PL), or "hard" processing only (PHY +
SGMII + PL, the ARM processors would be used only for the control plane), or any combination. the extra
switch IC in addition would be the cherry on top.

(i was afraid you'll just connect a second phy, like a 88E1111 to one GE hard IP, and connect the switch to
the other one. but that would be business as usual, not "create someting different", so i have high hopes. :)

also, if you have the switch connected to the ZYNQ PL via SGMII, i think you can can still route the GE hard
IP pins to the PL, do GMII <-> SGMII conversion in the PL, and then go to the swtich IC - the net effect is
that the switch appears to be connected to the GE hard IP.)

..

switch has an entire API that is closed and under NDA although it is capable of being configured and functioning standalone.

there is a reference to this particular IC in the linux source (see net/dsa/mv88e6171.c), so maybe you can get
at least some functionality working without NDA (did you have any success yet?). that's why i recommended
keeping it (in addition to the quad PHY). i just did not like having no WAN/LAN separation, but that would be
solved with the addition of a quad PHY in 2 + 2 mode.


very exiting, very exciting..


br,