Learn Gate-Array Programming In Python and Software-Defined Radio

Bruce Perens writes Chris Testa KB2BMH taught a class on gate-array programming the SmartFusion chip, a Linux system and programmable gate-array on a single chip, using MyHDL, the Python Hardware Design Language to implement a software-defined radio transceiver. Watch all 4 sessions: 1, 2, 3, 4. And get the slides and code. Chris's Whitebox hardware design implementing an FCC-legal 50-1000 MHz software-defined transceiver in Open Hardware and Open Source, will be available in a few months. Here's an Overview of Whitebox and HT of the Future. Slashdot readers funded this video and videos of the entire TAPR conference. Thanks!"

Comments

Not a fan of procedural languages syntax for HDL

[StandardCell]

Folks who do development with Python should be wary of using too many procedural definitions for algorithms, even if they can be converted to hardware. Main reason is the size of the state machines and data paths, and the efficiency of algorithmic implementations in hardware, as even the best synthesis tools need to be constrained for reasons of design frequency and implementation size (hence synthesis pragmas). Granted, the hardware has gotten much more powerful and yes I know Python has object-oriented elements, but the idea of inherent concurrency and expressed versus implied data path are the trickiest things about designing hardware with languages that most people use procedurally. My other concern is supporting formal verification tools to check that Python = Verilog netlist for RTL->gate. For us more experienced hardware folks, I wish there was more emphasis on VHDL or Verilog straight-up even with open source tools.

That said, it's great to see Chris getting this project off the ground. It'll be very helpful for the SDR community and I hope we see lots of good things come of it.

FOSS and ham radio need fully open FPGAs

[Morgaine]

Free and Open Source Software (FOSS) has achieved immense success worldwide in virtually all areas of programming, with only one major exception where it has made no inroads: FPGAs. Every single manufacturer of these programmable devices has refused to release full device documentation which would allow FOSS tools to be written so that the devices could be configured and programmed entirely using FOSS toolchains.

It's a very bad situation, directly analogous to not being able to write a gcc compiler backend for any CPU at all, and instead having to use a proprietary closed source binary compiler blob for each different processor. That would have been a nightmare for CPUs, but fortunately it didn't happen. Alas it has happened for FPGAs, and the nightmare is here.

The various FPGA-based SDR projects make great play about being "open source, open hardware", but you can't create new bitstreams defining new codecs for those FPGAs using open source tools. It's a big hole in FOSS capability, and it's a source of much frustration in education and for FOSS and OSHW users of Electronic Design Automation, including radio amateurs.

If FPGAs are going to figure strongly in amateur radio in the forthcoming years, radio amateurs who are also FOSS advocates would do well to start advocating for a few FPGA families to be opened up so that open source toolchains can be written. With sufficient pressure and well presented cases for openness, the "impossible" can sometimes happen.