GithubHelp home page GithubHelp logo

antonblanchard / microwatt Goto Github PK

View Code? Open in Web Editor NEW
644.0 41.0 97.0 65.03 MB

A tiny Open POWER ISA softcore written in VHDL 2008

License: Other

Makefile 0.23% VHDL 17.44% Python 0.22% Shell 0.07% C 3.62% Assembly 0.67% Rust 0.02% C++ 0.07% Verilog 76.18% Tcl 1.48%
vhdl processor openpower ppc64le

microwatt's Introduction

Microwatt

Microwatt

A tiny Open POWER ISA softcore written in VHDL 2008. It aims to be simple and easy to understand.

Simulation using ghdl

MicroPython running on Microwatt

You can try out Microwatt/Micropython without hardware by using the ghdl simulator. If you want to build directly for a hardware target board, see below.

  • Build micropython. If you aren't building on a ppc64le box you will need a cross compiler. If it isn't available on your distro grab the powerpc64le-power8 toolchain from https://toolchains.bootlin.com. You may need to set the CROSS_COMPILE environment variable to the prefix used for your cross compilers. The default is powerpc64le-linux-gnu-.
git clone https://github.com/micropython/micropython.git
cd micropython
cd ports/powerpc
make -j$(nproc)
cd ../../../

A prebuilt micropython image is also available in the micropython/ directory.

  • Microwatt uses ghdl for simulation. Either install this from your distro or build it. Microwatt requires ghdl to be built with the LLVM or gcc backend, which not all distros do (Fedora does, Debian/Ubuntu appears not to). ghdl with the LLVM backend is likely easier to build.

    If building ghdl from scratch is too much for you, the microwatt Makefile supports using Docker or Podman.

  • Next build microwatt:

git clone https://github.com/antonblanchard/microwatt
cd microwatt
make

To build using Docker:

make DOCKER=1

and to build using Podman:

make PODMAN=1
  • Link in the micropython image:
ln -s ../micropython/ports/powerpc/build/firmware.bin main_ram.bin

Or if you were using the pre-built image:

ln -s micropython/firmware.bin main_ram.bin
  • Now run microwatt, sending debug output to /dev/null:
./core_tb > /dev/null

Synthesis on Xilinx FPGAs using Vivado

  • Install Vivado (I'm using the free 2019.1 webpack edition).

  • Setup Vivado paths:

source /opt/Xilinx/Vivado/2019.1/settings64.sh
  • Install FuseSoC:
pip3 install --user -U fusesoc

Fedora users can get FuseSoC package via

sudo dnf copr enable sharkcz/danny
sudo dnf install fusesoc
  • If this is your first time using fusesoc, initialize fusesoc. This is needed to be able to pull down fussoc library components referenced by microwatt. Run
fusesoc init
fusesoc fetch uart16550
fusesoc library add microwatt /path/to/microwatt
  • Build using FuseSoC. For hello world (Replace nexys_video with your FPGA board such as --target=arty_a7-100): You may wish to ensure you have installed Digilent Board files or appropriate files for your board first.
fusesoc run --target=nexys_video microwatt --memory_size=16384 --ram_init_file=/path/to/microwatt/fpga/hello_world.hex

You should then be able to see output via the serial port of the board (/dev/ttyUSB1, 115200 for example assuming standard clock speeds). There is a know bug where initial output may not be sent - try the reset (not programming button) on your board if you don't see anything.

  • To build micropython (currently requires 1MB of BRAM eg an Artix-7 A200):
fusesoc run --target=nexys_video microwatt

Linux on Microwatt

Mainline Linux supports Microwatt as of v5.14. The Arty A7 is the best tested platform, but it's also been tested on the OrangeCrab and ButterStick.

  1. Use buildroot to create a userspace

    A small change is required to glibc in order to support the VMX/AltiVec-less Microwatt, as float128 support is mandiatory and for this in GCC requires VSX/AltiVec. This change is included in Joel's buildroot fork, along with a defconfig:

    git clone -b microwatt https://github.com/shenki/buildroot
    cd buildroot
    make ppc64le_microwatt_defconfig
    make
    

    The output is output/images/rootfs.cpio.

  2. Build the Linux kernel

    git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
    cd linux
    make ARCH=powerpc microwatt_defconfig
    make ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- \
      CONFIG_INITRAMFS_SOURCE=/buildroot/output/images/rootfs.cpio -j`nproc`
    

    The output is arch/powerpc/boot/dtbImage.microwatt.elf.

  3. Build gateware using FuseSoC

    First configure FuseSoC as above.

    fusesoc run --build --target=arty_a7-100 microwatt --no_bram --memory_size=0
    

    The output is build/microwatt_0/arty_a7-100-vivado/microwatt_0.bit.

  4. Program the flash

    This operation will overwrite the contents of your flash.

    For the Arty A7 A100, set FLASH_ADDRESS to 0x400000 and pass -f a100.

    For the Arty A7 A35, set FLASH_ADDRESS to 0x300000 and pass -f a35.

    microwatt/openocd/flash-arty -f a100 build/microwatt_0/arty_a7-100-vivado/microwatt_0.bit
    microwatt/openocd/flash-arty -f a100 dtbImage.microwatt.elf -t bin -a $FLASH_ADDRESS
    
  5. Connect to the second USB TTY device exposed by the FPGA

    minicom -D /dev/ttyUSB1
    

    The gateware has firmware that will look at FLASH_ADDRESS and attempt to parse an ELF there, loading it to the address specified in the ELF header and jumping to it.

Testing

  • A simple test suite containing random execution test cases and a couple of micropython test cases can be run with:
make -j$(nproc) check

Issues

  • There are a few instructions still to be implemented:
    • Vector/VMX/VSX

microwatt's People

Contributors

antonblanchard avatar classilla avatar deece avatar diagprov avatar gromero avatar hughhalf avatar iagocaran avatar iamjpn avatar jbalkind avatar kraigher avatar larsasplund avatar mikey avatar mkj avatar nickg avatar olofk avatar ozbenh avatar paulusmack avatar riktw avatar sharkcz avatar shawnanastasio avatar shenki avatar shingarov avatar tgingold avatar tianrui-wei avatar tomtor avatar umarcor avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

microwatt's Issues

Elaboration error in vivado at sim_bram_helpers.vhdl

ERROR: [VRFC 10-3361] function 'behavioural_initialize' does not always return a value [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_bram_helpers.vhdl:16]
ERROR: [XSIM 43-3321] Static elaboration of top level VHDL design unit core_dram_tb in library work failed.

Compatibility with compiled Micropython

I see that the prebuilt image in this repository is based on MicroPython v1.12-571 (some intermediate version I guess?)

I tried compiling micropython using GCC cross-compiler on Ubuntu 20.04 (with both buildroot download and gcc9.3 based from debian repositories)
I attempted using the current master branch, v1.13 and v1.12 from the micropython repo.
In all the cases, although I can compile without errors, when I run core_tb, I am not able to issue any inputs in the terminal from the keyboard. This does not happen with the prebuilt image.

I am not sure how exactly shall I debug this. But I would be happy to help and provide more details if neeeded.

Thank you.

Add example resource usage on Artix 7

It would be really good to include some information in the README around the resource usage of microwatt.

I would recommend the following stats;

  • LUT + FF usage
  • Highest fmax possible
  • DMIPS/Mhz
  • Coremark/Mhz

It would also be good to include the information for multiple FPGAs like;

  • Xilinx Artix 7 using Vivado
  • Lattice ECP5 using Diamond

It would make it easy to quickly compare it against various other soft processors like Microblaze from Xilinx.

It might also be worth looking at Everyone’s a Critic: A Tool for Exploring RISC-V Projects Paper from FPL to see some ways to benchmark. There is also the awesome An inventory of soft processor cores but it is a little out of date.

error in glibc_random_helpers.vhdl when building

Trying to build microwatt on Debian and I get

glibc_random_helpers.vhdl:5:14:error: unknown foreign VHPIDIRECT 'random'

when I make -j4. With make -j2, then I get

ghdl:error: unknown warning identifier

Microwatt emits lots of metavalue assertions when simulating in GHDL

After getting GHDL to emit some more information about metavalue assertions, the worst offenders are (the first column is the number of times I saw the assertion):

   3431 in process .core_tb(behave).soc0@soc(behaviour).processor@core(behave).mmu_0@mmu(behave).finalmaskgen
    847 in process .core_tb(behave).soc0@soc(behaviour).processor@core(behave).mmu_0@mmu(behave).addrmaskgen
    457 in process .core_tb(behave).soc0@soc(behaviour).processor@core(behave).icache_0@icache(rtl).icache_comb
    186 in process .core_tb(behave).soc0@soc(behaviour).processor@core(behave).dcache_0@dcache(rtl).dcache_request
     78 in process .core_tb(behave).soc0@soc(behaviour).processor@core(behave).icache_0@icache(rtl).itlb_update

cannot load package "vcomponents" when building with Docker for Windows 10

Coming from #151 (comment), I'm trying to build microwatt on Windows 10, using Docker Desktop and MSYS2 (MINGW64). The procedure is to just clone the repo, change line 29 of the makefile as explained in #209 (comment), and run:

# DOCKER=1 make
docker run --rm -v //t/microwatt://src:z -w //src ghdl/ghdl:buster-llvm-7 ghdl -c --std=08 -frelaxed -Psim-unisim -Wl,sim_vhpi_c.o -Wl,sim_bram_helpers_c.o -Wl,sim_console_c.o -Wl,sim_jtag_socket_c.o decode_types.vhdl common.vhdl wishbone_types.vhdl fetch1.vhdl utils.vhdl 
plru.vhdl cache_ram.vhdl icache.vhdl decode1.vhdl helpers.vhdl insn_helpers.vhdl gpr_hazard.vhdl cr_hazard.vhdl control.vhdl decode2.vhdl register_file.vhdl cr_file.vhdl crhelpers.vhdl ppc_fx_insns.vhdl rotator.vhdl logical.vhdl countzero.vhdl multiply.vhdl divider.vhdl execute1.vhdl loadstore1.vhdl mmu.vhdl dcache.vhdl writeback.vhdl core_debug.vhdl core.vhdl wishbone_arbiter.vhdl wishbone_bram_wrapper.vhdl sync_fifo.vhdl wishbone_debug_master.vhdl xics.vhdl syscon.vhdl soc.vhdl spi_rxtx.vhdl spi_flash_ctrl.vhdl sim_console.vhdl sim_pp_uart.vhdl sim_bram_helpers.vhdl sim_bram.vhdl sim_jtag_socket.vhdl sim_jtag.vhdl dmi_dtm_xilinx.vhdl sim_16550_uart.vhdl core_tb.vhdl -e core_tb
error: cannot load package "vcomponents"
ghdl: compilation error
make: *** [Makefile:101: core_tb] Error 1

@ozbenh sim-unisim/unisim-obj08.cf exists, but it contains:

v 4
file "T:\microwatt\" "sim-unisim/unisim_vcomponents.vhdl" "917ee7a8dc19536a72a1b70ebd3a36b8d76af2d8" "20200702062346.912":
  package vcomponents at 1( 0) + 0 on 4;
file "T:\microwatt\" "sim-unisim/BUFG.vhdl" "6e19508c796a8fded15f2e3068675dbd302e9da1" "20200702062346.912":
  entity bufg at 1( 0) + 0 on 4;
  architecture behaviour of bufg at 9( 121) + 0 on 4;
file "T:\microwatt\" "sim-unisim/BSCANE2.vhdl" "05310f6fb5017fb11aa2bf46e8ae2db937570aa6" "20200702062346.912":
  entity bscane2 at 1( 0) + 0 on 4;
  architecture behaviour of bscane2 at 24( 469) + 0 on 4;

I guess that "T:\microwatt\" "sim-unisim/unisim_vcomponents.vhdl" should be /t/microwatt/sim-unisim/unisim_vcomponents.vhdl or just /src/microwatt/sim-unisim/unisim_vcomponents.vhdl. Can you please let me know the content in your host?

Issue in xilinx-mult.vhdl file

For example:- inside xilinx-mult.vhdl file at line number :- 710 there is a module named "DSP48E1". In that modules generic map there is a parameter named "USE_MULT" which is assigned "none". It should be "NONE". this gave error while simulating in vivado 2019.1. There are 4-5 Locations which need to be changed to "NONE"

Elobration error in vivado in wishbone_arbiter.vhdl

ERROR: [XSIM 43-4187] File "C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/wishbone_arbiter.vhdl" Line 41 : The "Vhdl 2008 Sequential Conditional Signal Assignment" is not supported yet for simulation.
ERROR: [XSIM 43-4187] File "C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/litedram/extras/litedram-wrapper-l2.vhdl" Line 474 : The "Vhdl 2008 Condition Operator" is not supported yet for simulation.

The execute stage needs a shared barrel shifter

In order to get things to a functional core as fast as possible, I implemented a number of instructions in isolation that should share resources. One of the worst cases is all the rotate and shift instructions:

                                when OP_RLDCL =>
                                        result := ppc_rldcl(e.read_data1, e.read_data2, e.const2(5 downto 0));
                                        result_en := 1;
                                when OP_RLDCR =>
                                        result := ppc_rldcr(e.read_data1, e.read_data2, e.const2(5 downto 0));
                                        result_en := 1;
                                when OP_RLDICL =>
                                        result := ppc_rldicl(e.read_data1, e.const1(5 downto 0), e.const2(5 downto 0));
                                        result_en := 1;
...

A total of 17 instructions! Perhaps the synthesis tools notice this replication, but we should implement a common 64 bit barrel shifter and get all the instructions to use them.

Compile error at sim_jtag.vhdl in vivado

ERROR: [VRFC 10-2989] 'glob_jtag_t' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:18]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:39]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:41]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:49]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:51]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:53]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:55]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:56]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:59]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:60]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:62]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:74]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:75]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:76]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:77]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:78]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:79]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:80]
ERROR: [VRFC 10-2989] 'j' is not declared [C:/Users/NALLURI SASI KIRAN/Desktop/microwatt-master/sim_jtag.vhdl:81]

Issue in simulating only processor(core.vhdl) in vivado

I wanted to simulate the core to view wave forms of different instructions. But i am struck. I am getting this error "FATAL_ERROR: Vivado Simulator kernel has discovered an exceptional condition from which it cannot recover. Process will terminate. For technical support on this issue, please open a WebCase with this project attached at http://www.xilinx.com/support."

I created a System Verilog testbench file and instantiated core.vhdl first to see whether at least clock runs or not at my end but i got above error. I am attaching log files.
xvhdl.log
xvlog.log
elaborate.log
webtalk.log
compile.log
Tcl_console_output.txt
Capture_3567

Here is the code : -

`

`timescale 1ns/1ns
typedef struct packed { longint dat;
                                      bit ack;
                                      bit stall;} wish_slave_out ;
                    
typedef struct packed { longint dat;
                                      int addr;
                                      byte sel; 
                                      bit cyc;
                                      bit stb;
                                      bit we; } wish_master_out ;

module top_u ;

bit clk=1,rst=1,rst_1,dmi_req,dmi_ack,dmi_wr,ext_irq,terminated_out;
bit [3:0] dmi_addr;
longint dmi_din,dmi_dout;

wish_slave_out s_insn_in,s_data_in;
wish_master_out m_insn_out,m_data_out; 

parameter bit [63:0]alt_addr = '{64{0}};

core#(0,0,1,alt_addr,512) a1 (.clk(clk),.rst(rst),.alt_reset(rst_1),.wishbone_insn_in(s_insn_in),.wishbone_insn_out(m_insn_out),
                            .wishbone_data_in(s_data_in),.wishbone_data_out(m_data_out),.dmi_addr(dmi_addr),.dmi_din(dmi_din),
                            .dmi_dout(dmi_dout),.dmi_req(dmi_req),
                            .dmi_wr(dmi_wr),.dmi_ack(dmi_ack),.ext_irq(ext_irq),.terminated_out(terminated_out) );
                                                       
     initial
        begin
            repeat(1000)
                begin
                    #100 clk = ~clk;
                end
        end
     
     initial
        begin
            #200 rst = 0;
        end
          
     initial
        begin
            $dumpfile("dump.vcd");
            $dumpvars(0,top_u);
        end                      
                          

endmodule

`
Also i wanted to know if there is an SV verification requirement.
Thanks in advance

Verilator and Yosys support broken

I've been trying to use the microwatt.v and microwatt-verilator targets in the makefile, but it seems like both are broken. The microwatt.v file produced by Yosys generates invalid Verilog, which Yosys itself cannot read back. The issue seems to be caused by Yosys generating a few statements of the form assign "" = "". Should I report this directly to Yosys?

After removing those lines, Yosys can read the file in but Verilator still gives the error:

%Error: microwatt.v:203:3: Cannot find file containing module: 'EHXPLLL'

along with some warnings (LITENDIAN, and PINMISSING) though perhaps these can be ignored.

Are these targets supposed to be working, or are they still in-progress?

I'm using versions built fairly recently from source: Yosys 0.9+3672, Verilator 4.203 devel rev v4.202-56-g1f331bd9, and GHDL 2.0.0-dev (1.0.0.r333.g17ddaa0d).

GHDL build on native powerpc64le requires explicit LLVM backend selection

Debian doesn't build ghdl for powerpc64/le targets yet as package build results in incorrect mcode backend selection on powerpc64/le architectures. Manual specification of ./configure --with-llvm-config=$(which llvm-config) results in working native GHDL build which can be used to simulate microwatt according to README instructions natively on powerpc64/le. Suggest modifying README to include instructions and workaround lack of GHDL package availability in powerpc64/le debian and debian derived distros.

Microwatt should enter at 0x100 not 0x0

At the moment we enter at 0x0, but we probably should enter at the system reset vector of 0x100. We can modify existing software to handle both entry points, and eventually change Microwatt.

We need a divider

Right now we implement division in simulation, but not synthesis. We don't need anything spectacular, because modern compilers are quite good at optimising divides away. A basic non pipelined radix 2 divider would do nicely. Even so, I'm sure there are a lot of corner cases to take care of.

There are 4 32 bit and 4 64 bit divide instructions, but best to start with the ones we see in micropython: divd, divdu, divw, and divwu.

firmware sources

Looks to me that litedram/gen-src/sdram_init/ is missing some source files, it can't be rebuilt.

[dan@talos sdram_init]$ make
Makefile:3: variables.mak: No such file or directory
make: *** No rule to make target 'variables.mak'.  Stop.

The other question is whether shouldn't be a separate project for Microwatt's firmware :-)

Reading the DSISR can trigger an assert

Running the test case in #266 the core gets an assert failure:

register_file.vhdl:55:25:@62595ns:(report note): Writing GPR 09 00000000XXXXXXXX
register_file.vhdl:60:17:@62595ns:(assertion failure): Assertion violation
../core_tb:error: assertion failed

Fix GitHub language detection

I'm betting your project isn't 62% Coq
Screenshot from 2020-07-07 21-46-17

You can be fixed by adding a .gitattributes file. See the symbiflow-arch-defs example at f4pga/f4pga-arch-defs#1399

GitHub uses https://github.com/github/linguist to do language stats. linguist however mis-detects a bunch of things in this repo. It also needs to be told about the "vendored" files in the repo.

# Settings to improve linguist data reporting (used by GitHub)
*.v                     linguist-language=Verilog
*.vh                    linguist-language=Verilog
*.sql                   linguist-language=SQL

third_party/**          linguist-vendored

# FIXME: All vendor files should be under third_party
tests/9-soc/**          linguist-vendored
xc/xc7/tests/ddr/**     linguist-vendored
xc/xc7/tests/soc/**     linguist-vendored

CR logical ops need to be implemented

crand, crandc, creqv, crnand, crnor, cror, crorc, crxor are not implemented. We haven't seen them in gcc compiled code, but they do appear quite a lot in llvm code.

License Clearing

I noticed that your processor uses different code snippets like fpga/pp_fifo.vhd, which is originated from Potato Processor.

You processor has a CC-BY 4.0 license, where as the mentioned file has a BSD license.

  • How do you keep track of all the used code snipts and licenses?
  • How do you ensure all used licenses are compatible to each other?
  • Where do you list all included / nested licenses?

I would be interested in integrating your project into another project (Apache License, 2.0).


I suggest to review all files and track used licenses as early as possible in a project.

Improve architecture compliance (Book I)

We still have some gaps in our compliance with the architecture. We are missing some things that are in v3.0B Book I and most of the new stuff in v3.1 Book I.

Missing instructions:

bctar[l]
scv
lq, stq
addex
darn
maddhd[u]
maddld
cmprb
cmpeqb
bpermd
mcrxrx
setb

Additions for v3.1:
prefixed instructions
cntlzdm
cnttzdm
cfuged
pextd
pdepd
brh
brw
brd
setbc
setbcr
setnbc
setnbcr

Add instruction breakpoint

Add a instruction breakpoint to microwatt. When the PC hits this value, take a trace exception at 0xD00.

The ISA defines the CIABR which is the "completed" instruction. This means take the exception after the instruction is run which is not ideal from a software perspective. An implementation that takes the breakpoint before the instruction is executed would be more useful but we'd have to call it an IABR not CIABR.

Generate an static site and host it in GitHub Pages

This repository does not have a documentation or web site yet. However, there are several features which might be better comunicated by doing so.

Two different static site documentation generation systems are used in the open source hardware community mostly:

  • Sphinx is probably the most used (GHDL, VUnit, SymbiFlow, FuseSoc, cocotb, Fomu workshop, OSVB, pyVHDLModel, TerosHDL, Wishbone....). As a result, there are some very interesting benefits:

  • asciidoctor is probably the second most used (NEORV32, hdl/{containers,constraints,MINGW-packages}, Greg, RaspberryPi...).

    • asciidoctor-diagram supports wavedrom and bytefields, similarly to the sphinx-wavedrom extension.
    • Unfortunately, there is no solution in asciidoc or asciidoctor equivalent to intersphinx. In fact, asciidoctor generates single page HTML documents. In order to generate "sites", maintainers recommend using Antora (another tool written in JavaScript that wraps asciidoctor -Ruby-). As Luke@RaspberryPi commented, it is not strange to use some Python as well.

A few years ago, the Linux kernel evaluated both. See https://lwn.net/Articles/692704/.

Summarising, I like the asciidoctor syntax (I find it much easier to write than rst). I find the documentation of NEORV32 to be awesome. However, Sphinx's site generation and cross-referencing features are very valuable. Hence, I would probably recommend to go with Sphinx.

I could help with setting up CI for having the docs automatically built and pushed to gh-pages (thus, served at antonblanchard.github.io/microwatt).

Reads from the main memory can lock up the core

I've been experimenting with Microwatt, attempting to get it to run on a Xilinx Zynq 7000 embedded SoC. I'm currently in the process of hooking up the DDR3 SDRAM.

While debugging, I've noticed that certain reads from main memory (0x0...), aliased to the memory the firmware is loaded from, lead to unexpected behavior. This can also be reproduced in simulation.

I've created a sample program to illustrate the issue. When the program is linked at 0x0, and is loaded from the block RAM, the core appears to hang indefinitely when reading a quad word from address 0x00001400 (text segment). This address probably depends on the exact compiler output.

just to play : using windows wsl/ubuntu , building ghdl and running micropython

its relatively slow but it work using Windows wsl , Ubuntu and building ghdl with llvm ;-> using your tutorial to test.

image

54 sudo apt-get install gcc-4.8-powerpc-linux-gnu g++-4.8-powerpc-linux-gnu binutils-4.8-powerpc-linux-gnu
55 sudo apt-get install gcc-powerpc64le-linux-gnu
56 sudo apt-get install g++-powerpc64le-linux-gnu
57 sudo apt-get install binutils-powerpc64le-linux-gnu
58 sudo apt-get install binutils-powerpc64le-linux-gnu-dbg
61 sudo apt-get install binutils-powerpc64le-linux
64 sudo apt-get install gcc-4.8-powerpc-linux-gnu g++-4.8-powerpc-linux-gnu binutils-4.8-powerpc-linux-gnu

119 sudo apt-get install llvm
120 sudo apt-get install llvm-8

and for ghdl

https://gist.github.com/mathieucaroff/73ccbd30638d9b37b7129a7b7b8d7726

with these parameters :

./configure --prefix=/usr/local --with-llvm-config=/usr/bin/llvm-config-8

Vivado Implementation has negative slack

I have just run the microwatt with fusesoc on arty_a7-35. Then, I open the microwatt_0.xpr in vivado gui mode. I found that there are critical warning about the timing. It said that the design failed to meed the timing requirement.
2PNG
The ram initial is the hello_world.hex which is in this git.

Moreover, I saw the utilization is quite large for arty7.
3
Is there any suggestion for solve the slack and lean this core?

add instructions for FPGA implementation

First, thanks for doing this all. Second, I have verified that your core really returns 2 for a "1+1" command issued in micropython "natively" on a Power9 Talos II running Fedora 30 for ppc64le as host :-) But it would be great if you could publish also similar instructions for people wanting to play with the FPGA implementation.

Could microwatt work in an multicore configuration?

I was wondering if it would be possible to build a "multicore" power system using microwatt?

If it could happen, any idea what would need to be added to the core? I'm assuming something around atomics and cache + memory coherence?

Illegal use of conditional assignment in process

In multiple source files, a conditional signal assignment statement is used within a process, which is illegal in VHDL-2008. Instead an if statement or case statement should be used.

During compilation one will get errors such as:

Error (10500): VHDL syntax error at wishbone_arbiter.vhdl(41) near text "when"; expecting ";"

This is in process 'wishbone_muxes' (line 31of wishbone_arbiter.vhdl:

wishbone_muxes: process(selected, candidate, busy, wb_slave_in, wb_masters_in)
variable early_sel : wb_arb_master_t;
begin
early_sel := selected;
if busy = '0' then
early_sel := candidate;
end if;
wb_slave_out <= wb_masters_in(early_sel);
for i in 0 to NUM_MASTERS-1 loop
wb_masters_out(i).dat <= wb_slave_in.dat;
wb_masters_out(i).ack <= wb_slave_in.ack when early_sel = i else '0';
wb_masters_out(i).stall <= wb_slave_in.stall when early_sel = i else '1';
end loop;
end process;

Here both conditional assignments (lines 41 and 42) should be rewritten either as a case statement or if statement. The same error occurs in various other locations in other source files, which I can list here if needed.

Can Microwatt run on a Raspberry Pi Pico?

I'm not very familiar with PowerPC/POWER/OpenPower, or with microcontrollers, FPGAs or hardware design in general, so Microwatt is new to me in basically every way and I don't know if this even makes any sense, but... I'm wondering, if I wanted to experiment with the Microwatt project, would I be able to use a Raspberry Pi Pico to simulate an OpenPower ISA processor on real hardware, similar to how you could use Microwatt on an FPGA? (or am I just making connections where there aren't any?)

As I said, I don't really know enough about any of the technologies used in this project to even know if this makes any sense, but it seems micropython is used by the Microwatt project, and when I saw on the Raspberry Pi website that the Pico is "Programmable in C and MicroPython", I thought of Microwatt and wondered if it was possible to have it operate as a small OpenPower CPU on via the Microwatt project.

Please let me know if this is possible, and if not, what the technical reasons are. Thank you!

Shrinking Microwatt

I'd like to experiment using Microwatt as a 64-bit microcontroller on an ECP5 LFE5U-25F. Unfortunately, even with the following patch, I can't seem to get Microwatt and SoC peripherals to fit:

diff --git a/pythondata_cpu_microwatt/vhdl/core.vhdl b/pythondata_cpu_microwatt/vhdl/core.vhdl
index 4a83d69..e67ef4f 100644
--- a/pythondata_cpu_microwatt/vhdl/core.vhdl
+++ b/pythondata_cpu_microwatt/vhdl/core.vhdl
@@ -200,9 +200,9 @@ begin
     icache_0: entity work.icache
         generic map(
             SIM => SIM,
-            LINE_SIZE => 64,
-            NUM_LINES => 64,
-	    NUM_WAYS => 2
+            LINE_SIZE => 16,
+            NUM_LINES => 1,
+	    NUM_WAYS => 1
             )
         port map(
             clk => clk,
@@ -342,9 +342,9 @@ begin
 
     dcache_0: entity work.dcache
         generic map(
-            LINE_SIZE => 64,
-            NUM_LINES => 64,
-	    NUM_WAYS => 2
+            LINE_SIZE => 16,
+            NUM_LINES => 1,
+	    NUM_WAYS => 1
             )
         port map (
             clk => clk,

Command Line:

python3 litex_boards/targets/gsd_orangecrab.py --l2-size=0 --cpu-type=microwatt --cpu-variant=standard+ghdl+irq --build

Resource Usage (nextpnr):

Info: Device utilisation:
Info:          TRELLIS_SLICE: 15856/12144   130%
Info:             TRELLIS_IO:    64/  197    32%
Info:                   DCCA:     5/   56     8%
Info:                 DP16KD:    54/   56    96%
Info:             MULT18X18D:    16/   28    57%
Info:                 ALU54B:     0/   14     0%
Info:                EHXPLLL:     2/    2   100%
Info:                EXTREFB:     0/    1     0%
Info:                   DCUA:     0/    1     0%
Info:              PCSCLKDIV:     0/    2     0%
Info:                IOLOGIC:    49/  128    38%
Info:               SIOLOGIC:     0/   69     0%
Info:                    GSR:     0/    1     0%
Info:                  JTAGG:     0/    1     0%
Info:                   OSCG:     0/    1     0%
Info:                  SEDGA:     0/    1     0%
Info:                    DTR:     0/    1     0%
Info:                USRMCLK:     0/    1     0%
Info:                CLKDIVF:     1/    4    25%
Info:              ECLKSYNCB:     1/   10    10%
Info:                DLLDELD:     0/    8     0%
Info:                 DDRDLL:     1/    4    25%
Info:                DQSBUFM:     2/    8    25%
Info:        TRELLIS_ECLKBUF:     3/    8    37%
Info:           ECLKBRIDGECS:     1/    2    50%

I'd like to discuss whether core variants would be possible (standard, lite, minimal) based on the FPGA size someone has on hand. However, I first would like to actually get Microwatt to fit at all :). Do I have any recourse, or is Microwatt (plus peripherals) considered "inherently too big" to be practical for a 25k LUT FPGA?

Make timebase and decrementer (appear to) operate at 512MHz

The architecture says TB and DEC count at 512MHz, whereas we currently have them running at the core clock frequency. We should fix that, either by having them actually run at 512MHz, or by incrementing/decrementing by more than 1 on each core clock cycle.

Provide git ID of microwatt source in a syscon register

It would be cute to be able to identify the source code from which a particular microwatt cpu implementation was built. If the build process could look for the git SHA1 ID of the current head and include that as a constant value in the build, hooked up to the syscon framework so it could be read by MMIO, that could be useful. We would probably want (say) 32 bits of SHA1 plus a dirty flag.

Then the boot code could be enhanced to print that at startup along with the Soc signature, features, etc.

Building for ECP5 FPGA fails

When building for ECP5 FPGA using Docker images, I get the following error:

❯ make -f Makefile.synth
docker run --rm -v /Users/cdepaula/repos/microwatt:/src:z -w /src ghdl/synth:beta yosys -m ghdl -p "ghdl --std=08 -gMEMORY_SIZE=8192 -gRAM_INIT_FILE=hello_world/hello_world.hex -gRESET_LOW=true -gCLK_INPUT=12000000 -gCLK_FREQUENCY=12000000 fpga/soc_reset.vhdl fpga/clk_gen_bypass.vhd decode_types.vhdl common.vhdl wishbone_types.vhdl wishbone_debug_master.vhdl wishbone_arbiter.vhdl cache_ram.vhdl utils.vhdl plru.vhdl helpers.vhdl dcache.vhdl core_debug.vhdl fetch1.vhdl fetch2.vhdl register_file.vhdl insn_helpers.vhdl multiply.vhdl divider.vhdl logical.vhdl crhelpers.vhdl countzero.vhdl rotator.vhdl ppc_fx_insns.vhdl execute1.vhdl decode1.vhdl cr_file.vhdl writeback.vhdl loadstore1.vhdl icache.vhdl cr_hazard.vhdl gpr_hazard.vhdl control.vhdl decode2.vhdl core.vhdl fpga/pp_fifo.vhd fpga/pp_soc_uart.vhd dmi_dtm_dummy.vhdl fpga/main_bram.vhdl wishbone_bram_wrapper.vhdl soc.vhdl fpga/toplevel.vhdl -e toplevel; synth_ecp5 -json microwatt.json"

 /----------------------------------------------------------------------------\
 |                                                                            |
 |  yosys -- Yosys Open SYnthesis Suite                                       |
 |                                                                            |
 |  Copyright (C) 2012 - 2020  Claire Wolf <[email protected]>          |
 |                                                                            |
 |  Permission to use, copy, modify, and/or distribute this software for any  |
 |  purpose with or without fee is hereby granted, provided that the above    |
 |  copyright notice and this permission notice appear in all copies.         |
 |                                                                            |
 |  THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES  |
 |  WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF          |
 |  MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR   |
 |  ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES    |
 |  WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN     |
 |  ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF   |
 |  OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.            |
 |                                                                            |
 \----------------------------------------------------------------------------/

 Yosys 0.9+2406 (git sha1 UNKNOWN, clang 7.0.1-8 -fPIC -Os)


-- Running command `ghdl --std=08 -gMEMORY_SIZE=8192 -gRAM_INIT_FILE=hello_world/hello_world.hex -gRESET_LOW=true -gCLK_INPUT=12000000 -gCLK_FREQUENCY=12000000 fpga/soc_reset.vhdl fpga/clk_gen_bypass.vhd decode_types.vhdl common.vhdl wishbone_types.vhdl wishbone_debug_master.vhdl wishbone_arbiter.vhdl cache_ram.vhdl utils.vhdl plru.vhdl helpers.vhdl dcache.vhdl core_debug.vhdl fetch1.vhdl fetch2.vhdl register_file.vhdl insn_helpers.vhdl multiply.vhdl divider.vhdl logical.vhdl crhelpers.vhdl countzero.vhdl rotator.vhdl ppc_fx_insns.vhdl execute1.vhdl decode1.vhdl cr_file.vhdl writeback.vhdl loadstore1.vhdl icache.vhdl cr_hazard.vhdl gpr_hazard.vhdl control.vhdl decode2.vhdl core.vhdl fpga/pp_fifo.vhd fpga/pp_soc_uart.vhd dmi_dtm_dummy.vhdl fpga/main_bram.vhdl wishbone_bram_wrapper.vhdl soc.vhdl fpga/toplevel.vhdl -e toplevel; synth_ecp5 -json microwatt.json' --

1. Executing GHDL.
soc.vhdl:207:24: unit "xics" not found in library "work"
ERROR: vhdl import failed.
gmake: *** [Makefile.synth:69: microwatt.json] Error 1

uart16550 module not found by fusesoc

I got this error when running fusesoc recently

ERROR: Conflicting requirements:
Requirements: 'microwatt == 0-0' <- 'uart16550 >= 0-0'
    +microwatt-0-0 was ignored because it depends on missing packages
Requirements: 'microwatt == 0-0'
    Install command rule (+microwatt-0-0)

Failed to resolve dependencies for ::microwatt:0

If I understand it right, then microwatt.core is configured to rely on an external uart16550 module currently (https://github.com/antonblanchard/microwatt/blob/master/microwatt.core#L106). To solve that we should either update the instructions in https://github.com/antonblanchard/microwatt/blame/master/README.md#L100 or add uart16550.core to the bundled copy. I can prepare a PR, if you let me know your preference :-) I would go with the bundled copy personally, so Microwatt code is self-contained.

Add cache inhibited loads and stores and use them for UART

@ozbenh points out that we should be using the CI load and store instructions (lbzcix/stbcix etc). We'll need to update any out of tree software (eg micropython) once support has been added to microwatt.

Right now they can just map straight to the existing loads and stores.

Add quad I/O mode to flash driver (0xEB)

We currently support quad read mode (0x6B), where we send commands to the flash over 1 wire and read from it with 4 wires. We could get a bit of a speed up by using quad I/O mode (0xEB), which uses 4 wires for both directions.

refresh bundled MicroPython image

IMO it would useful to update the bunded MicroPython image in fpga/firmware.hex. It's smaller (~550kB, at least on my system) and mainly has the restart working when Ctrl+D is pressed.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.