samsoniuk

The project goal is identify some missing pins from the Storey Peak Stratix V FPGA board, but can be used widely with other recycled FPGA boards!

The concept is very easy: build an FPGA image that periodically send a UART string with the respective pin name, in a way that a probe attached to a USB/serial converter can read the pin in the PCB and help map the end points to the respective FPGA pins!

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...

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!

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.

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.

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

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.

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.

hmmm... I promise investigate this topic in the future!

I think the best feature of the RISC-V instruction set is that is very clear and very simple. The RV32I instruction set is composed by ~40 different instructions and, depending of the environment and the implementation, you don't even need implement all them, as long the compiler will never generate some instructions. A simpler core means faster clock rates, less logic and more cores per chip, which much more performance. By this way, although the performance in the FPGA is not so good as in a ASIC, the results are not so bad:

https://www.hotchips.org/wp-content/uploads/hc_archives/hc29...

With 1680 RISC-V cores running in parallel at 250MHz, the result is impressive, even working in a FPGA!

Good point, but unfortunately the focus of the project is only the RISC-V core running in a FPGA. Everything else is already widely available in the internet and can be easily integrated.

It is not even the first RISC-V with BSD license, but I love make some GPL friends cry! ;D

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 csrxxx), since the gcc generates by default exactly the implemented subset and nothing more. I think this is a very important advantage in the RISCV architecture when compared with others and I dont think the gcc will have the same benevolent behaviour in the case of ARM or x86. Maybe for MIPS is possible, but I am not sure about it. Anyway, why not use RISC-V? :)

wow! I didn't expect to get so many comments and questions about my weird project! thank you all! :)