chipyard | An Agile RISC-V SoC Design Framework with in-order cores, out-of-order cores, accelerators, and more

by ucb-bar C Version: 1.9.1 License: BSD-3-Clause

X-Ray Key Features Code Snippets Community Discussions(5)Vulnerabilities Install Support

kandi X-RAY | chipyard Summary

chipyard is a C library typically used in Embedded System applications. chipyard has no bugs, it has no vulnerabilities, it has a Permissive License and it has medium support. You can download it from GitHub.

Chipyard is an open source framework for agile development of Chisel-based systems-on-chip. It will allow you to leverage the Chisel HDL, Rocket Chip SoC generator, and other Berkeley projects to produce a RISC-V SoC with everything from MMIO-mapped peripherals to custom accelerators. Chipyard contains processor cores (Rocket, BOOM, CVA6 (Ariane)), accelerators (Hwacha, Gemmini, NVDLA), memory systems, and additional peripherals and tooling to help create a full featured SoC. Chipyard supports multiple concurrent flows of agile hardware development, including software RTL simulation, FPGA-accelerated simulation (FireSim), automated VLSI flows (Hammer), and software workload generation for bare-metal and Linux-based systems (FireMarshal). Chipyard is actively developed in the Berkeley Architecture Research Group in the Electrical Engineering and Computer Sciences Department at the University of California, Berkeley.

Support

Quality

Security

License

Reuse

Support

chipyard has a medium active ecosystem.

It has 1133 star(s) with 495 fork(s). There are 81 watchers for this library.

It had no major release in the last 12 months.

There are 111 open issues and 424 have been closed. On average issues are closed in 68 days. There are 21 open pull requests and 0 closed requests.

It has a neutral sentiment in the developer community.

The latest version of chipyard is 1.9.1

Quality

chipyard has 0 bugs and 0 code smells.

Security

chipyard has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

chipyard code analysis shows 0 unresolved vulnerabilities.

There are 0 security hotspots that need review.

License

chipyard is licensed under the BSD-3-Clause License. This license is Permissive.

Permissive licenses have the least restrictions, and you can use them in most projects.

Reuse

chipyard releases are available to install and integrate.

Installation instructions are not available. Examples and code snippets are available.

Top functions reviewed by kandi - BETA

kandi's functional review helps you automatically verify the functionalities of the libraries and avoid rework.
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of chipyard

Get all kandi verified functions for this library.

chipyard Key Features

No Key Features are available at this moment for chipyard.

chipyard Examples and Code Snippets

No Code Snippets are available at this moment for chipyard.

Community Discussions

Trending Discussions on chipyard

Adding an MMIO peripheral to Rocket-chip as a submodule

Developing Generic AXI4 Peripheral with Chisel

Is this caused by insufficient memory?

Running OpenOCD fails with jtagRocketConfig

Accessing Hardware Performance Counters in RISC-V

QUESTION

Adding an MMIO peripheral to Rocket-chip as a submodule

Asked 2022-Mar-03 at 16:36

I followed the MMIO Peripherals page from the Chipyard documentation to learn about adding modules to rocket-chip within Chipyard framework - and all that seems to have worked pretty well. I summed up my experiences and tried to write it in a slower pace on the pages of the Chisel Learning Journey <== adding that only if the person answering question may want to take a look and see that I've got everything working correctly. In other words, I added the MMIO with in the example package of Chipyard and it compiles, generates simulator, responds properly to toy benchmark I devised, I even see the corresponding waveforms in gtkwave.

Now, the next step I would like to take is to separate this dummy design (it literally just reads from a memory mapped register that holds a hardcoded value) from the chipyard/rocket-chip infrastructure in the sense that it is housed in a separate repo, that will become a submodule of my chipyard. So, to do that, I've started from this page and took all the steps as given there:

a new repo was created, called it my-chip
into the my-chip I added build.sbt of the following content:

...

ANSWER

Answered 2022-Mar-03 at 16:36

The error comes from the - in lazy val my-chip and package my-chip. If you want to use a - in a scala name you can wrap the name in backticks, like `my-chip`.

Source https://stackoverflow.com/questions/71237637

QUESTION

Developing Generic AXI4 Peripheral with Chisel

Asked 2022-Feb-10 at 17:09

I want to develop a generic AXI4 peripheral with Chisel. Can I use the Rocket-Chip's AMBA library for this purpose? I could only find the document in the link below on this subject;

MMIO-Peripherals

However, the example in this document is designed to be used with the Rocket-Chip. I want to develop a standalone AXI4 peripheral.

...

ANSWER

Answered 2022-Feb-09 at 16:44

Your question mentions following:

