Giter Site home page Giter Site logo

bluespec / piccolo Goto Github PK

View Code? Open in Web Editor NEW
305.0 24.0 49.0 12.2 MB

RISC-V CPU, simple 3-stage pipeline, for low-end applications (e.g., embedded, IoT)

License: Apache License 2.0

Makefile 0.10% C 0.12% C++ 0.03% Bluespec 2.91% Verilog 96.72% Python 0.12% Tcl 0.01% GDB 0.01%

piccolo's Introduction

Open-source RISC-V CPUs from Bluespec, Inc.

This is one of a family of free, open-source RISC-V CPUs created by Bluespec, Inc.

  • Piccolo: 3-stage, in-order pipeline

    Piccolo is intended for low-end applications (Embedded Systems, IoT, microcontrollers, etc.).

  • Flute: 5-stage, in-order pipeline

    Flute is intended for low-end to medium applications that require 64-bit operation, an MMU (Virtual Memory) and more performance than Piccolo-class processors.

  • Toooba: superscalar, deep, out-of-order pipeline, using MIT's RISCY-OOO core.

The three repo structures are nearly identical, and the ways to build and run are identical. This README is identical--please substitute "Piccolo" or "Flute" or "Toooba" below wherever you see <CPU>.

About the source codes (in BSV and Verilog)

The BSV source code in this repository, from which the synthesizable Verilog RTL in this repository is generated, is highly parameterized to allow generating many possible configurations, some of which are adequate to boot a Linux kernel.

The pre-generated synthesizable Verilog RTL source files in this repository are for a few specific configurations:

  1. RV32ACIMU: (DARPA SSITH users: with Piccolo this is the "P1" processor)

    • RV32I: base RV32 integer instructions
    • 'A' extension: atomic memory ops
    • 'C' extension: compressed instructions
    • 'M' extension: integer multiply/divide instructions
    • Privilege levels M (machine) and U (user)
    • Supports external, timer, software and non-maskable interrupts
    • Passes all riscv-isa tests for RV32ACIMU
    • Boots FreeRTOS
  2. RV64ACDFIMSU (DARPA SSITH users: with Flute this is the "P2" processor)

    • RV64I: base RV64 integer instructions
    • 'A' extension: atomic memory ops
    • 'C' extension: compressed instructions
    • 'D' extension: double-precision floating point instructions
    • 'F' extension: single-precision floating point instructions
    • 'M' extension: integer multiply/divide instructions
    • Privilege levels M (machine), S (Supervisor) and U (user)
    • Supports Sv39 virtual memory
    • Supports external, timer, software and non-maskable interrupts
    • Passes all riscv-isa tests for RV64ACDFIMSU
    • Boots the Linux kernel

If you want to generate other Verilog variants, you'll need the free and open-source bsc compiler, which you can find here.

The BSV source code supports:

  • RV32I or RV64I

  • Optional 'A', 'C', 'D', 'F' and 'M' extensions

  • Privilege level options M, MU and MSU

  • For privilege S, virtual memory schemes Sv32 (RV32) and Sv39 (RV64)

  • Hardware implementation option: serial shifter (smaller hardware, slower) or barrel shifter (more HW, faster) for shift instructions

  • Hardware implementation option: serial integer multiplier (smaller hardware, slower) or synthesized (more HW, faster)

  • AXI4 Fabric interfaces, with optional 32-bit or 64-bit datapaths (independent of RV32/RV64 choice)

  • and several other localized options

Testbench included

This repository contains a simple testbench (a small SoC) with which one can run RISC-V binaries in simulation by loading standard mem hex files and executing in Bluespec's Bluesim, Verilator simulation or iVerilog simulation. The testbench contains an AXI4 interconnect fabric that connects the CPU to models of a boot ROM, a memory, a timer and a UART for console I/O.

This repository contains several sample build directories, to build RV32ACIMU or RV64ACDFIMSU simulators, using Bluespec Bluesim simulation, Verilator Verilog simulation, or Icarus Verilog ("iverilog") simulation.

The generated Verilog is synthesizable. Bluespec tests all this code on Xilinx FPGAs.

Plans

  • Ongoing continuous micro-architectural improvements for performance and hardware area.

Source codes

This repository contains two levels of source code: Verilog and BSV.

Verilog RTL can be found in directories with names suffixed in '_verilator' or '_iverilog' in the 'builds' directory:

    builds/..._<verilator or iverilog>/Verilog_RTL/

[There is no difference between Verilog in a Verilator directory vs. the corresponding iverilog directory. ]

The Verilog RTL is synthesizable (and hence acceptable to Verilator). It can be simulated in any Verilog simulator (we provide Makefiles to build simulation executables for Verilator and for Icarus Verilog (iverilog)).

The RTL represents RISC-V CPU RTL, plus a rudimentary surrounding SoC enabling immediate simulation here, and which is rich enough to enable booting a Linux kernel. Users are free to use the CPU RTL in their own Verilog system designs. The top-level module for the CPU RTL is Verilog_RTL/mkCore.v. The top-level module for the surrounding SoC is Verilog_RTL/mkTop_HW_Side.v. The SoC has an AXI4 fabric, a timer, a software-interrupt device, and a UART. Additional library RTL can be found in the directory src_bsc_lib_RTL. There is a sketch of the module hierarchy in this document:

    Doc/Microarchitecture/Microarchitecture.pdf

Bluespec BSV source code (which was used to generate the Verilog RTL) can be found in:

  • src_Core/, for the CPU core, with sub-directories:

    • ISA/: generic types/constants/functions for the RISC-V ISA (not CPU-implementation-specific)
    • RegFiles/: generic register files for the GPRs (General-Purpose Registers) and CSRs (Control and Status Registers)
    • Core/: the CPU Core
    • Near_Mem_VM/: for the MMU and first-level cache. In the CPU, this is instantiated twice to provide completely separate channels (MMU and Cache) for instructions and data.
    • BSV_Additional_Libs/: generic utilities (not CPU-specific)
    • Debug_Module/: RISC-V Debug Module to debug the CPU from GDB or other debuggers
  • src_Testbench/, for the surrounding testbench, with sub-directories:

    • Top/: The system top-level (Top_HW_Side.bsv), a memory model that loads from a memory hex file, and some imported C functions for polled reads from the console tty (not currently available for Icarus Verilog).

    • SoC/: An interconnect, a boot ROM, a memory controller, a timer and software-interrupt device, and a UART for console tty I/O.

    • Fabrics/: Generic AXI4 code for the SoC fabric.

The BSV source code has a rich set of parameters, mentioned above. The provided RTL source has been generated from the BSV source automatically using Bluespec's bsc compiler, with certain particular sets of choices for the various parameters. The generated RTL is not parameterized.

To generate Verilog variants with other parameter choices, the user will need the free and open-source bsc compiler. See the next section for examples of how the build is configured for different ISA features.

In fact the CPU also supports a "Tandem Verifier" that produces an instruction-by-instruction trace that can be checked for correctness against a RISC-V Golden Reference Model. Please contact Bluespec, Inc. for more information.


Building and running from the Verilog sources, out of the box

In any of the Verilog-build directories:

        builds/<ARCH>_<CPU>_verilator/
        builds/<ARCH>_<CPU>_iverilog/
  • $ make simulator will create a Verilog simulation executable using Verilator or iverilog, respectively

  • $ make test will run the executable on the standard RISC-V ISA test rv32ui-p-add or rv64ui-p-add, which is one of the tests in the Tests/isa/ directory. Examining the test: target in Makefile, we see that it first runs the program Tests/elf_to_hex/elf_to_hex on the rv32ui-p-add or rv64ui-p-add ELF file to create a Mem.hex file, and then runs the simulation executable which loads this Mem.hex file into its memory.

  • Following the pattern of $ make test, the user can run any of the other tests in the Tests/isa/ directory by pointing at the chosen ELF file.

  • $ make isa_tests will run the executable on all the standard RISC-V ISA tests relevant for ARCH (regression testing). This uses the Python script Tests/Run_regression.py. Please see the documentation at the top of that program for details.

Note: an RV32ACIMU simulator will only successfully run ELF files compiled for RV32ACIMU, privilege U and M; running it on any other ELF file will result in illegal instruction traps. An RV64ACDFIMSU simulator will successfully run ELF files compiled for RV64ACDFIMSU, privilege U, S and M.

Tool dependencies:

We test our builds with the following versions of iVerilog and Verilator. Later versions are probably ok; we have observed some problems with earlier versions of both tools.

    $ iverilog -v
    Icarus Verilog version 10.1 (stable) ()

    $ verilator --version
    Verilator 3.922 2018-03-17 rev verilator_3_920-32-gdf3d1a4

Note: we provide a setup for iVerilog because it is well-known and widely used. However, it is much slower than Bluesim or Verilator. For example, on a particular x86 Ubuntu platform, running through all ISA tests takes 53 minutes with iVerilog but hardly 1 minute with Bluesim or Verilator.


What you can build and run if you have Bluespec's bsc compiler

The free and open-source bsc compiler is available here.

Note: even without Bluespec's bsc compiler, you can use the Verilog sources in any of the builds/<ARCH>_<CPU>_verilator/Verilog_RTL directories-- build and run Verilog simulations, incorporate the Verilog CPU into your own SoC, etc. This section describes additional things you can do with a bsc compiler.

Building a Bluesim simulator

In any of the following directories:

    builds/<ARCH>_<CPU>_bluesim
  • $ make compile simulator

will compile and link a Bluesim executable. Then, you can make test or make isa_tests as described above to run an individual ISA test or run regressions on the full suite of relevant ISA tests.

Re-generating Verilog RTL

You can regenerate the Verilog RTL in any of the build/<ARCH>_<CPU>_verilator/ or build/<ARCH>_<CPU>_iverilog/ directories. Example:

    $ cd  builds/RV32ACIMU_<CPU>_verilator
    $ make compile

Creating a new architecture configuration

In the builds/ directory, you can create a new sub-directory to build a new configuration of interest. For example:

    $ cd  builds
$ Resources/mkBuild_Dir.py  ..  RV32CI  bluesim

will create a new directory: builds\RV32CIU_<CPU>_bluesim populated with a Makefile to compile and link a bluesim simulation for an RV32 CPU with 'I' and 'C' ISA options. You can build and run that simulator as usual:

    $ cd  builds/RV32CIU_<CPU>_bluesim
    $ make compile simulator test isa_tests

piccolo's People

Contributors

darius-bluespec avatar davidchisnall avatar dhand-galois avatar joestoy avatar jrtc27 avatar nirajnsharma avatar peterrugg avatar quark17 avatar rsnikhil avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

piccolo's Issues

Toolchain support for custom opcodes

Add macros for using custom instructions. Refer:

https://github.com/riscv/riscv-gnu-toolchain/issues/190

Verify support for custom instructions in RV toolchain.

fcvt.w.d rounds incorrectly in rmm mode

Here's a test case:

_start:
lui ra, 2
csrs mstatus, ra
_test:
li t0, 0x40e6a09e66689b2e
fmv.d.x f0, t0
fcvt.w.d a0, f0, rmm

Piccolo rounds down to 0xb504, while spike rounds up to 0xb505. I believe that spike is correct.

(If you're wondering where the strange constant came from, it's sqrt(MAXINT), but I think that isn't important for this bug).

Can't run simulator, missing symbol _Z27dollar_test_dollar_plusargsP9tSimStatePKcPKSs

$ git clone https://github.com/nixos/nixpkgs
$ nix-shell -I nixpkgs=`pwd`/nixpkgs -p bluespec verilog
$ git clone https://github.com/bluespec/Piccolo
$ cd Piccolo/builds/RV32ACIMU_Piccolo_bluesim
$ make compile
$ make simulator
$ ./exe_HW_sim
Error: dlopen: ./exe_HW_sim.so: undefined symbol: _Z27dollar_test_dollar_plusargsP9tSimStatePKcPKSs
    invoked from within
"sim load $model_name $top_module"
    invoked from within
"if {$wait} {
sim load $model_name $top_module wait
} else {
sim load $model_name $top_module
}"
    (file "/nix/store/p4byndpkpmd2blkqzk0l9wv9g1n3lfwz-bluespec-unstable-2020.02.09/lib/tcllib/bluespec/bluesim.tcl" line 193)



relocation truncated error when compiling `elf_to_hex.c` file to create the Mem Hex files

Hi all,

I don't know if it is only with my gcc version 11.1.0 but I am getting the next error when I tried to use the elf_to_hex.c file to compile with the Makefile in Tests/elf_to_hex.

The error:

