Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory component #9

Open
4 of 6 tasks
perlindgren opened this issue Jul 6, 2023 · 6 comments
Open
4 of 6 tasks

Memory component #9

perlindgren opened this issue Jul 6, 2023 · 6 comments
Assignees

Comments

@perlindgren
Copy link
Owner

perlindgren commented Jul 6, 2023

I will now start implementing a memory component.

In order to avoid double work I think its a good idea if we create tracking issues for the work we do.

A key problem here is howto manage the state in order to allow reversing (aka, UnClocking). We probably don't want to make history buffer containing the complete memory state for each clock cycle. A good design to solve this effectively might be re-usable for other purposes (when we later implement other stateful components, e.g., peripherals). Stateful reversal was never really correctly implemented in the original SyncSim model, with the effect that reversing interrupts never worked totally correct.

Features:

Implemented:

  • read/write of u8/u16/u32
  • alignment checking
  • byte ordering
  • vizia GUI (very simple). See the data_mem example.

Todo:

  • local history buffer
  • egui GUI
@perlindgren perlindgren self-assigned this Jul 6, 2023
@perlindgren
Copy link
Owner Author

As a comment to self, the reg_file component currently has no history.

@perlindgren
Copy link
Owner Author

A first POC is available in the https://github.com/perlindgren/syncrim/tree/memory_component branch.
It currently supports only u8 accesses.

Todo:s include

  • u8/u16/u32/u64
  • alignment checking
  • byte ordering
  • local history buffer

Notice, we will likely need to add un_clock, and reset to the Component trait (but this will be a separate issue/PR).

The implementation showcases how we can provide structured abstractions to inputs and outputs using num_enum. This allows to give meaning to signals (e.g., the ctrl signal being an enum of variants (None, Read, Write) etc. This will improve readability/ease of use of components.

@perlindgren
Copy link
Owner Author

A minimal viable implementation has been merged.

@perlindgren
Copy link
Owner Author

Added simple vizia frontend, with an example (data_mem).

@perlindgren
Copy link
Owner Author

Fixed some clippy warning and updated dependencies, will merge if passing.

@onsdagens
Copy link
Collaborator

Partly addressed with #78 . I think optimally you have a generic memory component with an architecture specific wrapper (exposing ports specific to some architecture). That way we can re-use most of the generic memory code and UI. Let's keep this issue around.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants