Piotr Esden-TempskiFor some time @securelyfitz and I have been working on a new hardware security tool. It is called epic-erebus. It is a tiny m.2 WiFi module sized FPGA board allowing the access to the PCIe interface. If you remember the slotscreamer, this is the evolution of that idea. It can do a lot more in the small form factor and FPGA on board. We just published our pre-campaign page. You can sign up for updates for when the campaign launches some time next year. https://www.crowdsupply.com/securinghw/epic-erebus #EpicErebus #fpga
tnt@esden @securelyfitz Does that include the development of PCIe core for ECP5 ? AFAIK there is currently no such thing ?
@tnt @securelyfitz Yes it does, we are in the process of developing open-source PCIe gateware for the ECP5. This is why we are planning to launch the campaign next year so that we can show off working gateware. :)
Marcus Müller@esden @tnt @securelyfitz jay! (I don't care about the security work, sorry! But I could really make use of an M.2 FPGA prototyping tool for DSP and FEC dev, and for educational purposes.)
@funkylab @tnt @securelyfitz Yeah 100%, we are definitely aware of all kinds of non security related use cases. We will are making sure you can write your own gateware for the board! Part of the project goal is the development of all necessary elements allowing you to use fully open-source tools and gateware blocks. This means no need for special licenses and proprietary tools. Part of the reason why it is based on ECP5 ;)
@esden @tnt @securelyfitz it's a nice low-cost choice for basic PCIe support, regardless of the toolchain :)
Brian Swetland@esden @funkylab @tnt @securelyfitz Very cool. I'm definitely more interested in non-security-related applications and very enthused about fully open-source gateware for PCIe.
@swetland @funkylab @tnt @securelyfitz what would you use it for? I am curious about all the uses people have in mind.
@esden @funkylab @tnt @securelyfitz I don't have a specific goal in mind at the moment, but having the glue to be able to drop an FPGA project into a larger machine and communicate over a more integrated / higher speed / DMA-capable link rather than SPI / UART / USB feels like a fun option to have and previously would have had to start with me fighting with vendor tooling and/or deciphering PCIe on my own...
Henning Paul DC4HP@funkylab @esden @tnt @securelyfitz Same here. I would totally rip off that design to build a PCIe card-form factor SDR you can use in a Thunderbolt-to-PCIe adapter.
@hennichodernich @esden @tnt @securelyfitz honestly, just a plain PCIe-to-moderately-high-speed-serdes would be helpful; I currently don't have a lab setup requiring any of this, but a lot of people with avalanche photon detectors, time-of-flight sensors or just complex trigger sequencing setups would benefit from being able to stream binary at a GS/s to or from host RAM, which frankly is not that much bandwidth for PCIe.
@hennichodernich @funkylab @tnt @securelyfitz Interesting, to be fair there is already a bunch of PCIe connected SDR solutions out there. They are not using an FPGA that is supported by the open-tools, but otherwise they do offer that form factor. I am curious what the advantage beyond openness of the underlying protocol that has nothing to do with the actual SDR capabilities you would gain here. https://www.crowdsupply.com/search?q=sdr
@esden @hennichodernich @tnt @securelyfitz a lot (actually all, to the best of my knowledge) of the COTS SDRs with PCIe interface that are *not* made by Ettus don't support timed commands, i.e. starting streams, changing gain, switching antennas, retuning the DDC etc; however, if you want a PCIe-attached SDR instead of say USB3 or Ethernet, that's usually for timing related reasons.
plus, so many many SDRs, and nearly none of them with even acceptable driver support…
plus, so many many SDRs, and nearly none of them with even acceptable driver support…
@funkylab @hennichodernich @tnt @securelyfitz Ok that makes sense. So what you are saying is that there needs to be "someone" to build a "proper" PCIe SDR that can compete with Ettus offerings. If I understand correctly Ettus makes cool stuff but it is quite pricy and closed source. I did hear about the driver issues and lack of support in other solutions in the PCIe SDR segment.
So I hope our foundational work to unlock PCIe a bit more will be useful here. This is big part of the campaign.
@esden @hennichodernich @tnt @securelyfitz ha, disclaimer: used to contract for Ettus (am not the only one in this chat); good folks. almost all of their gateware is FOSS, and there is a long way from having access to PCIe-enabled ECP5 to a useful SDR; but as you say, needs a starting point.
@SDRHoernchen actually is working on a open toolchain SDR, by the way.
@SDRHoernchen actually is working on a open toolchain SDR, by the way.
@esden @funkylab @hennichodernich @securelyfitz
The HW is not open, although usually schematics are available as PDF, just not design files.
Gateware and Software is open.
Thing is for SDR, the "hardware" is the easy part. Good driver stack and proper support in the various frameworks and application (continued through the _years_ !) is an order of magniture harder and costlier. And "crowdfunded" hw never account for that ... and so end up with crappy sw.
@tnt @esden @hennichodernich @securelyfitz yep. The investment in fixing and continously extending their drivers and on-FPGA DSP chain framework that Ettus does is *quite* substantial; not to mention individual and org investment in fostering software ecosystems.
@tnt @funkylab @hennichodernich @securelyfitz Ahh ok. Sorry to misrepresent things in that case. Even then, it is good to have more than one option.
As for HW vs SW/GW: I 100% agree... the hardware often the easy part, the hard and very expensive part is the software... open source volunteering is rarely enough... think Black Magic Debug… :D
@esden @tnt @hennichodernich @securelyfitz yeah Ettus certainly led the affordable SDR wave years ago, and Matt did the right thing (both commercially and ethically) working in the FOSS context and contributing to FOSS software directly (so much GNU Radio code was written by people back then or eventually paid by Ettus) and indirectly; but it's not trivial to replicate that amount of long-term maintenance for a diverse and complex product range.
F4GRX Sébastien@esden @hennichodernich @funkylab @tnt @securelyfitz openhpsdr, if they have a pcie solution, will be limited to multiple low bw receivers for ham voice usage.
@f4grx @esden @hennichodernich @tnt @securelyfitz yeah that's one where PCIe fills no needs; neither would ham modes use any of the low latency, nor would you need more than an FX2 to get the data across USB2.
@funkylab @f4grx @esden @tnt @securelyfitz Pavel Demin is currently designing a 10GbE version of the Red Pitaya with doubled bandwidth, I would prefer a PCIe device.
I could use a bit more bandwidth for my 8ch 80MSps receiver...
@esden @funkylab @tnt @securelyfitz I find no joy in using SDRs. I find tremendous joy in designing and building them. 😉
🇺🇦 haxadecimal 🚫👑@hennichodernich @esden @funkylab @tnt @securelyfitz
I womder when will there be:
* next generation SDR chip
* cheap clone of AD9361
I womder when will there be:
* next generation SDR chip
* cheap clone of AD9361
Felix "tmbinc" Domke@tnt @esden @funkylab @hennichodernich @brouhaha @securelyfitz https://www.eswincomputing.com/bocupload/2022/07/28/16590235251668l4m67.pdf maybe? ECR8660A (not sure if this is part of this series though) is used in some commercial devices (DJI Sub2G module)
@felix @tnt @esden @hennichodernich @brouhaha @securelyfitz I talked to ESWIN at embedded world about exactly that family and sent multiple emails; they never got back
@brouhaha @esden @funkylab @tnt @securelyfitz I'm looking forward to the ADRV9002. (I had the opportunity to play around with it on an FMC add-on board at $DAYJOB.)
@hennichodernich @esden @funkylab @tnt @securelyfitz
AD was talking about a PlutoNG three years ago. What happened to it? Sigh.
AD was talking about a PlutoNG three years ago. What happened to it? Sigh.
@brouhaha @esden @funkylab @tnt @securelyfitz https://wiki.analog.com/resources/eval/user-guides/jupiter-sdr
It got upgraded and therefore now is named after the biggest planet in our solar system.
It got upgraded and therefore now is named after the biggest planet in our solar system.
@hennichodernich @esden @funkylab @tnt @securelyfitz
It doesn't seem to matter what the name is, it doesn't actually appear to be available.
It doesn't seem to matter what the name is, it doesn't actually appear to be available.
@brouhaha @hennichodernich @esden @tnt @securelyfitz
> * next generation SDR chip
I mean, the AD9371 is out there to play around with. Reference schematics of working products do exist, e.g. https://kb.ettus.com/images/9/9d/USRP_N310_N300_DB_Schematic.pdf
Kraftwerk-Das Model Collapse
izzy boiii ✈️ Swizzle.fun