-
Notifications
You must be signed in to change notification settings - Fork 5
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
Comments
As a comment to self, the |
A first POC is available in the https://github.com/perlindgren/syncrim/tree/memory_component branch. Todo:s include
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 |
A minimal viable implementation has been merged. |
Added simple |
Fixed some clippy warning and updated dependencies, will merge if passing. |
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. |
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:
vizia
GUI (very simple). See thedata_mem
example.Todo:
egui
GUIThe text was updated successfully, but these errors were encountered: