I finally have a RISC-V based single board computer (SBC) – the Nezha from RV Boards shipped to me directly from China.
It’s tiny (about the same form-factor as a Raspberry Pi though) and relatively expensive (it cost me just over £100 to order and get it shipped here) but whilst I was slightly concerned I was being a bit naïve in buying it (as it was either a scam or it wouldn’t work), it boots (slowly) into Linux (see image) and works (slowly).
Can RISC-V cores (which are ‘open source hardware’ and free from licensing fees) break ARM’s grip on SBCs and similar devices? A year ago the answer looked like a very clear negative as, despite years of hype, RISC-V designs just weren’t moving off the page and into silicon. Now it looks much more uncertain as the Nezha is actually the second RISC-V SBC to ship (the other, the Beagle-V, has only been distributed to a select group of developers so far – and this didn’t include me despite my application – but is expected to be available globally in the autumn).
The plans are for RISC-V SBCs retailing for less than $20 inside a year and – crucially – for the RISC-V cores to feature vector extensions which could mean some interesting use-cases being opened up.
(If you want to know more about RISC-V or if you are thinking of starting a RISC-V assembly project I cannot recommend The RISC-V Reader highly enough.)
Embed from Getty Images
If you have ever written a computer program with any degree of seriousness then you will know the feeling: your heart sinking as you realise what you thought was a perfectly good piece of code has a bug somewhere less than obvious.
In my case this has happened twice in a week and both times has meant the work I had done as part of my PhD has had to start again (not all of it, obviously, but this, most recent bit). Yesterday evening’s realisation was particularly annoying because it came after I had sent my supervisor an email suggesting I had some quite interesting and counter-intuitive results to share.
Since then I had spent quite a few hours trying to work out what on Earth was wrong – debugging assembly is not complex in the sense that most instructions do simple things – but it also reminds you of the essential state-machine-nature of a general computing device: there are lots of things to track.
Of course, that also brings pleasure – there is no point in denying that solving these problem is one of the truly engaging things about computing.
Job is done now and I am once again collecting results and hoping that I do not spot another flaw.
For the last week or so I have been writing and then debugging (and so mainly debugging) a least-recently-used (LRU) page replacement system on my Microblaze simulation.
Perhaps I shouldn’t have bothered – I had a working first-in-first-out (FIFO) system after all. But no one seriously uses FIFO, so I had to write some LRU code.
I thought I had it working tonight – it ran through the target exercise in about 6 million instructions (as the MMU in a Microblaze is crude, memory gets loaded in and out ‘by hand’ and so the instruction count measures time/efficiency) when the system had 32 4k local pages and in about 10.5 million instructions when it had 24 4k pages available locally – all seems fine: less pages means more time is required.
But then things started to get weird – testing the system with 28 pages took about 9 million instructions, but when I tried to use 26 pages I had to break the code after it had executed 14 trillion instructions.
Indeed it seems to only work for a very limited number of page counts. How odd – though a typically debuggers story. A week in, finally thinking I’d cracked it when some really strange behaviour manifests itself.
Update: It appears to be an unaligned data exeception issue. Somewhere along the line a piece of code relies on the LRU queue to be a multiple of 4 in length would be my guess…
They say of C it has all the speed of assembly programming and all the maintainability of … assembly programming. What it lacks is the basic sense of complete mastery over the machine that a successful piece of assembly delivers but, actually, it is a bit easier to maintain than assembly.
These past few weeks, for the first time in more than thirty years, I have spent a lot of time writing assembly – and for a 32 bit RISC processor, quite different from the 8 bit CISC world of the Z80, where I last did this.
Assembly gives you complete control, but it is also very frustrating – debugging iteration after debugging iteration.
How sad is it to admit, though, that I am enjoying it greatly?