Slashdot Mirror
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!"
HackRF is designed to be test equipment rather than a legal radio transceiver. It doesn't meet the FCC specifications for spectral purity, especially when amplified. You could probably make filters to help it produce a legal output.
Whitebox is meant to meet FCC specifications for spurious signals that are required when amplification of 25 watts or higher is used. Amplifiers also contribute spurious signals and will usually incorporate their own filters.
HackRF is something that sticks on your laptop via USB. Whitebox is meant to be a stand-alone system or one that is controlled from your Smartphone via a WiFi or Bluetooth link.
Whitebox is optimized for battery power. Using a FLASH-based gate-array rather than the conventional SRAM one makes a big difference.
Bruce Perens.
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.
Chris can explain this much better than I, but we are definitely conscious of the gate-array resource use. Currently we are running within the space of the least expensive SmartFusion II chip, which I think you can get for $18 in quantity. Smartfusion 1 was more of a problem as it didn't have any multiplier macrocells and we had to make those out of gates. SmartFusion II provides 11 multipliers in the lowest end chip, and thus the fixed-point multiply performance of a modern desktop chip for a lot less power.
We are also aware of algorithmic costs. For example we were using Weaver's third method and will probably go to something else, maybe a version of Hartley.
Bruce Perens.
Not sure you understand. The OO model is useful for representing a 4-input device with a logical output determined by a look-up table, which is the fundamental logical element. At least it's useful to do it elegantly. Lua is a small embedded language, but the purpose of MyHDL in this case is not to execute Python at runtime but to generate VHDL or Verilog describing an inherently parallel implementation of an algorithm.
Bruce Perens.
I would say that the main advantage of using Python is in the verification process - writing test fixtures and analyzing the results of simulations is much easier to do with the Python toolkit. Design of real world Digital Signal Processing for the FPGA feels much more natural.
In the end, All simulations end up running in a real Verilog simulator, after conversion. I use Icarus Verilog and it integrates seamlessly at this point. You can tie in your own Verilog modules too.
Chris KD2BMH
From what you just wrote, I concluded that I understand. But the OO model in the Kay(ian?) definition is hardly more suited for describing hardware than not using it. Second, if whatever algorithmic code gets executed serves as a metamodel (regardless of whether the code is OO, non-OO imperative, or functional) rather then a model, then it is indeed the case that Lua is more suited since it was designed partly as a data description language since its inception, whereas Python gets just commonly mutilated and abused to serve the same purpose. OK, it works, but I never felt comfortable reading things like that. (Too much implicit magic for my taste, I guess.)
Ezekiel 23:20
If you ever write a means of describing digital logic designs in Lua we can compare it. Just describing data structures is not sufficient, you need to describe parallel boolean algebraic operations and macrocells such as multiply. At the moment no such thing exists and it would take a long time to duplicate the work of the MyHDL project.
Bruce Perens.
Chris and I would like to do an Open gate array as our next project. Sufficient patents have expired, etc.
Bruce Perens.
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.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra