←back to thread

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

(chipsandcheese.com)
154 points rbanffy | 3 comments | 30 Aug 25 14:18 UTC | HN request time: 0s | 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 #
1. IshKebab ◴[30 Aug 25 16:29 UTC] No.45075901[source]▶
I don't think that would help - the set of instructions that have dynamic latencies is basically fixed. Anything memory-related (loads, stores, cache management, fences, etc.) and complex maths (division, sqrt, transcendental functions, etc.)

So you know what code can be statically scheduled just from the instructions already.

replies(1): >>45076005 #
2. bee_rider ◴[30 Aug 25 16:43 UTC] No.45076005[source]▶
I’m just spitballing. But, what if we had some system that went:

1) load some model and set the system into “ready” mode

2) wait for an event from a sensor

3) when the event occurs, trigger some response

4) do other stuff; book keeping, update the model, etc,

5) reset the system to “ready” mode and goto 2

Is it possible we might want some hard time bounds on steps 2 and 3, but be fine with 1, 4, and 5 taking however long? (Assuming the device can be inactive while it is getting ready). Then, we could make sure steps 2 and 3 don’t include any non-static instructions.

replies(1): >>45076810 #
3. IshKebab ◴[30 Aug 25 18:10 UTC] No.45076810[source]▶
Not sure what you're getting at tbh... Do you know about interrupts?