[HN Gopher] 13-Year-Old, Nicholas Sharkey, Creates a RISC-V Core
___________________________________________________________________
13-Year-Old, Nicholas Sharkey, Creates a RISC-V Core
Author : EvgeniyZh
Score : 119 points
Date : 2020-11-14 14:15 UTC (8 hours ago)
(HTM) web link (riscv.org)
(TXT) w3m dump (riscv.org)
| brian_herman wrote:
| Wow I took a Computer Architecture class at UIC with Professor
| Theys and I didn't even get this far. I got some catching up to
| do!
| IshKebab wrote:
| Presumably not from scratch?
| bovermyer wrote:
| That's really impressive. I'm 38 and I'm not sure I can compare
| to his dedication and focus.
| abdullahkhalids wrote:
| The workshop is happening again early December
|
| https://www.vlsisystemdesign.com/riscv-based-myth/
|
| Github is here https://github.com/kuby1412/RISC-V-MYTH-Workshop
| ninjha wrote:
| Also, the course materials for CS61C at Berkeley
| (https://cs61c.org/) are publicly available if you want an
| intro to RISC-V/Verilog.
|
| Lecture videos for the current semester are no longer public
| thanks to some lawsuit, but you can find videos from previous
| semesters on YouTube.
| blkknightarms wrote:
| As a computer architecture learning process, I suggest building a
| microprogrammed, single-cycle processor using digital building
| blocks without an HDL and without library blocks. Then, refactor
| it to be pipelined (which demands branch stall logic). Next, add
| branch prediction. Then, refactor in an HDL. Finally,
| superscalar, VLIW, and/or unified scheduler.
|
| Choosing MICMAC or MMIX would be good macrolanguage target to
| start with. Remember, the microprogramming ops can be much
| simpler and VLIW-style.
|
| The microprogram will be a ROM block that runs the decoding and
| execution of the actual processor's ISA. It's helpful to write a
| microprogram assembly language and compiler to make maintenance
| easier.
| musicale wrote:
| Hey, that sounds.... just like a typical computer architecture
| course. ;-)
|
| disclosure: I love computer architecture courses, and I highly
| recommend them.
|
| edit: I also think you can skip the microprogramming, but I
| think I understand what you are getting at, which is that you
| do a multi-cycle implementation first and then a pipelined
| implementation.
| [deleted]
| GeorgeTirebiter wrote:
| Seems to me starting with microprogramming adds complexity that
| doesn't necessarily make sense for a risc instruction set?
| Heck, this guy does a Verilog Z-80 without microprogramming.
| https://dl.acm.org/doi/book/10.5555/3199987
|
| While true the microprogramming ops are much simpler, the
| inherent parallelism means writing that stuff and getting it
| correct is usually challenging.
| musicale wrote:
| I think the "microprogramming" bit can/should simply be a
| multi-cycle, non-pipelined implementation.
|
| Non-pipelined is easier to write and debug, especially if you
| are used to regular sequential programming; once you have
| that working then it isn't too hard to turn it into a
| pipelined implementation.
|
| A basic RISC style design is probably easier than a Z-80
| because of the simpler addressing modes and the simpler
| decode.
| klelatti wrote:
| Any recommendations for tools / environment to do this?
| jacquesm wrote:
| Go wild:
|
| https://store.digilentinc.com/fpga-development-boards-
| kits-f...
| klelatti wrote:
| Thank you!
| jacquesm wrote:
| You're welcome. I have one of those (a bit older though),
| and every now and then I play around with it for a bit to
| keep my skills alive, it's super impressive what you can
| do with hardware this flexible. Get something with as
| much IO as you can find/afford.
| jsjohnst wrote:
| Anyone taken this workshop? Seems interesting, but I'd like to
| hear thoughts from someone who's done it and is an experienced
| software engineer.
| burade wrote:
| Did he? Because most of these stories turn out to be "It was
| really his parents who did most of the work"
| raphlinus wrote:
| Not all the time, and I personally don't consider it nice that
| you would assume that. There are indications in the story that
| the organizers know something about the full story, and I doubt
| they would actively perpetuate a fraud.
|
| For reference, I started programming when I was 6, did a little
| hardware design (easy stuff, interfacing DACs and RAM chips to
| 8 bit CPUs), wrote an assembler at 9, got a patent when I was
| 12, etc. My dad did a lot to inspire me and provide me with
| resources, and had some knowledge of electrical stuff (he had
| been an electrician in the Navy in WW2), but all the
| programming I did was very much mine. So it's not hard at all
| for me to believe that this young man completed a training
| course intended to get people up to speed on this technology.
| NicoJuicy wrote:
| It's voluntary, no reasons for the parents to be involved.
|
| Also, his parents weren't in the zoom call?
| iancmceachern wrote:
| Thank you Steve for showing up for him.
| baybal2 wrote:
| Quite impressive, I once though "building SoCs is no more hard
| than Lego these days," building an actual core from scratch with
| HDL is a wholly different level of involvement.
| [deleted]
| blkknightarms wrote:
| Yes, it's LEGO for anyone with domain knowledge bias.
|
| I would go one further: building a functional, prototype core
| vs. a marketable core are entirely different beasts given the
| litany of testing and customer considerations. It's difficult
| to say what exactly this kid did since the article is light on
| detail; it could be an achievement.
|
| It's quite trivial to build a simple processor in HDL (.v or
| .vhdl) because the compiler synthesizes the actual digital
| logic for you. It's not much different than C or a functional
| language like Haskell or OCaml, but with considerations of
| timing and don't cares/high impedance.
|
| PS: s/no more hard/no more difficult/ because "more hard" is
| always improper when "harder" exists.
___________________________________________________________________
(page generated 2020-11-14 23:01 UTC)