Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open source RISC-V implemented from scratch in one night

github.com

Post reply on HN
Print view View original

101–110 of 114 posts

Re: Open source RISC-V implemented from scratch in one night

#101

Post by samsoniuk »

amelius wrote: post #55

> works up to 75MHz How much would this increase if it used an ASIC instead of FPGA? And how much would it cost for different batch-sizes?

I am not sure is recommendable integrate this design in a ASIC because is not so stable yet, but the synthesis tool pointed 133MHz in a Xilinx Artix-7 FPGA, running at 1 clock/instruction. A more pipelined and stable RISC-V design, such as the VexRisc, can easily reach 346MHz in the same FPGA and uses less logic, but with only 0.5 instructions per clock. A performance optimized VexRisc runs at 183MHz in the same FPGA with impressive 1.44 instructions per clock, but uses more logic. There are lots of RISC-V implementations, each one with different features.

Re: Open source RISC-V implemented from scratch in one night

#102

Post by samsoniuk »

Symmetry wrote: post #65
amelius wrote: post #55

> works up to 75MHz How much would this increase if it used an ASIC instead of FPGA? And how much would it cost for different batch-sizes?

Quite a bit in theory but memory latency wouldn't decrease so there would have to be some added complexity in interfacing with it.

Well, I tested three different configurations for memory:

darkriscv@75MHz cache=off 0-wait-states 2-stage pipeline 2-phase clock: 6.40us

darkriscv@75MHz cache=on 3-wait-states 3-stage pipeline 1-phase clock: 9.37us

darkriscv@50MHz cache=on 3-wait-states 2-stage pipeline 2-phase clock: 13.84us

The first configuration works in a zero wait-state environment with separate instruction and data high speed synchronous memories working in a different clock phase (weeeeeird!). As long there are no latency, this configuration works at 75MIPS with a 2-stage pipeline, which means only one clock is lost when the pipeline is flushed by a branch.

The second configuration uses a small hi-speed cache with 256 bytes for instruction and 256 bytes for data, a 3-stage pipeline, which means two clocks are lost when the pipeline is flushed by a branch and a more convencional single phase clock architecture, as well a memory with 3 wait states or something like this. Although working at 75MIPS, the cache miss and the longer pipeline decrease the performance to around 51MIPS.

The third configuration is the core configuration from the first scenario, but with the small hi-speed cache from the second scenario and the 3 wait states. In this configuration, the performance decreased to 50MHz and, according to my calculations, the performance is around 34MIPS.

By this way, if is possible work only with the interna FPGA memory, the first configuration is better, otherwise you can use the second configuration.

I guess is possible create a fourth configuration with the 3-stage pipeline and zero wait-states (no cache), but I need implement a two-clock load instruction. In this case, I guess is possible peak around 100MHz.

Re: Open source RISC-V implemented from scratch in one night

#103

Post by waterhouse »

Annatar wrote: post #88
waterhouse wrote: post #59

Earlier quoted context omitted.

Indeed, in RISC-V, full 32-bit constants must be broken across two instructions. The translation goes: ; 1. lea MemoryAddress(pc), a0 auipc a0, [upper 20 bits of (MemoryAddress - label)] addi a0, a0, [lower 12 bits of (MemoryAddress - label)] label: ; 2. move.l #$00bfe001, a1 lui a1, 0x00bfe000 addi a1, a1, 0x001 ; 3. rts jalr x0, x1, 0 It is cumbersome in that sense. But it will probably be handled by an assembler (…

"Indeed, in RISC-V, full 32-bit constants must be broken across two instructions." Any RISC processor has that issue, because encoding is fixed at 32-bits to keep the hardware simple. That's not what I'm referring to. Look at that retardation, "auipc". Because "auipc" is intuitive, right? (For the record, I'm being sarcastic.) What the hell was the instruction designer smoking? Then there is the square bracket notati…

All right, I count myself disappointed. Surely you know that "processors" don't use parentheses; the parentheses and brackets are in assembler syntax, which is long gone by the time the processor is executing byte sequences. There is nothing inherent about Intel-style syntax in physical RISC-V processors; nor in Intel processors, for that matter, as demonstrated by the fact that gcc outputs its x86-64 assembly in AT&T syntax by default. The fact that Intel syntax appears in the RISC-V spec might, at the very worst, demonstrate that the creators have bad taste in that area. If that taste has led to bad decisions elsewhere, it would be more substantive to point out those bad decisions. If not, you can configure your toolchain to use AT&T syntax and take pride in your superiority.

Bad names are harder to work around. However, about those names: "auipc" is certainly letter salad, but (a) it stands for "Add Upper Immediate to Program Counter", and its effect is to add an immediate value (multiplied by 2^12) to the program counter and put the result in a register, so the name is entirely logical given its task; and (b) except in the rare case where the PC-relative offset is exactly a multiple of 2^12, an AUIPC will be immediately followed by an add (to load a full PC-relative address), or perhaps a load-with-offset (to load a value at a full PC-relative address), or a jump-with-offset (to jump to a label at a full PC-relative address); and all three of these AUIPC+(add|load|jump) combinations are given as pseudoinstructions as well (e.g. "la" for "load address"), so the programmer will probably never need to write a bare "auipc". As for "jalr", well, it stands for "jump and link register", which jumps to the "register" argument and stores the return address in the "link" argument. There's a set of pseudo-instructions based off x0 being the "always-zero" register and x1 being the conventional "return address" register:

  Pseudo      Real            Description
  j offset    jal x0, offset  Jump 
  jal offset  jal x1, offset  Jump and link
  jr rs       jalr x0, rs, 0  Jump register
  jalr rs     jalr x1, rs, 0  Jump and link register
  ret         jalr x0, x1, 0  Return from subroutine
Seems logical enough to me. You can just use "jal offset" and "ret" if you prefer.

Anyway, if your goal was to convince me there are serious flaws in RISC-V, then criticizing the naming conventions and surface syntax has led me away from the hypothesis that you know any.

Re: Open source RISC-V implemented from scratch in one night

#104

Post by samsoniuk »

tomhoward wrote: post #47
sergioisidoro wrote: post #42

/rant "after one week of exciting sleepless nights of work (which explains the lots of typos you will found ahead), the darkriscv reached a very good quality result" Not commenting on the actual quality of the code, but I wonder how can one make typos due to sleep deprivation, and yet produce "good quality results" in software. I wonder when will we, as a community, stop praising all nighters and rushed work.

There's a big difference between doing short bursts of work with little sleep - particularly when you're young - vs doing it constantly for months/years. In this case it just seems to indicate enthusiasm for the project rather than dangerous overwork.

in fact: 50% enthusiasm for the project, 50% dangerous overwork! hehehe

Re: Open source RISC-V implemented from scratch in one night

#105

Post by samsoniuk »

Annatar wrote: post #30

"The main motivation for the darkriscv is create a migration path for some projects around the 680x0/coldfire family." On the Amiga we don't need a replacement for MC680## processors because we have the Vampire 2+ accelerator, which gives us a superscalar, 64-bit MC68080 with AMMX extensions. Coming to ATARI ST and Amiga 1200 near you if the Apollo team keeps this momentum.

Yeah, I know about it! But unfortunately the 68080 is too large for my FPGA applications, which are cost driven. Other open source 680x0 projects does not work too, by the same reason. For some years, I wondering how create a compact implementation of the 680x0 in the FPGA, but with no success. At some moment I started work in a subset of the 680x0, something like a RISC version of 68000, with a minimal instruction set and a very optimized pipeline, but in this case the problem moved to the toolchain and make the gcc work well is not so easy... Defeated by all that problems and limitations, I started test lots of new architectures and found the RISC-V.

Re: Open source RISC-V implemented from scratch in one night

#106

Post by samsoniuk »

josemanuel wrote: post #3

Writing RTL takes one night but, how long will the verification take? How much will it take to tapeout? Who will pay for it?

After two weeks, I hope most critical problems are already solved, as long more complex software is working without problems, thanks to the clear and simple RV32I instruction set! Of course, as observed in the project description, I am working only with FPGAs, which means that is far more faster and easy to simulate with real software and find problems. As long most of complex work is done by the FPGA tool and I have a well comported clock environment, always according to the specifications, the verification is purely logical.

Re: Open source RISC-V implemented from scratch in one night

#107

Post by Annatar »

waterhouse wrote: post #103
Annatar wrote: post #88

Earlier quoted context omitted.

"Indeed, in RISC-V, full 32-bit constants must be broken across two instructions." Any RISC processor has that issue, because encoding is fixed at 32-bits to keep the hardware simple. That's not what I'm referring to. Look at that retardation, "auipc". Because "auipc" is intuitive, right? (For the record, I'm being sarcastic.) What the hell was the instruction designer smoking? Then there is the square bracket notati…

All right, I count myself disappointed. Surely you know that "processors" don't use parentheses; the parentheses and brackets are in assembler syntax, which is long gone by the time the processor is executing byte sequences. There is nothing inherent about Intel-style syntax in physical RISC-V processors; nor in Intel processors, for that matter, as demonstrated by the fact that gcc outputs its x86-64 assembly in AT&…

You can have a "phenomenal" processor design (Itanium was "phenomenal") in that sense, but if it's crap to program, it's not going to do it much good. As you've so aptly demonstrated, RISC-V is crap to program; you aren't likely to see any scene demos written for it, but that aside, we've yet to see whether the performance of this "phenomenal" processor will live up to the hype. Right now the closest this "phenomenal" processor has come to reality is in a tinkertoy. That's long ways away from servers and production. I still stand by my position: the mnemonics suck and compared to MC68000 or OpenSPARC the programming model is retarded, even for a RISC processor. Good luck with the hype.

Re: Open source RISC-V implemented from scratch in one night

#108

Post by samsoniuk »

craftyguy wrote: post #6
josemanuel wrote: post #3

Writing RTL takes one night but, how long will the verification take? How much will it take to tapeout? Who will pay for it?

> Writing RTL takes one night but, how long will the verification take? Obviously more than a night, but hey development is completely open so you can see for yourself. > How much will it take to tapeout? 0 days. It is running on an FPGA. > Who will pay for it? See previous comment. Presumably the author paid for the FPGA, but maybe it was a gift?

Almost! For most of time I work only in the simulator (Xilinx ISIM), but luckily I have lots of FPGA boards available at work too!

Re: Open source RISC-V implemented from scratch in one night

#109

Post by jononor »

Annatar wrote: post #107
waterhouse wrote: post #103

Earlier quoted context omitted.

All right, I count myself disappointed. Surely you know that "processors" don't use parentheses; the parentheses and brackets are in assembler syntax, which is long gone by the time the processor is executing byte sequences. There is nothing inherent about Intel-style syntax in physical RISC-V processors; nor in Intel processors, for that matter, as demonstrated by the fact that gcc outputs its x86-64 assembly in AT&…

You can have a "phenomenal" processor design (Itanium was "phenomenal") in that sense, but if it's crap to program, it's not going to do it much good. As you've so aptly demonstrated, RISC-V is crap to program; you aren't likely to see any scene demos written for it, but that aside, we've yet to see whether the performance of this "phenomenal" processor will live up to the hype. Right now the closest this "phenomenal…

Programming RISC-V will for most people be practically just like programming Thumb2,x86,etc - because they will use a standard high level languages and compiler toolchain.

Re: Open source RISC-V implemented from scratch in one night

#110

Post by Symmetry »

samsoniuk wrote: post #102
Symmetry wrote: post #65

Earlier quoted context omitted.

Quite a bit in theory but memory latency wouldn't decrease so there would have to be some added complexity in interfacing with it.

Well, I tested three different configurations for memory: darkriscv@75MHz cache=off 0-wait-states 2-stage pipeline 2-phase clock: 6.40us darkriscv@75MHz cache=on 3-wait-states 3-stage pipeline 1-phase clock: 9.37us darkriscv@50MHz cache=on 3-wait-states 2-stage pipeline 2-phase clock: 13.84us The first configuration works in a zero wait-state environment with separate instruction and data high speed synchronous memor…

I applaud your hackerishness in trying out all this.
Post reply on HN