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!"
Is it possible to encode deep web machine learning on a Beowulf cluster of these chips on a custom ruby on rails brogrammind cloud?
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.
...in just about any language,
Time is what keeps everything from happening all at once.
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.
Just because the language of the implementation is procedural and the language of the input specification is procedural doesn't mean the input can't be richly descriptive if all the input does is generating certain data structures describing the device model from the input. And your "object-oriented" comment seems quite out of place because it hardly brings anything new to the table that would be useful in this case compared to going the other way.
Having said all that, I'd probably go for Lua anyway since this is the thing it was basically designed for.
Ezekiel 23:20
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.
It'll truly be the end of Slashdot if you, Mr. Perens, joins the "frost piss" gang !!
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.
Just describing data structures is not sufficient, you need to describe parallel boolean algebraic operations and macrocells such as multiply.
You're effectively saying that a compiler must embody not only syntax but also the semantics of its input format. I never disagreed with that! It's kind of obvious, otherwise you have a mere parser. Plus, I didn't say you can't do that in Python, in fact I explicitly said that 1) it's perfectly possible to do it in Python, but 2) perhaps Lua would have been a somewhat better choice.
I have been in fact very much interested in having a similar system in Lua, but the proprietary nature of virtually all the relevant output devices strongly discourages me. The last FPGA I vaguely recall a having a public or reverse-engineered bitcode (some Xilinx chip, I think) was discontinued a looong time ago.
Ezekiel 23:20
Chris and I would like to do an Open gate array as our next project. Sufficient patents have expired, etc.
Bruce Perens.
Nope, Chris Testa!
(okay, this is actually a fine example of 'news for nerds' submissions, so kudos.)
Well, that would give me a serious EErection.
Ezekiel 23:20
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
The set of "radio amateurs who are also FOSS advocates" and who program FPGAs can probably be numbered in 2 digits, maybe 3. Each of them may buy one, maybe two, instances of the FPGA (and not all of the same part number). (I am one of them, W6RMK)
As a developer of the only open source (albeit export controlled) software radio using FPGAs that is flying in space, I'm well aware of the challenges faced by small volume customers.
http://spaceflightsystems.grc.nasa.gov/SOPO/SCO/SCaNTestbed/
I just don't see that there is significant pressure to be exerted in an industry where the sales rep asks how many thousand units per month you're thinking about for your application. Ham radio is a niche market, in an area (SDR) that is already a niche.
The other issue is that commercially available FPGAs have limited market lives. You could easily spend years developing an open source tool chain for a part that is available only on eBay as a "refurbished after removed from equipment". My radio in space uses Virtex II FPGAs, no longer sold by Xilinx, and supported by ISE 10, which is several generations behind the current tool chain (fortunately, you can still download the ISE 10 tools, and while not technically supported under the latest OS versions, they do work)
Those who are serious about learning logic design for custom integrated circuits and gate arrays should learn Verilog, or better yet SystemVerilog. Python is great and all but the logic tools are built around Verilog and VHDL and require static typing. Once one knows Verilog and VHDL, then Python, Perl, etc. can be used to dynamically abstract and stamp out repetitive stuff better than the native HDL languages.
This sounds like an interesting project, but my personal experience has been that VHDL is a pretty simple language to learn. I remember during my undergrad bashing out code for a fifo buffered UART in less than a day with no prior knowledge of the stuff. As far as I can tell, the real issues with FPGA development are when you get up against the performance limits of the logic, and have to start thinking about across chip skew, jitter effects on high speed asynchronous inputs, and efficiently utilising specialised macro-blocks etc etc.
The actual logic coding side of things seemed pretty straightforward.
To all those who equate MyHDL with "procedural input", just because it is pure Python, please hold your horses for a minute.
HDLs like Verilog and VHDL have both procedural and concurrent semantics. The concurrent part is very specific: fine-grained, massive, but tightly controlled through event-driven semantics. The only thing necessary to emulate that in Python are generators (functions with state), which is a pure Python concept , and an event-driven scheduler (implemented in a Simulation object).
As a result, the semantics of MyHDL, in particular its concurrent semantics, are basically identical to Verilog and VHDL semantics.
One well-known market would be immediately available and very eager to embrace an open FPGA, namely EE education.
Educating future electronics engineers in programmable logic techniques is difficult and unsatisfactory today because part of the process is deliberately hidden and the tools are closed and proprietary. Below the level of HDL, that education is being hindered and in reality is being replaced by company-specific vocational training. This is widely recognized as inadequate for students, unbalanced for industry, and contrary to the goals of education.
This bad situation is made even worse by some pragmatic issues. Every company's SDK is huge and entirely different, so it's not possible to create company-agnostic course materials, and having all the SDKs installed doesn't make educational sense even if it were logistically feasible. On top of that, every company imposes licensing hurdles, and their SDKs are not portable so we cannot run them where we might wish.
These many problems combine into a very difficult situation for EE education. I have not the slightest doubt that an open FPGA would be welcomed with open arms in virtually every college and university involved in electronics engineering, worldwide.
Hey Jan, thanks for making MyHDL :D
As a regular developer-type geek who's never done anything with radio, can somebody tell me what this does and why it is interesting? I don't want to watch an hour of video to try to figure that out.
(Please don't take that as snark - I'm truly curious.)