lowrisc/ibex

Ibex is a small 32 bit RISC-V CPU core, previously known as zero-riscy.

Ibex OpenTitan configuration Nightly Regression

Ibex RISC-V Core

Ibex is a production-quality open source 32-bit RISC-V CPU core written in SystemVerilog. The CPU core is heavily parametrizable and well suited for embedded control applications. Ibex is being extensively verified and has seen multiple tape-outs. Ibex supports the Integer (I) or Embedded (E), Integer Multiplication and Division (M), Compressed (C), and B (Bit Manipulation) extensions.

Ibex was initially developed as part of the PULP platform under the name "Zero-riscy", and has been contributed to lowRISC who maintains it and develops it further. It is under active development.

Configuration

Ibex offers several configuration parameters to meet the needs of various application scenarios. The options include different choices for the architecture of the multiplier unit, as well as a range of performance and security features. The table below indicates performance, area and verification status for a few selected configurations. These are configurations on which lowRISC is focusing for performance evaluation and design verification (see supported configs).

Config	"micro"	"small"	"maxperf"	"maxperf-pmp-bmfull"
Features	RV32EC	RV32IMC, 3 cycle mult	RV32IMC, 1 cycle mult, Branch target ALU, Writeback stage	RV32IMCB, 1 cycle mult, Branch target ALU, Writeback stage, 16 PMP regions
Performance (CoreMark/MHz)	0.904	2.47	3.13	3.13
Area - Yosys (kGE)	16.85	26.60	32.48	66.02
Area - Commercial (estimated kGE)	~15	~24	~30	~61
Verification status	Red	Green	Green	Green

Notes:

• Performance numbers are based on CoreMark running on the Ibex Simple System platform. Note that different ISAs (use of B and C extensions) give the best results for different configurations. See the Benchmarks README for more information.
• Yosys synthesis area numbers are based on the Ibex basic synthesis flow using the latch-based register file.
• Commercial synthesis area numbers are a rough estimate of what might be achievable with a commercial synthesis flow and technology library.
• For comparison, the original "Zero-riscy" core yields an area of 23.14kGE using our Yosys synthesis flow.
• Verification status is a rough guide to the overall maturity of a particular configuration. Green indicates that verification is close to complete. Amber indicates that some verification has been performed, but the configuration is still experimental. Red indicates a configuration with minimal/no verification. Users must make their own assessment of verification readiness for any tapeout.
• v.1.0.0 of the RISC-V Bit-Manipulation Extension is supported as well as the remaining sub-extensions of draft v.0.93 of the bitmanip spec. The latter are not ratified and there may be changes before ratification. See Standards Compliance in the Ibex documentation for more information.

Documentation

The Ibex user manual can be read online at ReadTheDocs. It is also contained in the doc folder of this repository.

Examples

The Ibex repository includes Simple System. This is an intentionally simple integration of Ibex with a basic system that targets simulation. It is intended to provide an easy way to get bare metal binaries running on Ibex in simulation.

A more complete example can be found in the Ibex Demo System repository. In particular it includes a integration of the PULP RISC-V debug module. It targets the Arty A7 FPGA board from Digilent and supports debugging via OpenOCD and GDB over USB (no external JTAG probe required). The Ibex Demo System is maintained by lowRISC but is not an official part of Ibex.

Contributing

We highly appreciate community contributions. To ease our work of reviewing your contributions, please:

• Create your own branch to commit your changes and then open a Pull Request.
• Split large contributions into smaller commits addressing individual changes or bug fixes. Do not mix unrelated changes into the same commit!
• Write meaningful commit messages. For more information, please check out the contribution guide.
• If asked to modify your changes, do fixup your commits and rebase your branch to maintain a clean history.

When contributing SystemVerilog source code, please try to be consistent and adhere to our Verilog coding style guide.

When contributing C or C++ source code, please try to adhere to the OpenTitan C++ coding style guide. All C and C++ code should be formatted with clang-format before committing. Either run clang-format -i filename.cc or git clang-format on added files.

To get started, please check out the "Good First Issue" list.

Issues and Troubleshooting

If you find any problems or issues with Ibex or the documentation, please check out the issue tracker and create a new issue if your problem is not yet tracked.

Questions?

Do not hesitate to contact us, e.g., on our public Ibex channel on Zulip!

License

Unless otherwise noted, everything in this repository is covered by the Apache License, Version 2.0 (see LICENSE for full text).

Credits

Many people have contributed to Ibex through the years. Please have a look at the credits file and the commit history for more information.

ibex's Issues

Support for PMP

Implement Physical Memory Protection (PMP) as per privspec 1.10. My team is planning to work on that.

Add support for User (U) mode

Currently, Ibex is M-mode only. For some usage scenarios, support for U mode would be beneficial.

Subtasks:

• Evaluate the implementation effort for this change. As a starting point, we can look at RI5CY (https://github.com/pulp-platform/riscv)
• Check overhead of this extension.
• Decide on configurability: should this feature be always-on, or configurable via a parameter? (Depends much on the area overhead.)
• Ensure that we have DV for this.

Run RISC-V Compliance tests through Verilator

Provide a Verilator model of Ibex to serve as target for the RISC-V compliance test suite, and add required tooling and documentation for it. (https://github.com/riscv/riscv-compliance/tree/master/doc#the-target-environment)

Inspiration can be taken from RI5CY (https://github.com/pulp-platform/riscv/tree/master/tb/core).

HINT instruction decoding issue - 0x7065

Based on the spec, it should be decoded as HINT instruction (C.LUI, rd == 0), but it's decoded as illegal instruction by design incorrectly.
https://github.com/lowRISC/ibex/blob/master/rtl/ibex_compressed_decoder.sv#L105

          3'b011: begin
            // c.lui -> lui rd, imm
            instr_o = {{15 {instr_i[12]}}, instr_i[6:2], instr_i[11:7], {OPCODE_LUI}};

            if (instr_i[11:7] == 5'h02) begin
              // c.addi16sp -> addi x2, x2, nzimm
              instr_o = {{3 {instr_i[12]}}, instr_i[4:3], instr_i[5], instr_i[2],
                         instr_i[6], 4'b0, 5'h02, 3'b000, 5'h02, {OPCODE_OPIMM}};
            end else if (instr_i[11:7] == 5'b0) begin // this is INCORRECT
              illegal_instr_o = 1'b1;
            end

            if ({instr_i[12], instr_i[6:2]} == 6'b0) illegal_instr_o = 1'b1;
          end

ra register not update when single step debug

When core execute JAL instruction, return address should be written to ra register. But in single step execution, the ra register is not updated.
Here is an example waveform.
code is: 730000ef jal ra,102073c

1. the core is free run.
   
   You can see the return address 0x1020010 is written to ra register.

2. the core is in single step.
   
   Return address 0x1020010 is not written to ra register. We debug this issue and found that core deassert we_a_i in DBG_SIGNAL state. And ctrl_fsm_ns enter DBG_SIGNAL state before ra register update.
   I tried to fix this issue by add & id_ready_i when ctrl_fsm_ns try to enter DBG_SIGNAL.
   jump_set_i: begin
   pc_mux_o = PC_JUMP;
   pc_set_o = 1'b1;
   perf_jump_o = 1'b1;
   dbg_trap_o = dbg_settings_i[DBG_SETS_SSTE];
   if (dbg_req_i & id_ready_i)
   ctrl_fsm_ns = DBG_SIGNAL;

The return address can be written to ra due to this change. But I'm not sure this is a good workaround.

ASIC synthesis

Hello，How many MHz can the zero-riscy ASIC synthesis achieve? @zarubaf @Razer6 @wallento @fabianschuiki

[tracking] Pass RISC-V compliance test suite

We want to execute and pass the RISC-V compliance tests on Ibex.

Setup tasks

• Create target to run the compliance tests in Verilator: #99

Known issues:

• Standards-compliant trap/interrupts: #70
• Implement the MSCRATCH CSR: #97

If instr[14:12]=3’b111”, rd=M[rs1+rs2]. This instruction code is not defined in the RISC-V spec.

Please refer the line 289-307 in the RTL file “zeroriscy_decoder.sv”. If instr[14:12]=3’b111”, rd=M[rs1+rs2]. This instruction code is not defined in the RISC-V spec.

Missing prim_clock_gating module

I can't seem to find this module anywhere. Can someone point me to where this might be?

[tracking] Implement bit manipulation (B) RISC-V ISA extension

The bit manipulation (bitmanip) extension is currently being specified. Bit manipulation is a common task in many scenarios where Ibex could be used.

The bitmanip extension adds many new instructions to Ibex, not all of them have a straightforward implementation. Please have a look at the implementation plan and the implementation tracking sheet for an overview

• Draft standard
• Implementation plan
• Implementation tracking sheet

All implementations of individual instructions are tracked in separate issues.

Replace core_id and cluster_id parameters in favour of a single hartid parameter

Ibex should allow system integrators to directly specify the hartid using whatever scheme makes most sense for their design. Currently core_id and cluster_id must be specified - this makes sense for the PULP use case, but will require some gymnastics for users who have a different hartid generation scheme.

[EDIT: "gymnastics" is hyperbolic given they're just concatenated - but you get my point. An integrator may also want a hartid that is greater than 10 bits in length]

Implement the mscratch CSR

The title says it all.

We need to document working versions of CAD tools

The Google UVM framework requires either VCS or incisive.
I have found that vcs-mx/N-2017.12-SP1 works but that vcs-2016.06-sp1 does not.

We should record these experiences in some sort of compatibility table.

The failing version crashes out, with a fatal error.

Enum assignment cast

In the following lines the enum types are assigned with a value without an explicit cast

ibex/rtl/ibex_controller.sv

Line 159 in 93b0b77

exc_cause_o = '0;

ibex/rtl/ibex_controller.sv

Line 162 in 93b0b77

csr_cause_o = '0;

when will ibex pass some of the compliance tests

I see from #96 Boot Address the comment 'Work is underway to update it to to the current spec' etc.

This is good - my question is when do you think the ibex will be able to run the relevant risc-v compliance suites - as they require at least 1.10, 2.1.

We have tried to run ibex in its dv/uvm /tb testbench with the first few compliance tests but have now halted this work due to many issues needing resolving so felt it was best to ask you to get it work - then we can continue.

Pls give an indication when you expect ibex to pass some of the compliance tests.

thanks
Simon

Support for riscv-formal

Is it possible to support the RISC-V Formal Verification Framework? If yes, are there plans to do this?

Unaligned instruction fetch and data addresses

Hi,
I've got an issue while trying to execute a code compiled by riscv64-unknown-elf-gcc-8.2.0-2019.02.0-x86_64-linux-centos6 (from https://www.sifive.com/boards/) on the ibex core.

Listing:

25e: 028b2783 lw a5,40(s6)

Message:

316725ns: Illegal instruction (core 0) at PC 0x0000025e: 0x028b028b

Could you please suggest what might be wrong here.
Thanks.

clock_en_i no longer connected

Hello,

It seems that the top level signal 'clock_en_i' no longer drives anything. Is this intentional?

Reference integration for FPGA

Goal: Provide a minimal, but fully working example of how to use Ibex on a well-known FPGA board.

Target board: One of the well-known Xilinx 7-series boards, Nexys or Arty*.

This will require:

• A toplevel
• Additional hardware blocks
  • A RAM
  • A prim_clock_gating implementation
  • A trivial GPIO IP would be nice which maps some bus reads/writes to LEDs/Switches.
• A board-dependent constraints file (xdc)
• Build system support (a fusesoc core file)
• Documentation and code to run a minimal hello world (including linker file, crt)

I'm not sure about where to put these things into the repository, I'd most likely go for a top-level directory like examples/fpga/nexyvideo and examples/sw/hello_world.

Switch ibex_tracer to use RVFI

Currently ibex_tracer is instantiated within the ibex_core.sv file depending on a define. It would be cleaner if we do the following:

• Modify ibex_tracer.sv take the RVFI signals as input. Requires #61 to be merged first.
• Remove the instantiation of ibex_tracer from ibex_core.sv
• Show people how to instantiate ibex_core and ibex_tracer in their top-level design; either in documentation, or by creating ibex_core_tracing.sv which instantiates ibex_core and ibex_tracer and passes through all signals except for the tracing ones.

why mstatus accessed by CSR instruction will flush prefetch fifo

Please refer the line 306 in “zeroriscy_controller.sv”, what purpose is for the csr_status_i (mstatus accessed by CSR instruction) will enter the FLUSH state?

          else if (~branch_set_i & ~jump_set_i & (mret_insn_i | ecall_insn_i | pipe_flush_i | ebrk_insn_i | illegal_insn_i | csr_status_i))
          begin
            ctrl_fsm_ns = FLUSH;
            halt_if_o   = 1'b1;
            halt_id_o   = 1'b1;
          end

Clock gate for latch-based register file

The clock gate currently provided in dv/uvm/tb/prim_clock_gating.sv is not compatible with the latch-based register file. Usage of this clock gate leads to wrong behavior in simulation as reported in #75.

For commercial, event-based simulators a clock-gate using a latch for the enable signal can be used. For Verilator, a different workaround is needed.

Also, the requirements on the clock gate must be documented accordingly.

Moreover, we should rename the two register files to register_file_ff.sv and register_file_latch.sv to avoid people accidentally taking the wrong register file and running into the same problem again.

Fix PDF documentation build

$ LANG=C make latexpdf
Running Sphinx v2.0.1
building [mo]: targets for 0 po files that are out of date
building [latex]: all documents
updating environment: 12 added, 0 changed, 0 removed
reading sources... [100%] register_file                                                                                                                                                      
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
processing ibex.tex... index introduction integration instruction_fetch load_store_unit register_file cs_registers interrupts performance_counters exception_interrupts debug copyright 
resolving references...
done
writing... failed

Exception occurred:
  File "/home/philipp/src/ibex/doc/venv/lib64/python3.7/site-packages/cairosvg/parser.py", line 414, in __init__
    'No tag with id="{}" found.'.format(element_id))
TypeError: No tag with id="vvv-2-2" found.
The full traceback has been saved in /tmp/sphinx-err-u9zes32v.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
make: *** [Makefile:20: latexpdf] Error 1

The SVG image in question actually is generated through wavedrom, as this part of the stacktrace shows:

  File "/home/philipp/src/ibex/doc/venv/lib64/python3.7/site-packages/sphinxcontrib/wavedrom.py", line 187, in visit_wavedrom
    imgname = render_wavedrom(self, node, outpath, bname, format)
  File "/home/philipp/src/ibex/doc/venv/lib64/python3.7/site-packages/sphinxcontrib/wavedrom.py", line 162, in render_wavedrom
    cairosvg.svg2pdf(svgout.tostring(), write_to=fpath)

The SVG (which is then converted to PDF and causes the error) contains a couple of tags with xlink:href="#vvv-2-2" statements, but no tag with the id="vvv-2-2" attribute. So the error message of cairosvg is correct, and something is wrong in the generation of the wavedrom SVG (for reference: the same problem happens with vvv-2, but vvv-3 is handled correctly in the SVG)

The following wavedrom source code is trying to be rendered. It's in doc/instruction_fetch.rst:

{"signal":
  [
    {"name": "clk", "wave": "p......"},
    {"name": "data_addr_o", "wave": "x===xxx", "data": ["Address", "Address", "Address"]},
    {"name": "data_req_o", "wave": "01..0.."},
    {"name": "data_gnt_i", "wave": "0..10.."},
    {"name": "data_rvalid_i", "wave": "0....10"},
    {"name": "data_rdata_i", "wave": "xxxxx=x", "data": ["RData"]}
  ],
  "config": { "hscale": 2 }
}

So we have:

1. A bug: wavedrom should not generate invalid SVG.
2. More to investigate: is the wavedrom source actually wrong, or is the conversion wrong?
3. More error reporting would be helpful, getting the file which causes the error required adding print statements across the sources.

dbg_req_i & irq_req_ctrl_i both are high

Following assertion in zeroriscy_controller (Line 515) is failing in 12 cycles after reset in formal. I've turned on the PULP_FPGA_EMUL to not use clock gating for now to check this. Can send the VCD but not allowed to attach here.

assert property (
@(posedge clk) (~(dbg_req_i & irq_req_ctrl_i)) ) else $warning("Both dbg_req_i and irq_req_ctrl_i are active");

Implement trap handling according to latest RISC-V spec

Hi guys (@vogelpi , @imphil )

according to the Priv ISA Spec of RISC-V 1.10, you should handle the exceptions by always jumping to mtvec rather than vectoring them as it was in the past

Look at the section
3.1.12 Machine Trap-Vector Base-Address Register (mtvec)
of this document please: https://riscv.org/specifications/privileged-isa/

I have already done it in RISCY.
So now in the controller everytime you get an exception you set exc_pc_mux_o to exceptions:
https://github.com/pulp-platform/riscv/blob/master/rtl/riscv_controller.sv#L731

and in the IF stage you always jump to the same address regardless the exception cause:
https://github.com/pulp-platform/riscv/blob/master/rtl/riscv_if_stage.sv#L141

Boot Address

Hi
Something strange is happening, I have defined the Reset / Boot address to be 0x80000000
but the first address fetched is 0x80000080
How do I define the reset address I wish to be the first fetch address ?

Thx
Lee

migrating to micro-riscy configuration problem

Hello I am having a bit of trouble configuring the processor to work as "micro-riscy"

I changed all the:
parameter RV32M = 0 instead of 1
and
parameter RV32E = 1 instead of 0

But I still see mult_div signals in the modelsim waveform.

Is there anything else that I need to do in order to configure to that version.

Thankyou

Replace block diagram with updated version

The block diagram at https://ibex-core.readthedocs.io/en/latest/introduction.html is outdated and should be replaced. Unfortunately we need to redraw it as the SVG cannot be opened in Inkscape for unknown reasons, and the original file seems to be lost.

Remove reg-reg loads

reg-reg load (i.e., offset taken from a register and not from an immediate) should not be part of the Ibex ISA.

The code at line 261 here:
https://github.com/lowRISC/ibex/blob/master/rtl/ibex_decoder.sv

is a piece of code coming from RISCY and it should be removed.

Issues using Zero-Riscy in Vivado

I apologize in advance if this is the wrong place to post this, but I could not think of anywhere else. I intend to use the Zero-Riscy core as part of a Xilinx Vivado project, but I have encountered two issues that I was hoping someone might be able to answer.

1. When running behavioral simulation and synthesis, several errors occur: "illegal context for assignment pattern" for lines 172 - 174, 181, 182, 189, 190, 197, 204, 211, 212, 222, 225, 256, 260, 284, and 285 in 'zeroriscy_tracer.sv'. I am more familiar with Verilog than SystemVerilog and searching for solutions provided no answers. What should I do?

2. After reading the documentation, thoroughly, I am still unsure how to start the core's main operation. I've set 'clk_i' to a steady clock and set both 'clock_en_i' and 'fetch_enable_i' positive as part of my testbench. What is it that I have missed?

Thank you so much and sorry for your trouble.

Prefetcher busy_o

Two asserts that check that busy_o in the prefetch_buffer can change its state are failing. The assert that checks that once busy_o is low it can go high in future is failing in two clock cycles; this one I'm more inclined to say it can be a setup issue, as I'm still not fully familiar with the design; the interfaces are not fully specified either so difficult to say. However, the assert that says once you're busy you should become not busy eventually is also failing at 6 clock cycles suggesting it is possible to put the prefetcher in the busy state forever.

Number of performance counters

the parameter MHPMCounterNum does not seem to influence the number of performance counters. I synthesized the core once with MHPMCounterNum=1 and then with MHPMCounterNum=8 and it results in almost exactly the same area.

by looking at the code I also don't see how this parameter is changing the number of physically present counters/flipflops. I'm pretty sure there are 32 64b registers and 32 64b adders no matter what the parameters are.

I think MHPMCounterWidth has the same problem. it probably only counts to the desired width, but the registers [63:MHPMCounteWidth] cannot be optimized away.

the problem with the width can be easily fixed by changing:

csr_rdata_int = mhpmcounter_q[mhpmcounter_idx][63:32];

to

csr_rdata_int[MHPMCounterWidth-1:0] = mhpmcounter_q[mhpmcounter_idx][MHPMCounterWidth-1:32];
csr_rdata_int[32-1:MHPMCounterWidth-32] = '0;

if mhpmcounter_q[63:MHPMCounterWidth] is never accessed, the synthesizer can optimize it away. otherwise these registers are there but cannot really be used.

interrupt & interrupt_disable

the core wakes up when an interrupt is received, but the mie=0. I think that's a bug.

https://github.com/lowRISC/ibex/blob/master/rtl/ibex_core.sv#L279

should be:

  assign clock_en    = core_busy |  (irq_i & m_irq_enable)  | debug_req_i;

I'm also not sure about the behaviour of mret. I think if mret is executed twice it will enable the mie which could lead to problems:
https://github.com/lowRISC/ibex/blob/master/rtl/ibex_cs_registers.sv#L418-L426

in ibex_cs_registers.sv:

      csr_restore_mret_i: begin //MRET
        mstatus_n.mie  = mstatus_q.mpie;
        mstatus_n.mpie = 1'b1;
      end //csr_restore_mret_i

      csr_restore_dret_i: begin //DRET
        mstatus_n.mie  = mstatus_q.mpie;
        mstatus_n.mpie = 1'b1;
      end //csr_restore_dret_i

I think mpie should be reset to either 0 or the value of mie, but I'm not sure what the correct behaviour is:

      csr_restore_mret_i: begin //MRET
        mstatus_n.mie  = mstatus_q.mpie;
        mstatus_n.mpie = mstatus_q.mie;
      end //csr_restore_mret_i

      csr_restore_dret_i: begin //DRET
        mstatus_n.mie  = mstatus_q.mpie;
        mstatus_n.mpie = mstatus_q.mie;
      end //csr_restore_dret_i

Switch back to upstream Sphinx package

Once a Sphinx release with sphinx-doc/sphinx#6364 is out we need to switch back to it, we're currently using a fork to fix a bug.

ibex/doc/requirements.txt

Line 2 in 62185d0

git+https://github.com/wallento/sphinx@fix-latex-figure-in-admonition#egg=sphinx

Replace non-unique `case` constructs by `unique case`

There are still many non-unique case constructs in the ibex code base that should be replaced by unique case constructs with a proper default as required by our coding guidelines.

N_EXT_PERF_COUNTERS

Wonder what the correct value of parameter N_EXT_PERF_COUNTERS should be?

The current instance of it being set to 0
parameter N_EXT_PERF_COUNTERS = 0

followed by

input logic [N_EXT_PERF_COUNTERS-1:0] ext_perf_counters_i

doesn't make much sense.

Decode HINT as NOP

The core fetched an compressed instruction like below.

From a downstream bug report:

core 0: 0xffffffff8000f2ec (0x00009056) add zero, zero, s5

0x9056 is correctly decoded as HINT instruction by spike, but ibex decode it as illegal C.EBREAK instruction:

https://github.com/lowRISC/stwg-base/blob/master/hw/vendor/lowrisc_ibex/rtl/ibex_compressed_decoder.sv#L215

              if (instr_i[11:7] == 5'b0) begin
                // c.ebreak -> ebreak
                instr_o = {32'h00_10_00_73};
                if (instr_i[6:2] != 5'b0) illegal_instr_o = 1'b1;

This code first checks if instr[11:7] is zero to determine if it's c.ebreak instruction, then check instr[6:2] to see if it's illegal. However, when instr[6:2] == 0 and instr_i[11:7] != 0, it should be treated as HINT instruction rather than illegal instruction.

Bit clear operation (`csrrc` and `csrrci` ops) wrong for performance counter registers

Looking at RTL, clear operations are implemented bad. Applies to all CSRs related to performance counters (PCMR, PCER, PCCRx).

Below is the sample code for PCMR, but the same pattern applies to the other CSRs. Rather than inverting the register value, do invert the mask (i.e. csr_wdata_i).

https://github.com/pulp-platform/zero-riscy/blob/b1b89f55fb1dbbf6f35ac5f92c5c1d12b2f41d45/zeroriscy_cs_registers.sv#L431

Document trap precision

The RISC-V spec gives us some flexibility how precise traps should be. We need to document our current behavior.

I'd expect all traps to be precise, but we should double-check with the code.

[tracking] Synthesize Ibex with Yosys

This is a tracking bug. This description will be updated to reflect the current state of affairs. Comment if you have suggestions or updates.

Yosys currently supports only a limited subset of SystemVerilog, which isn't sufficient to parse Ibex. This issue tracks the outstanding issues. We are generally open to find a common ground between tools, but only as long as it doesn't affect code quality and correctness. This means some issues will be resolved upstream in Yosys, while others might be worked around in Ibex.

Updated 2020-08-20. We're almost there, thanks to the work of @kgugala and others at Antmicro, and of course the Yosys reviewers!

We currently know of these issues which are still blocking us from synthesizing Ibex with Yosys:

• YosysHQ/yosys#2331
• YosysHQ/yosys#2330
• YosysHQ/yosys#2329
• YosysHQ/yosys#2312
• YosysHQ/yosys#2248

Test trap precision

Add DV to ensure that traps are as precise as we expect them to be. This requires the expectations to be documented first in #86.

PCMR bits swapped in documentation

Looking at the RTL code, the function of Global Enable and Saturation is swapped in the documentation. Saturation is really controlled by bit 1 and enable by bit 0.

Please indicate which one is correct. RTL or doc?

https://github.com/pulp-platform/zero-riscy/blob/c6eeb34f57ff1cec354a74e025b889c26138146b/doc/performance_counters.rst#L16-L26

https://github.com/pulp-platform/zero-riscy/blob/b1b89f55fb1dbbf6f35ac5f92c5c1d12b2f41d45/zeroriscy_cs_registers.sv#L401-L406

Testbench for running simulations

Hi,

I was going through the source directory but couldn't find an existing Testbench which could be used to run sims. Is there a chance that the TB would also made open-source?

Cleanup: Remove REG_* defines from ibex_id_stage

Can we get rid of those defines and replace them by parameters or structs?

Why performance counters don’t start counting right away

Hello, I would like to ask, why the program has been executed for a while during the simulation process, and the performance counters will start working. Instead of starting work immediately during system startup.
Is it because the firmware code is being executed? Does the performance counter work require firmware? If the firmware code is not executing, what is the operation, causing the performance counters to not start working immediately?

@zarubaf @Razer6 @wallento

Evaluate the feasibility of parameterising ibex by XLEN

It could be interesting to support RV64I as well as RV32I (imagine small helper cores, with access to the same address space as a larger 64-bit application cores). Before leaping into doing this, someone needs to do the ground work to see how disruptive it might be, so we can evaluate the potential maintenance / readability costs vs the benefits of supporting an RV64I configuration.

Illegal assignment of logic variable to enum type port

Hi there,
The following illegal assignment is found:

ibex/rtl/ibex_core.sv

Line 482 in 93b0b77

.csr_op_i ( csr_op ),

Changing the csr_op to enum type should be combined with a change in csr_op_ex as well as the relevant signals in "ibex_id_stage.sv".

Best,
Ioannis

Standard-compliant performance counters

We need to look into performance counters and see how we can implement them in a standard-compliant way (or ensure that we document where we have good reasons to deviate).

While at it, check #17, #16 and #15 to see if they are valid and fix/close as needed.

Missing description of input signal from documentation.

Hi,
Description of input "data_err_i" of the data memory interface is missing from documentation. This signal is currently used only for an assertion. Since it is a top level input, I believe it would be better for the user to read about it in the documentation instead of figuring it out from the RTL.

Best,
Ioannis

Implement sleep with wfi instruction

We currently implement the WFI instruction as NOP. This implementation is correct, but we should think about putting the core to sleep instead to save power.