Skip to content

GUI Architecture

Nicolas Peschke edited this page Apr 5, 2024 · 4 revisions

PYRPL GUI Architecture

pyrpl makes extensive use of metaprogramming to semi-automatically build a GUI based on the PyQt framework.

pyrpl uses the following module structure to communicate with the FPGA on the RedPitaya:

erDiagram

GUI_CLIENT ||--|| SERVER : Ethernet
SERVER ||--|| FPGA : SharedMemory

GUI_CLIENT {
	runsOn RemotePC "connected via Ethernet"
	writtenIn Python
}
SERVER {
	runsOn RedPitaya "ARM Coprocessor"
	writtenIn C	
}
FPGA {
	runsOn RedPitaya "FPGA Core"
	writtenIn Verilog "also SystemVerilog and VHDL"
}

Loading

Communication between Remote PC and RedPitaya running pyrpl

The server and the FPGA share access to a specific location in the memory of the RedPitaya. Those memory addresses are static and there is one part of memory that is used for the FADS functionality see Memory Access for more information.

How to get information from the FPGA to the GUI and vice versa

FPGA

Using the custom system bus pyrpl implements, the FPGA logic can write and read from specific memory addresses in the RedPitaya Memory e.g. address 0x40600000. Additionally a number of bits/bytes to read/write must be specified as well.

Server (aka. Monitor Server in pyrpl)

The server runs on the ARM CoProcessor of the RedPitaya. It has access to the same part of shared memory that the FPGA core has. The purpose of that server is to expose the shared memory over ethernet. A request with the e.g. the address 0x40600000 and a number of bytes to read/write can be sent by the GUI Client over ethernet to the server which will look up the data at the memory location and relay it back to the client.

GUI Client

To connect to the server on the RedPitaya and to read and write data from/to the FPGA, pyrpl uses multiple classes spread over many modules. A quick overview:

The top-level RedPitaya class

https://github.com/wenzel-lab/pyrpl/blob/302b489dd342c04925bd4217b27280847615679e/pyrpl/redpitaya.py#L64

The MonitorClient class
The FADS class inheriting from HardwareModule

Adding a new module to the GUI

Adding a new module to the GUI is non trivial and requires numerous changes and additions all over the pyrpl package. The changes can be grouped by the subpackages (directories) they reside in.

Checklist

  • Hardware module added to pyrpl/hardware_modules/

    • added hardware module as its own python module
      • implemented addr_base, name, _widget_class, _gui_attributes and _setup_attributes class attributes
    • class added to hardware_modules subpackage __init__.py
  • Widget added to pyrpl/widgets/module_widgets

    • added manager widget to module_manager_widget.py
    • added widget as its own module
    • added manager widget and widget classes to module_widgets subpackage __init__.py
  • Software module added to pyrpl/software_modules

    • added module manager class to module_managers.py
      • implemented _widget_class
      • typically the same name as the hardware module class with a plural "s" in the end
    • added moudule manager class to software_modules subpackage __init__.py
  • added module manager class name to the soft_mod_names in pyrpl/pyrpl.py

  • added hardware module class to the cls_modules in pyrpl/redpitaya.py

For reference on how the changes are implemented, the pyrpl master branch can be compared with my fork.

cd pyrpl-fads
git diff upstream/master open_fpga_fads

Hardware Module

To access the RedPitaya directly using the memory mapped interface from the GUI, the following class attributes have to be implemented

Attribute Description
addr_base Base address for the module e.g. 0x40600000 for FADS
name Name for the module (used for metaprogramming)
_widget_class The GUI widget class defined in widgets.module_widgets
_gui_attributes List of the names of the attributes/properties that should be displayed in the GUI
_setup_attributes List of the names of the attributes/properties that should be set up (default: same as _gui_attributes
Clone this wiki locally