Untethered lowRISC FPGA_FULL mode simulation Error
Hi, LowRISC team:
When I do FPGA_FULL mode simulation of your Untethered lowRISC version 0.2 got from Git, I meet a strange simulation scenario showed below.
I found the "mem_nasti.r_ready[0:0]" always be 0, but driver of this wire is 1. The driver is "io_nasti_r_ready" of Rocket. So the Hellworld test will be failed.
But if I use FPGA mode to do the simulation for same Helloworld test, it is successful finished. I have checked the difference of this two simulation modes,
the difference are forcus on DRAM(xilinx mig) ,clock and reset generation which is not the interface the Helloworld test need to access.
I am not sure it is VCS simulator's problem, or I missed something?
Waiting your feedback. Thank you!
4 years, 11 months
Design of a multi-core platform based on lowRISC
by Noureddine AIT SAID
I'm new to the lowRISC and RISCV community and also to the SoC and MP-SoC
I'm working on an MP-SoC platform that should run a basic OS with
multithreading based on lowRISC (or Rocket-Chip) which targets a Virtex-7
I decided to begin with the lowRISC because it is untethered and the
additional components that I will need in the future.
*Now I would like to know if there is anybody who already worked on an
MP-SoC before or who is working on it now? Will Linux be capable of running
in the multi-core on the Virtex-7 and what challenges does it take to do
that? Not sure if the actual Linux supports or is going to support SMP?*
I'm thinking of using something light like FreeRTOS instead of linux, I saw
this repository: https://github.com/illustris/FreeRTOS-RISCV but* I'm not
sure how rough will this be to run it on the new platform nor what things
should be changed ? Is there any other minimal OS or app that can run on
the multi-core ?*
As I said I'm new to RISCV, I'm sorry for the very basic questions. I would
be very thankful for any information or documentation/book recommendation.
Thank you very much.
4 years, 12 months
boot linux directly from DDR, (no sdcard)
by Anup Kini
I am trying to boot linux on lowRISC using a custom Virtex-7 board.
Unfortunately, the SD card interface has some issues and I am unable to use
I was able to bring up the lowRISC design and run hello world and dram test
Since, I do not have the SD Card, I tried to load the BBL directly on to
DDR using the custom AXI interface provided by the board vendor.
It loads successfully and a few debug prints from the BBL also show up on
the UART terminal. I had to modify the boot.c code inorder to get this
Going forward, I was curious to know if I can load the vmlinux and root.bin
also to DDR and boot linux.
I understand that the base address for vmlinux is fixed to
Will it be possible for me to change this and boot linux directly from DDR ?
Thanks & Regards,
run-asm-tests fails in lowRISC (untether-v0.2)
by Anshujit Sharma
I wanted to simulate lowRISC untether-v0.2 using verilator as described in
Following is the sequence of commands used:
fails with the following terminal output:
./DefaultConfig-sim +max-cycles=100000000 +load=output/towers.riscv.hex |
output/towers.riscv.verilator.out && [ $PIPESTATUS -eq 0 ]
Core 0 get unsolved tohost code 21680
Makefile:201: recipe for target 'output/towers.riscv.verilator.out' failed
make: *** [output/towers.riscv.verilator.out] Error 1
Kindly, let me know how to debug this problem.
Computer Aided Design Laboratory
Department of Computational and Data Sciences <http://cds.iisc.ac.in/>
Indian Institute of Science
Bangalore: 560012, India
Tel: +918011223483, +917406490246
email: anshujit(a)cadl.iisc.ernet.in, anshujitsharma(a)gmail.com
upgrading lowrisc sd/mmc to eMMC (and SPI)
by Luke Kenneth Casson Leighton
ok so i am talking to rudolf from asics.ws, and for the shakti m_class
core it needs to have eMMC. would it be of interest to lowRISC to
have eMMC (8-bit SD/MMC), and if so would the CIC behind lowRISC be
interested to share the development cost for rudolf's time?
if yes i can specifically ask him to start from ethernet-v0.5 (or
other suitable branch). i may ask him that anyway as it's likely the
easiest (libre-licensed) stack to work with.
p.s. there *is* a linux kernel driver for the sd/mmc interface, right?
:) it doesn't have to be absolutely up-to-date / mainline, it just
has to "work".