I initially misunderstood this headline to mean the opposite: I took "drops" to mean "introduces", which is the opposite of the intended meaning -- "withdraws". Not sure where I got this non-mainstream meaning of "to drop".
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 altitude was comparable to the altitude of an object being held in a person's hands, and the final altitude ground level, this would suggest the clause being discarded or removed.
It's what most hip clothing brands do to launch merch. Look at Supreme as an early example. Artificially limited stock, released like Black Friday. Scarcity ups the coolness and bragging factor. It's somewhat odd though many times - take
Supreme example - the retail costs don't actually match the demand (they could charge higher) not supply side and a large re-sale market opens (even stockx.com a real market with order book)
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.
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.
I don't see a connection to "outsource tool development to some other company".
If I commission some work from another company, this company doesn't receive, modify or extend my software under the standard EULA. They do so under our contract.
The ULX3S is great! I built myself an early prototype a year ago, and have used it every so often for occasional hacks. It has since evolved to be a first-class citizen in a number of projects and frameworks (LiteX, including LiteDRAM), which makes it great to get started with.
Also worth noting, that you can use a fully open source flow (Yoys + nextpnr + prjtrellis) for this FPGA family. Here's a repository I made that shows a basic blinky for an ULX3S: https://github.com/q3k/ulx3s-foss-blinky/
Yeah I also DIY'd one and it makes an excellent dev kit - the right combo of peripherals in a small footprint. It also has a lot of IO's on normal 0.1" headers so it's a good starting point if you want to stack it on top of another prototype PCB. Your blinky was actually the first code I ran on it.
It is the fully open design flow that I really enjoy. I have a couple of IceBreakers[1] which have a smaller Lattice part and they are quite capable. I find the addition of the ESP32 compelling as an interesting "hard" processor.
Desktops, perhaps never - 10 years? Alibaba seem to be funding some R&D in this direction, but I'm not too familiar (and I can't speak Chinese). It's certainly possible, but desktop processors aren't simple in any way. Regardless of absolute technical excellence, RISC-V only has to be better than ARM (in both specification and implementation, and cost, of course) which will be a moving target as RISC-V improves.
Single Board Computers - https://www.sifive.com/boards/hifive-unleashed this seems to fit the bill. However, they don't seem to be selling those yet - the development kit for that particular CPU seems to be an FPGA soft-core.
I am currently working on an open-hardware project that requires a fair amount of grunt (or FPGA); in an effort to keep is open I was looking into RISC-V processor's. You can actually buy RISC-V hardware today as a guy on the street (i.e. Digikey etc.) but the offerings I could find were generally fast microcontrollers rather than general purpose processors.
If RISC-V is to be adopted it's probably more of a question of engineering knowledge and training than solely hardware: One of the chips I found in my search above is an interesting Chinese system on module that has a RISC-V at 400MHz, Wi-Fi, and a hardware NN coprocessor - it's a cool chip but even in Chinese the documentation is unusable and awful.
If a big western company like ST or Cypress etc. picks up RISC-V and starts making it easy and safe to actually use (for example, the section of the manual for the serial peripherals on most NXP microcontrollers is longer than all the documentation I could find for the aforementioned SoM).
> for example, the section of the manual for the serial peripherals on most NXP microcontrollers is longer than all the documentation I could find for the aforementioned SoM
In Chinese though? Or did you compare long English to short Chinese?
Because, I don't speak (or read) it either, but compared to English it's extremely information sense: its characters are closer to whole words than to Latin letters. In fact if you think of it also being like German, with Longerwordbuiltfromothers, they are, and L... would be just a few characters at most.
Not that that makes Chinese documentation any more helpful to us non-speakers, though.
> In Chinese though? Or did you compare long English to short Chinese?
I did some google translate-ing and had some help from my token Chinese friend. I might have missed it but the document had the same structure in English and Chinese. In short, you could probably work it out by reading the rtos they distribute for you to use and there is a little documentation of the actual peripherals but it is absolutely bare bones. And that's (what we would call) application notes, the actual datasheet is pretty much just some marketing BS and a PCB footprint (not that they actually provide any symbols - sometimes even the big chip makers don't bother which is quite annoying if you're stuck using anything other than Altium)
The HiFive Unleashed was released (and for sale) back in 2018. From memory, there was a limited run (priced at US$1k each), as it was targeted to specific types of developers looking to do further work improving the platform.
For example, Red Hat bought some and used them for improving the RISC-V support in Fedora. From memory, Richard Jones (@rwmj here on HN) was involved with it.
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 specifications are not too far away. I imagine it will still take firmware developers a long time to create motherboards that fit the spec, considering they are starting from scratch. Here is a recent presentation about the state of booting RISC-V[1].
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?
Quite possibly; I only intended to comment on booting/firmware issues. It depends on your goal, too; I'd be quite happy to see RISC-V servers (headless) and desktops (separate video card). Basically, give me a 100% libre SoC/CPU+motherboard and I'm personally happy to worry about the rest later. Also depending on your specific goals and ideology, there's no reason you couldn't make a RISC-PI that just licensed a proprietary video core; that'd still make you more open-source than today's Pi, which has a proprietary CPU and GPU.
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.
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?)
The Hub75 boards are great, but aren't really comparable to the ulx3s as they have extremely limited I/O options (a whole ton of output-only TTL level shifters, + 2 gigabit interfaces). Great if your project fits into those constraints, but few projects do. Plus they are only available with 25F size parts whereas the ulx3s is available with a 85F part.
(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
I've recently bought second-hand Xilinx FPGAs on Ebay for $250 each with list price of $3500. They come on boards that have an unidentified manufacturing fault. Salvaging and reusing the chips seems realistic using a budget vapor phase soldering setup (not attempted yet) but the challenge for me is designing or otherwise acquiring suitable PCBs to put them onto. I'm told that you can potentially find suitable PCBs on Aliexpress but I haven't looked into this in detail yet.
In other words, there doesn't seem to be much demand in the secondhand market, and you can potentially use that in your favor to take advantage of supply selling at steep discounts.
I handle most of pull requests and issue tracking on the chubby75 project: it's a great FPGA board for experimenting, but only if you need to drive a lot of IOs and don't have any GPIO input requirements.
A replacement for the general purpose ULX3S it is not.
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")
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 :/
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
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.
- The bit patterns allocated to the simplest instructions
(eg. rv32i) seem random. Why not allocate starting from zero
to allow dense jump tables?
- I can't make any sense of the groupings. A bunch of instructions
have 0b1100011 in the lowest bits, do these instructions have
something in common?
I assume there is some rhyme and reason to all this? Where is this explained?
I'm not sure about publications that try to answer "why RISC-V?", but the specification often describes the rationales behind many of these kinds of decisions.
The bit patterns are often designed to make it easier to write efficient hardware designs to implement them. For example, if an instruction encodes an "immediate" value, the most significant bit of the instruction will always hold that value's sign-extension bit. And if you compare the immediate values in I-/S-/B-/J-type instructions, you can see that bits [5:10] are always in the same place. It's not exactly intuitive, but there is some rhyme and reason.
In the base instruction set, the 0b1100011 opcode encodes a set of conditional branch instructions. They perform relative jumps if rs1 == rs2, or if rs1 < rs2, etc.
Also, to the specific "0b1100011 in the lowest bits" question, page 8 of the spec shows that, for an instruction to be 32 bits, the lowest two bits must be 11 (non-11 is used for 16-bit) and the next three bits must not all be 111 (111 is used for 48-bit and larger instructions).
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.
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".
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.
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 which need to compute the register dependence graph). Likewise, the sign-extend bit for immediates is always in the same place, providing relief for another potential critical path.
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.
> 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.
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.
There is this mystical unit LUT, every manufacturer defines it a bit differently, but it’s ok to use it for comparison. Arty A7 has 35k of them, the cheapest board has 12k. Arty A7 is clear winner here. I think, Digilent has another cheaper Artix 7 board with 35k LUTs.
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.
“Open hardware tax” is huge here, your impression is correct. Real 800MHz Dual-core ARM Cortex-A9 processor is on Terasic board while this has a soft core processor. In my experience soft core can run at ~200 MHz best case. Then comes slower RAM and this limits overall possible applications. Unless somebody wants RISC-V badly.
And DOS, NES, Amiga, Apple I, Apple II, Z80 !
I am new to FPGAs so it is a bit difficult to know what to expect from a given number of LUTs, but you can compare between models: the big version of ECP5 in ULX3S has 85k LUTs while the previous well open-source supported FPGA (iCE40) had only up to 7.7 k LUTs, so more than a 10x jump :)
84 comments
[ 2.6 ms ] story [ 160 ms ] thread"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 altitude was comparable to the altitude of an object being held in a person's hands, and the final altitude ground level, this would suggest the clause being discarded or removed.
https://en.m.wikipedia.org/wiki/Auto-antonym
But of course it would be even better if they would just publish the documentation.
[1] https://youtu.be/0se7kNes3EU?t=1367
I don't see a connection to "outsource tool development to some other company".
If I commission some work from another company, this company doesn't receive, modify or extend my software under the standard EULA. They do so under our contract.
https://news.ycombinator.com/item?id=23440907
Also worth noting, that you can use a fully open source flow (Yoys + nextpnr + prjtrellis) for this FPGA family. Here's a repository I made that shows a basic blinky for an ULX3S: https://github.com/q3k/ulx3s-foss-blinky/
Single Board Computers - https://www.sifive.com/boards/hifive-unleashed this seems to fit the bill. However, they don't seem to be selling those yet - the development kit for that particular CPU seems to be an FPGA soft-core.
I am currently working on an open-hardware project that requires a fair amount of grunt (or FPGA); in an effort to keep is open I was looking into RISC-V processor's. You can actually buy RISC-V hardware today as a guy on the street (i.e. Digikey etc.) but the offerings I could find were generally fast microcontrollers rather than general purpose processors.
If RISC-V is to be adopted it's probably more of a question of engineering knowledge and training than solely hardware: One of the chips I found in my search above is an interesting Chinese system on module that has a RISC-V at 400MHz, Wi-Fi, and a hardware NN coprocessor - it's a cool chip but even in Chinese the documentation is unusable and awful.
If a big western company like ST or Cypress etc. picks up RISC-V and starts making it easy and safe to actually use (for example, the section of the manual for the serial peripherals on most NXP microcontrollers is longer than all the documentation I could find for the aforementioned SoM).
In Chinese though? Or did you compare long English to short Chinese?
Because, I don't speak (or read) it either, but compared to English it's extremely information sense: its characters are closer to whole words than to Latin letters. In fact if you think of it also being like German, with Longerwordbuiltfromothers, they are, and L... would be just a few characters at most.
Not that that makes Chinese documentation any more helpful to us non-speakers, though.
I did some google translate-ing and had some help from my token Chinese friend. I might have missed it but the document had the same structure in English and Chinese. In short, you could probably work it out by reading the rtos they distribute for you to use and there is a little documentation of the actual peripherals but it is absolutely bare bones. And that's (what we would call) application notes, the actual datasheet is pretty much just some marketing BS and a PCB footprint (not that they actually provide any symbols - sometimes even the big chip makers don't bother which is quite annoying if you're stuck using anything other than Altium)
The HiFive Unleashed was released (and for sale) back in 2018. From memory, there was a limited run (priced at US$1k each), as it was targeted to specific types of developers looking to do further work improving the platform.
For example, Red Hat bought some and used them for improving the RISC-V support in Fedora. From memory, Richard Jones (@rwmj here on HN) was involved with it.
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 specifications are not too far away. I imagine it will still take firmware developers a long time to create motherboards that fit the spec, considering they are starting from scratch. Here is a recent presentation about the state of booting RISC-V[1].
[1]https://content.riscv.org/wp-content/uploads/2019/12/Summit_...
(Please, instead of downvoting me, just correct me?)
https://github.com/MiSTer-devel/Main_MiSTer/wiki
https://www.retrorgb.com/mister.html
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
In other words, there doesn't seem to be much demand in the secondhand market, and you can potentially use that in your favor to take advantage of supply selling at steep discounts.
A replacement for the general purpose ULX3S it is not.
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")
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 :/
Edit: After a lot of back and forth, perhaps this is a good intro: https://hackaday.com/2019/01/14/ulx3s-an-open-source-lattice...
$150
Just placed an order : https://www.crowdsupply.com/radiona/ulx3s
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/master/src/commo...
In particular:
I assume there is some rhyme and reason to all this? Where is this explained?The bit patterns are often designed to make it easier to write efficient hardware designs to implement them. For example, if an instruction encodes an "immediate" value, the most significant bit of the instruction will always hold that value's sign-extension bit. And if you compare the immediate values in I-/S-/B-/J-type instructions, you can see that bits [5:10] are always in the same place. It's not exactly intuitive, but there is some rhyme and reason.
In the base instruction set, the 0b1100011 opcode encodes a set of conditional branch instructions. They perform relative jumps if rs1 == rs2, or if rs1 < rs2, etc.
https://riscv.org/specifications/isa-spec-pdf/
Take a look at the "RV32/64G Instruction Set Listings" table to get a feel for the encodings.
Compressed was an afterthought on Risc-V. A well thought out afterthought, but you do things differently when you know in advance.
What, they are absolutely relevant in hardware and selected to optimize the resulting generated hardware.
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 which need to compute the register dependence graph). Likewise, the sign-extend bit for immediates is always in the same place, providing relief for another potential critical path.
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.
To see what I mean, have a gander at this:
https://github.com/ulx3s/apple2fpga/blob/master/cpu6502.vhd
Link to board: https://aliexpress.com/item/4000170042795.html
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.