Bennett/Requirements

Base Requirements

• Multiplatform (Linux/Windows. Mac if possible, but has serious challenges) - use C++/Qt
• Needs to support different different architectures: ARM, RISC-V, [others]
  • Needs to be configurable to 8, 12, 16, 24, 32, or 64 bit architecture
  • Needs to support different memory models, different register configurations, etc
  • Needs be able to work with simulators, or to communicate with a lab board
• Display of CPU registers (which registers are available will depend on architecture)
• Display of Status Flags (which flags are available will depend on architecture)
• Memory view, with optional disassembly.
  • View should be configurable to show memory in different ways: single word, multiple words, ascii characters, disassembly (word size and disassembly will depend on architecture) and if an address matches the value in a register, the register name should be highlighted next to that address.
• Multiple memory views need to be available, and individually configurable.
• Breakpoints (stop on PC reaching memory address)
• Watchpoint (stop on value at address being changed/set to value)
• CPU controls: step [single, multiple], run, halt, reset - is continue just another form of 'run', is 'run' just unconstrained 'step'?
• Needs to be extensible to support different simulated memory-mapped peripherals. Peripherals separate from architecture?
• avoid using linux-specific mechanisms for IPC: sockets instead of pipes, for example. Dynamic loading of extensions will need thought (QLibrary system in Qt provides portable option here).

Extras

• Compilers/assemblers for target architectures
  • GNU as (GAS) (part of the gcc suite) will target almost any architecture, but may not produce useful file types (MU0 support is curiously absent, for example)
  • Writing assemblers for all possible targets is possible but nontrivial. Are there real reasons not to use GAS (mingw under Windows) when a suitable target exists? Would they function as stopgaps in the short-term?

Design thoughts

Top-level architecture

These are general thoughts about the design, expect these to change/be refined as things progress.

• First, and most important concept: the design of the system is split so that there is a 'monitor core' and a number of 'system modules', with a minimal interface between the two.
  • The core handles module discovery, module selection and loading, and the behaviour of the common monitor UI.
  • System modules contain AND FULLY ENCAPSULATE individual simulators or hardware interfaces.
  • System modules should expose a set of 'capabilities' that describe the configuration of UI elements in the core.
  • The core should have absolutely no system-specific logic inside it: it should be a wholly architecture and implementation agnostic user interface that is capable of enabling/disabling/configuring the interface elements presented to the user based on the selected system module capabilities [NOTE: Means we need to decide on an appropriate superset of possible elements that may be needed for each interface element]
  • The core needs to provide a mechanism whereby system modules can register UI extensions. These allow specific UI elements or windows implemented in the system module to be shown to the user. For example, a simulator system module may provide a separate console output window, or a simulated 'screen' and keyboard. Note again: everything about such extensions - from UI definition to callbacks - should happen inside the module, all the core should care about is providing a way to register/add the UI elements!
• endianness is a problem. All current and future planned architectures are little-endian, but if the system can be made endian-agnostic, if might have wider application.

Interface Elements

The two key features a monitor needs to provide are CPU view and control, and memory view and control. Below are summaries of the interface elements and features needed to provide CPU and memory view and control, followed by additional elements the rest of the monitor should support.

Memory

The memory view and control should provide:

• Multiple independently configurable memory views (with pop in/ pop out to separate windows?)
• Means to select which memory to show if there are multiple memories (system module capabilities should give address ranges).
• Memory address display.
• A means to set the current address shown in the memory view.
• Word size is determined by the capabilities information from the system module.
• A way to configure the number of words shown per line in the memory display (note that having more than one word per line will mean hiding disassembly/source views).
• Optional indication of whether a CPU register contains a current address.
• Memory contents display: hex, ascii equivalent, disassembly/source view.
• Set the value stored in memory.

Notes:

• the memory view window logic should not include code to attempt disassembly! Things that can be handled by the memory view in the core:
  • current address and window size.
  • hex version of memory contents (simple conversion from bytes).
  • ascii equivalent of memory contents (simple conversion from bytes).
  • metadata display, if appropriate. This is a display of data provided by the system module for that address.
• Data from the system module should contain the word data as bytes.
• Data from the system module should contain metadata to show for an address. This is typically either the disassembly or source for that address.
• Setting the value at an address in the memory view should tell the system module that the value has been updated. The system module should update its memory, and send back revised data to show in the memory view. The monitor core should not assume it has been set successfully until the system module says so.