gcc -g -o elf_to_hex  elf_to_hex.c  -lelf
/tmp/cc4D9tPQ.o: in function `c_mem_load_elf':
/home/jairom/Documents/TUD_Projects/05_Semester/Piccolo/Tests/elf_to_hex/elf_to_hex.c:94:(.text+0x25a): relocation truncated to fit: R_X86_64_PC32 against symbol `bitwidth' defined in .bss section in /tmp/cc4D9tPQ.o
/home/jairom/Documents/TUD_Projects/05_Semester/Piccolo/Tests/elf_to_hex/elf_to_hex.c:98:(.text+0x2a2): relocation truncated to fit: R_X86_64_PC32 against symbol `bitwidth' defined in .bss section in /tmp/cc4D9tPQ.o
/home/jairom/Documents/TUD_Projects/05_Semester/Piccolo/Tests/elf_to_hex/elf_to_hex.c:130:(.text+0x394): relocation truncated to fit: R_X86_64_PC32 against symbol `min_addr' defined in .bss section in /tmp/cc4D9tPQ.o
/home/jairom/Documents/TUD_Projects/05_Semester/Piccolo/Tests/elf_to_hex/elf_to_hex.c:131:(.text+0x39f): relocation truncated to fit: R_X86_64_PC32 against symbol `max_addr' defined in .bss section in /tmp/cc4D9tPQ.o
/home/jairom/Documents/TUD_Projects/05_Semester/Piccolo/Tests/elf_to_hex/elf_to_hex.c:132:(.text+0x3aa): relocation truncated to fit: R_X86_64_PC32 against symbol `pc_start' defined in .bss section in /tmp/cc4D9tPQ.o
/home/jairom/Documents/TUD_Projects/05_Semester/Piccolo/Tests/elf_to_hex/elf_to_hex.c:133:(.text+0x3b5): relocation truncated to fit: R_X86_64_PC32 against symbol `pc_exit' defined in .bss section in /tmp/cc4D9tPQ.o
/home/jairom/Documents/TUD_Projects/05_Semester/Piccolo/Tests/elf_to_hex/elf_to_hex.c:134:(.text+0x3c0): relocation truncated to fit: R_X86_64_PC32 against symbol `tohost_addr' defined in .bss section in /tmp/cc4D9tPQ.o
/home/jairom/Documents/TUD_Projects/05_Semester/Piccolo/Tests/elf_to_hex/elf_to_hex.c:155:(.text+0x4c6): relocation truncated to fit: R_X86_64_PC32 against symbol `min_addr' defined in .bss section in /tmp/cc4D9tPQ.o
/home/jairom/Documents/TUD_Projects/05_Semester/Piccolo/Tests/elf_to_hex/elf_to_hex.c:156:(.text+0x4d6): relocation truncated to fit: R_X86_64_PC32 against symbol `min_addr' defined in .bss section in /tmp/cc4D9tPQ.o
/home/jairom/Documents/TUD_Projects/05_Semester/Piccolo/Tests/elf_to_hex/elf_to_hex.c:157:(.text+0x4f3): relocation truncated to fit: R_X86_64_PC32 against symbol `max_addr' defined in .bss section in /tmp/cc4D9tPQ.o
/home/jairom/Documents/TUD_Projects/05_Semester/Piccolo/Tests/elf_to_hex/elf_to_hex.c:158:(.text+0x515): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
make: *** [Makefile:7: elf_to_hex] Error 1

The problem can be solved adding the the flag -mcmodel=medium. According to what I have read is because this particular C file requires a large amount of memory in the stack that could not be fulfilled using a 32 bits AS operations. Is this a unique problem from my environment?

Thank you for your time,

Jairo M

Building and Running from the Verilog Sources, out of the box results in Error

Execution of
$make simulator

in the
builds/<ARCH>_<CPU>_verilator/

directory results in
%Warning-DEPRECATED: Verilog_RTL/mkTop_HW_Side_edited.v:7: Deprecated -msg in configuration files, use -rule instead.

%Error: Exiting due to 6 warning(s) make: *** [../../builds/Resources/Include_verilator.mk:52: simulator] Error 1

How to resolve this error?

fcvt.wu.d does not round up denormalized values

If the rounding mode is set to round up, fcvt.wu.d of a denormalized value rounds down to zero rather than rounding up to 1. (Spike gets this right).

Here's a test:

.global _start
_start:
lui ra, 2
csrs mstatus, ra

_test:
li t0, 0x10
fmv.d.x f1, t0
fcvt.wu.d a0, f1, rup

No C extension causes Piccolo compile failure

I tried building Piccolo as a simple RV32 IM yesterday, and the compile failed, saying:

Error: "../../src_Core/CPU/CPU_Stage1.bsv", line 243, column 35: (T0004)
  Unbound variable `instr_C'

It comes from here, where instr_C is used outside of an ISA_C block.

I'm not sure the most elegant way to handle this, but I've done this in the meantime locally and it works fine as far as I can tell:

         if (alu_outputs.exc_code == exc_code_ILLEGAL_INSTRUCTION)
`ifdef ISA_C
            tval = (is_i32_not_i16
                    ? zeroExtend (instr)
                    : zeroExtend (instr_C));                   // The instruction
`else
            tval = zeroExtend (instr);
`endif

How to generate VCD files for simulations?

Hi, I hope you are well.

I want to analyse the waveforms for the execution of an elf in the /tests folder. For this purpose, I uncommented line 41 of the makefile in /builds/Resources/Include_verilator.mk. In one of the /builds/*_verilator folders, I executed the make simulator and make test commands, but I could not find where the VCD file is. Is there any other modification required that I missed?

Also, I want to analyse the L1 cache behaviour. Hence, which cache replacement policy does Piccolo use?

nmsub.s of all (positive) zeros

With Piccolo, nmsub.s with rounding mode=RNE and all the source registers containing IEEE positive zero returns an IEEE negative zero.

I believe that the correct IEEE 754:2008 result is negative zero if the rounding mode is RDN, and positive zero otherwise. Spike gives the result I expected.

Here's a test:

.global _start
_start:
lui ra, 2
csrs mstatus, ra
fmv.w.x ft0, zero

_test:
fnmsub.s ft0, ft0, ft0, ft0, rne
fmv.x.w a0, ft0

fcvt.wu.s of negative zero

fcvt.wu.s of negative zero of IEEE negative zero sets FCSR.NV, Spike doesn't set the flag. I believe that what spike does is the correct IEEE 754:2008 behaviour.

Here's a test:
.global _start
_start:
lui ra, 2
csrs mstatus, ra
fmv.w.x ft0, zero
test:
fsgnjn.s f0, f0, f0
fcvt.wu.s t0, f0, rtz
csrrs a0, fcsr, zero

dhrystone test

Hi,
Do you have the testbench or program to run the dhrystone,or the result of dhrystone by riscv-gcc?

best wishes

AXI Fabric bugs

I recently took an opportunity to review mkFabric_AXI4.v using a formal AXI4 property checker under SymbiYosys. It appears to have some difficulties routing packets from the correct source to the correct destination. The attached (abbreviated) trace should give you an idea of what I'm talking about.

bad-wstrb

In this example, a burst packet presented from master 0 gets routed to slave 0. The associated W* channel data, however, gets corrupted in the process. (The appropriate WSTRB value sent by the master was 0, not 4.) Not shown are two similar bursts presented from master 1 during this time which may (or may not be) relevant.

Dan

Illegal instruction not handled properly

When you have a branch instruction with an illegal funct3 field (e.g. 3'b010), the processor triggers an exception and jumps to the exception handler, but it sets the wrong cause to the mcause CSR. The cause should be illegal instruction (2) instead of instruction address misaligned (0). I haven't looked to see if there are any other illegal instructions that result in the wrong cause to be written to the mcause CSR.

The relevant code in Piccolo can be found here: https://github.com/bluespec/Piccolo/blob/master/src_Core/Core/EX_ALU_functions.bsv#L227-L239

And here is a small test I used to observe the error:

.text.init:

.globl _start
.globl tohost
.globl exit

_start:
    # setup trap handler
    la t0, trap_handler
    csrw mtvec, t0
    # do an illegal instruction that looks like a branch
    .word 0x00002063
    # .word 0x00001063 # legal branch
    li a0, 1337
    j write_tohost

trap_handler:
    csrr a0, mcause
    j write_tohost

write_tohost:
    slli t0, a0, 1
    ori t0, t0, 1
    la t1, tohost
    sw t0, 0(t1)
exit:
    j exit

.align 4

tohost:
    .word 0x0

This test prints PASS when it runs because the mcause CSR had 0 in it (the code for instruction address misaligned). This test should fail with a code of 2 representing an illegal instruction exception.

Can the project be taken to Google summer of code 2021 as organization

Hello to people maintaining the project, I would like to contribute to this amazing hardware project and I was wondering if this project can be taken to google summer of code 2021, the organization application openings start from February I believe, please do consider my request.

verbosity of MMU_Cache is always 0

When you set the verbosity of the CPU to be 1 or 2, the verbosity of the MMU_Cache.bsv file is stuck-at-0. Hence, none of the display messages of this file can be displayed during simulation. This can be verified by running any isa test with VERBOSITY=+v1 or VERBOSITY=+v2 and checking the output log.

I believe the problem is that although MMU_Cache.bsv has a set_verbosity method, there is no way to reach it as the Near_Mem_IFC.bsv file doesn't have one.

One possible solution is to add set_verbosity method to the Near_Mem_IFC.bsv file (with a proper body in Near_Mem_Caches.bsv) and call it in the set_verbosity method of the CPU.bsv file.
https://github.com/bluespec/Piccolo/blob/master/src_Core/Core/CPU.bsv#L1477-L1480

Thank you

Cache replacement policy / Shrinking Size

Hi, I hope you are well.

What is Piccolo's L1 cache replacement policy? Which bus is activated when a cache flush/eviction happens?

Also, is it possible to generate a Piccolo version with cache sizes smaller than 1KB (say 256/512 bytes)? I am asking because it seems like I can't have a value < 1 here in the kb_per_cache

Thanks!

when run DC, BRAM.v has Error

Hi,
when I run DC of the BRVF_Core project, it occurs the Error that is "BRAM.v:99: Net 'RAM[0][63]' or a directy connected net is driven by more than one source, and not all drivers are three-state".
Does the BRAM.v have bug or I set somewhere wrong?
best wishes!

The Architecture Documentation

Hi,
I would like to view the micro-architecture of Piccolo, and I noticed that the pdf file should be in the directory Doc/Microarchitecture/Microarchitecture.pdf according to the README. However, I could not find this directory.
So I would like to ask where the pdf file locates. Thank you so much for your time!

SC to 4-byte aligned but not 8-byte aligned address will always report success

Since the MMU Cache shifts the memory access result based on the alignment of the address request, and the 1 to indicate SC failure is passed through the same logic, the 1 is shifted out in the case that the address is misaligned, leaving 0 which falsely indicates success.

Example code sequence:
auipc a0, 0x0
addi a0,a0,52 # load 4-byte but not 8-byte aligned value into a0
li a1, 42 # arbitrary value to be stored
sc.w a2, a1,(a0) # perform an SC that should fail (no paired LL)

Piccolo RV32ACIMU currently returns 0 in this case.

CPU modification for custom opcodes

Dispatch an instruction with a custom opcode to a TCA, and collect the response.

  • Stage1 modification to detect a custom instruction
  • Dispatch custom instruction to TCA from Stage2
  • Collect responses from TCA in Stages 2 and 3
  • Service memory read and write requests from TCA

Mixed code indentation

This is a minor issue.

For SSITH, I may extend the source code of Piccolo (and Flute). During these early phases, I am reading and understanding the source code. I noticed some mixed (tab, spaces) or non-correct indentation that reduces the code readability. I can easily fix it on my side as I proceed with my feature integration, but it would be great to have it fixed on the baseline.

Thank you!

Reference TCA Design

Create a reference TCA which uses the custom instruction support in the CPU to receive commands. The TCA needs to support operations which have both scalar and vector results.

Running Dhrystone or CoreMarks benchmarks

I see an impressive 1.9 DMIPS/MHz performance reported here for the RV32IM version of Piccolo. I'm interested in reproducing this result as well as study the effect of different configurations. I would also be interested in CoreMarks figures as a better alternative. Are ports of Dhrystone/CoreMark available for Piccolo/Flute/Toooba?

As the results of these tests are usually printed on the console:
Are there any documentation/examples available for using the available UART? Do I only need to store at address '0xc0000000' ? Is there a libgloss port or even simple a printf wrapper available?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.