What does HackerNews think of openwifi?
open-source IEEE 802.11 WiFi baseband FPGA (chip) design: driver, software
> It should be noted that many WiFi routers, such as TP-Link AC1750, come with 3 antennas, so our method only requires 2 of these routers.
> WiFi-based perception is based on the Channel-state-information (CSI) that represents the ratio between the transmitted signal wave and the received signal wave. The CSIs are complex decimal sequences that do not have spatial correspondence to spatial locations
AFAIK, access to raw CSI data is not available on consumer routers. You need specific FPGA/SDR boards which happens to speak the WIFI 2.4G/5G protocol.
There are some open sources efforts such as https://github.com/open-sdr/openwifi
https://ans.unibs.it/projects/csi-murder/ enabled by https://github.com/open-sdr/openwifi Both partially funded by EU's Horizon2020 program.
Openwifi talk at FOSDEM 2020 https://www.youtube.com/watch?v=8q5nHUWP43U
That opens the door to less conventional stuff, such as CMOS imagers, memories, RF/Analog designs, etc. Obviously the available space and I/O are going to be limitting factors.
Regarding Wi-Fi, I was thinking of some of the RF frontend for a project such as [1]. I am not extremely knowledgeable about RF, so that would be a learning opportunity. I imagine it to be mostly carrier generation and multiplexing, the higher layers are doable on an off-the-shelf FPGA.
That said, Wi-Fi is a simple target, but maybe not the most interesting one. That's the first full-custom application example I thought of.
Both partially funded by EU's Horizon2020 program.
Openwifi talk at FOSDEM 2020 https://www.youtube.com/watch?v=8q5nHUWP43U
There is another alternative open source WiFi stack, openwifi and it has been discussed in HN before [2][3].
[1]https://www.analog.com/en/design-center/evaluation-hardware-...
- https://github.com/bastibl/gr-ieee802-11 (gnuradio transceiver by the amazing Bastian Bloessl)
- https://github.com/open-sdr/openwifi (efforts to make a low-cost SDR Wi-Fi transceiver)
From my point of view, cool projects, all the hardware I have access to is closed source and sometimes I really wish I could just change some low level parameters in my Wi-Fi cards.
A bit longer answer: Basically Linux gives packet to our driver, and then our driver gives the packet to our FPGA for further processing (queuing, modulation, CSMA, etc). So you can compose your packet in the driver or anywhere else that can communicate with the driver, then instruct the FPGA to send your packet at any frequency 70M~6GHz.
It will be very worth to read the README and project document word by word on the github: https://github.com/open-sdr/openwifi . I believe you can already find answers of more questions there.
Now, how do you generate these layouts? It depends on what you are doing. If more on the experimental side of things, writing scripts to generate structures is fine, as long as these conform to the fab-provided design rules. Technically, that's still what everyone is doing at the industrial level, except the scripts -- often written in tcl -- are provided by the fab.
Now if you have some FPGA experience, you are probably interested in logic synthesis tools. There are a few ones, I've seen some academic with their own place-and-route stage, for instance. https://open-src-soc.org/program.html#T-CHAPUT does that, I think.
The slides linked above outline one of the possible ways to do this: leverage chisel ( https://www.chisel-lang.org/) and the FIRRTL intermediate representation for RTL description. A few tools can ingest the output and try to come up with a layout. Hammer (https://github.com/ucb-bar/hammer) is such a tool, but I don't think that PDK is available with it just yet. To be honest, I don't think commercial tools are that advanced, and it would be fairly doable to catch up.
There is some interesting work in this field, but since fabbing is expensive, it tends to be more within the academic community than the free software one. I'd look for papers, not on Github, though that's slowly changing.
The chip design world is a slow beast to turn around: everything in the fabrication process is optimized to maximize yield, hence very little leeway is allowed: "If it ain't broken, don't fix it" is the motto, for good reason: if changing humidity levels 0.2% can make a fab lose millions; they won't try to use new and experimental software.
I'm watching this space, notably with Verilog alternatives such as Migen. The open source community starts to embrace FPGA, wich is already great. I wish more manufacturers opened up their bitstream, so maybe we need an open FPGA? Though this free fabbing offer would be a great fit for Wi-Fi chips, I think. I wonder if People at openwifi (https://github.com/open-sdr/openwifi) are interested?
I hope that gives a few interesting pointers to whoever reads this :)
I would also like to point out that these tools will likely help us juice up a bit more performance from the existing processes, but we aren't really likely to see a lot more of Moore's scaling, going forward. So the door is open to new processes, that may or may not be open hardware-friendly. And current, top-end processes might also become cheaper over time. While I doubt a lot of new foundries will catch up with the end of Moore's scale, it might actually become easier to get there, while disruptive technologies get some time to play catch-up. Together with innovative synthesis tools.