Starting up a Chip using another Chip
71 views
Skip to first unread message
Tim Heaton
May 31, 2024, 4:29:15 PMMay 31
to Chipyard
Hey,
I'm interested in having multiple chips that can program their nearest neighbors via TileLink, leading me to have a couple questions.
First, does it seem fair to assume that I should just be able to have Chip0 program Chip1 with standard TL-UL Put operations to the same ports that the TLSerdesser connects to?This does imply that I would have to remove the TSI setup and replace it with something more custom.
Second, The FESVR seems to manage a lot with the TOHOST and FROMHOST registers. With this being removed, I assume it would be expected that printing and shutting down the SoC would not work anymore? I would imagine that the chip to chip TL communication would have to be used to indicate when the host chip should start shutting things down.
Finally, has something similar to Chip to Chip programming been investigated? I found some commentary on ChipLink and other projects, but I figured this might be the place to get some more up to date info on this.
Best,
Tim H
I'm interested in having multiple chips that can program their nearest neighbors via TileLink, leading me to have a couple questions.
First, does it seem fair to assume that I should just be able to have Chip0 program Chip1 with standard TL-UL Put operations to the same ports that the TLSerdesser connects to?This does imply that I would have to remove the TSI setup and replace it with something more custom.
Second, The FESVR seems to manage a lot with the TOHOST and FROMHOST registers. With this being removed, I assume it would be expected that printing and shutting down the SoC would not work anymore? I would imagine that the chip to chip TL communication would have to be used to indicate when the host chip should start shutting things down.
Finally, has something similar to Chip to Chip programming been investigated? I found some commentary on ChipLink and other projects, but I figured this might be the place to get some more up to date info on this.
Best,
Tim H
Jerry Zhao
May 31, 2024, 5:27:35 PMMay 31
to chip...@googlegroups.com
> I'm interested in having multiple chips that can program their nearest neighbors via TileLink, leading me to have a couple questions.
To be precise, I interpret "programming" a chip as "bringing up" the chip... that is, not only writing the target binary onto the chip, but also setting any configuration registers that are needed before the chip starts executing the binary.
In this sense "programming" a chip implies both a physical interface and hardware protocol for memory access into the chip, as well as a procedure for the process of loading/configuring/starting the chip.
Using this terminology, our default single-chip system uses SerialTilelink as the physical interface, TileLink-UL as the hardware protocol, and HTIF/TSI (in FESVR) as the procedure. The TOHOST//FROMHOST thing is part of the procedure of how FESVR/HTIF communicates with target binaries on the chip.
If you are developing a chiplet based system, SerialTileLink with TileLink-UL still works as the physical interface and hardware protocol (The existing multi-chip configs do this). However, there is no existing procedure for how one chip should bringup/program the other. If you are trying to build a system where chip0 needs to configure a bunch of registers on chip1, send the binary over, then launch chip1 and shut it down, you'll have to develop that procedure on your own (although I would be curious to see what you come up with, if you are free to share it). This procedure can use the existing serial-tlielink chip-to-chip interface implementation.
The FESVR "shutdown" via tohost doesn't actually physically "shut down" the chip, in the sense of either sending a poweroff signal to the PMU (we don't even model a PMU) or even just putting the chip back into reset. The FESVR "shutdown" via tohost just terminates the FESVR frontend, which normally just halts the RTL simulation. If you are building a physical system where one chip actually needs to physically shut the other one down, you'll need your own mechanism.
Regarding existing work on chip-to-chip programming.... there has been work towards developing new chip-to-chip physical interfaces (of which ChipLink is an example), but nothing as far as I'm aware concerning a codified standard procedure. I think it would be difficult to develop a "standard" for this kind of thing, since the architecture and intended use case of the multi-chip-system would be quite varied.
-Jerry
In this sense "programming" a chip implies both a physical interface and hardware protocol for memory access into the chip, as well as a procedure for the process of loading/configuring/starting the chip.
Using this terminology, our default single-chip system uses SerialTilelink as the physical interface, TileLink-UL as the hardware protocol, and HTIF/TSI (in FESVR) as the procedure. The TOHOST//FROMHOST thing is part of the procedure of how FESVR/HTIF communicates with target binaries on the chip.
If you are developing a chiplet based system, SerialTileLink with TileLink-UL still works as the physical interface and hardware protocol (The existing multi-chip configs do this). However, there is no existing procedure for how one chip should bringup/program the other. If you are trying to build a system where chip0 needs to configure a bunch of registers on chip1, send the binary over, then launch chip1 and shut it down, you'll have to develop that procedure on your own (although I would be curious to see what you come up with, if you are free to share it). This procedure can use the existing serial-tlielink chip-to-chip interface implementation.
The FESVR "shutdown" via tohost doesn't actually physically "shut down" the chip, in the sense of either sending a poweroff signal to the PMU (we don't even model a PMU) or even just putting the chip back into reset. The FESVR "shutdown" via tohost just terminates the FESVR frontend, which normally just halts the RTL simulation. If you are building a physical system where one chip actually needs to physically shut the other one down, you'll need your own mechanism.
Regarding existing work on chip-to-chip programming.... there has been work towards developing new chip-to-chip physical interfaces (of which ChipLink is an example), but nothing as far as I'm aware concerning a codified standard procedure. I think it would be difficult to develop a "standard" for this kind of thing, since the architecture and intended use case of the multi-chip-system would be quite varied.
-Jerry
--
You received this message because you are subscribed to the Google Groups "Chipyard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chipyard+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/c55a37d6-4ea5-47b8-af65-75c7f1d4bf6dn%40googlegroups.com.
Message has been deleted
Tim Heaton
Jun 4, 2024, 9:04:31 PMJun 4
to Chipyard
Yup, this makes a lot of sense. I can see what you are referring to throughout the Chisel.
As for the startup procedure, I was leaning towards an interrupt based system since my base chip controls the actions of the rest, so
a cascading interrupt scheme seemed to be a decent solution, but I'll see once I implement it.
As a final note, when it comes to exposing memories between chiplets, does the manager node normally reflect what is on the other side
of the serial link?
For example, the RocketCoreChipletConfig (https://github.com/ucb-bar/chipyard/blob/main/generators/chipyard/src/main/scala/config/ChipletConfigs.scala#L50-L86)
has 2 serial ports. The second one is defined as a manager which makes me think the RocketCoreChipletConfig should have a slave connected to a memory. Instead, it seems to indicate the second serial port will connect to the LLCChipletConfig which is the memory.
Its as if a manager node in a SerialTLParams definition is indicative on what is on the other side of the link?
Thanks!
Tim H
Reply all
Reply to author
Forward
0 new messages