Live data from Hacker News

ULX3S: Hackable FPGA that runs Linux on RISC-V

ulx3s.github.io

81–85 of 85 posts

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

#81
post #42
post #33

Earlier quoted context omitted.

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…

Qmtech on Aliexpress have the best price/performance when it comes to FPGA boards.

Prob not bad for some applications, but if you are trying to have cost of a overall system low in order to make it more available to more people… id rather go with the ice40LP's

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

#82

Earlier quoted context omitted.

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.

>Remember all those strange bit positions are irrelevant in hardware. What, they are absolutely relevant in hardware and selected to optimize the resulting generated hardware.

I was super unclear there. The strange routing is largely irrelevant. In software it's a pain to do all that reshuffling, in hardware it's just wires from here to there.

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

#83

Earlier quoted context omitted.

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.

Right, so I made 16bit opcodes only have 4 bits for register indexes. 32bit ones would provide the 5th bit for each register. That means a compiler should prefer the first 16 registers in order to reduce code size, but they are all still available. It also meant a reduced size chip with half the registers would not need different instruction encodings.

Compressed was an afterthought on Risc-V. A well thought out afterthought, but you do things differently when you know in advance.

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

#84

Earlier quoted context omitted.

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.

Right, so I made 16bit opcodes only have 4 bits for register indexes. 32bit ones would provide the 5th bit for each register. That means a compiler should prefer the first 16 registers in order to reduce code size, but they are all still available. It also meant a reduced size chip with half the registers would not need different instruction encodings. Compressed was an afterthought on Risc-V. A well thought out afte…

Compressed was very explicitly made optional so that implementers would have the choice of recycling that encoding space for something else. It was not just an "afterthought".

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

#85

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

The ISA was likely designed for efficient implementation in Silicon rather than being easy to grok by a human.

To see what I mean, have a gander at this:

https://github.com/ulx3s/apple2fpga/blob/master/cpu6502.vhd

Post reply on HN