-
Notifications
You must be signed in to change notification settings - Fork 79
Design of DP scheduling with deadline calculations #515
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Design of DP scheduling with deadline calculations #515
Conversation
architectures/firmware/sof-zephyr/mpp_layer/images/dp_scheduling/example3_5.pu
Outdated
Show resolved
Hide resolved
architectures/firmware/sof-zephyr/mpp_layer/images/dp_scheduling/example3_5.pu
Outdated
Show resolved
Hide resolved
this commit contains a detailed description of DP scheduling and DP deadline calculations Signed-off-by: Marcin Szkudlinski <[email protected]>
597464d
to
7958665
Compare
resolved changes in git. The preview page is not changed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR adds comprehensive documentation for DP (Data Processing) scheduling with deadline calculations in the SOF firmware architecture. It introduces a detailed design document that explains the EDF (Earliest Deadline First) scheduling algorithm used for data processing modules running in separate threads with lower priority than LL (Low Latency) threads.
Key changes:
- Addition of DP scheduling documentation with mathematical formulations for deadline calculations
- Comprehensive examples demonstrating different scheduling scenarios including startup cases
- Multiple PlantUML diagrams illustrating pipeline states and data flow
Reviewed Changes
Copilot reviewed 30 out of 30 changed files in this pull request and generated 5 comments.
File | Description |
---|---|
architectures/firmware/sof-zephyr/mpp_layer/index.rst | Adds reference to new dp_scheduling documentation |
architectures/firmware/sof-zephyr/mpp_layer/dp_scheduling.rst | Main documentation file with detailed DP scheduling design and examples |
architectures/firmware/sof-zephyr/mpp_layer/images/dp_scheduling/*.pu | 29 PlantUML diagram files showing various pipeline states and scheduling scenarios |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
- data reciever's consumption rate and period | ||
- data source production rate and period | ||
- data reciever's module's LST - latest start time |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The word 'reciever' should be spelled 'receiver' (appears twice in lines 40 and 42).
- data reciever's consumption rate and period | |
- data source production rate and period | |
- data reciever's module's LST - latest start time | |
- data receiver's consumption rate and period | |
- data source production rate and period | |
- data receiver's module's LST - latest start time |
Copilot uses AI. Check for mistakes.
|
||
*Example:* if a data rate is 48samples/msec and OBS = 480samples, the "worst case" period should be calculated 10ms | ||
|
||
*NOTE:* in case of sampling freq like 44.1 a round up should taken - if ration is 44.1 samples per mlisecond, 45 samples should be used for calculations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Multiple spelling errors: 'ration' should be 'ratio' and 'mlisecond' should be 'millisecond'. Also 'should taken' should be 'should be taken'.
*NOTE:* in case of sampling freq like 44.1 a round up should taken - if ration is 44.1 samples per mlisecond, 45 samples should be used for calculations | |
*NOTE:* in case of sampling freq like 44.1 a round up should be taken - if ratio is 44.1 samples per millisecond, 45 samples should be used for calculations |
Copilot uses AI. Check for mistakes.
**def: DP module's latest start time (LST)** | ||
|
||
LST is the latest time when **a module** must start processing a portion of data in order to meet its deadline. It can be calculated as: | ||
``deadline - LPT`` When a module is in the middle of processing, its LST may be negative. In that case 0 should be taken to all futhure calculations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The word 'futhure' should be spelled 'future'.
``deadline - LPT`` When a module is in the middle of processing, its LST may be negative. In that case 0 should be taken to all futhure calculations. | |
``deadline - LPT`` When a module is in the middle of processing, its LST may be negative. In that case 0 should be taken to all future calculations. |
Copilot uses AI. Check for mistakes.
End of stream | ||
============= | ||
|
||
When a SP module is in the middle of processing when a pipeline is stopping, it should finish processing its current chunk of data. Unformtunately there's no way to interrupt ongoing processing without risk of memory leaks etc. Therefore IPC stopping a pipeline should wait till all DP modules finish processing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The word 'Unformtunately' should be spelled 'Unfortunately'. Also 'SP module' appears to be inconsistent with 'DP module' used elsewhere in the document.
When a SP module is in the middle of processing when a pipeline is stopping, it should finish processing its current chunk of data. Unformtunately there's no way to interrupt ongoing processing without risk of memory leaks etc. Therefore IPC stopping a pipeline should wait till all DP modules finish processing. | |
When a DP module is in the middle of processing when a pipeline is stopping, it should finish processing its current chunk of data. Unfortunately there's no way to interrupt ongoing processing without risk of memory leaks etc. Therefore IPC stopping a pipeline should wait till all DP modules finish processing. |
Copilot uses AI. Check for mistakes.
- dedline of DP2 can't be calculated | ||
- dedline of DP1 can't be calculated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The word 'dedline' should be spelled 'deadline' (appears twice).
- dedline of DP2 can't be calculated | |
- dedline of DP1 can't be calculated | |
- deadline of DP2 can't be calculated | |
- deadline of DP1 can't be calculated |
Copilot uses AI. Check for mistakes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some spellings.
this commit contains a detailed description of DP
scheduling and DP deadline calculations
readable version:
https://marcinszkudlinski.github.io/sof-docs/PAGES/architectures/firmware/sof-zephyr/mpp_layer/dp_scheduling.html