Live data from Hacker News

ULX3S: Hackable FPGA that runs Linux on RISC-V

ulx3s.github.io

31–40 of 85 posts

Re: ULX3S: Hackable FPGA that runs Linux on RISC-V

#31

Is there any published rationale for the RISC-V instruction encoding? A few months back I set out to write a software emulator of RISC-V for fun. I expected the instruction set encoding to lend itself well to a very simple implementation, eg. something you could decode in 5-10 lines of C plus some tables. But the instruction encoding is much more irregular than I expected: https://github.com/ucb-bar/riscv-sodor/blob/…

I spent some time defining an alternate encoding of the base instruction set. I dont think they did a good job, but it's also not easy to do better. I started from an assumption of variable length - 16 bit or 32 bit opcodes plus immediate data in 16 bit chunks. It's not easy. Remember all those strange bit positions are irrelevant in hardware. But they are a bitch for things like linkers.

Re: ULX3S: Hackable FPGA that runs Linux on RISC-V

#32
post #30

Layman question: how many years before we get RISC-V desktops or Raspberry Pi like computers?

Others have pointed out economic problems with producing hardware, which is fair, but another big issue is standardization. There is no RISC-V equivalent of BIOS / UEFI, multiboot, etc. We take it for granted that all motherboards and all bootable drives 'just work'. That kind of consistency is important for consumer desktop PCs (less so for rasberry-pi type machines). This is being worked on, and I think a stable sp…

We have open-source UEFI and openfirmware implementations already; is it really any more complicated then porting one and populating what I understand to be fairly standard interfaces for exposing device information to the operating system? Like... I'm sure it's not actually that easy, but what's the hard part once you've got working code execution from anyting resembling a normal compile chain?

Re: ULX3S: Hackable FPGA that runs Linux on RISC-V

#33

very impressive project, its a good time to get into fpga projects

It's much better than before, but it's still surprisingly difficult to buy a cheap (good) FPGA board. For example, the cheapest ECP5 on digikey (FPGA's go for a lot less than list if you're buying more than a few) is about $10 yet the cheapest proper development board is a lot more.

The FPGA manufacturers like the margins, fine, but I'm surprised people who make boards like this one but for other things don't just chuck an FPGA on them (for some definition of "just")

Re: ULX3S: Hackable FPGA that runs Linux on RISC-V

#35
post #33

very impressive project, its a good time to get into fpga projects

It's much better than before, but it's still surprisingly difficult to buy a cheap (good) FPGA board. For example, the cheapest ECP5 on digikey (FPGA's go for a lot less than list if you're buying more than a few) is about $10 yet the cheapest proper development board is a lot more. The FPGA manufacturers like the margins, fine, but I'm surprised people who make boards like this one but for other things don't just ch…

Yeah, ~$45 dollars min for ice40LP on digikey: https://www.digikey.com/products/en/development-boards-kits-...

But I have no idea how proper it is, only ~10x the cost of the FGPA itself. I'm still interested in it though, kind of want to buy it now but to lazy to figure out how to buy it from where I am now in indonesia and imports are a PITA here :/

Re: ULX3S: Hackable FPGA that runs Linux on RISC-V

#36
post #7

2x more resources compared to $30 https://github.com/q3k/chubby75 at 5x the price

What is your pick for the best FPGA for the money or if money is no object? I just don’t know much about this area outside the MiSTer project. https://github.com/MiSTer-devel/Main_MiSTer/wiki https://www.retrorgb.com/mister.html

Intel Stratix 10

Re: ULX3S: Hackable FPGA that runs Linux on RISC-V

#37

Layman question: how many years before we get RISC-V desktops or Raspberry Pi like computers?

If I understood it correctly, that seemed to be the original goal of the lowrisc project, but it seems like it changed direction or it's just too much work. The founder I believe was involved in RPi.

(Please, instead of downvoting me, just correct me?)

Re: ULX3S: Hackable FPGA that runs Linux on RISC-V

#38
post #30

Earlier quoted context omitted.

Others have pointed out economic problems with producing hardware, which is fair, but another big issue is standardization. There is no RISC-V equivalent of BIOS / UEFI, multiboot, etc. We take it for granted that all motherboards and all bootable drives 'just work'. That kind of consistency is important for consumer desktop PCs (less so for rasberry-pi type machines). This is being worked on, and I think a stable sp…

We have open-source UEFI and openfirmware implementations already; is it really any more complicated then porting one and populating what I understand to be fairly standard interfaces for exposing device information to the operating system? Like... I'm sure it's not actually that easy, but what's the hard part once you've got working code execution from anyting resembling a normal compile chain?

I suspect GPU / display controller and associated licensing and patents are an even bigger obstacle.

Re: ULX3S: Hackable FPGA that runs Linux on RISC-V

#39

Earlier quoted context omitted.

What is your pick for the best FPGA for the money or if money is no object? I just don’t know much about this area outside the MiSTer project. https://github.com/MiSTer-devel/Main_MiSTer/wiki https://www.retrorgb.com/mister.html

Intel Stratix 10

Can you say more about why this one is the one? Is it better in quantitative ways or ease of use than competitors? Cheaper or more reliable? Etc

Re: ULX3S: Hackable FPGA that runs Linux on RISC-V

#40
Can anyone comment on how this compares to the popular Terasic DE10-Nano used for the MiSTer project? The price point is around the same and I see they note running video game cores as a market for this device, but I have absolutely no clue how to reasonably compare FPGAs.

From my rudimentary understanding it looks like this doesn't have a hard CPU and has a smaller FPGA, so I'm guessing we have a fair bit of "open hardware tax" at play here too.

Post reply on HN