To model delayed events, such as a DRAM access, it would be nice if we could post events into the future.

For the different test programs, note down "cycles/second" (with and without logging), what host CPU, which version etc.

Instead of printing all ports/wires, allow the user to specify which ports to log. E.g. using a text file. The simulator would then only print the ports matching the strings given in the text/config file.

Description

Scenario: Assume there is a module A, which contains another module B. A, inside its process() method, takes B's output (by directly reading B's output port), computes something with it, and writes something to its own output.

Regardless of how B's input ports are wired up (they could be either connected directly to one of A's inputs or, they could be written to during A's processing), A will always be processed before B.

Now, when B's output changes, who is notified? Only input ports can notify their parent module.

Solution

Similar to Verilog/VHDL, when we want to use some output of an inner module within the outer module, we should connect that output to some wire. That way, whenever the inner module's output changes, the change is also captured by the wire, thus adding the outer module to the simulation queue.

There is no real need to read an output port anyways, so we could just throw an exception when an output port is read.

The designer shouldn't have to deal with adding functions to the simulation queue.

E.g. see todo in Memory._tick().

(This issue is not referring to invalid memory accesses caused by running programs)

When during the current cycle some module's process function gets executed with unstable port values, and one of these unstable ports is used as a memory address (or any other list for that matter), we might have an invalid access exception (in Python).

However, as the port is unstable, we have to assume that it eventually will stabilize, and then the process method is executed again with valid inputs. While we are processing with unstable values, we need to relax access checks. Catching the exception and maybe issuing a warning instead might be a solution.

Description

Currently, we have two choices for default values of Ports:

• Some numeric value (e.g. 0)
• None

Both options have issues. When a module gets added to the simulation queue, but at least one input port still has a None value, computation might fail. On the other hand, a numeric default value could coincide with the reset value of a connected register. Thus at the very beginning of the sim, when the reset is asserted, the port will not see any change. However, it is not guaranteed that the output ports of the corresponding module have valid values, so forced processing in the first cycle is mandatory.

Proposal

Introduce a flag attribute in the Port class that indicates whether the port is written for the first time or not. When the port is written for the first time, the _propagate() method is called irrespective of the new value. From the next write on, the normal behavior applies, i.e., only propagate when the value has changed.

Add some basic exception handling as required by the RISC-V spec.

• Illegal instruction
• Instruction address misaligned
• Load address misaligned
• Store/AMO address misaligned

The following exceptions should be covered in the future:

• Instruction access fault
• Load access fault
• Store/AMO access fault