SPI Engine: Fixed delay behaviour on Chip-Select and Sleep instructions #1200
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Description
This PR fixes observed behavior of the Chip-Select and Sleep instructions not matching the documentation. A separate testbench was created for this behavior on a fork. A corresponding PR will be created for the testbench. To run it, simply go to the testbenches/pulsar_adc_pmdz directory, and run
make CFG=cfg1 TST=sleep_delay_test
According to the documentation on the wiki, the Sleep instruction should sleep for
sleep_time = (t + 1) * ((div + 1) * 2) / f_clk
where "t" is the parameter given to the sleep instruction. However, the current SPI engine implementation (before this PR) actually sleeps for double the duration, due to the way the counter was implemented. The Chip-Select instruction was also affected by this.
The Chip-Select instruction documentation states that the instruction was supposed to create a delay before and after the CS change. The delay after a CS change is useful when implementing fast SPI converters, which sometimes have some timing requirements between CS activation and a SCLK edge. However, the behavior before this PR is that the full delay was happening only before the CS change. Additionally, as stated above, the counter implementation made the delay double (but didn't make it happen after the CS change).
The wiki documentation gives the following for the Chip-Select instruction, where t is the delay parameter:
delay_per_edge = t * (div + 1) / f_clk
This would imply that this instruction does not use the same prescaler as the rest of the SPI Engine, so I updated the formula on the .rst documentation to reflect this, to:
delay_per_edge = t * (div + 1) *2/ f_clk
The changes introduced do not affect the behavior for CS when t=0, which, as far as I know is the common case. So it shouldn't break any existing projects.
PR Type
PR Checklist