Skip to content
GitLab
Explore
Sign in
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
fd098dbf
Commit
fd098dbf
authored
9 years ago
by
Pepping
Browse files
Options
Downloads
Patches
Plain Diff
Addecomemnts
parent
e3ed3bf7
No related branches found
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
applications/apertif/designs/apertif_unb1_cor_mesh_ref/tb/vhdl/tb_apertif_unb1_cor_mesh_ref.vhd
+56
-4
56 additions, 4 deletions
...nb1_cor_mesh_ref/tb/vhdl/tb_apertif_unb1_cor_mesh_ref.vhd
with
56 additions
and
4 deletions
applications/apertif/designs/apertif_unb1_cor_mesh_ref/tb/vhdl/tb_apertif_unb1_cor_mesh_ref.vhd
+
56
−
4
View file @
fd098dbf
...
@@ -21,7 +21,59 @@
...
@@ -21,7 +21,59 @@
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-- Purpose: Verify that unb1_terminal_bg_mesh_db can simulate
-- Purpose: Verify that unb1_terminal_bg_mesh_db can simulate
-- Description:
-- Description:
--
-- Each node sends 8 streams of data via a block generator. Eacht stream
-- is targetting one of the 8 nodes. The data value in the real part of the
-- data stream represents the source node. The data value in the imag part
-- of the data represents the destination node. The following table shows the
-- data values of each stream per node:
--
-- BLOCKGENERATOR CONFIGURATION:
-- STREAMS --> S0 | S1 | S2 | S3 | S4 | S5 | S6 | S7
-- NODE RE IM | RE IM | RE IM | RE IM | RE IM | RE IM | RE IM | RE IM
-- 0 (FN0) 0 0 | 0 1 | 0 2 | 0 3 | 0 4 | 0 5 | 0 6 | 0 7
-- 1 (FN1) 1 0 | 1 1 | 1 2 | 1 3 | 1 4 | 1 5 | 1 6 | 1 7
-- 2 (FN2) 2 0 | 2 1 | 2 2 | 2 3 | 2 4 | 2 5 | 2 6 | 2 7
-- 3 (FN3) 3 0 | 3 1 | 3 2 | 3 3 | 3 4 | 3 5 | 3 6 | 3 7
-- 4 (BN0) 4 0 | 4 1 | 4 2 | 4 3 | 4 4 | 4 5 | 4 6 | 4 7
-- 5 (BN1) 5 0 | 5 1 | 5 2 | 5 3 | 5 4 | 5 5 | 5 6 | 5 7
-- 6 (BN2) 6 0 | 6 1 | 6 2 | 6 3 | 6 4 | 6 5 | 6 6 | 6 7
-- 7 (BN3) 7 0 | 7 1 | 7 2 | 7 3 | 7 4 | 7 5 | 7 6 | 7 7
--
-- Naturally the data received at each node should be the data that was targeted
-- for that specific node. The real parts marks the source node and the imag part
-- marks the destination node. Unfortunately the source and destination labeling
-- are not accordingly (FIXME?: that requires new settings for the reorder_rewire)
-- Here are the source and destination numbers linked to the nodes:
--
-- NODE Source | Destination
-- 0 (FN0) 0 | 0
-- 1 (FN1) 1 | 2
-- 2 (FN2) 2 | 4
-- 3 (FN3) 3 | 6
-- 4 (BN0) 4 | 1
-- 5 (BN1) 5 | 3
-- 6 (BN2) 6 | 5
-- 7 (BN3) 7 | 7
-- Therefor the data received at the databuffers at
-- each node should be according to the next table:
--
-- EXPECTED DATA DATABUFER:
-- STREAMS --> S0 | S1 | S2 | S3 | S4 | S5 | S6 | S7
-- NODE RE IM | RE IM | RE IM | RE IM | RE IM | RE IM | RE IM | RE IM
-- 0 (FN0) 0 0 | 1 0 | 2 0 | 3 0 | 4 0 | 5 0 | 6 0 | 7 0
-- 1 (FN1) 0 2 | 1 2 | 2 2 | 3 2 | 4 2 | 5 2 | 6 2 | 7 2
-- 2 (FN2) 0 4 | 1 4 | 2 4 | 3 4 | 4 4 | 5 4 | 6 4 | 7 4
-- 3 (FN3) 0 6 | 1 6 | 2 6 | 3 6 | 4 6 | 5 6 | 6 6 | 7 6
-- 4 (BN0) 0 1 | 1 1 | 2 1 | 3 1 | 4 1 | 5 1 | 6 1 | 7 1
-- 5 (BN1) 0 3 | 1 3 | 2 3 | 3 3 | 4 3 | 5 3 | 6 3 | 7 3
-- 6 (BN2) 0 5 | 1 5 | 2 5 | 3 5 | 4 5 | 5 5 | 6 5 | 7 5
-- 7 (BN3) 0 7 | 1 7 | 2 7 | 3 7 | 4 7 | 5 7 | 6 7 | 7 7
--
--
--
--
-- Usage:
-- Usage:
-- > as 8
-- > as 8
...
@@ -47,7 +99,7 @@ ARCHITECTURE tb OF tb_apertif_unb1_cor_mesh_ref IS
...
@@ -47,7 +99,7 @@ ARCHITECTURE tb OF tb_apertif_unb1_cor_mesh_ref IS
CONSTANT
c_nof_bn
:
NATURAL
:
=
4
;
CONSTANT
c_nof_bn
:
NATURAL
:
=
4
;
CONSTANT
c_nof_fn
:
NATURAL
:
=
4
;
CONSTANT
c_nof_fn
:
NATURAL
:
=
4
;
CONSTANT
c_nof_nodes
:
NATURAL
:
=
c_nof_bn
+
c_nof_fn
;
CONSTANT
c_nof_nodes
:
NATURAL
:
=
c_nof_bn
+
c_nof_fn
;
CONSTANT
c_ena_mesh_reorder
:
BOOLEAN
:
=
FALSE
;
--
TRUE;
CONSTANT
c_ena_mesh_reorder
:
BOOLEAN
:
=
TRUE
;
CONSTANT
c_sim_unb_nr
:
NATURAL
:
=
0
;
CONSTANT
c_sim_unb_nr
:
NATURAL
:
=
0
;
...
@@ -58,8 +110,8 @@ ARCHITECTURE tb OF tb_apertif_unb1_cor_mesh_ref IS
...
@@ -58,8 +110,8 @@ ARCHITECTURE tb OF tb_apertif_unb1_cor_mesh_ref IS
CONSTANT
c_tr_clk_period
:
TIME
:
=
6400
ps
;
-- 156.25 MHz XO on UniBoard
CONSTANT
c_tr_clk_period
:
TIME
:
=
6400
ps
;
-- 156.25 MHz XO on UniBoard
CONSTANT
c_pps_period
:
NATURAL
:
=
1000
;
CONSTANT
c_pps_period
:
NATURAL
:
=
1000
;
TYPE
t_mesh_arr
IS
ARRAY
(
c_nof_nodes
-1
DOWNTO
0
)
OF
STD_LOGIC_VECTOR
(
c_unb1_board_tr_mesh
.
bus_w
-1
DOWNTO
0
);
TYPE
t_mesh_arr
IS
ARRAY
(
0
TO
c_nof_nodes
-1
)
OF
STD_LOGIC_VECTOR
(
c_unb1_board_tr_mesh
.
bus_w
-1
DOWNTO
0
);
-- DUT
-- DUT
SIGNAL
WDI
:
STD_LOGIC
;
SIGNAL
WDI
:
STD_LOGIC
;
SIGNAL
ext_pps
:
STD_LOGIC
;
SIGNAL
ext_pps
:
STD_LOGIC
;
...
...
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