Test chip features #128
Test chip features #128
Conversation
… tile-reset-ctrl word-packed
There was a problem hiding this comment.
I think this looks nice. The one assumption that I think you are making is that you will write to all SCRs in batch. In my test chip I write SCRs in phases (I have some scripts that write SCRs to reset... wait a bit... set clocks.... wait a bit / calc stuff... set more stuff). However, this seems like a useful 1st step for simulation purposes.
jerryz123
changed the title
Yeah. For anything more complicated this simple solution breaks down. But it is useful for simulation in this form |
There was a problem hiding this comment.
I think the init_writes feature is useful but as Abe mentioned for an actual chip it is probably insufficient and people would end up writing their own my_chip_tsi_t class or something more custom like that to solve this issue. It is worth at least mentioning that in the documentation for this new feature on what to do when this in insufficient.
The CustomBootPin feature seems to be missing the part of self-boot where the bootrom is updated to read from some off-chip storage before jumping to it. Is the idea that one would use yet-another-boot-loader(YABL) in some other ROM/RAM for the reading from off-chip storage?
My other question about CustomBootPin is why do we choose to make this a hardware state machine vs the traditional way we have done this in bootrom SW?
And finally compressing the reset regs doesn't seem very useful to me and removes some functionality.
| val r_tile_resets = (0 until nTiles).map({ i => | ||
| withReset (asyncResetSinkNode.in.head._1.reset) { | ||
| Module(new AsyncResetRegVec(w=1, init=(if (params.initResetHarts.contains(i)) 1 else 0))) | ||
| } | ||
| }) | ||
| node.regmap((0 until nTiles).map({ i => | ||
| i -> Seq(RegField.rwReg(1, r_tile_resets(i).io)), | ||
| i * 4 -> Seq(RegField.rwReg(1, r_tile_resets(i).io)), |
There was a problem hiding this comment.
This change still seems silly to me.
The only benefit seems to be the user doesn't need to know that state of the cores to affect a change, i.e. they can just write a 0 or 1 to a specific word without reading first or keeping of track of which cores are in reset.
The down side is the user cannot bring multiple cores out of reset at once. This can be problematic if the user has cores that are designed to come up together.
There was a problem hiding this comment.
The fact that byte-wide writes through TSI don't work is the real motivation for this change. This just seems safer for now, as its more intuitive to do a series of word-writes, instead of doing byte-mask manipulation.
Also if some cores are designed to come up together with reset, then some other widget should be used instead of this one. Even if we byte-packed them, this widget wouldn't support bringing them out of reset together if their hartids are more than 8 apart, or not aligned properly.
Yes. This functionality gives us the flexibility to put YABL off-chip as well, instead of on a on-chip ROM.
One benefit is that the bootrom code can stay the same, regardless of whether or not this pin is present. Instead of having the bootrom check if this pin is set, have this pin control when hart0 wakes up and where it tries to boot from. Also the HW state machine for this is very simple. |
|
This has all been tested by me using these features to simulate various boot sequences. |
|
Issue for docs opened here: ucb-bar/chipyard#844 |
A set of useful features for testchip
+init_write=<addr>:<val>argument lets the user write to arbitrary SCRs before hart0 leaves the bootrom. Useful for setting up clocks, putting things in and out of reset, etc. You can string together an arbitrary sequence ofinit_writeflags to set up the SCRs in any way you want.BootAddrRegmemory-mapped register, instead of always sending the harts toDRAM_BASE. The default is stillDRAM_BASECustomBootPinfunctionality exposes a ChipTop pin that, when asserted, writes some custom address to theBootAddrReg, and then writes MSIP for hart0. This lets us simulate untethered boot, since we can redirect hart0 to secondary boot media without relying on TSI for anything.+no_hart0_msipargument prevents the tsi widget from breaking hart0 out of the bootrom by writing MSIP. When coupled with theCustomBootPinfunctionality, this lets us simulate untethered bootread_chunkandwrite_chunkdoes not work with sub-word accesses. https://github.com/riscv/riscv-isa-sim/blob/21684fd9b073cf9bd8f8d23cfc5f94ce361f170c/fesvr/tsi.cc#L55 . Making the ResetCtrl registers word-packed lets them be manipulated through TSI, which is useful.