Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
H
HDL
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Iterations
Wiki
Requirements
Jira
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Locked files
Build
Pipelines
Jobs
Pipeline schedules
Test cases
Artifacts
Deploy
Releases
Container Registry
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Code review analytics
Issue analytics
Insights
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
RTSD
HDL
Commits
6ec7950c
Commit
6ec7950c
authored
1 year ago
by
Eric Kooistra
Browse files
Options
Downloads
Patches
Plain Diff
Comment updates.
parent
58cb44c2
No related branches found
No related tags found
1 merge request
!353
Resolve L2SDP-962
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
libraries/base/dp/src/vhdl/dp_packet_merge.vhd
+5
-5
5 additions, 5 deletions
libraries/base/dp/src/vhdl/dp_packet_merge.vhd
with
5 additions
and
5 deletions
libraries/base/dp/src/vhdl/dp_packet_merge.vhd
+
5
−
5
View file @
6ec7950c
...
...
@@ -67,18 +67,18 @@
-- input and output for merging e.g. 3 packets. Draw the sop and eop and also draw the case that
-- there is a data invalid gap between packets. There needs to be a packet counter so, also
-- draw this signal.
-- . Using the timing diagram now assi
n
g each of the v fields. Try to keep the implementation
-- . Using the timing diagram
,
now assig
n
each of the v fields. Try to keep the implementation
-- for each field seperate, i.e. do not combine multiple fields into one if then else statement.
-- The reason is that keeping each field implementation seperate makes the code more clear and
-- The reason is that keeping each field implementation seperate
,
makes the code more clear and
-- also eases making modifications later on. Mark the implementation section by a comment line.
-- . Typically use r in the if condition and at the right of the := assignment. Depending only
-- on r for implementing v has the advantage that the order of the code section is not important,
-- i.e. similar as with seperate combinatorial processes. However for some cases it can be
-- beneficial to use v in the condition or in the assignment, e.g. as with v
_
busy.
-- beneficial to use v in the condition or in the assignment, e.g. as with v
.
busy.
-- . If the component will not support flow control, then the snk - src latency may be made
-- > 1. However to prepare for adding flow control later on it is prefered to keep the input -
-- output latency at 1. Keeping the snk - src latency at 1 typically also makes the
-- implementation more clear, because if more latency is needed then it may be better to
-- implementation more clear, because if more latency is needed
,
then it may be better to
-- partition the function over two or more components. The snk - src latency of 1 is not
-- functional, because the nxt_r with latency 0 also could be used as output. However the
-- registering of outputs can be functional. From digital implementation point of view it is
...
...
@@ -355,7 +355,7 @@ begin
if
snk_in
.
eop
=
'1'
then
if
r
.
pkt_cnt
=
0
then
v
.
src_out
.
err
:
=
snk_in
.
err
;
v
.
src_out
.
err
:
=
snk_in
.
err
;
-- take err field of first packet
else
v
.
src_out
.
err
:
=
r
.
src_out
.
err
or
snk_in
.
err
;
-- OR the err fields of the packets to reflect combined error status.
end
if
;
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment