Tests link: https://github.com/medexs/riscv-tests

Also add '1' bit to misa register to indicate M ext support.

• Mention in readme that $dumpfile and $dumpvars must not be used (otherwise no VCD will be written by Vivado).
• Speed up runtime by creating the project template only once and then saving as temp.
• Kill Vivado instead peaceful exit (causes unnecessary slowdown).
• Add params to Vivado to move journals and logs to build dir.
• Edit also rvtest to use Vivado.

CLK-domain synchronization should occur on ALL inputs to avoid metastability. Simple 2 stage FF synchronizer should help but the module should be parametrized.

Filename: rv32mi/sbreak.S
Required registers: mcause, mtvec, mepc
Controller should correctly set exception cause.

Every PR should trigger a make.py testing.

• rars,
• qtrvsim,
• https://github.com/celebi-pkg/riscv-assembler,
• https://github.com/eigenraven/rvasm (easily extendable),
• official toolchain (very large),
• llvm

Use subprocess.check_output, check for ASSERT_(FAIL+SUCCESS) or FATAL keywords

Our tests have 3 options for run - rvtest, hwtest and test (rvtest + hwtest). When test is run, the statistics at the end show info only about rvtest and not hwtest, which are shown right after it's end.

For now, all build/test recipes are hardcoded in make.py, which is dumb and messy. Maybe an universal recipe (in YAML?) will be nicer. This recipe will also probably allow to specify even build instructions. Needs further research.

Possibilities (from lowest to highest level of abstraction):

1. Load all files from specified folder (folder as a test suite specification). No external sources are required, all is built-in (current state).
2. Allow to specify file list manually (config file as a test suite specification). There will be only one external source of information:
   • file list: which files to pass to hard-coded recipe (function)
3. Allow to specify test steps manually (config file as a whole test specification). There will be then two external sources of information:
   • recipe: describes how the test will run
   • file list: which files to pass to recipe
   • recipe can optionally also include file list which can be overriden by sth like --srcfiles argument. This will maintain out-of-the-box-working behavior as is now and also will be much much nicer.

Note: file list probably can be specified in 2 different ways:

• as an argument: --src test.v or --src testFolder
• as a file list: --src filelist.list

Tasks:

• Add mpysource evaluation to every source and dest (for now only in run step)
• Finish copy step
• Fix a case where a file is copied to a path that is not possible to create (e.g. one of the requested folders in paths is actually a file).
• Add custom recipe run
• Add possibility to pass custom source file/folder (only) to custom recipe

Exception should be called:

• when CSR, mret, ebreak, ecall are executed in the wrong mode
  Exceptions should disable all writes (to CSR, memory, registers...)

This CI/CD pipeline should build the project (in project-less Tcl mode preferably) and output a bitstream for Basys 3 to Releases. We can postpone this issue until the project is in stable state (pre-article?). This will be nice for demo purposes at school, people will only download ready-to-use bitstream.

• Add reset to tx shift register?

Please look at the error handling and always make sure that the run stops when an error occures and print the error message from iverilog to the console.

When trying to write RAM memory from a invalid file in top.v, the ERROR that iverilog raises is ignored by make.py:

There is too large delay of the critical path of the design: 16.385 ns (must be below 10 ns)

Possible solutions:

• split memories,
• use caches,
• use special LUTs: https://docs.xilinx.com/r/en-US/ug953-vivado-7series-libraries/RAM32M

For now, this function should convert from:

• binary to hex format

This function should remove all autogenerated content.

Maybe new command customtest with switches:

--file (test file)
--type [executable | testbench | auto]

Or adding possibility to enable/disable test by renaming/moving the files? (Bad)

Or changing the functionality of the test subcommand?

Consider adding skrýš for more premium experience. This skrýš will contain sensitive data protected by sophisticated Caesar's cipher.

Inspiration here.

The main goal is to create an address space to which peripherals will be mapped, for now GPIO access and UART. These peripherals must be accessible from C (probably using some structures holding pointers to physical addresses).

The memory map will be probably dependent on specific board (platform), thus being part of a BSP.

If no arguments are passed to the make.py script, following exception is raised:

Figure out how many IRQ inputs we need and how to encode these.

Illegal instructions should throw an exception.

It'll probably be handy to have a ready to use development environment. This will bring a "shared terminal server" feel without a need of an actual server — same OS, same libs, tools, etc. Also it'll make using precompiled tools (such as gcc) hassle free. For this we can probably use Docker or similar stuff.

For now it's not needed, but it'll make setting up the environment very easy for newcomers or for moving to a new device. If anything, it's a good DevOps exercise.

There are 20 error messages in Vivado like this:

[Synth 8-9873] overwriting previous definition of module 'alu' ["/risc-v-embedded/src/components/alu.v":30]

As of now, if specified in a recipe, make.py iterates over all steps for every source file specified. This is usually not wanted behaviour. Example: we need to do some tasks only at the start of the testing, such as creating a folder, precompiling something etc.

Possible solutions:

1. Create a new section "presteps", which will only execute once (regardless of if and how many source are there).
2. There will be some kind of loops, or substeps, where every substep can have its own set of sources. This will be more universal but requires a lot more work.

This is not required by any of the current test mechanisms and so is only a proposal for enhancement.

This bootloader will be below the OS bootloader - it will only serve for loading data from UART to data/instr memories.

Come up with a name for our CPU/microarchitecture and a name for the repository.

• Change repo name
• Change README title
• Add logo

Fix assignments, create a more sophisticated TB.

Rewrite all occurrences of casex statement to casez - the first one is not ideal for synthesisable code.

This should be usable for both LED dimming (= configurable duty) and playing tones on buzzer (= configurable frequency).

Krátkodobá:

• vytvořit takovou minimální mikroarchitekturu, která bude schopná spustit Linux a komunikovat s kamerou, jejíž video vystaví přes RTSP / jiný jednodušší protokol
  • je třeba stanovit seznam potřebných rozšíření, během výletu se může implementovat nějaké z nich, jako základ poslouží APSková mikroarchitektura

Dlouhodobá:

• obohatit mikroarchitekturu o různá rozšíření, možná už ve formě SoC mimo procesor:
  • HW akcelerované de/enkódování H.264, 265, nebo toho, co zrovna bude v módě, až se k tomu dostaneme :D. Ale H.264 je kompatibilní snad se vším
  • rozpoznávání objektů pomocí neuronek přímo na hardwaru - AIoT a napojení na rozšířené systémy - tak, aby například kromě API šlo tyto data nechat posílat i do MQTT brokeru
  • můžeme experimentovat nejen s WiFi, ale i Zigbee, nebo třeba Matter

Create a testbench that tests if CPU+GPIO works properly along with the firmware written in C.

Note: for some reason, Doom can be included with buildroot builds.

The Python generator will generate a Verilog module of an address decoder using an input YAML file describing the memory map.

These tools can be probably used:

• https://pypi.org/project/pyverilog/
• https://pypi.org/project/veriloggen/

There are several ways a documentation can be written:

• plain Markdown files in the repository,
• GitHub Wiki,
• Word document,
• Overleaf-hosted document (impractical cooperation support, poor git support),

These two are most prefered:

• autogenerated website published on GitHub pages (Spinx and similar tools: https://naturaldocs.org/),
  • https://www.mkdocs.org/ - this supports Markdown
• separate repository with LaTeX-based docs with automatic GitHub Actions powered releases.
  We can probably use some generator to generate both LaTeX and website.