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

Add support for optional axis_tstrb #60

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

Conversation

ollie-etl
Copy link

Support driving tstrb, if present.

Unimplmented, and unknown if desried, but when both tstrb and tkeep are present, should monitoring be added for the invalid state tvalid & tstrb & !tkeep? If so, where?

@ollie-etl ollie-etl marked this pull request as ready for review March 31, 2023 16:58
if self.tstrb is not None:
self.tstrb = self.tstrb[:n] + [self.tstrb[-1]]*(n-len(self.tstrb))
else:
self.tstrb = self.tkeep
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is deliberate. If tstrb is not used, it should match tkeep. This implies 2 possible states:

  • keep byte + byte is data
  • may discard byte

It also means the invalid state of tkeep low + tstrb high is avoided.

@@ -95,6 +100,11 @@ def normalize(self):
else:
self.tkeep = [1]*n

if self.tstrb is not None:
self.tstrb = self.tstrb[:n] + [self.tstrb[-1]]*(n-len(self.tstrb))
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The open question is if tstrb should be checked here, to validate the validity of the tkeep, tstrb combination.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely should check for protocol violations when possible. The question is what to do: I'm thinking logging a warning or error would be appropriate, but an exception or assert I suppose could also be reasonable. Perhaps the best solution would be to have an option for enabling protocol assertions somewhere, which would generate exceptions instead of log messages.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But, I suppose what we could do is roll with the log messages for now and then think about some config options for this sort of thing separately.

@@ -306,6 +323,14 @@ def __init__(self, bus, clock, reset=None, reset_active_level=True,
self.byte_lanes = len(self.bus.tkeep)
if byte_size is not None or byte_lanes is not None:
raise ValueError("Cannot specify byte_size or byte_lanes if tkeep is connected")
if hasattr(self.bus, "tstrb") and (len(self.bus.tstrb) != self.byte_lanes):
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If both tkeep and tstrb are provided, then they should be the same size.

if hasattr(self.bus, "tstrb") and (len(self.bus.tstrb) != self.byte_lanes):
raise ValueError("tstrb must be the same width as tkeep")

elif hasattr(self.bus, "tstrb"):
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tstrb only provided, we can use that to get byte_lanes. Also reflected in the docs

@@ -691,16 +724,18 @@ async def _run(self):
if tready_sample and tvalid_sample:
if not frame:
if self.byte_size == 8:
frame = AxiStreamFrame(bytearray(), [], [], [], [])
frame = AxiStreamFrame(bytearray(), [], [], [], [], [])
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These caught me out, and may catch out users. the API change may justify a major version uplift

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could mitigate this by adjusting the ordering of tstrb in the constructor arguments?

@ollie-etl
Copy link
Author

ollie-etl commented Apr 1, 2023

@alexforencich Your thoughts here would be appreciated, especially on the validity checking and API implications

@ollie-etl
Copy link
Author

@alexforencich?

@ollie-etl
Copy link
Author

@alexforencich I think this is ready to go

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.

2 participants