[HN Gopher] SatCat5: FPGA gateware that implements a low-power, ...
___________________________________________________________________
SatCat5: FPGA gateware that implements a low-power, mixed-media
Ethernet switch
Author : sohkamyung
Score : 143 points
Date : 2023-02-16 11:52 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| f_devd wrote:
| Interesting that it's both patented and under LGPLv3/GPLv3
| (unclear which applies), seems like a way to avoid non-
| FOSS/proprietary implementations although I would think releasing
| it as regular GPLv3 would already serve as prior art under patent
| law, IANAL but would love to know.
| pclmulqdq wrote:
| OSH licenses for FPGA code are a total mess. I am working on
| some hardware that I plan to open source very soon, but
| figuring out what license to use is extremely difficult. My
| options seem to be:
|
| * Start with CC-BY-NC that pretty clearly disallows commercial
| use in any way and punt on the question (or allow commercial
| users to pay a nominal fee for a commercial license)
|
| * GPL or LGPL - both of which are unclear how they apply in the
| case of ASIC and FPGA designs, particularly when you consider
| weird corner cases like partial reconfiguration (FPGA and ASIC
| tools allow you to sequester the open source block in its own
| "compilation unit" and compiling that unit separately from the
| main system, only connecting the wires at the last steps)
|
| * CERN OHLv2 license of some kind, which seems to give up its
| copyleft provisions on things that don't involve giving stuff
| to a customer
|
| * MIT/BSD
|
| A lot of folks in hardware are not particularly interested in
| going for the MIT/BSD route because of the commercial nature of
| IP cores. It essentially allows a random firm to repackage your
| IP and sell it as their own (usually for a shit load of money -
| hardware licenses are often 5-6 figures).
| aylons wrote:
| CERN has published specific licenses for FPGA development,
| reviewed by lawyers and used by actual developers:
|
| https://ohwr.org/project/cernohl/wikis/home
|
| It takes your concerns in consideration, and much more. For
| FPGA the CERN-OHL-W is the usual one.
| pclmulqdq wrote:
| I addressed my concerns about the CERN license already. In
| particular the definition of "Convey" doesn't seem to apply
| unless you provide a product of some sort to a customer of
| some sort or release your source code as open-source.
| Hosted products and commercial use for internal purposes
| are arguably not covered under the copyleft parts of the
| license.
|
| It does seem to be the least bad option, though, for most
| things.
| sitkack wrote:
| You could look at MPL? https://www.mozilla.org/en-US/MPL/
|
| I agree that hardware should have stronger copyleft
| requirements than code.
|
| MIT/BSD has a place where you have a consortium or an org
| encouraging the ecosystem to maintain compatibility. The gain
| is that the ecosystem is compatible with a spec, so the whole
| is more important than each individual entity.
| pclmulqdq wrote:
| I just read the MPL, and if you look at the CERN license,
| you can see some of the problems with licenses like GPL and
| MPL.
|
| In the software-oriented licenses, the lawyers who wrote
| them are very diligent to define things very clearly in
| software-specific terms, and then stop before defining
| those terms. It lets them keep the contract shorter and
| allow those definitions to change over time. For the GPL,
| this means taking the definition of "linking" for granted,
| and in the MPL, the definition of "larger work" pretty
| clearly seems to apply to only software:
|
| A "Larger Work" is a work that "...combines Covered
| Software with other material, _in a separate file or files_
| , that is not Covered Software." In software land, this is
| fine because you distribute software in the form of files,
| but if you are distributing the Covered software as a piece
| of silicon, it's unclear whether that is a "larger work" or
| not, because the other material is not in a separate file
| at the point of distribution.
|
| Here's the CERN "strongly reciprocal" license for
| reference, showing the difference between the software- and
| hardware-specific language:
|
| https://spdx.org/licenses/CERN-OHL-S-2.0.html
|
| The CERN license, by the way, has the opposite problem for
| FPGA code - it defines things in terms that really apply to
| physical stuff.
| roblabla wrote:
| > (FPGA and ASIC tools allow you to sequester the open source
| block in its own "compilation unit" and compiling that unit
| separately from the main system, only connecting the wires at
| the last steps)
|
| The whole "compilation unit" stuff kind of reminds of the
| whole debacle with Nvidia (and many other linux driver
| vendors) creating a "generic" closed source driver, and a
| thin, useless, open source "shim" layer that connected the
| closed source driver to the GPL symbols of the kernel.
|
| Needless to say, nobody was amused by this. It never went to
| court, but the linux kernel put various technical
| restrictions in place to prevent those shims from working.
| See these notes from kernel 5.9[0].
|
| [0]: https://www.phoronix.com/news/Linux-59-Proprietary-Shim-
| Tain...
| leoedin wrote:
| The interfaces with devices over SPI/I2C etc is interesting.
| There's actually some other interesting developments in this area
| - 10Base-T1S and 10Base-T1L are recent standards that are
| designed to allow ethernet packet communication over much more
| lightweight multi-drop networks - basically allowing a small
| network of interconnected devices to talk ethernet to each other
| (and the outside world, via a bridge) without the requirement for
| bulky and expensive traditional ethernet transformers.
|
| https://www.microchip.com/en-us/solutions/ethernet-technolog...
|
| I don't think there's wide silicon support yet - but the prospect
| of a small network of sensors which communicate over ethernet,
| which can be effortlessly bridged to a standard network is quite
| nice.
| amluto wrote:
| Not just sensors -- entire devices and ecosystems of devices
| could use this, internally and for expandability. Anything that
| currently uses an RS-485-based protocol or even CAN could
| potentially switch.
| [deleted]
| [deleted]
| [deleted]
| myself248 wrote:
| This is really intriguing. I was recently pondering something
| related:
|
| 10/100 ethernet only uses two pairs, one in each direction. Of
| course the jack has four pairs, and the cable has four pairs and
| gigabit uses all four. But, if you're only using 10/100, it's
| trivial to split the jack on either end of a run, and carry two
| "ports" worth over a single cat5 cable.
|
| However, this requires a second splitter at the switch end, like
| so:
|
| https://lib.store.yahoo.net/lib/cablesonline/NETWORK13.JPG
|
| Would it be possible for a suitably-bastardized GigE PHY to drive
| the four pairs as two independent "ports" of 10/100, assuming
| such a splitter was just on the far end, but the cable on the
| near end was plugged directly into the switch?
|
| Don't ask about practical applications, I really have none in
| mind. It just struck me as a perverted and wrong thing to do,
| therefore it must be done.
|
| (And on that note, since GigE really runs the four pairs as four
| nearly-independent bidirectional channels and then merges their
| capacity afterward.... could you get four 250Mbps "ports" out of
| such a thing? By routing all four pairs to four separate devices,
| each of which is also running this bonkers implementation?
| Essentially reinventing single-pair ethernet (yet again yet again
| yet again yet again) using all stock PHYs. This would require
| cooperating devices on both ends of the link, but the prior idea
| could be used with stock 10/100 devices.)
| xxpor wrote:
| that's hilarious. it's essentially a physical vlan. it could be
| of use for anything that doesn't support vlans directly, and
| it'd be a lot cheaper than running a switch to do the
| tagging/untagging.
| myself248 wrote:
| I've done exactly that, when I couldn't be arsed to figure
| out QinQ on a wrt54g which already uses VLAN tagging
| internally between the SOC and the switch ASIC. Just used two
| physical ports and a splitting scheme just like the above.
|
| The trick would be doing it with _one_ physical port on a
| suitably malleable GigE-equipped device.
| seiferteric wrote:
| Wow this looks really cool and useful! I had a thought though, if
| the concept here is to create a local LAN for devices on a
| isolated system (satellite) to send data to each other, I wonder
| if there is some other model than a network that might be better.
| I am thinking like a shared memory store with transactional
| operations support, key/value and pub/sub notifications etc. Sort
| of like a hardware version of redis? Seems like dealing with
| network stuff is just necessary overhead.
| dogleash wrote:
| Models other than networking already exist for the embedded
| space (some sorta analogous to what you propose, but not
| exactly thought about in those terms). They're the more common
| option than going all the way to a communication protocol as
| complex as ethernet.
|
| But you eventually have to bridge between that and typical IP
| networking. It's usually the responsibility of the designer to
| bring their own hardware for the transition between (e.g.) SPI
| and twisted pair Ethernet. That's why this project to put it in
| the switch is novel.
| sitkack wrote:
| As an embodiment of hardware abstraction, the present invention
| relates to a key value interface in an Ethernet switch. The
| invention provides a Redis interface on the switch, enabling
| the interfacing with I2C devices to be akin to a read operation
| from a key/value store over the Redis protocol. The invention
| contemplates the publication of RISC-V or Wasm code to a
| key/value endpoint, followed by awaiting a response on a value.
| The present invention constitutes prior art in the patent
| categories of network switches, key-value stores, and hardware
| abstraction.
|
| patent classification codes: H04L, G06F 17/30, G06F 15/76, G06F
| 9/44 and G06F 9/455
|
| Seemed like something someone would make a BS patent for, so I
| had ChatGPT spiffy it up.
| teleforce wrote:
| Thanks for sharing, just learnt from the article and the
| following link the meaning of gateware:
|
| https://www.gateware.org/definition-of-gateware
| malwrar wrote:
| I see no mention of security--If you're exposing raw serial
| busses via ethernet, one would expect some manner of security
| controls, no?
| jdsnape wrote:
| I think it depends on the application. It's very unlikely
| someone will MITM the connection between components on a set of
| circuit boards in a satellite (the use-case they designed this
| for)
| moremetadata wrote:
| > SatCat5 also includes software libraries targeting both
| baremetal and POSIX systems for:
|
| So with the windows linux subsystem, it might just about run
| anywhere which could then introduce its own security
| situation.
|
| It will be interesting to see if the UAC prompt overrides
| I've seen when using Kali Linux and wireshark as a VMware
| guest on Win10, will also occur with this code. So the UAC
| prompt override's is where the Vmware guest network for Kali
| linux is put into promiscuous mode in order to capture all
| packets.
|
| Every windows reboot switches off the promiscuous mode and
| someone on here suggested its Vmware doing this not windows.
|
| Maybe this is the code/tool to see if it is windows or vmware
| overriding UAC protected settings or not.
| dogleash wrote:
| All interfaces still talk Ethernet.
| jhallenworld wrote:
| Looking at their patent: how is this different from an IOT
| gateway? Or a router that supports SLIP, ATM, PPP, etc.?
| Whatever..
| bsder wrote:
| While I am _always_ down with Ethernet All The Things(tm), this
| seems like an odd duck. I 'm thinking that they wanted to
| monetize this but 10Base-T1L and 10Base-T1S sidelined them.
|
| SPI Ethernet chips have existed for quite a while. Existing COTS
| Ethernet switch chips are going to be far more robust and quite a
| bit smaller. And, now that you can actually buy 10Base-T1L and
| 10Base-T1S transceivers--you can get even lower power by reducing
| the signalling levels (or maybe not for space applications). T1L
| gets you solid industrial point-to-point robustness, and T1S
| finally gets you multi-drop on single pair again (And the angels
| sang "Hallelujah!" for networking like it's 1988). Both of which
| can have genuine transformer or transformerless galvanic
| isolation.
|
| All this for far cheaper, far less complexity and _WAY_ less
| power than that FPGA.
|
| I guess the main advantage is UART interface Ethernet? A lot of
| cellular modem-like things have this really bastardized
| networking over UART that does have the advantage that it seems
| to be a "standardized" AT command set, so it's possible that this
| is important in satellite stuff which tends to piggyback on other
| industries as much as possible due to low volume.
| jhallenworld wrote:
| Ethernet over UART: you mean PPP? (RFC 1661)
___________________________________________________________________
(page generated 2023-02-16 23:01 UTC)