Feature: Reintroduce `tapasco-debug` with new interface in Rust #290

zyno42 · 2021-07-05T08:41:23Z

Closes #264

jahofmann · 2021-07-05T09:01:32Z

Thanks for starting this.

For reference: You can use the new API introduced in #279 to access platform memory:

tapasco/runtime/libtapasco/src/device.rs

Line 618 in 50ed109

pub fn get_available_platform_components(&self) -> Vec<String> {

This is needed for e.g. DMA and Interrupt status registers.

zyno42 · 2021-07-05T09:03:52Z

Thanks, I will have a look into this.

jahofmann · 2021-07-05T09:09:22Z

runtime/examples/Rust/tapasco-debug/src/app/mod.rs

+        // Allocate the first device with ID 0 (because most devices will only have one FPGA)
+        let mut tlkm_device = tlkm.device_alloc(0, &HashMap::new()).context(TLKMInit {})?;
+        // Change device access to excluse to be able to acquire PEs
+        tlkm_device.change_access(tapasco::tlkm::tlkm_access::TlkmAccessExclusive).context(DeviceInit {})?;


This will be an issue as you cannot run any other tapasco software requiring exclusive access while running tapasco-debug this way.

You might want to change your "acquire_pe_without_job" to return a read-only version of the PE which does not require exclusive access.

Yes, I wanted to discuss this anyway, so I've split it into a separate commit. Thank you for bringing it up directly.

I'm not sure how to resolve this in the end but I think in order to set register values (which is not implemented at the moment) there should be exclusive access. If someone wants to observe another Tapasco application there could be a read-only mode of tapasco-debug where you cannot set the values but run with other software side-by-side.

What do you think about this?

We might want to have ´tapasco-debug´ ignore all of the scheduler etc and go entirely with debug functionality. This could look like the functions I've prepared for this purpose for the platform part at

tapasco/runtime/libtapasco/src/device.rs

Line 618 in 50ed109

pub fn get_available_platform_components(&self) -> Vec<String> {

For the Arch part we'd only need two functions, e.g.:

pub fn get_available_pes(&self) -> Vec<(Id, PEId)> {} pub fn get_pe(&self, read_only: bool) -> PE {}

For those we can have a read-only version which does not require exclusive access, and a full access version. Tapasco-debug can then have e.g. three modes

Default: Monitor mode -> read only

Full Access -> requires exclusive

Forced Full Access -> Works with monitor mode but provides full access, all safety is off

Sounds good to me. I'm going to talk about it with @cahz later and see what his opinion is on this.

There are now three modes: Monitor, Debug and Unsafe. But they don't work correctly yet. See:
#296

I have now disabled the debug mode again and added a comment for #296.

runtime/libtapasco/src/device.rs

This is the first commit for a work-in-progress effort on Issue esa-tu-darmstadt#264. Since `tapasco-debug` was removed in the v2020.10 release because the ncurses-based UI was "quite flaky" you had to use two different Tapasco workspaces to have the debugger still around while using the recent Tapasco version. This reimplementation of `tapasco-debug` is written in Rust and uses the `libtui-rs` and `crossterm` crates for the terminal user interface along with the new Tapasco runtime. For the moment it provides a list of PEs which can be selected to see the first 16 argument registers along with some generic bitstream and platform information. Writing to argument registers, starting PEs, dumping Local Memory is not possible yet. To integrate it into the build process of this repository it uses the same mechanism to build using Cargo from CMake as PR esa-tu-darmstadt#285.

This is a necessary change for `tapasco-debug` to be able to acquire a PE in order to call its methods instead of directly starting a job on that PE as it is usually the case.

In order to implement a Monitor Mode where values can only be observed in `tapasco-debug` the function in `libtapasco` which is used to acquire PEs is modified to return non-mutable PE structs which do not need exclusive access to the device.

See commit 5911074.

As discussed in the respective PR esa-tu-darmstadt#290 (esa-tu-darmstadt#290) there are now three differenct access modes: Monitor, Debug, Unsafe. This commit introduces command-line subcommands to choose the mode in which to operate. In `Monitor` mode nothing can be modified only another runtime can be monitored. In `Debug` Mode the argument registers can also be set interactively. In `Unsafe` Mode the only difference to `Debug` Mode is that the driver is released, so another host application can run in parallel.

- Adds unsafe method to directly access platform component memory - Simplifies usage of platform components with interrupts if they follow the TaPaSCo PE conventions - NOTE: Does not return a Job as most operations such as memory copy does not make sense for most platform components

from the cherry-picked commit from PR esa-tu-darmstadt#279: 03d717e This requires the App state to hold the device for the reference which makes unsafe mode effectively debug mode. But this is not a problem because debug mode is in reality unsafe mode as long as the exclusive access is not working correctly.

when parsing the timestamp of the bitstream generation.

to make it unsafe again.

by removing unnecessary folders.

Also leave some instructions on how to enable it again. Debug mode is currently the same as unsafe mode due to libtapasco not handling this case of access mode. Additionally, the DMA Buffers, Interrupts, etc. are also allocated in Monitor Mode which leads to the problem that you have to start your other runtime twice. For this case I've added a comment in the help section of `tapasco-debug`.

Write the 1 to start the PE directly to the appropriate address in the mapped memory. Using `libtapasco`'s API function to start a PE is not possible because ownership of the `PE` struct has already been taken and cannot be stolen back in the starting function.

that are necessary for `tapasco-debug` but break up the usually wanted encapsulation of `libtapasco`, so they are guarded behind conditional compilation if the non-default feature is activated.

TryInto is now in the prelude of the 2021 edition.

Replace unnecessary `StatefulList`s with `ListStates`. Make the number of registers and the size of local memory endless.

cahz

Thank you for your contribution! This will make many users happy :-)

zyno42 · 2022-03-18T11:45:13Z

I do hope so! :)

jahofmann reviewed Jul 5, 2021

View reviewed changes

zyno42 force-pushed the feature/reintroduce-tapasco-debug branch from 1a55414 to 1dbf30e Compare July 5, 2021 13:38

jahofmann reviewed Aug 16, 2021

View reviewed changes

runtime/libtapasco/src/device.rs Outdated Show resolved Hide resolved

zyno42 marked this pull request as ready for review September 6, 2021 15:33

zyno42 force-pushed the feature/reintroduce-tapasco-debug branch from 13b7fa5 to b5b3e02 Compare March 14, 2022 20:41

zyno42 force-pushed the feature/reintroduce-tapasco-debug branch from b5b3e02 to 9e706fe Compare March 14, 2022 20:54

zyno42 force-pushed the feature/reintroduce-tapasco-debug branch from 9e706fe to 873ae73 Compare March 18, 2022 11:06

zyno42 and others added 17 commits March 18, 2022 12:07

Modify libtapasco to acquire a PE without a job

097d8d1

This is a necessary change for `tapasco-debug` to be able to acquire a PE in order to call its methods instead of directly starting a job on that PE as it is usually the case.

Add env_logger crate for logging

3e45744

Print snafu's backtrace in Display format

af8cc07

Restructure module imports in main.rs

4d79685

Modify libtapasco to acquire a PE read-only

ebf946a

In order to implement a Monitor Mode where values can only be observed in `tapasco-debug` the function in `libtapasco` which is used to acquire PEs is modified to return non-mutable PE structs which do not need exclusive access to the device.

Fix CMakeLists for tapasco-debug in debug mode

ce68549

See commit 5911074.

Apply clippy lints and ruftfmt

9aa8082

Remove a cast that can panic

6b6ebad

when parsing the timestamp of the bitstream generation.

Remove exclusive access from Unsafe Mode

2d7ffd9

to make it unsafe again.

Simplify tapasco-debug directory layout

335d715

by removing unnecessary folders.

Update tapasco-debug dependencies, add lock file

774fdf3

Apply rustfmt again

19e0d2a

zyno42 added 17 commits March 18, 2022 12:07

Improve input handling to accept hex values

5701fdb

Rename Normal mode to Navigation mode

9dcaaaf

Add tapasco-debug feature to libtapasco to make getters pub

0ae916e

that are necessary for `tapasco-debug` but break up the usually wanted encapsulation of `libtapasco`, so they are guarded behind conditional compilation if the non-default feature is activated.

Update Cargo.lock

b020de2

Improve logging in src/ui.rs

a29d975

Implement tapasco-debug message view

287a5d7

Update Cargo.lock

4370005

Update Rust edition from 2018 to 2021

22b195c

Remove unnecessary import

40fdcb2

TryInto is now in the prelude of the 2021 edition.

Improve inline comments and TODOs

9e4df7d

Improve code quality and UI

3bad6ea

Improve code for Registers and Local Memory panes

f5f24ef

Replace unnecessary `StatefulList`s with `ListStates`. Make the number of registers and the size of local memory endless.

Apply lints and make subtraction saturating

de9051e

Remove resolved TODOs and refactor comments

a54c48a

Apply rustfmt formatting

ba0a3e6

Fix compilation errors after rebasing on develop

7c59523

zyno42 force-pushed the feature/reintroduce-tapasco-debug branch from 873ae73 to 7c59523 Compare March 18, 2022 11:08

cahz approved these changes Mar 18, 2022

View reviewed changes

cahz merged commit ffc11ee into esa-tu-darmstadt:develop Mar 18, 2022

zyno42 deleted the feature/reintroduce-tapasco-debug branch March 18, 2022 11:46

cahz added this to the 2022.1 milestone May 3, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature: Reintroduce `tapasco-debug` with new interface in Rust #290

Feature: Reintroduce `tapasco-debug` with new interface in Rust #290

zyno42 commented Jul 5, 2021

jahofmann commented Jul 5, 2021

zyno42 commented Jul 5, 2021

jahofmann Jul 5, 2021

zyno42 Jul 5, 2021

jahofmann Jul 5, 2021 •

edited

Loading

zyno42 Jul 5, 2021

zyno42 Aug 16, 2021

zyno42 Sep 20, 2021

cahz left a comment

zyno42 commented Mar 18, 2022

Feature: Reintroduce tapasco-debug with new interface in Rust #290

Feature: Reintroduce tapasco-debug with new interface in Rust #290

Conversation

zyno42 commented Jul 5, 2021

jahofmann commented Jul 5, 2021

zyno42 commented Jul 5, 2021

jahofmann Jul 5, 2021

Choose a reason for hiding this comment

zyno42 Jul 5, 2021

Choose a reason for hiding this comment

jahofmann Jul 5, 2021 • edited Loading

Choose a reason for hiding this comment

zyno42 Jul 5, 2021

Choose a reason for hiding this comment

zyno42 Aug 16, 2021

Choose a reason for hiding this comment

zyno42 Sep 20, 2021

Choose a reason for hiding this comment

cahz left a comment

Choose a reason for hiding this comment

zyno42 commented Mar 18, 2022

Feature: Reintroduce `tapasco-debug` with new interface in Rust #290

Feature: Reintroduce `tapasco-debug` with new interface in Rust #290

jahofmann Jul 5, 2021 •

edited

Loading