Skip to content
Projects
Groups
Snippets
Help
Loading...
Sign in
Toggle navigation
M
MasterFIP - Testing
Project
Project
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
Wiki
Wiki
image/svg+xml
Discourse
Discourse
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Commits
Issue Boards
Open sidebar
Projects
MasterFIP - Testing
Commits
43ed4fc8
Commit
43ed4fc8
authored
May 24, 2017
by
Marek Gumiński
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Updated comments
parent
0671fff8
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
with
51 additions
and
165 deletions
+51
-165
spec_masterfip_pts.vhd
gateware/top/spec/spec_masterfip_pts.vhd
+46
-159
test02.py
python/test02.py
+5
-6
No files found.
gateware/top/spec/spec_masterfip_pts.vhd
View file @
43ed4fc8
...
...
@@ -12,118 +12,29 @@
---------------------------------------------------------------------------------------------------
-- File spec_masterfip_pts.vhd |
-- |
-- Description Top level of the masterFIP design with Mock Turtle on a SPEC carrier. |
-- Description Top level of the masterFIP PTS design with Mock Turtle on a SPEC carrier. |
--
-- This top module was strongly based on original masterFIP top module.
--
-- Modifications:
-- masterfip_pts added
-- overwrites external synchronisation line controls
-- controls used in fmc_masterFIP_core is insufficient to fully verify
-- external synchronisation lines
--
-- xwb_i2c_master added
-- i2c interface used to communicate with FMC EEPROM
--
-- carrier_csr added
-- status register, kept for backward compatibility with previous PTS version
-- | |
-- mock turtle configuration
-- removed second core from CPU since PTS doesn't use MT at all
-- core was removed to simplify synthesis
-- MT was not removed completely in order
-- to keep design as similar to original as possible |
-- |
-- Figure 1 shows the architecture and main components of the design. |
-- ______________________________________________________________________ |
-- | | |
-- | _________________________________________ | |
-- | | MOCK TURTLE | | |
-- _ | | _____ | | |
-- | | | | ___ | | | | |
-- |F| | . .| . . . . . . . . . . . >| | | | | | |
-- |I| | _____ . | | | | | | | |
-- |E| | | | . | . . . . . . . .>| | | | | | |
-- |L| <--| | | . | . HMQs | | | | | | |
-- |D| | | F | . | . | | | | | | |
-- |R| | | M | . | ______ | | | | | | |
-- |I| -->| | C | . | DP | | | | | | | | |
-- |V| | | | . .|. .>| CPU0 | _____ | X | | G | | | |
-- |E| | | M | ____ . | |______| | | | b | | N | | | <-PCIe->|
-- |_| | | A | | | . | | SH. | | a | | 4 | | | host |
-- | | S |....|Xbar|... | ______ | MEM | | r | | 1 | | | |
-- ext pulse --> | | T | |____| . | | | |_____| | | | 2 | | | |
-- | | E | . | DP | CPU1 | | | | 4 | | | |
-- | | R | . .|. .>|______| | | | | | | |
-- FMC 1wire <-->| | F | | . | | | | | | |
-- | | I | | . HMQs | | | | | | |
-- | | P | | . . . . . . . . >|___| | | | | |
-- FMC LEDs <--| | | | |_____| | | |
-- | |_____| | _^_ | | |
-- | | | | | | |
-- | | |VIC| | | |
-- | | |___| | | |
-- | |_________________________________________| | |
-- |______________________________________________________________________| |
-- Figure 1: spec_masterfip_pts architecture |
-- |
-- |
-- FMC MASTERFIP CORE: |
-- On one side the FMC MASTERFIP CORE is the interface to the FMC hardware (i.e. |
-- FielDrive chip, external pulse LEMO, 1-wire DS18B20 chip, LEDs) on the other side |
-- it provides a wbgen2 WISHBONE where a set of control and status registers have |
-- been defined to interface with the MOCK TURTLE. |
-- The core ignores the notion of the WorldFIP frame type (ID_DAT/RT_DAT/..etc), |
-- or the macrocycle sequence and macrocycle timing; the sw running on the Mock |
-- Turtle CPUs is responsible for managing these aspects and for providing to this |
-- core all the payload bytes (coming from the host) that have to be serializedand, |
-- together with a serialization startup trigger, or for enabling the deserializer |
-- and then providing to the host the deserialized bytes. |
-- Figure 2 shows the structure of a WorldFIP frame. The core is internally |
-- generating (in the case of serialization) or validating (in the case of |
-- deserialization) only the FSS, CRC and FES bytes; the rest of the bytes are |
-- retrieved from or provided to the MOCK TURTLE. The core also encodes/decodes all |
-- the bytes to/from the Manchester2 code (as specified by the WorldFIP protocol) and|
-- controls/monitors all the FielDrive signals. |
-- _____________________________________________________________________________ |
-- |_____FSS_____|__Ctrl__|_____________Payload_____________|_____CRC____|__FES__| |
-- |
-- Figure 2: WorldFIP frame structure |
-- |
-- MOCK TURTLE: |
-- Instead of having a big FSM in HDL that would be executing the WorldFIP |
-- macrocycle, we have software running on an embedded CPU, in order to add |
-- flexibility and ease the implementation of the design. Mock Turtle is the |
-- generic core that offers multi-CPU processing and all the infrastructure around. |
-- The interface between the CPUs and the PCIe host is though HostMessageQueues(HMQ).|
-- The interface between the CPUs with the FMC MASTERFIP CORE is a set of wbgen2- |
-- generated registers. |
-- In this design MT is configured with 2 CPUs: |
-- - CPU0 is the heart of the design; it is "playing" the WorldFIP macrocycle. |
-- For example,it initiates the delivery of a WorldFIP question frame, by providing|
-- the frame bytes to the FMC MASTERFIP CORE, and then awaits for the reception of |
-- the response frame.It retrieves these consumed data from the FMC MASTERFIP CORE,|
-- packs them in the corresponding HMQ (according to the frame type) and can notify|
-- the host through an IRQ. |
-- - CPU1 is mainly polling the host to retrieve new payload bytes for production. |
-- When new data is received from the host through a dedicated HMQ, CPU1 puts them |
-- into the Shared Memory for CPU0 to retrieve them and provide them to the |
-- FMC MASTERFIP CORE for serialization. |
-- CPU1 does not need access to the FMC MASTERFIP CORE; however access is possible |
-- for debugging purposes. |
-- |
-- XBAR: |
-- The crossbar between the FMC MASTERFIP CORE and MOCK TURTLE is used so that |
-- CPU0, CPU1 and to the PCIe host can access directly the wbgen2-defined regs |
-- in the FMC MASTERFIP CORE. |
-- Note that to give access to the FMC MASTERFIP CORE to both CPU0 and CPU1, we |
-- could have used the Shared Port of MT, instead of using the Dedicated Ports (DP) |
-- and this crossbar; this though would have also affected (potentially slowed down) |
-- the accesses to the MT Shared Memory. |
-- Note also that as mentioned above CPU1 is only accessing the FMC MASTERFIP CORE |
-- for debugging purposes; the same goes also for the PCIe host. |
-- |
-- CLK, RST: |
-- There is only one clock domain of 100 MHz, in the whole design. The clock is |
-- generated inside the MOCK TURTLE, from the 125 MHz SPEC PLL IC6 output clock |
-- (clk_125m_pllref_p_i,clk_125m_pllref_n_i) and it is used by both MOCK TURTLE CPUs,|
-- by the FMC MASTERFIP CORE and the XBAR. A PCIe reset signal, synchronous to |
-- the 100 MHz clock is also provided by MOCK TURTLE. |
-- |
-- MEMORY MAP AS SEEN FROM PCIe: |
-- 0x00000000 (size: 4 bytes) : SDB signature |
-- 0x00002000 (size: 64 bytes) : VIC |
-- 0x00010000 (size: 644 bytes) : Host access to the FMC MASTERFIP CORE |
-- 0x00020000 (size: 128 kB) : MOCK TURTLE |
-- |-- 0x00020000 : HMQ Global Control Registers |
-- |-- 0x00024000 : HMQ incoming slots (Host->CPUs) |
-- |-- 0x00028000 : HMQ outgoing slots (CPUs->Host) |
-- |-- 0x0002c000 : CPU Control/Status Registers |
-- |-- 0x00030000 : Shared Memory (64 KB) |
-- |
-- Authors Evangelia Gousiou (Evangelia.Gousiou@cern.ch) |
-- Eva Calvo Giraldo (Eva.Calvo.Giraldo@cern.ch) |
-- Tomasz Wlostowski (Tomasz.Wlostowski@cern.ch) |
-- Authors Marek Guminski (marek.guminski@creotech.pl) |
-- |
---------------------------------------------------------------------------------------------------
...
...
@@ -199,7 +110,8 @@ entity spec_masterfip_pts is
-- SPEC LEDs
led_green_o
:
out
std_logic
;
-- blinking with clk_100m_sys
led_red_o
:
out
std_logic
;
-- active during a PCIe rst, l_rst_n_i
-- PCB version
-- PCB version
pcb_ver_i
:
in
std_logic_vector
(
3
downto
0
);
-- FMC signals
...
...
@@ -207,7 +119,7 @@ entity spec_masterfip_pts is
-- FMC presence
fmc_prsnt_m2c_n_i
:
in
std_logic
;
-- FMC presence (used by MT)
-- fmc i2c interface
-- fmc i2c interface
fmc_scl_io
:
inout
std_logic
;
fmc_sda_io
:
inout
std_logic
;
...
...
@@ -264,30 +176,6 @@ architecture rtl of spec_masterfip_pts is
-- MOCK TURTLE CONSTANTS --
---------------------------------------------------------------------------------------------------
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- HMQ: It total 10 HMQs have been defined. Each HMQ has 4 entries of 128 x 32 bits, each.
-- 8 "out HMQs" from the MT -> towards the host
-- - 0: HMQ from CPU0 with the WorldFIP payloads from periodic consumed variables
-- - 1: HMQ from CPU0 with the WorldFIP payloads from aperiodic consumed variables
-- (only for the case of identif variable, scheduled as periodic variable, by radMon app)
-- - 2: HMQ from CPU0 with the WorldFIP payloads from aperiodic consumed messages
-- - 3: HMQ from CPU0 with the WorldFIP payloads from periodic consumed diagnostic variables
-- (only for the case of the FIPdiag variable 0x067F)
-- - 4: HMQ from CPU0 with the WorldFIP payloads from aperiodic consumed diagnostic variables
-- (aperiodic presence and identification)
-- - 5: HMQ for debugging data from CPU0 and CPU1 towards the host
-- - 6: HMQ for the responses of CPU0 to the commands of the host, see below "in HMQ0"
-- (e.g.: acknowledgement of the configuration???)
-- - 7: HMQ for the responses of CPU1 to the commands of the host, see below "in HMQ1",
-- (e.g.: content of the report variable)
-- 2 "in HMQs" from the host -> towards MT
-- - 0: HMQ towards CPU0 with commands for the bus config, used only at startup (e.g.: HW_RESET,
-- PROGRAM_BA, BA_START, BA_RUNNING)
-- - 1: HMQ towards CPU1 with the payloads for produced WorldFIP frames (variables and messages;
-- CPU1 then puts this data into the Shared Memory for CPU0 to access and put them in the bus)
-- as well as requests for report data, requests for the scheduling of aperiodic traffic
-- (presence/ identification) etc (CPU1 again passes these requests into the Shared Memory).
constant
C_HMQ_CONFIG
:
t_wrn_mqueue_config
:
=
(
out_slot_count
=>
8
,
-- MT -> towards the host
...
...
@@ -316,6 +204,10 @@ architecture rtl of spec_masterfip_pts is
in_slot_count
=>
0
,
in_slot_config
=>
(
others
=>
(
0
,
0
)));
-- !!!!!!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!
-- !!!!!!!!!!! Mock Turtle core removed!!!!!!!
-- !!!!!!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
constant
C_NODE_CONFIG
:
t_wr_node_config
:
=
(
app_id
=>
x"0f1dc03e"
,
...
...
@@ -392,8 +284,6 @@ begin
---------------------------------------------------------------------------------------------------
-- FIXED SIGNALS --
---------------------------------------------------------------------------------------------------
-- ext_sync_dir_o <= '0'; -- Direction fixed to: B -> A
-- ext_sync_oe_n_o <= '0'; -- Output fixed to: enabled
-- To be removed on hw V3
-- Note: For the hw v1 signals ext_sync_tst_n_o, adc_prim_conn_n_o and adc_sec_conn_n_o, in order
...
...
@@ -452,12 +342,10 @@ begin
-- FMC presence
fmc_prsnt_m2c_l_i
=>
fmc_prsnt_m2c_n_i
,
-- WISHBONE connection of the fmc_masterFIP_core to the MT CPUs
dp_master_o
(
0
)
=>
wbmain_masters_ms
(
0
),
-- access from MT CPU0 at base address 0x100000
-- dp_master_o(1) => wbmain_masters_ms(1),
dp_master_i
(
0
)
=>
wbmain_masters_sm
(
0
),
-- access from MT CPU1 at base address 0x100000
-- dp_master_i(1) => wbmain_masters_sm(1),
dp_master_o
(
0
)
=>
wbmain_masters_ms
(
0
),
dp_master_i
(
0
)
=>
wbmain_masters_sm
(
0
),
-- WISHBONE connection of the fmc_masterFIP_core to the host
fmc0_host_wb_o
=>
wbmain_masters_ms
(
1
),
-- access from PCIe host at base address 0x10000
fmc0_host_wb_o
=>
wbmain_masters_ms
(
1
),
fmc0_host_wb_i
=>
wbmain_masters_sm
(
1
),
fmc0_host_irq_i
=>
'0'
,
-- not used
...
...
@@ -469,12 +357,8 @@ begin
---------------------------------------------------------------------------------------------------
-- XBAR --
---------------------------------------------------------------------------------------------------
-- Crossbar to give access to the fmc_masterFIP_core to CPU0, CPU1 and directly to the PCIe host.
-- Note that to give access to the fmc_masterFIP_core to both CPU0 and CPU1, the SP of MT could
-- have been used instead of the DP and this crossbar; this though would have also affected
-- (potentially slowed down) the accesses to the MT Shared Memory.
-- Note that in the MT firmware the CPU1 is only accessing the masterfip_leds register for debugging
-- purposes. The PCIe host is accessing the core directly only for testing purposes.
-- two wishbone masters are localed in spec_node_template
-- components instantiated in this file are wishbone slaves
cmp_wb_crossbar
:
xwb_crossbar
generic
map
(
g_num_masters
=>
2
,
...
...
@@ -517,11 +401,12 @@ begin
fd_txck_o
=>
fd_txck_o
,
fd_txd_o
=>
fd_txd
,
fd_txena_o
=>
fd_txena_o
,
-- External Synch
-- External Synch lines are connected to masterfip_pts core
-- in PTS design
ext_sync_term_en_o
=>
open
,
ext_sync_a_i
=>
'0'
,
ext_sync_dir_o
=>
open
,
-- hard-wired to '0'
ext_sync_oe_n_o
=>
open
,
-- hard-wired to '0'
ext_sync_dir_o
=>
open
,
ext_sync_oe_n_o
=>
open
,
-- LEDs
leds_o
=>
leds
,
-- WISHBONE interface with MT CPU0 and CPU1
...
...
@@ -550,8 +435,10 @@ begin
led_sync_err_n_o
<=
leds
(
5
);
-- probe on R6
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -
-- fd_txd_o <= fd_txd;
fd_txd_o
<=
fd_txd
when
fd_txd_corrupt
=
'0'
else
'0'
;
-- fielddrive serial output corruption
-- driver is controlled as usual, but data is constant 0
-- this causes tx error to occur
fd_txd_o
<=
fd_txd
when
fd_txd_corrupt
=
'0'
else
'0'
;
tp1_o
<=
fd_rxd_i
;
tp2_o
<=
fd_txd
;
tp3_o
<=
leds
(
8
);
...
...
@@ -560,10 +447,8 @@ begin
------------------------------------------------------------------------------
-- Carrier CSR
-- Carrier type and PCB version
-- Bitstream (firmware) type and date
-- Release tag
-- VCXO DAC control (CLR_N)
-- Added in order to keep compatibility with previous PTS version
-- Would be good to actually connect PLL status pins (but can't do it without modifying spec_node_template)
------------------------------------------------------------------------------
cmp_carrier_csr
:
entity
work
.
carrier_csr
port
map
(
...
...
@@ -636,6 +521,8 @@ begin
---- Module containing PTS cores
---------------------------------------------------------
-- controls for external synchronisation line
-- fd status line monitoring is more precise then in masterfip core
pts_core_inst
:
entity
work
.
masterfip_pts
port
map
(
-- Clock and reset
...
...
python/test02.py
View file @
43ed4fc8
...
...
@@ -387,9 +387,9 @@ def main (card=None, default_directory='.',suite=None,serial=""):
############################### test ##########################################
# transmit
long fram
e
#
pool CSR looking for TXERR during normal operation
#
and with disconnected WorldFIP cable (should give error)
# transmit
normal frame - make sure that tx error is inactiv
e
#
transmit corrupted frame - make sure that tx error is active
#
frame is corrupted by forcing serial data output to constant 0 in gateware
util
.
section_msg
(
"Testing FD TX_ERR line"
)
dut
.
rst_core
()
wait_transmission_termination
(
dut
)
...
...
@@ -400,9 +400,8 @@ def main (card=None, default_directory='.',suite=None,serial=""):
##############################################################################
############################### test ##########################################
# transmit long frame
# pool CSR looking for TXERR during normal operation
# and with disconnected WorldFIP cable (should give error)
# transmit regular frame and make sure that FD WDG line is inactive
# transmit frame long enough to activate watchdog
util
.
section_msg
(
"Testing FD WDG_N line"
)
dut
.
rst_core
()
wait_transmission_termination
(
dut
)
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment