Live data from Hacker News

Open source RISC-V implemented from scratch in one night

github.com

111–114 of 114 posts

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

#111
post #58

Earlier quoted context omitted.

Firefox used to have Tab Groups, it got removed but the webextension API got some new features specifically to support similar functionality in an extension. i.e. https://addons.mozilla.org/en-US/firefox/addon/basic-panoram... In reality I think it's just not a priority for browser devs because the overwhelming majority of users do not use huge numbers of tabs.

Thanks. Yeah I suspect tab junkies are probably a minority. Do you know is the latest Firefox on par with Chrome in terms of tab usage and memory footprint?

Memory usage in FF with lots of tabs seems a bit better than Chrome, CPU usage seems a bit worse. I think the UI does a significantly better job of handling them though, since Chrome just shrinks everything until there's no text left.

About a year ago FF was really awful with lots of tabs, CPU usage was very high and the UI would occasionally freeze up for 10+ seconds at a time. They're really been making some big performance improvements lately.

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

#112
post #74

Sorry to burst any bubbles here, but this is s very incomplete implementation. You couldn’t run anything but small toy programs on this machine. This is more like what a student would build in an undergraduate course in computer architecture. For example, there is no MMU, no debug support, no traps, no interrupts, no exception handling, no OS privledge levels, no FP, no memory controller etc. Of course, one wouldn’t…

I fully agree with you about the missing features! However, as long my objective is replace some legacy 680x0/683xx/coldfire processors running small toy programs, I see no need for that complex features. Please keep in mind that although 25% of RV32I instruction set is missing in my implementation, there is no side effect, since that instructions are not relevant for this specific environment (fencex, exxx and csrxx…

Yes. Part of the motivation for RISC-V was to enable designers to do one-off experiments like this or small production runs with custom ISAs based on RISC-V, without having to worry about licenses or intellectual property issues. RISC-V even leaves some op codes uncommitted so designers can add their own custom instructions. Dave Patterson (RISC-V designer and Turing award winner) explained this at a talk I attended a few years ago.

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

#113
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 s…

What about OpenSPARC, since it has low power consumption and can be cut down to less cores and threads?

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

#114

Earlier quoted context omitted.

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

What about OpenSPARC, since it has low power consumption and can be cut down to less cores and threads?

The available implementation of the OpenSPARC is too complex: a single core with 4 threads requires 59350 LUTs and runs at 62.5MHz in a Virtex FPGA (according to [1], slide 21). Although is possible remove some features, I don't think is possible reduce the logic without impact the compatibility. I think the Leon3 [2] is a far better option for FPGAs, since requires only around 3500 LUTs and runs at 125MHz in a Virtex FPGA. In a low-cost FPGA, the performance of Leon3 is around 66MHz, which is enough to replace the 680x0 and coldfire v2 processors. The requirement for 3500LUTs is not so bad, as long the TG68 (an open source 68000 replacement in VHDL) has similar requirements. However, the typical RISC-V implementation uses less than 1/3 of the logic when compared with Leon3 and TG68. Also, although the RISC-V provides almost the same performance as the Leon3, the extra logic can be used for more parallel RISC-V cores, resulting in a increase of 2 or 3x in the total performance. Finally, there is an additional problem with OpenSPARC, Leon3 and TG68: the GPL license. In another hand, most RISC-V implementations use the BSD license, as long the RISC-V instruction set itself uses the BSD license. Of course, the OpenSPARC, Leon3 and TG68 are implemented that way. There is no obstacle, other than the technical complexity, to prevent develop a new OpenSPARC, Leon3 or TG68 from scratch, with a more firendly license, better performance or better use of the logic. In this case, the question is: how many time you need to implement a minimal viable core with one of that architectures? In the case of RISC-V is perfectly possible implement a small core in a FPGA with the RV32I instruction set in few hours, because the RV32I set of instructions is really very poor and primitive, which make it specially friendly to the hardware and explain why is so compact.

[1] http://ramp.eecs.berkeley.edu/Publications/OpenSPARC%20T1%20... [2] http://ramp.eecs.berkeley.edu/Publications/LEON3%20SPARC%20P...

Post reply on HN