You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 29, 2024. It is now read-only.
I have no idea if this could work or how it would look, but it could be a very powerful idea.
Quite often, a kaze module is developed against one or more simulated peripherals, written in software. For example, a CPU design is tested against a simulated memory, or even an entire system bus with multiple peripheral simulations.
With just one or two peripheral simulations, managing the simulations and how they interact with the kaze-generated design simulation isn’t terribly difficult, but this complexity very quickly grows as the number of peripherals increases. This is also the case as the ways in which the peripherals interact becomes more complex.
If each simulated peripheral were to be considered in isolation, this is more or less trivial in most cases. A simulation could be implemented as a coroutine that may interact with the kaze generated sim, including stepping cycles and peeking/poking ports.
In order to sync the various simulations, it could make sense to code each one in a separate coroutine, with each cycle step represented by yielding. Some underlying system could manage the various continuations and perhaps propagating signals in between.
These ideas might be able to play nicely with rust’s async/await features somehow. I think this should be explored, as it would make writing and maintaining reusable software simulations much, much nicer, which in turn makes kaze even more effective.
Note that it may make more sense to explore this idea as a separate concept/library from kaze entirely, that kaze could itself integrate well with; I imagine these kinds of software simulations have broader applicability than just supporting kaze design development.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I have no idea if this could work or how it would look, but it could be a very powerful idea.
Quite often, a kaze module is developed against one or more simulated peripherals, written in software. For example, a CPU design is tested against a simulated memory, or even an entire system bus with multiple peripheral simulations.
With just one or two peripheral simulations, managing the simulations and how they interact with the kaze-generated design simulation isn’t terribly difficult, but this complexity very quickly grows as the number of peripherals increases. This is also the case as the ways in which the peripherals interact becomes more complex.
If each simulated peripheral were to be considered in isolation, this is more or less trivial in most cases. A simulation could be implemented as a coroutine that may interact with the kaze generated sim, including stepping cycles and peeking/poking ports.
In order to sync the various simulations, it could make sense to code each one in a separate coroutine, with each cycle step represented by yielding. Some underlying system could manage the various continuations and perhaps propagating signals in between.
These ideas might be able to play nicely with rust’s async/await features somehow. I think this should be explored, as it would make writing and maintaining reusable software simulations much, much nicer, which in turn makes kaze even more effective.
Note that it may make more sense to explore this idea as a separate concept/library from kaze entirely, that kaze could itself integrate well with; I imagine these kinds of software simulations have broader applicability than just supporting kaze design development.
The text was updated successfully, but these errors were encountered: