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
ULX3S: Hackable FPGA that runs Linux on RISC-V
61–70 of 85 posts
Re: ULX3S: Hackable FPGA that runs Linux on RISC-V
#62Is 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
#63Earlier 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…
Re: ULX3S: Hackable FPGA that runs Linux on RISC-V
#64Is 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…
Re: ULX3S: Hackable FPGA that runs Linux on RISC-V
#65Layman 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…
Re: ULX3S: Hackable FPGA that runs Linux on RISC-V
#66Is it any better than Artix-7 XC7A100T or XC7A35T boards from Aliexpress(search QMTECH, they sell 100K board for ~$100)?
Re: ULX3S: Hackable FPGA that runs Linux on RISC-V
#67Earlier 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.
Re: ULX3S: Hackable FPGA that runs Linux on RISC-V
#68Is 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/…
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
#69Earlier 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?
Re: ULX3S: Hackable FPGA that runs Linux on RISC-V
#70Earlier 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.
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