libncursesw-dev does not exist

[srinisy-22]

when I run this command sudo apt-get install libncurses5 libncursesw-dev, the error message displayed is Reading package lists... Done Building dependency tree
Reading state information... Done E: Unable to locate package libncursesw-dev Due to this my xlininx installation also fails. Kindly help me out setting this up.

[srinisy-22]

Due to this I am not able to run ./xsetup and it throws this error : error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory

[samsoniuk]

hmmmm maybe there is a typo! I checked there and found the following installed packages:

libncurses5 libncurses5-dev libncursesw5 libncursesw5-dev

but I have no libncursesw-dev, so try install the same as above and try run the xsetup again.

regards, marcelo

[srinisy-22]

Hello,

Thanks for the response. I did Try this out and it got installed and ./xsetup worked. But When I followed the video I couldn't find the License file for ISE Xilinx. I made a request for a license at the AMD website and requested the ISE Embedded Editions License file. and I loaded it at the ISE interface. But it didn't work as expected and the make command at darkriscv/ results in a failure. This is the failure

[srinisy-22]

Is there another license file I need to analyze?

[srinisy-22]

Sorry or load into the ise interface?

[samsoniuk]

The iverilog (Icarus) is not part of ISE, so you can try open a ISE project directly on the graphic interface and run the simulation directly on ISE, for example:

boards/avnet_microboard_lx9/darksocv.xise

In the case of iverilog, it is an opensource tool that does not need the ISE, so the tool is supposed to generate an executable called darksocv on the sim directory:

$ cd sim $ ls -al darksocv -rwxr-xr-x 1 marcelo staff 137124 Oct 2 02:30 darksocv

the rwx attribute means that the file is executable. case the file is present, but with no permission, just make it executable:

$ chmod 755 darksocv $ ./darksocv

and the simulation will run on iverilog (not ISE). in order to visualize the waveforms, you can use the gtkwave:

$ gtkwave darksocv.vcd

that is almost as equivalent to simulate on ISE, but opensource.

[srinisy-22]

Yes I understand that. I have loaded the design on modelsim and I was able to get the startup code working. But I wanted get the Software stack setup for DarkRISCV so that I can modify the C code to generate different types of .mem files which can be used for simulation.

[samsoniuk]

oh, ok! It is because the top level include the entire cycle "software, simulation, hardware", so you can just edit the top level Makefile and comment the parts that are not needed, for example:

all: make -C src all

make -C sim all

#make -C boards all

This will build the src code, but not trigger the simulation and hardware generation (since you will simulate and synthesize via graphic interface). Another way is enter in the src directory, so you can make clean, make all, etc.

