axi_slice has been re-written and re-named to axi_cut and is a standard component within the axi repo.

The issues templates are slightly modified from the verification repo.
they should be reviewed by the HW TG chairperson

utils/ioscript does multiple things:

1. reads rtl/../data/*.csv and produces .md files for documentation -- this is accessed with a 'make' in docs/
2. reads rtl/../data/*.csv and produces .h files for software -- I think there should be a sw/ folder parallel to /docs with a make for this
3. read rtl/../data/*.csv and produces .svh files for simulation/emulation/synthesis -- ???
4. reads pintable.csv and produces .sv and .svh files for simulation/emulation/synthesis -- ???

My question is how we want to handle the last two cases. If we used make, then that would handle running ioscript if the pintable or pulp_soc_defines.sv were updated. But the current scheme uses ./generate_scripts instead of make.

One option would be to modify the generated scripts to invoke ioscript so that there is no issue of stale files. ioscript is pretty fast, so I don't think this would be onerous. The drawback to this approach is that the changes have to be introduced into each script -- verilator/questa/xilinx/synopsys etc.

Another option is to incorporate this in the top-level make. A drawback to this is that the current methodology doesn't recommend using the top-level make.

A final question is what happens if we switch to fusesoc, and therefore what would be most compatible.

Currently, we are missing a couple of Quicklogic modules:

@timsaxe and team, I'd like to have your input on this:

• Can we open source this? Or is it proprietory?
• If we can't how can we make a behavioral module for those components or stub the FPGA?

As soon as we have an agreement we can proceed with a further issue.

Hi,
I was wondering if there are any plans for other FPGA ports. I'd mostly be interested in Zedboard and ZCU102.

In the past these ports (and softcores as standalone projects in general) have been a bit annoying because you had to use an external JTAG programmer since the on-board USB-JTAG was only connected to the ARM CPU (PS). I am currently evaluating if it would be possible to get rid of that with an IP core xilinx added to vivado 2019.2 (I think... hard do determine with Xilinx "documentation"): https://www.xilinx.com/products/intellectual-property/bscan-to-jtag-converter.html Does anybody have some insights into that?

Also, is there any communication channel/mailing list used specifically for core-v mcu? is there a openhwgroup irc channel?

I fail to understand why we would need to different timer units in the system. Can somebody enlighten me, please? @davideschiavone @timsaxe @gmartin102

Hi!

It looks like this project is using the LowRISC style guide. You thus might be interested in Google's verible project which provides an Apache 2.0 licensed SystemVerilog linter and code formatter with the LowRISC style guide as an early target!

Due to the permissive license, you can even run the linter on CI systems like Travis CI, GitHub actions or Azure Pipelines to check that your code stays in compliance!

Good luck with your project!

Is it known that the signal is multiply driven? Would be good to check this.

I'd like to get your input on removing the hwpe. Are you using it in QuickLogic @timsaxe?

Further input requested from @davideschiavone @gmartin102.

Template for CORE-V-MCU Task Issues

Tasks are defined, assigned and tracked as GitHub Issues. For obvious reasons,
the template for a task is very different from the template for a bug.

Please use this file as a template for creating Tasks to create or update any of
the documentation in this repository.

Hint: click on the edit symbol (looks like a pencil) and then
edit the markdown source to create your issue.

Task Title

A clear and concise description of the Task. This can go in the titlebar.

Task Outcome

Provide a brief description of what is expected. For example, "Implement an
XYZ UVM Agent." If necessary point to a specification document.

Background information

If necessary point to a specification in an outside document.

Location Information

Specify the path, relative to the root of this GutHub project, of the code that
will be created and/or modified.

Completion Criteria

Answer the question: how does the Assignee know they are done?

Additional context

Add any other context about the problem here.

Searching all IP repositories for pulp_soc_defines.sv (rg -w pulp_soc_defines -g '!core-v-mcu/*') leads to:

cluster_interconnect/rtl/peripheral_interco/AddressDecoder_PE_Req.sv
46:`include "pulp_soc_defines.sv"

IPs should be stand-alone and should not depend on includes. Let's refactor and remove them!

I am not able to build the datasheet from sources. Either I am missing some utilties or there are missing cls files. Here is the output from make all (see "Steps to Reproduce" below for additional information):

*****
***** Printing Tgif figure:
***************************
***** ./figures_raw/riscv_overview.eps
In reading state, cannot find color #62, use 'Black' as the current color.
*****
***** Converting Tgif EPS to PDF:
*********************************
***** ./figures_raw/riscv_overview.eps --> ./figures_raw/riscv_overview.pdf
*****
***** Moving EPS and PDF figures
********************************
***** ./figures_raw/riscv_overview.eps --> ./figures/riscv_overview.eps
***** ./figures_raw/riscv_overview.pdf --> ./figures/riscv_overview.pdf
*****
pdflatex datasheet.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./datasheet.tex
LaTeX2e <2020-02-02> patch level 2
L3 programming layer <2020-02-14>

! LaTeX Error: File `scrbook.cls' not found.

Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: cls)

Steps to Reproduce

$ cd core-v-mcu/doc/datasheet
$ make all

This generated a lot of errors due to missing utilities and packages, so I also did the following:

$ sudo apt-get install epstopdf
$ sudo apt install texlive-font-utils
$ sudo apt install tgif
$ sudo apt-get install xfonts-75dpi
$ sudo apt-get install gsfonts-x11

axi_slice_dc has been re-written and re-named to axi_cdc and is a standard component in axi.

Currently the FPGA and ASIC specific modules are ifdefed and scattered throughout the code. I would propose two fixes to that:

• SRAMs are wrapped in technology unspecific ways. During implementation, they can be substituted with the tech specific versions. Similar to other tech specific components (see tech_cells_generic).
• For the clock generator I would propose we pull out the clock into the top-level. For the FPGA we can instantiate the clock generator in xilinx_core_v_mcu.v (or use the block generator). For the ASIC I would suggest we keep core_v_mcu_chip.sv where we instantiate the FLL. That would also allow us to remove the VHDL stub of FLL which is a. annoying with Verilator and b. contains too much information for RTL sim IMHO.

Template for CORE-V-MCU Issues

Bug Title

fpga/readme shows git clone -branch v1 for cloning pulp-sdk. Should be --branch (or -b)

Type

Documentation error

Steps to Reproduce

Cut and paste the git clone for pulp-sdk

Additional context

Add any other context about the problem here.

Fusesoc comes with pretty nice FPGA support. That would also help to target different FPGA boards with less code duplication. Things to figure out:

• How we can generate the IPs as part of the fusesoc flow (if this is at all necessary): olofk/fusesoc#505
• How to parameterize the platform and fpga: https://github.com/fusesoc/blinky/blob/1563da51e7169dfc993c1603b88b838f51556ada/blinky.core

Template for CORE-V-MCU Issues

Bug Title

The main readme.md refers to fpga/readme.md in the cmc repo which is not in sync

Type

Documentation

Steps to Reproduce

Go to main readme, click on following link:

Instructions to install the Core-v-mcu environment, instantiate the CV32E40P processor, and
build the FPGA platform are [here](https://github.com/hpollittsmith/core-v-mcu/tree/master/fpga).

Additional context

The precise issue that I ran into is that the cmc version refers to configs/platform_fpga.sh when the file is actually named configs/platform-fpga.sh. This is correct in the OHW repo.

Bug Title

GDB in prebuilt pulp toolchain lack to tui support

Type

• Toolchain

Description

I used the riscv32-unknown-elf-gdb in suggested Embecosm PULP GCC toolchain to connect to a cv32e40p FPGA. The debugging can work, but it is lacking of tui support so can't achieve interactive debugging

$ riscv32-unknown-elf-gdb --tui build/bubble/bubble
riscv32-unknown-elf-gdb: TUI mode is not supported

I build my own toolchain from pulp-riscv-gnu-toolchain, the tui mode is supported, however when I try to connect to target, there is a segmentation fault reported. Seems some patch/extra-configuration are needed for general toolchain to support cv32e40p.

Can tui mode be added in pre-built toolchain, or instruction can be given on how to build cv32e40p toolchain by ourselves.

Block RAMs can be inferred using either the correct coding style or Xilinx Parameterized Macros (XPM) such as used in the tc_srams.

i'm running hello application for ZedBoard FPGA and no thing displayed with screen /dev/ttyUSB0 115200

Configuration

• PULP-RISCV-TOOLCHAIN ( Pre-built)
• PULP-SDK
• Processor : CV32E40P
• Soc : Pulpissimo
• Board: ZedBoard FPGA

JTAG and UART Connections:

C Program

Openocd

GDB

screen /dev/ttyUSB0 115200

I don't know why nothing is displayed on the screen.
Any suggestions are appreciated
Thanks!

Currently, the script to generate the IO configuration is missing. That is why I needed to add some stubs for pad_control and pad_frame. Let's bring the pad frame generator into the open space and we can also check-in a known good configuration?

Of course, comments more than welcome!

Due to the IO changes, there isn't a valid IO assignment for the Gensys2 board available. If that has been fixed we can try to re-enable the FPGA target.

Legacy, but the sub-tasks hold.

Migrate Content from master:

• Instantiate CV32E40P. A fork of the SoC is going to be necessary.
• Update documentation.

I've created two branches in this repository:

• pulpissimo which contains an up-to-date tree of PULPissimo.
• core-v-mcu which currently also contains an up-to-date tree of PULPissimo. This is the target branch to where we want to port the changes.
• Finally, there is a legacy master branch that contains the work of @hpollittsmith so far, as a back-up and inspiration if needed.

The idea is to re-introduce the changes to the core-v-mcu branch in a consistent and upstreamable manner. Finally, we are going to (try) upstream the changes to PULPissimo.

Let's use this task to break-out the different sub-tasks and track the necessary changes. So far I have:

• Fork pulp_soc add CV32E40P, point the commit to a stable commit within openhwgroup/pulp_soc (#43)
• Adjust documentation (#45)
• CI/CD for Genesys 2/Nexys A7 (#44)

When bringing up verilator I ran into two issues:

• core-v-mcu/rtl/core-v-mcu/top/pad_frame.sv

  Line 130 in 57c8dc3

  .O (jtag_tdo_i),

  jtag_tdo_i is connected to an output, I guess that is probably a problem with the IO script. @timsaxe
• https://github.com/openhwgroup/core-v-mcu/blob/57c8dc34f3ecbb079cf14c8562b01d73fd9f476d/rtl/vendor/pulp_platform_tech_cells_generic/src/deprecated/pad_functional.sv The pmos and nmos primitives are not supported in Verilator. I would like to have your opinion on whether we can generate the pad frame (including the pads) in a new layer around core_v_mcu (one for the chip and one for the FPGA). That would help us entangle the situation a bit and allow for Verilator simulation.

I'd like to have your input @timsaxe, @gmartin102, @davideschiavone

Template for CORE-V-MCU Task Issues

Tasks are defined, assigned and tracked as GitHub Issues. For obvious reasons,
the template for a task is very different from the template for a bug.

Please use this file as a template for creating Tasks to create or update any of
the documentation in this repository.

Hint: click on the edit symbol (looks like a pencil) and then
edit the markdown source to create your issue.

Task Title

A clear and concise description of the Task. This can go in the titlebar.

Task Outcome

Provide a brief description of what is expected. For example, "Implement an
XYZ UVM Agent." If necessary point to a specification document.

Background information

If necessary point to a specification in an outside document.

Location Information

Specify the path, relative to the root of this GutHub project, of the code that
will be created and/or modified.

Completion Criteria

Answer the question: how does the Assignee know they are done?

Additional context

Add any other context about the problem here.

Install continuous delivery of FPGA bitstreams for:

• Genesys 2
• Nexys A7

I've already set-up the required FPGA container. The remaining challenges are:

• Make sure PULPissimo synthesizes correctly to FPGA. I could see that support for the Nexys board is somehow broken.
• Setting up a (fork local) CI flow
• Decide whether to run the implementation flow nightly and/or on push to master.
• Pushing the artifacts and deciding where they should live:
  • For dedicated (stable) versions I would suggest we host them as part of the release data.
  • For nightly regressions, I suggest we host the last n bitstreams on something like S3.
• Clearly link to the bitstream location in the project's README.

Any input is very welcome.

Currently, the testbench is pretty overloaded with functionality and legacy, which ideally, I would like to re-factor into:

• A small testbench to just execute small test programs. What kind of software are we running on it?
• A chip-level testbench, potentially in the implementation repo, that contains models for the peripherals, etc.

I am creating this tracking issue to see how we can bring up the Verilator testbench. @jeremybennett if you can point me towards the GDB resources that could be very helpful.

Currently, the crossbar pulls in a lot of unnecessary dependencies and is one big monolithic block. I think there is a replacement in the making for it based on better verified standard components. We should see how we could (if we want) integrate it. Alternatively, we can also architect a more tailored solution for the next gen.

• Automate FPGA building
• Automate publishing to i.e., S3 buckets

We have quite some port explosion going on, for example when looking at soc_peripherals.sv. I'd suggest we try to bundle up the ports of the same type into structs which we can have in a core_v_mcu_pkg.sv.

fc_subsystem.sv connects the incorrect interrupts from apb_interrupt_cntrl.sv. core_irq_x is a priority encoded vector, but since cv32e40p uses fast interrupts irq_o vector from apb_interrupt_cntrl was added to present unmasked pending interrupts to th cv32e40p

Template for CORE-V-MCU Task Issues

Tasks are defined, assigned and tracked as GitHub Issues. For obvious reasons,
the template for a task is very different from the template for a bug.

Please use this file as a template for creating Tasks to create or update any of
the documentation in this repository.

Hint: click on the edit symbol (looks like a pencil) and then
edit the markdown source to create your issue.

Task Title

A clear and concise description of the Task. This can go in the titlebar.

Task Outcome

Provide a brief description of what is expected. For example, "Implement an
XYZ UVM Agent." If necessary point to a specification document.

Background information

If necessary point to a specification in an outside document.

Location Information

Specify the path, relative to the root of this GutHub project, of the code that
will be created and/or modified.

Completion Criteria

Answer the question: how does the Assignee know they are done?

Additional context

Add any other context about the problem here.

To resolve the clock_gating_module for FPGA synthesis, so that cv32e40p code doesn't need to be modified, I'm suggesting the following:

• Create core-v-mcu/fpga/pulpissimo-nexys/rtl/cv32e40p_clock_gating_xilinx.sv; this is a copy of pulp_clock_gating_xilinx.sv in the same directory, with the gating module and ports renamed to match with cv32e40p requirement
• Modify core-v-mcu/fpga/pulpissimo-nexys/tcl/run.tcl to add cv32e40p_clock_gating_xilinx.sv as source file

Note this would have to be repeated for Genesys2, etc.

Other suggestions?

At least one hart must have a known hart ID of zero

As per the The RISC-V Instruction Set Manual Volume II: Privileged Architecture, paragraph 3.1.5 "The mhartid CSR is an XLEN-bit read-only register containing the integer ID of the hardware thread running the code. This register must be readable in any implementation. Hart IDs might not necessarily be numbered contiguously in a multiprocessor system, but at least one hart must have a hart ID of zero". Currently the only hart in Core-V-MCU platform is assigned an id of 992 - see

Bug Type

This is an implementation bug - the behavior exhibited does not comply with RISC-V Instruction Manual requirements.

Steps to Reproduce

1. Follow instructions in the Core-v-mcu project repository to build bare metal example bubble sort application but add the following code in the main function

        unsigned int hartId = 12345;

        __asm volatile( "csrr %0, mhartid" : "=r"( hartId ) );

        printf("Hart ID is %u \n\r", hartId); 

2. Open the serial console and run the example code that prints the hart id as per the instructions, and verify printed hart ID is 992 and not 0

Hart ID is 992                                                               
Unsorted array: ...

Additional context

Operating systems such as Linux and FreeRTOS may rely on running system critical code on a single hart with id of 0, and no such is present in Core-V-MCU.

Is the SCM (standard-cell memory) actually needed? Are you looking for such features @timsaxe?

@davideschiavone do you happen to know more, whats your take?

apb_node violates the APB standard which makes it inconvenient to attach peripherals that are actually looking for standard compliance. Luckily, there is a new component axi_to_apb which is standard compliant. That would also allow us to remove the said modules.

PULPissimo should be fully compliant with the RISC-V debug specification so I don't see why this legacy module is still needed. Imho the module can be removed.

@gmartin102 noticed a number of other places where the width is hardcoded [19:0]. They should probably be fixed to be APB_FPGA_ADDR_WIDTH also. Please @gmartin102 if you could address that in a separate pull request?

Reference #107

Fix the issue templates:

• They contain typos (e.g., GutHub) and inconsistent capitalization.
• Furthermore, the structure is non-intuitive and the template is overly long and complex. As they are now I think it would be better to remove them entirely. For example, they have multiple title fields, it is unclear where to put the necessary information.

This task tracks the MCU documentation writing progress

Template for CORE-V-MCU Task Issues

Tasks are defined, assigned and tracked as GitHub Issues. For obvious reasons,
the template for a task is very different from the template for a bug.

Please use this file as a template for creating Tasks to create or update any of
the documentation in this repository.

Hint: click on the edit symbol (looks like a pencil) and then
edit the markdown source to create your issue.

Task Title

A clear and concise description of the Task. This can go in the titlebar.

Task Outcome

Provide a brief description of what is expected. For example, "Implement an
XYZ UVM Agent." If necessary point to a specification document.

Background information

If necessary point to a specification in an outside document.

Location Information

Specify the path, relative to the root of this GutHub project, of the code that
will be created and/or modified.

Completion Criteria

Answer the question: how does the Assignee know they are done?

Additional context

Add any other context about the problem here.

• Fork pulp_soc in OpenHW Group
• Update core-v-mcu ips_list with OpenHW Group pulp_soc
• Integrate CV32E40P
• Define interrupt mapping
• Push to PULP pulp_soc repository our contribution

Please Greg Martin, @timsaxe, @jeremybennett define how the interrupts should be mapped in the CV32E40P core and document it so that HW and SW(freeRTOS) get aligned on it.