Skip to content

M
MasterFIP - Testing
Commit 43ed4fc8 authored by Marek Gumiński's avatar Marek Gumiński
Browse files
Options

Updated comments

parent 0671fff8
Hide whitespace changes
Inline Side-by-side
Showing with 51 additions and 165 deletions
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 frame
# 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 inactive
# 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 )
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment