[rom_ctrl,rtl] Add a flop between rom_ctrl and kmac #27658
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rswarbrick
force-pushed
the
rom-ctrl-kmac-flop
branch
from
129145e to
86d892c
Compare
vogelpi
approved these changes
Jul 18, 2025
There was a problem hiding this comment.
Thanks @rswarbrick , this looks great! Let's wait for @davidschrammel 's feedback.
I think since the flop stage is optional, it's fine to use 2 stages. In some cases ROMs are very big and one may want to have the initial boot phase to run fast.
This injects a clock edge between data coming out of the ROM and data going into KMAC to be hashed. Inserting the delay is pretty trivial: we just use a prim_fifo_sync. There *is* an area vs. efficiency question. Because there is no pass-through, a prim_fifo_sync with depth 1 will have half throughput, because it has to alternate between taking an item and passing it on. Although, there's the bandwidth to do both on the same cycle, breaking the combinatorial path means that we can't pass the KMAC block's "ready" signal all the way back to the ROM. This works perfectly well, but takes twice as long as you might hope. A lazy workaround is to use Depth = 2. This is a little silly, because it uses twice as much area as necessary. But it's very easy from a coding perspective! Signed-off-by: Rupert Swarbrick <rswarbrick@lowrisc.org>
Signed-off-by: Rupert Swarbrick <rswarbrick@lowrisc.org>
Signed-off-by: Rupert Swarbrick <rswarbrick@lowrisc.org>
rswarbrick
force-pushed
the
rom-ctrl-kmac-flop
branch
from
86d892c to
a537191
Compare
Razer6
reviewed
Jul 19, 2025
| sent to KMAC. This may break long paths in a target chip, at the cost of | ||
| adding chip area. | ||
| ''' | ||
| local: "false", |
There was a problem hiding this comment.
I think it would be better to make it local: "true" so that it becomes an localparam and the top-level HJSON is the single source of truth.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This injects a clock edge between data coming out of the ROM and data going into KMAC to be hashed. Inserting the delay is pretty trivial: we just use a prim_fifo_sync.
There is an area vs. efficiency question. Because there is no pass-through, a prim_fifo_sync with depth 1 will have half throughput, because it has to alternate between taking an item and passing it on. Although, there's the bandwidth to do both on the same cycle, breaking the combinatorial path means that we can't pass the KMAC block's "ready" signal all the way back to the ROM.
This works perfectly well, but takes twice as long as you might hope.
A lazy workaround is to use Depth = 2. This is a little silly, because it uses twice as much area as necessary. But it's very easy from a coding perspective!