Skip to content
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

SPI Engine: Fixed delay behaviour on Chip-Select and Sleep instructions #1200

Merged
merged 4 commits into from
Oct 30, 2023

Conversation

LBFFilho
Copy link
Contributor

@LBFFilho LBFFilho commented Oct 18, 2023

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

  • 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

- previously, a sleep time happened before the chip select change
- the intended behaviour was for another sleep time, of equal amount, to happen after the chip select change as well
- additionally, the counter logic implementation was creating an additional factor of 2 on the sleep time

All of the above points were fixed. The changes introduced also fix another issue where the sleep instruction was likewise happening
with a duration larger than intended by a factor of 2

Signed-off-by: Laez Barbosa <laez.barbosa@analog.com>
… behaviour.

Signed-off-by: Laez Barbosa <laez.barbosa@analog.com>
@CLAassistant
Copy link

CLAassistant commented Oct 18, 2023

CLA assistant check
All committers have signed the CLA.

…han 0.

Updated delay documentation to match behavior.

Signed-off-by: Laez Barbosa <laez.barbosa@analog.com>
Signed-off-by: Laez Barbosa <laez.barbosa@analog.com>
@LBFFilho LBFFilho merged commit becc035 into analogdevicesinc:master Oct 30, 2023
1 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants