←back to thread

Condor's Cuzco RISC-V Core at Hot Chips 2025

(chipsandcheese.com)
154 points rbanffy | 5 comments | 30 Aug 25 14:18 UTC | HN request time: 0.001s | source
Show context
bee_rider ◴[30 Aug 25 15:20 UTC] No.45075394[source]▶
The static schedule part seems really interesting. They note that it only works for some instructions, but I wonder if it would be possible to have a compiler report “this section of the code can be statically scheduled.” In that case, could this have a benefit for real-time operation? Or maybe some specialized partially real-time application—mark a segment of the program as desiring static scheduling, and don’t allow memory loads, etc, inside there.
replies(4): >>45075641 #>>45075901 #>>45078349 #>>45087597 #
usrusr ◴[30 Aug 25 15:50 UTC] No.45075641[source]▶
What would the CPU do with the parts not marked as "can be statically scheduled"? I read it as they try it anyways and may get some stalling ("replay") if the schedule was overoptimistic. Not sure how a compiler marking sections could be of help?
replies(2): >>45075909 #>>45081427 #
1. IshKebab ◴[30 Aug 25 16:30 UTC] No.45075909[source]▶
Stalling and replay are not the same btw. Stalling is when you wait a bit before continuing, replay is when you try an operation multiple times.
replies(1): >>45077825 #
2. usrusr ◴[30 Aug 25 20:41 UTC] No.45077825[source]▶
So the difference is block everything until the dependency is available and then continue immediately, vs give up on time slots already reserved for downstream dependencies while continuing with those parts in the current schedule that are not blocked and copy the blocked parts at the end of the queue? Sounds like a trade-off that can go one way or the other? But yeah, I was using the term "stalling" in a browser sense, as the superset of both. No idea how incorrect that is.
replies(1): >>45078218 #
3. IshKebab ◴[30 Aug 25 21:39 UTC] No.45078218[source]▶
Yeah I think even traditional OoO designs use replay for missed loads rather than stalling. The performance would be too bad if it actually stalled for every load.

I think stalling is used for rarer more awkward things like changing privilege modes or writing certain CSRs (e.g. satp) where you don't want to have to maintain speculative state.

replies(1): >>45079141 #
4. monocasa ◴[31 Aug 25 00:08 UTC] No.45079141{3}[source]▶
Traditional OoO designs don't stall for loads per se, but will stall for a full ROB that has a chain of dependencies waiting on the results of the load.
replies(1): >>45080863 #
5. IshKebab ◴[31 Aug 25 06:31 UTC] No.45080863{4}[source]▶
Good point, but I guess that's the sort of delay that you can't avoid. If there's literally no work to do until a load is available you have to wait. This design can't avoid that either.