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

Fix set_bus_skew constraint upper bound in axis_async_fifo.tcl #33

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

LukasVik
Copy link

The goal of the constraint is to ensure that parallel Gray-coded words sampled in the destination domain always assume valid values. Since Gray code is used, within each source clock period, a maximum of one bit can change value. Hence the skew constraint should have an upper bound that is equal to the period of the source clock.

This is equivalent to saying that in each destination word, the bits might come from two different source words.

The previous constraint used the destination clock period. This can fail when going from a fast to a slow clock. Imagine going from a 5 ns clock to a 10 ns clock. Words sampled in the destination domain can come from three different source words, meaning that multiple bits might have changed value, meaning that the Gray code might not be valid.

There is a third set_bus_skew constraint for the wr_ptr_commit_sync_reg signal. This does not seem to use Gray code. So I don't really know what this is. I'm leaving this as it is, maybe someone with more insight into the design can decide what to do with this.

The goal of the constraint is to ensure that parallel Gray-coded words sampled in the destination domain always assume valid values.
Since Gray code is used, within each source clock period, a maximum of one bit can change value.

Hence the skew constraint should have an upper bound that is equal to the period of the source clock.
This is equivalent to saying that in each destination word, the bits might come from two different source words.

The previous constraint used the destination clock period. This can fail when going from a fast to a slow clock.
Imagine going from a 5 ns clock to a 10 ns clock.
Words sampled in the destination domain can come from three different source words, meaning that multiple bits might have changed value, meaning that the Gray code might not be valid.

There is a third `set_bus_skew` constraint for the `wr_ptr_commit_sync_reg` signal.
This does not seem to use Gray code. So I don't really know what this is. I'm leaving this as it is, maybe someone with more insight into the design can decide what to do with this.
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.

1 participant