SPI Engine: fix off-by-one sleep time

[LBFFilho]

Fixes error seen in #1389

Somewhat recently, during #1200, while fixing a related bug, I altered the documentation to reflect what was then the behavior of the SPI Engine for the Sleep instruction: it slept for t prescaler ticks.

What I didn't realize back then was that the intended behavior, as seen on the first SPI Engine commit, is to sleep for t+1 ticks, and that there had been a regression in the meantime.

To illustrate, I've made some simple tests, which call the sleep instruction with a parameter of t=4. Expected behavior is for it to sleep for t+1 ticks, as seen on first commit and as has been documented in the old wiki.

This is with the current main (counts only t ticks):

This is how it was before #1200
(before I changed the doc), it counts each tick as double the duration - that was the bug being solved, but is not relevant to the current PR. At this point, there had already been a regression (counts only t ticks):

This is the behavior on the first commit for the SPI Engine (counts the correct number of t+1 ticks):

PR Type

• Bug fix (change that fixes an issue)
• New feature (change that adds new functionality)
• Breaking change (has dependencies in other repos or will cause CI to fail)

PR Checklist

• I have followed the code style guidelines
• I have performed a self-review of changes
• I have compiled all hdl projects and libraries affected by this PR
• I have tested in hardware affected projects, at least on relevant boards
• I have commented my code, at least hard-to-understand parts
• I have signed off all commits from this PR
• I have updated the documentation (wiki pages, ReadMe files, Copyright etc)
• I have not introduced new Warnings/Critical Warnings on compilation
• I have added new hdl testbenches or updated existing ones

[dlech]

Tested this with the AD496x project. We are getting the expected minimum delay time now.

The requested time for the two delays pictured here is 715 ns each. We aren't using SPI offload, so that probably explains why they a bit longer than requested. But the important part is that they are not less than requested.