About the ModelSim, I have support for Intel Cyclone 10 but, regardless the Intel tool uses the ModelSim, I did not simulated on it, so I am not much sure how it works :(

[srinisy-22]

Got it ! I will try it out. But a quick question. Do I need to install ISE Xilinx for this too?

[srinisy-22]

I am guess not though.

[srinisy-22]

I commented it out and it worked! Here is the output. So I need to modify main.c to get different .mem files?

[srinisy-22]

I tried it out without commenting and it still worked. Without the ISE installation. But when I modify the main.c in ./src/darkshell then there is no change in the output.

[srinisy-22]

Im sorry for bombarding with questions, but when I go into the darkriscv/src folder and run the Makefile there then it throws this error.

[samsoniuk]

The project is a mixed set of hardware and software, so you do not need really install the Xilinx tools to build and simulate the software. In fact, you will install different tools according to the hardware you have (ISE for old Xilinx FPGAs, Vivado for new Xilinx FPGAs, Quartus for Intel FPGAs, etc). For simulation only, you can use Icarus (iverilog), but in order to rebuild the software, you need a cross-gcc w/ support for RISC-V.

You need edit the src/Makefile, locate and adjust the CCPATH variable according to your system, with the location of the risc-v compiler.

Well, there is a small bug on the src/Makefile, it does not check the app dep, so when you change the code, it does not relink... the better workaround is use "make clean all", so it will rebuild from scratch (I am checking how to solve this problem).

[srinisy-22]

Thanks a lot for the response. Where would I find the cross compiler? How would I install it on my Ubuntu system?

[srinisy-22]

I found this link: https://stackoverflow.com/questions/74231514/how-to-install-riscv32-unknown-elf-gcc-on-debian-based-linuxes Would this suffice?

[samsoniuk]

good question... I am not sure the pre-compiled package will work, because you need support for rv32ie, but most pre-compiled packages are compiled for rv64gc... maybe the only way to know is try install and test it. Case the pre-compiled package does not work, you will need compile it... but since compile the compiler is not so easy, I guess make sense try the pre-compiled package 1st.

[srinisy-22]

Ohh Okay, Can you let me know where will it be available so that I can download it?

[samsoniuk]

hmmm did you tested the ubuntu package?

my guess is try test the ubuntu package 1st and, case it not works, try build the compiler...

well, I included the instructions in the darkriscv README, but basically I used the same as the following link:

https://www.lowrisc.org/blog/2017/09/building-upstream-risc-v-gccbinutilsnewlib-the-quick-and-dirty-way/

it worked fine in my systems (macos and slackware linux), but you must note that those instructions were from 2017 (I am working w/ gcc-9.0.0, I guess), so it may or may not work well nowadays.

[srinisy-22]

Yes so I tried the ubuntu package and it didn't work. I ran the make file in src I have also changed the CC path

[srinisy-22]

I am Using Ubuntu 18.04.6 as OS in VM

[srinisy-22]

I found these on the drive Which one should I download?

[samsoniuk]

Yes so I tried the ubuntu package and it didn't work. I ran the make file in src I have also changed the CC path

well, I tested here w/ the ubuntu package and it worked fine!

basically:

apt-get install gcc-riscv64-unknown-elf

and edited the src/Makefile:

which means: comment the old CROSS and CCPATH, add new CROSS and CCPATH variables, after that the make clean all will work fine!

best regards, marcelo

[srinisy-22]

Perfect! I will try it out now and keep you posted! THanks a lot!!

[srinisy-22]

I so i tried the apt-get install gcc-riscv64-unknown-elf it threw this error. I even tried the apt-get update but still didn't work.

[samsoniuk]

maybe you need a more update version: I tested w/ ubuntu 20, which is not exactly new, but it not so old as ubuntu 18.

[srinisy-22]

okay I will try it out in VM Ubuntu 20.04

[srinisy-22]

So I have setup the software stack successfully now And here is the modified startup code. I have changed the main.c in /src/darkshell and it is printing as expected! Thanks a lot for all your support!

[srinisy-22]

Please let me know if this is the way to go to get different .mem files

[samsoniuk]

yeah, currently the "make clean all" from top level will rebuild and run the simulation again, while "make" will only run the simulation. it is wired in the Makefile to be this way, in order to avoid rebuild the firmware when you are changing the Verilog code -- remember that this is a hardware project, not exactly a software project! :)

of course, the default setup is the minimum setup for 4KB of memory, case you need more code, you may need change the rtl/config.vh and comment line 183, uncomment line 184 to enable more memory:

//`define MLEN 12 // MEM[12:0] -> 4KBytes LENGTH = 0x1000
`define MLEN 15 // MEM[12:0] -> 32KBytes LENGTH = 0x8000 for coremark!

and edit the top level Makefile to comment the SMALL variable on line 37:

// export SMALL = 1# uncomment for smaller firmware

so the code and core are enabled to address 32KB of memory. You can even increase more (up to 2GB!), but the linker script must be changed by hand.

well, thank you for using darkriscv and good hacking! case you have more questions, feel free to comment or, case you have no further comments, just close this issue! :)

best regards, marcelo

[srinisy-22]

Sure I will close it. And I understand that this is a hardware project. I am attempting to use the software stack to produce more .mem files to improve coverage. I am currently trying to use the DarkRISCV processor and expand it to a multicore SoC. This of course involves adding a cache module, exception module, replicating the processors, and accounting for cache coherence protocol. Please let me know the extent of its feasibility.

[samsoniuk]

well, I think is possible, but the feasibility depends on the strategy and targets...

I am currently (slowly) working to break apart the darksocv in smaller modules, so is possible reduce the complexity on the top level and, at the same time, make it more modular. I already removed the UART (darkuart), PLL (darkpll) and caches (darkcache, not integrated yet) to separate files, but I need also separate the BRAMs (darkram) and some IO modules (darkio or something like), in a way that the top level can be customized per board.

one key element is design a bridge or switch, in a way that multiple peripherals and bus masters can be attached, which enables the development of more advanced peripherals, such as ethernet, sdram/ddr, spi/qspi, hdmi/vga, etc. as well the use of multiple cores in the same system, with different organizations: asymetrical multi-processing, symmetrical multi-processing, array of processing elements + network on chip, etc.

so, there is a very long and hard road in order to reach all this! :)

[srinisy-22]

Great! Thanks a lot!

[srinisy-22]

Can I attempt to build a MPSoC from the darkrisc by adding my own cache controller, Interrputs and cache coherence?

[samsoniuk]

Yes, of course! My suggestion is start with a instruction cache only, because the instruction bus is more critical: when running the test software at 100MHz on a spartan-6, the instruction bus requires 400MB/s of bandwidth to keep a performance of 70MIPS, while the data bus accounts for only 40MB/s of bandwidth, so the instruction cache is far more important for performance. Of course, it depends of the application, but my recommendation is start w/ the instruction cache only and check if you really need a data cache.