I want to develop a standalone Axi4 peripheral

When I had started developing AXI4 interfaces in Chisel, my starting point was the Chisel official documentation where they start with a typical Verilog peripheral using AXI4 for a write channel as following:

Source https://stackoverflow.com/questions/71049419

QUESTION

Is this caused by insufficient memory?

Asked 2021-Mar-19 at 22:17

This problem occurred when I used chipyard to compile Boom. Is this because of insufficient memory? I am running on a 1 core 2G cloud server.

/bin/bash: line 1: 9986 Killed java -Xmx8G -Xss8M -XX:MaxPermSize=256M -jar /home/cuiyujie/workspace/Boom/chipyard/generators/rocket-chip/sbt-launch.jar -Dsbt.sourcemode=true -Dsbt.workspace=/home/cuiyujie/workspace/Boom/chipyard/tools ";project utilities; runMain utilities.GenerateSimFiles -td /home/cuiyujie/workspace/Boom/chipyard/sims/verilator/generated-src/chipyard.TestHarness.LargeBoomConfig -sim verilator" /home/cuiyujie/workspace/Boom/chipyard/common.mk:86: recipe for target '/home/cuiyujie/workspace/Boom/chipyard/sims/verilator/generated-src/chipyard.TestHarness.LargeBoomConfig/sim_files.f' failed make: *** [/home/cuiyujie/workspace/Boom/chipyard/sims/verilator/generated-src/chipyard.TestHarness.LargeBoomConfig/sim_files.f] Error 137

When I adjusted the memory to 4G, this appeared.

Done elaborating. OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006dc3b7000, 97148928, 0) failed; error='Cannot allocate memory' (errno=12)

There is insufficient memory for the Java Runtime Environment to continue. Native memory allocation (mmap) failed to map 97148928 bytes for committing reserved memory. An error report file with more information is saved as: /home/cuiyujie/workspace/Boom/chipyard/hs_err_pid2876.log /home/cuiyujie/workspace/Boom/chipyard/common.mk:97: recipe for target 'generator_temp' failed make: *** [generator_temp] Error 1

Should I adjust to 8G memory, or through what command to increase the memory size that the process can use?

When I adjusted the memory to 16G, this appeared.

/bin/bash: line 1: 2642 Killed java -Xmx8G -Xss8M -XX:MaxPermSize=256M -jar /home/cuiyujie/workspace/Boom/chipyard/generators/rocket-chip/sbt-launch.jar -Dsbt.sourcemode=true -Dsbt.workspace=/home/cuiyujie/workspace/Boom/chipyard/tools ";project tapeout; runMain barstools.tapeout.transforms.GenerateTopAndHarness -o /home/cuiyujie/workspace/Boom/chipyard/sims/verilator/generated-src/chipyard.TestHarness.LargeBoomConfig/chipyard.TestHarness.LargeBoomConfig.top.v -tho /home/cuiyujie/workspace/Boom/chipyard/sims/verilator/generated-src/chipyard.TestHarness.LargeBoomConfig/chipyard.TestHarness.LargeBoomConfig.harness.v -i /home/cuiyujie/workspace/Boom/chipyard/sims/verilator/generated-src/chipyard.TestHarness.LargeBoomConfig/chipyard.TestHarness.LargeBoomConfig.fir --syn-top ChipTop --harness-top TestHarness -faf /home/cuiyujie/workspace/Boom/chipyard/sims/verilator/generated-src/chipyard.TestHarness.LargeBoomConfig/chipyard.TestHarness.LargeBoomConfig.anno.json -tsaof /home/cuiyujie/workspace/Boom/chipyard/sims/verilator/generated-src/chipyard.TestHarness.LargeBoomConfig/chipyard.TestHarness.LargeBoomConfig.top.anno.json -tdf /home/cuiyujie/workspace/Boom/chipyard/sims/verilator/generated-src/chipyard.TestHarness.LargeBoomConfig/firrtl_black_box_resource_files.top.f -tsf /home/cuiyujie/workspace/Boom/chipyard/sims/verilator/generated-src/chipyard.TestHarness.LargeBoomConfig/chipyard.TestHarness.LargeBoomConfig.top.fir -thaof /home/cuiyujie/workspace/Boom/chipyard/sims/verilator/generated-src/chipyard.TestHarness.LargeBoomConfig/chipyard.TestHarness.LargeBoomConfig.harness.anno.json -hdf /home/cuiyujie/workspace/Boom/chipyard/sims/verilator/generated-src/chipyard.TestHarness.LargeBoomConfig/firrtl_black_box_resource_files.harness.f -thf /home/cuiyujie/workspace/Boom/chipyard/sims/verilator/generated-src/chipyard.TestHarness.LargeBoomConfig/chipyard.TestHarness.LargeBoomConfig.harness.fir --infer-rw --repl-seq-mem -c:TestHarness:-o:/home/cuiyujie/workspace/Boom/chipyard/sims/verilator/generated-src/chipyard.TestHarness.LargeBoomConfig/chipyard.TestHarness.LargeBoomConfig.top.mems.conf -thconf /home/cuiyujie/workspace/Boom/chipyard/sims/verilator/generated-src/chipyard.TestHarness.LargeBoomConfig/chipyard.TestHarness.LargeBoomConfig.harness.mems.conf -td /home/cuiyujie/workspace/Boom/chipyard/sims/verilator/generated-src/chipyard.TestHarness.LargeBoomConfig -ll error" /home/cuiyujie/workspace/Boom/chipyard/common.mk:123: recipe for target 'firrtl_temp' failed make: *** [firrtl_temp] Error 137

...

ANSWER

Answered 2021-Mar-09 at 03:23

Short anwer : yes

Error 137 is thrown when your host runs out of memory.

"I am running on a 1 core 2G cloud server"

When you try to assign 8GB to the JVM, OOM-Killer says "no-no, f... no way", and kicks in sending a SIGKILL; This Killer is a proactive process that jumps in to save the system when its memory level goes too low, by killing the resource-abusive processes.

In this case, the abusive process (very abusive, indeed) is your java program, which is trying to allocate more than(*) 4 times the maximum avaliable memory in your host.

Exit Codes With Special Meanings

Source https://stackoverflow.com/questions/66539759

QUESTION

Running OpenOCD fails with jtagRocketConfig

Asked 2020-Mar-27 at 14:49

This is what I get when I try to connect Software RTL simulation and OpenOCD:

...

ANSWER

Answered 2020-Mar-27 at 14:49

I managed to run OpenOCD.

This is the current content of OpenOCD config file:

Source https://stackoverflow.com/questions/60734812

QUESTION

Accessing Hardware Performance Counters in RISC-V

Asked 2020-Feb-08 at 18:41

I would like to instrument a program to access hardware performance counters.

I have compiled a basic Rocketchip (freechips.rocketchip.system-DefaultConfig) and am using riscv-pk to run a binary. I am running a simulation of the core in Verilator, having compiled it all with largely defaults in the UCB Chipyard project.

The C for the binary is as follows:

...

ANSWER

Answered 2020-Feb-08 at 18:41

Yes, pk runs binaries in user mode, thus it's expected that accessing a machine-level register from user space yields a illegal instruction exception:

Attempts to access a CSR without appropriate privilege level or to write a read-only register also raise illegal instruction exceptions.

(RISC-V Privileged spec 1.12-draft 2020-01-13, Section 2.1 CSR Address Mapping Conventions)

The hpmcounter* registers are accessible from user-mode (cf. Table 2.2 Currently allocated RISC-V user-level CSR addresses, RISC-V privileged spec), if and only if they are enabled in the next higher mode:

If S-mode is implemented, the same bit positions in the scounteren register analogously control access to these registers while executing in U-mode. If S-mode is permitted to access a counter register and the corresponding bit is set in scounteren, then U-mode is also permitted to access that register.

The pk snippet that enables them looks sound. The 'S' and 'U' misa bits are defined in the RISC-V privileged spec:

The “U” and “S” bits will be set if there is support for user and supervisor modes respectively.

But note that the RISC-V privileged spec also specifies (emphasis mine):

Registers mcounteren and scounteren are WARL registers that must be implemented if U-mode and S-mode are implemented. Any of the bits may contain a hardwired value of zero, indicating reads to the corresponding counter will cause an illegal instruction exception when executing in a less-privileged mode.

Perhaps your CPU doesn't implement hpmcounter3 and has it hardwired to zero?

To troubleshoot this further you can add a breakpoint inside pk, i.e. right before write_csr(scounteren, -1) and single step assembler instructions to see if the writes actually happen. If they happened you can inspect the registers to check if hpmcounter3 is hardwired to zero or not.

Source https://stackoverflow.com/questions/60048337

Community Discussions, Code Snippets contain sources that include Stack Exchange Network

Vulnerabilities

No vulnerabilities reported

Install chipyard

You can download it from GitHub.

Support

STABLE DOCUMENTATION: https://chipyard.readthedocs.io/USER QUESTION FORUM: https://groups.google.com/forum/#!forum/chipyardBUGS AND FEATURE-REQUESTS: https://github.com/ucb-bar/chipyard/issues

Find more information at: