Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
W
White Rabbit core collection
Manage
Activity
Members
Labels
Plan
Issues
33
Issue boards
Milestones
Wiki
Code
Merge requests
5
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Deploy
Releases
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Projects
White Rabbit core collection
Wiki
WR Streamers Principle of Operation
WR Streamers Principle of Operation
· Changes
Page history
Update WR Streamers Principle of Operation
authored
4 years ago
by
Maciej Lipinski
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
WR-Streamers-Principle-of-Operation.md
+7
-1
7 additions, 1 deletion
WR-Streamers-Principle-of-Operation.md
with
7 additions
and
1 deletion
WR-Streamers-Principle-of-Operation.md
View page @
546ed59b
...
...
@@ -34,6 +34,12 @@
-
The user asserts
`tx_flush_i`
to explicitly request transmission
of the data that has been written to the buffer of the Tx
Streamer.
-
When
**fixed-latency**
mode is set on the receiver, the
**
Rx Streamer
*
module
does not provide the received data to the user as soon as its reception is completed. Instead,
the receiver compares the transmission timestamp (received with the data) with its local WR time
and calculates their difference. As soon as the calculated difference equals to the configured
fixed-latency. the data is provided to the user. In case the calculated difference is greater
that the configured fixed-latency, the data is provided to the user immediately.
A
[
simulation
](
/WR-Streamers-Simulation
)
of the Tx and Rx streamer can
be run in order to understand how some of these features work in
...
...
@@ -45,7 +51,7 @@ practice.
The number of
**data words**
grouped into
**blocks**
is specified by the
user who indicates the last
**data word**
. Inside the frame, each
*block** ends with a CRC and an *
escape code
*
(
`0xCAFE`
). If such
*
*block**
ends with a CRC and an
*escape code*
(
`0xCAFE`
). If such
*escape code*
happens to be in transmitted data, another
`0xCAFE`
is
inserted during transmission. Two consecutive
*escape codes*
indicate to
the receiver that the received data included
`0xCAFE`
.
...
...
This diff is collapsed.
Click to expand it.