-
Notifications
You must be signed in to change notification settings - Fork 2
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
FC Data corrupt? #47
Comments
|
#28 is likely related to this as well. |
Should probably add a Avalon-ST Delay core from the output of the framers. That way the framers can use the error signal to drop packets that are being prepared (e.g. too large, bad SOF/EOF etc) EDIT: The IP core seems to be for some other version or environment than the one we are using. Instead, making this by ourselves shouldn't be too hard - just add a FIFO before the output stream and tie an _error line to the synchronous clear. |
The output of the framer looks pretty good actually. Correct first 4 bytes seems to be EDIT: Some more traces: https://gist.github.com/bluecmd/73ff52dae88e1ea6f828cbbb2be6c50b |
Testing with only fc_xcvr and 2x fifo seems to be a problem as well.
In this mode fejkon is basically just a media converter so this should really work. |
It seems that when the In order to solve #28 as well, it might be a good idea to reset the synchronization until it has aligned using a supported alignment. Down side of this is of course I do not know how much this will affect link up, but I bet it will work fine as long as restarting the pattern detection is not prone to sticking to whatever alignment it has now. In the testbench all xcvr's sync to alignment 4 as well. The branch fc_xcvr_tb, possibly commit a1403f3 should have things needed to get a testbench syncing with other pattern alignment. |
The length is good, the data is because we have no framer unscrambling yet. Closing this in favor of #56 |
There seems to be some odd things going on with the FC data.
This is one of the frames from the C2H DMA:
The SOF marker is clearly present, and it is in the correct place - so I wonder what the other data is.
This could be something special that SOFf frames do as well that I need to read up on.
The frames are really huge as well, increasing by 404 bytes every time.
The first packet that is sent to the C2H is:
Followed by:
The text was updated successfully, but these errors were encountered: