Live data from Hacker News

ULX3S: Hackable FPGA that runs Linux on RISC-V

ulx3s.github.io

61–70 of 85 posts

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

#61
post #41
post #25

How does it compare to the Arty A7 for $129?

The question is rather, How does it compare to the Qmtech Wukong board? And the answer is: you get way more bang for your buck with the Wukong board. No Symbiflow, though, if that's what you're after. Link to board: https://aliexpress.com/item/4000170042795.html

I think prjxray + nextpnr has support for at least some of Artix7. Checkout https://github.com/daveshah1/nextpnr-xilinx/

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

#62

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.

It has to encode 32 GPR's and three-operand instructions so instruction encoding is a bit cramped, even in 32 bits. 16-bit encodings are reserved for "compressed" special-case forms of existing 32-bit instructions.

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

#63
post #20
post #5

Earlier quoted context omitted.

People do talk about “dropping” an album to indicate it’s being released. Your confusion is somewhat understandable. English is hard. :(

similarly, dropping off supplies or deliveries -- maybe where they are dropped from a great height via parachute out of a plane. Or dropped off by a delivery truck. "Lattice drops recent EULA clause" would be easier to interpret if the initial and final altitude of the clause was specified. If the initial altitude was unusually high, it might indicate that the clause was being introduced via parachute. If the initial…

Haha, that made me laugh out loud. "Lattice drops recent EULA clause from 1.5 meter height".

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

#64
post #44

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/…

Being "simple" for a C program to decode is not the point; generating the smallest hardware to decode instructions and to reduce the critical path for things like deducing the instruction operands are. For example, the operands all stay in the same position, which prevents putting decode on the critical path before you can figure out which registers you need to read (which is doubly important for superscalar designs…

Exactly this. We had a hardware design where the difference between a load and store was a single bit, we also had a register file that wasn't afraid of bit flips, and part of the decode was on the critical path so it wasn't sufficiently parity protected. You can imagine what happened and how fun that was to debug.

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

#65
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…

The Unix platform spec group is working on this. Meetings every month. https://lists.riscv.org/g/tech-unixplatformspec You have to join up as an individual membership, which is free for open source software developers.

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

#67

Earlier quoted context omitted.

A developer of Symbiflow toolchain once described Lattice Semi as very friendly and cooperative towards them [1]. I was wondering why they suddenly changed their attitude. It may have been a clause that they introduced without giving much thought. Happy to see that at least one vendor has the right idea about tooling. [1] https://youtu.be/0se7kNes3EU?t=1367

Hackaday comments were hypothesizing that they outsource tool development to some other company.

Why would they change an EULA clause for that?

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

#68

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/…

> Is there any published rationale for the RISC-V instruction encoding?

Computer Organization and Design, RISC-V edition, goes into these. R-types have opcode = 0b0110011, SB (branch) types have opcode = 0b1100011, etc.

The lower bits also have extra meanings (16 bit, 48 bit, etc. instruction).

This allows hardware to just branch on these bits in sub-groups. The hardware pipeline for 16 bit is different than that of 48 bit, and the 48-bit is probably even optional.

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

#69
post #67

Earlier quoted context omitted.

Hackaday comments were hypothesizing that they outsource tool development to some other company.

Why would they change an EULA clause for that?

To signal potential open source contributors that there is no danger of being sued for their work. Too many vendors have used the fact or even just the accusation of reverse-engineering or other non-EULA-compliant behaviour to suppress OSS.

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

#70
post #60

Earlier quoted context omitted.

Oh wow, I had no idea they were that advanced. How much do these go for secondhand?

There is no sensible secondhand market for things like this; it will be embedded in someone's board. And there aren't many about to start with. Sometimes people are lucky enough to find decent FPGAs in scrap, but it's like panning for gold.

(De)soldering FPGAs is also very intricate, very high number of pins, high pin density make for a high error rate and low to no chance of simple rework. Also, the need for boards with a lot of layers to get that high pin count and density out from under the chip.

It is easier, faster and cheaper to start from one of the available devel boards and maybe even use them as production components for small batches

Post reply on HN