Skip to content

M
MasterFIP - Gateware
Commit cf087b1f authored by Evangelia Gousiou's avatar Evangelia Gousiou
Browse files
Options

corrected fd_rstn_o that was treated as active high

parent 0cea86ef
Hide whitespace changes
Inline Side-by-side
Showing with 234 additions and 171 deletions
rtl/fmc_masterFIP_core.vhd
View file @ cf087b1f
......@@ -47,19 +47,19 @@
-- and RX. Regarding the PAYLOAD data, it was decided not to use a FIFO for passing |
-- the WorldFIP PAYLOAD data from the processor to this core for serialization or for|
-- passing the WorldFIP PAYLOAD data that have been deserialized from this core to |
-- the processor. Instead a set of 67 registers (= 268 bytes, which is the max |
-- WorldFIP frame size) is used is used for each of the TX and RX; like this the |
-- time for which the data need to remain static to be read is minimized, leading to |
-- a simpler design. |
-- the processor. Instead a set of 67 32-bit-registers (= 268 bytes, which is the max|
-- WorldFIP frame size) is used for each of the TX and RX; like this the time for |
-- which the data need to remain static to be read is minimized, leading to a simpler|
-- design. |
-- |
-- MASTERFIP TX: |
-- The masterfip_tx is placing a complete WorldFIP frame on the bus. |
-- The masterfip_tx is ignorant of the frame type (ID_DAT/RT_DAT/RP_MSG etc..), |
-- of the macrocycle sequence and macrocycle timing; the processor (Mock Turtle for |
-- example) is responsible for managing all these issues and for providing to the |
-- masterfip_tx the bytes to serialise along with a start pulse. |
-- The communication between the processor (MT) and the masterfip_tx is through a set|
-- of control (from the MT) and status (from the masterfip_tx) signals/registers |
-- The masterfip_tx places a complete WorldFIP frame on the WorldFIP bus. |
-- The masterfip_tx ignores the frame type (ID_DAT/RT_DAT/RP_MSG etc..), or the |
-- macrocycle sequence and macrocycle timing; the processor (MT) is responsible for |
-- managing all these issues and for providing to the masterfip_tx the bytes to |
-- serialise, along with a start pulse. |
-- The communication between the processor and the masterfip_tx is handled through a |
-- set of control (from the MT) and status (from the masterfip_tx) signals/registers |
-- defined in the masterfip_wbgen2_csr module. |
-- Upon a rising edge on the tx_ctrl_start pulse, the masterfip_tx: |
-- - copies all the payload registers (tx_payld_ctrl, tx_payld_reg1..tx_payld_reg67)|
......@@ -67,7 +67,7 @@
-- serialize (tx_ctrl_bytes_num) |
-- - starts serializing a WorldFIP frame (see following Figure). Note that the FSS, |
-- CRC and FES fields are generated internally in the masterfip_tx unit. |
-- - after the FES, rises the tx_stat_stop status bit to signal the MT for the end |
-- - after the FES, rises the tx_stat_stop status bit to signal to the MT the end |
-- of a successful frame transmission. |
-- ______________________________________________________________________________ |
-- |_____FSS_____|__Ctrl__|_____________tx_payld_____________|_____CRC____|__FES__| |
......@@ -77,14 +77,14 @@
-- Figure 2: WorldFIP tx frame structure |
-- |
-- MASTERFIP RX: |
-- The masterfip_rx is retrieving a WorldFIP frame from the bus. |
-- Similar to the masterfip_tx, the masterfip_rx has no intelligence regarding the |
-- The masterfip_rx retrieves a WorldFIP frame from the WorldFIP bus. |
-- Similarly to the masterfip_tx, the masterfip_rx has no intelligence regarding the |
-- macrocycle sequence; it is controlled and monitored by the processor (MT) through |
-- the masterfip_wbgen2_csr, where a set of control and status registers are defined.|
-- As long as it is not under reset, the masterfip_rx is probing the WorldFIP bus |
-- trying to identify the FSS sequence of a WorldFIP frame. Upon the FSS detection |
-- it signals the processor through the status bit rx_stat_pream_ok and continues |
-- following the rest of the frame. It stores the first byte after the FSS to the |
-- trying to identify the FSS sequence of a WorldFIP frame. It signals the FSS |
-- detection to the processor through the status bit rx_stat_pream_ok and continues |
-- deserializing the rest of the frame. It stores the first byte after the FSS to the|
-- rx_payld_ctrl register and the rest of the bytes to the registers |
-- rx_payld_reg1..rx_payld_reg67. Upon the detection of a FES the masterfip_rx |
-- checks the CRC of the frame and enables the status bit rx_stat_frame_ok or |
......@@ -93,9 +93,8 @@
-- the number of rx_payld_regs and the number of bytes inside the last rx_payld_reg |
-- to be retrieved by the processor). |
-- The processor should copy the rx_payld_regs upon a rx_stat_frame_ok; the regs |
-- keep their values until an rx_rst or until the detection of a new rx_stat_frame_ok|
-- this in the worst case of the fastest bit rate 2.5 Mbps with a received frame |
-- being followed by the shortest RP_FIN is: |
-- keep their values until a rx_rst or until the detection of a new rx_stat_frame_ok.|
-- This time, in the worst case (bit rate 2.5 Mbps) can be calculated as: |
-- (Min Turnaround time of a node = 4 us) + (RP_FIN duration = 19.2 us) = 23.2 us |
-- ______________________________________________________________________________ |
-- |_____FSS_____|__Ctrl__|_____________rx_payld_____________|_____CRC____|__FES__| |
......@@ -105,28 +104,28 @@
-- Figure 3: WorldFIP rx frame structure |
-- |
-- EXT SYNC PULSE: |
-- The modules regarding the ext_sync_pulse are synchronising, deglitching and |
-- counting the number of rising-edge pulses that are arriving to the ext_sync input |
-- of the board and provide the result to a dedicated masterfip_wbgen2_csr register. |
-- The modules related to the ext_sync_pulse, synchronise, deglitch and count the |
-- number of rising-edge pulses that arrive to the ext_sync input of the board; |
-- they provide the result to a dedicated masterfip_wbgen2_csr register. |
-- |
-- MACROCYCLE: |
-- The modules regarding the macrocycle are counting the time of a macrocycle using |
-- the 10 ns input clock as well as the number of macrocycles since startup/a reset. |
-- The modules related to the macrocycle, count the time of a macrocycle using the |
-- 10 ns input clock as well as the number of macrocycles since startup/a reset. |
-- Dedicated registers in the masterfip_wbgen2_csr provide the counters values |
-- to the processor (MT). Note that the macrocycle length comes from the processor |
-- through another dedicated register in the masterfip_wbgen2_csr and should be set |
-- once in the application startup. |
-- to the processor (MT). Note that the duration/length of the macrocycle comes |
-- from the processor through another dedicated register in the masterfip_wbgen2_csr |
-- that should be set once in the application startup. |
-- |
-- TURNAROUND, SILENCE TIMES: |
-- The modules regarding the turnaround and silence time are counting the respective |
-- time using the 10 ns clock. Dedicated regs in the masterfip_wbgen2_csr provide |
-- the counters values to the processor (MT). As in the case of the macrocycle length|
-- The modules related to the turnaround and silence time, count the respective time |
-- using the 10 ns clock. Dedicated regs in the masterfip_wbgen2_csr provide the |
-- counters values to the processor (MT). As in the case of the macrocycle length, |
-- the turnaround and silence time length is provided through other dedicated regs in|
-- the masterfip_wbgen2_csr that should be set once in the application startup. |
-- |
-- ONEWIRE: |
-- The DS18B20 module is for the 1-wire reading of the unique ID and temperature on |
-- the mezzanine. Different than in other designs that implement sw-bit-banging, |
-- the mezzanine. Differently than in other designs that implement sw-bit-banging, |
-- here the communication is hard-coded in vhdl, so as to simplify the drivers. |
-- |
-- Authors Evangelia Gousiou (Evangelia.Gousiou@cern.ch) |
......@@ -316,7 +315,7 @@ begin
extended_o => fd_host_rst);
extend <= std_logic_vector(c_BIT_RATE_UCLK_TICKS(to_integer(unsigned(speed))));
fd_rstn_o <= fd_host_rst;
fd_rstn_o <= not fd_host_rst;
---------------------------------------------------------------------------------------------------
......@@ -377,7 +376,8 @@ begin
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -
-- counter of the number of rising edges
cmp_ext_sync_p_cnt:incr_counter
generic map(g_counter_lgth => 32)
generic map(g_counter_lgth => 32) -- for the fastest macrocycle of 20ms, the counter
-- can keep counting for > 2.5 years
port map
(clk_i => clk_i,
counter_incr_i => ext_sync_p,
......@@ -849,9 +849,9 @@ begin
-- payload bytes are stored in registers, not in FIFO.
-- The fmc_masterfip_core is copying locally the tx registers upon a tx_stat_start.
-- The processor should copy all the rx data upon a rx_stat_frame_ok; the data stays stable in the
-- rx_frame regs until a rx_rst or until the detection of another rx_stat_frame_ok; this in the
-- worst case of the fastest bit rate 2.5 Mbps with a received frame being followed by the shortest
-- RP_FIN is: (Min Turnaround time of a node = 4 us) + (RP_FIN duration = 19.2 us) = 23.2 us.
-- rx_frame regs until a rx_rst or until the detection of another rx_stat_frame_ok.
-- This time, in the worst case (bit rate 2.5 Mbps) can be calculated as:
-- (Min Turnaround time of a node = 4 us) + (RP_FIN duration = 19.2 us) = 23.2 us
-- tx regs
tx_frame(0) <= reg_from_mt.tx_payld_reg1_o;
......@@ -991,6 +991,7 @@ begin
reg_to_mt.rx_payld_reg66_i <= rx_frame(65);
reg_to_mt.rx_payld_reg67_i <= rx_frame(66);
---------------------------------------------------------------------------------------------------
-- CHIPSCOPE --
---------------------------------------------------------------------------------------------------
......@@ -1025,6 +1026,7 @@ begin
-- TRIG2(29) <= core_rst;
-- TRIG2(31 downto 30) <= speed_b1_i & speed_b0_i;
end rtl;
----------------------------------------------------------------------------------------------------
-- architecture ends
......
rtl/masterfip_rx.vhd
View file @ cf087b1f
......@@ -16,12 +16,12 @@
-- Figure 1 shows the main units/processes; the units RX DESERIALIZER, RX OSC and |
-- RX DEGLITCHER come unmodified from the nanoFIP project. |
-- Figure 2 shows the WorldFIP frame structure; note that the fmc_masterfip_core |
-- is completely ignorant of the notion of PDU_TYPE, LGTH, MPS, etc fields inside |
-- the PAYLOAD part of the frame and is not checking them during reception. |
-- ignores completely the notion of PDU_TYPE, LGTH, MPS, etc fields inside the |
-- PAYLOAD part of the frame and is not checking them at reception. |
-- It is the processor (MT) that is handling individually the bytes inside the |
-- PAYLOAD frame field. On the other hand the FSS, CRC and FES fields are |
-- checked by the masterfip_rx. |
-- As long as the rx_rst_i is not activated the deserializer is probing the bus |
-- PAYLOAD frame field. On the other hand the FSS, CRC and FES fields are checked |
-- and validated by the masterfip_rx. |
-- As long as the rx_rst_i is not activated the deserializer probes the bus |
-- looking for a FSS; upon the detection of a FES it activates the rx_crc_wrong_p_o |
-- or rx_fss_crc_fes_ok_p_o accordingly. |
-- |
......@@ -348,8 +348,8 @@ begin
rx_word_index_o <= std_logic_vector(to_unsigned(word32_num,7));
end architecture struc;
end architecture struc;
--=================================================================================================
-- architecture end
--=================================================================================================
......
rtl/masterfip_tx.vhd
View file @ cf087b1f
......@@ -15,28 +15,28 @@
-- Description The unit groups the main actions that regard FIELDRIVE data transmission. |
-- Figure 1 shows the main units/processes; the units TX SERIALIZER and TX OSC come |
-- unmodified from the nanoFIP project. |
-- Figure 2 shows the frame structure; note that the fmc_masterfip_core is completely|
-- ignorant of the notion of PDU_TYPE, LGTH, MPS, etc fields inside the PAYLOAD |
-- Figure 2 shows the frame structure; note that the fmc_masterfip_core ignores |
-- completely the notion of PDU_TYPE, LGTH, MPS, etc fields inside the PAYLOAD |
-- part of the frame. It is the processor (MT) that is providing all the bytes inside|
-- the PAYLOAD frame field. On the other hand the FSS, CRC and FES fields are |
-- generated by the masterfip_tx. |
-- The serialization starts upon a rising edge on the tx_start_p_i and upon the end |
-- of the FES transmission the masterfip_tx is activating the tx_end_p_o signal. |
-- of the FES transmission the masterfip_tx activates the tx_end_p_o signal. |
-- |
-- o TX SERIALIZER this unit comes unmodified from the nanoFIP project. |
-- It receives bytes from the processor (Mock Turtle for example) |
-- trough the tx_frame structure, encodes them in Manchester 2, |
-- adds the FSS, CRC, FES fields and puts one by one bits to the |
-- FIELDRIVE output FD_TXD following the synchronization signals |
-- from the wf_tx_osc unit. It also generates the output FD_TXENA. |
-- It receives bytes from the processor trough the |
-- tx_frame structure, encodes them in Manchester 2, adds the FSS, |
-- CRC, FES fields and puts one by one bits to the FIELDRIVE |
-- output FD_TXD following the synchronization signals from the |
-- wf_tx_osc unit. It also generates the output FD_TXENA. |
-- |
-- o TX OSC this unit comes unmodified from the nanoFIP project. |
-- It generates the output FD_TXCK as well as an array of pulses, |
-- tx_sched_p_buff, used for the synchronization of the |
-- TX SERIALIZER's actions. |
-- |
-- o DATA RETRIEVAL this unit copies the bytes provided by the processor (MT) |
-- upon the activation of the signal tx_start. |
-- o DATA RETRIEVAL this unit copies the bytes provided by the processor upon |
-- the activation of the signal tx_start. |
-- |
-- Mock Turtle |
-- ___________________________________________________________ |
......@@ -314,7 +314,6 @@ begin
byte_request_accept_p <= byte_request_accept_p_d2; -- response to wf_tx_serializer's request
-- for a byte
end architecture struc;
--=================================================================================================
-- architecture end
......
rtl/wf_package.vhd
View file @ cf087b1f
......@@ -16,8 +16,8 @@
-- serialization and deserialization; the package is essential for all the modules |
-- coming from the nanoFIP design. |
-- As in the masterFIP design the clk is 100 MHz and in the nanoFIP 40 MHz it was |
-- needed to have a new wf_package. In principle the nanoFIP design could have been |
-- modified to accept generics rather than constants, however as it is a stable |
-- necessary to have a new wf_package. In principle the nanoFIP design could have |
-- been modified to accept generics rather than constants, however as it is a stable |
-- design it was decided to keep it as it is and use for synthesis this package |
-- rather than the one coming with the nanoFIP submodule. |
-- A different package, the masterfip_pkg is used in the masterfip design for all |
......
sim/spec/testbench/tb_masterFIP.vhd
View file @ cf087b1f
----------------------------------------------------------------------------------------------------
-- CERN-BE-CO-HT
----------------------------------------------------------------------------------------------------
--
-- unit name : TDC test-bench (tb_masterFIP)
-- author : G. Penacoba
-- date : May 2011
-- version : Revision 1
-- description : top module for test-bench
-- dependencies:
-- references :
-- modified by :
--
----------------------------------------------------------------------------------------------------
-- last changes:
----------------------------------------------------------------------------------------------------
-- to do:
----------------------------------------------------------------------------------------------------
--_________________________________________________________________________________________________
-- |
-- |SPEC masterFIP| |
-- |
-- CERN, BE/CO-HT |
--________________________________________________________________________________________________|
---------------------------------------------------------------------------------------------------
-- |
-- tb_masterFIP |
-- |
---------------------------------------------------------------------------------------------------
-- File tb_masterFIP.vhd |
-- |
-- Description Simple test bench of the masterFIP design. The test bench is triggering the |
-- fmc_masterfip_core through the PCIe host interface, that is not passing through |
-- Mock Turtle. The WorldFIP exchange, as specified in the masterFIP_test.vec |
-- consists of: |
-- fmc_masterfip_core: sends ID_DAT |
-- fmc_masterfip_core: sends RD_DAT |
-- fmc_masterfip_core: sends ID_DAT |
-- fmc_masterfip_core: expects RD_DAT from the nanoFIP node |
-- etc.. |
-- |
-- Platform FPGA-generic |
-- |
---------------------------------------------------------------------------------------------------
-- GNU LESSER GENERAL PUBLIC LICENSE |
-- ------------------------------------ |
-- This source file is free software; you can redistribute it and/or modify it under the terms of |
-- the GNU Lesser General Public License as published by the Free Software Foundation; either |
-- version 2.1 of the License, or (at your option) any later version. |
-- This source is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; |
-- without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. |
-- See the GNU Lesser General Public License for more details. |
-- You should have received a copy of the GNU Lesser General Public License along with this |
-- source; if not, please download it from http://www.gnu.org/licenses/lgpl-2.1.html |
---------------------------------------------------------------------------------------------------
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
library nanoFIP_lib;
use nanoFIP_lib.all;
library nanofip_lib;
use nanofip_lib.all;
library work;
use work.wishbone_pkg.all;
......
top/spec/spec_masterfip_mt.vhd
View file @ cf087b1f
......@@ -7,61 +7,57 @@
---------------------------------------------------------------------------------------------------
-- |
-- spec_masterfip |
-- spec_masterfip_mt |
-- |
---------------------------------------------------------------------------------------------------
-- File spec_masterfip.vhd |
-- File spec_masterfip_mt.vhd |
-- |
-- Description Top level of the masterFIP design on a SPEC carrier. |
-- There is only one clock domain in the whole design. It is the 100 MHz clock
-- generated within the spec_node_template from the 125 MHz SPEC PLL clk_125m_pllref.
-- Both MT CPUs as well as the fmc_masterfip are running with this clock.
--
-- Figure 1 shows the architecture of the unit; the main units are:
-- Description Top level of the masterFIP design with Mock Turtle on a SPEC carrier. |
-- |
-- Figure 1 shows the architecture and main components of the design. |
-- ______________________________________________________________________ |
-- | | |
-- | _______________________________________ | |
-- | | SPEC NODE TEMPLATE | | |
-- _ | | _____ | | |
-- | | | | ___ | | | | |
-- |F| | |--- |----------------------| | | | | | |
-- |I| | _____ | | | | | | | | |
-- |E| | | | | | |---------------| | | | | | |
-- |L| <--| | | | | | HMQs | | | | | | |
-- |D| | | F | | | | | | | | | | |
-- |R| | | M | | | __ |__ | | | | | | |
-- |I| -->| | C | | | | | | | | | | | |
-- |V| | | | |----|--| CPU0 | _____ | X | | G | | | |
-- |E| | | M | ____ | | |______| | | | b | | N | | | <-PCIe->|
-- |_| | | A | | | | | | SH. | | a | | 4 | | | host |
-- | | S |----|Xbar|--| | ______ | MEM | | r | | 1 | | | |
-- ext plse --> | | T | |____| | | | | |_____| | | | 2 | | | |
-- | | E | | | | CPU1 | | | | 4 | | | |
-- | | R | |----|--|______| | | | | | | |
-- FMC 1wire <-->| | F | | | | | | | | | |
-- | | I | | | HMQs | | | | | | |
-- | | P | | |----------------|___| | | | | |
-- FMC LEDs <--| | | | |_____| | | |
-- | |_____| | _^_ | | |
-- | | | | | | |
-- | | |VIC| | | |
-- | | |___| | | |
-- | |_______________________________________| | |
-- | _________________________________________ | |
-- | | 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 plse --> | | T | |____| . | | | |_____| | | | 2 | | | |
-- | | E | . | DP | CPU1 | | | | 4 | | | |
-- | | R | . .|. .>|______| | | | | | | |
-- FMC 1wire <-->| | F | | . | | | | | | |
-- | | I | | . HMQs | | | | | | |
-- | | P | | . . . . . . . . >|___| | | | | |
-- FMC LEDs <--| | | | |_____| | | |
-- | |_____| | _^_ | | |
-- | | | | | | |
-- | | |VIC| | | |
-- | | |___| | | |
-- | |_________________________________________| | |
-- |______________________________________________________________________| |
-- Figure 1: spec_masterfip_mt architecture |
-- |
-- |
-- FMC MASTERFIP CORE: |
-- On one side it is the interface to the FMC hardware: FielDrive chip, external |
-- pulse LEMO, 1-wire DS18B20 chip, LEDs; on the other side is has a wbgen2 WISHBONE |
-- where a set of control and status registers have been defined to interface with |
-- where a set of control and status registers have been defined to interface with |
-- the spec_node_template. |
-- The core is ignorant of the notion of the WorldFIP frame type (ID_DAT/RT_DAT/etc),|
-- of the macrocycle sequence or macrocycle timing; the sw running on the CPUs in |
-- the spec_node_template is responsible for managing these issues and for providing |
-- to this core all the payload bytes (that have been retrieved from the host) that |
-- need to be serializedand and a serialization startup trigger, or for enabling the |
-- pulse LEMO, 1-wire DS18B20 chip, LEDs; on the other side is provides a wbgen2 |
-- WISHBONE where a set of control and status registers have been defined to |
-- interface with the spec_node_template. |
-- 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 issues and for providing to this |
-- core all the payload bytes (that have been retrieved from the host) that have |
-- to be serializedand, and 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 |
......@@ -75,12 +71,61 @@
-- |
-- Figure 2: WorldFIP frame structure |
-- |
-- SPEC NODE TEMPLATE: |
-- Instead of implementing a big FSM in HDL that would have been executing the |
-- WorldFIP macrocycle, it was easier to put this complexity into software running in|
-- an embedded CPU. The spec_node_template is a generic core that offers multi-CPU
-- processing and all the infrastructure around.
-- MOCK TURTLE: |
-- In the spec_masterfip_mt design, to add flexibility and ease the implementation, |
-- instead of having a big FSM in HDL that would be executing the WorldFIP |
-- macrocycle, we have software running on an embedded CPU. Mock Turtle is the |
-- generic core that offers multi-CPU processing and all the infrastructure around. |
-- The interface of the CPUs with the PCIe host is though Host Message Queues. |
-- The interface of the CPUs with the FMC MASTERFIP CORE is though a set of wbgen2- |
-- generated registers. |
-- In this design the configuration of MT is 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; it can access the core |
-- though for debugging purposes. |
-- |
-- XBAR: |
-- The crossbar between the FMC MASTERFIP CORE and MOCK TURTLE is used so that |
-- CPU0, CPU1 and also directly to the PCIe host can access 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, 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) |
-- |
---------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------
......@@ -155,6 +200,7 @@ entity spec_masterfip_mt 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
-- FMC signals
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- FMC presence
......@@ -198,7 +244,7 @@ entity spec_masterfip_mt is
tp4_o : out std_logic; -- connected to MT led&dbg reg bit 9
-- To be removed on hw V3
ext_sync_tst_n_o : out std_logic;
ext_sync_tst_n_o : out std_logic := 'Z';
adc_1v8_shdn_n_o : out std_logic;
adc_m5v_shdn_n_o : out std_logic;
adc_5v_en_n_o : out std_logic;
......@@ -213,7 +259,7 @@ end spec_masterfip_mt;
architecture rtl of spec_masterfip_mt is
---------------------------------------------------------------------------------------------------
-- Mock Turtle CONSTANTS --
-- MOCK TURTLE CONSTANTS --
---------------------------------------------------------------------------------------------------
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- HMQ: It total 10 HMQs have been defined. Each HMQ has 4 entries of 128 x 32 bits, each.
......@@ -284,6 +330,7 @@ architecture rtl of spec_masterfip_mt is
constant C_SLAVE_ADDR : t_wishbone_address_array(0 downto 0):= (0 => x"00000000");
constant C_SLAVE_MASK : t_wishbone_address_array(0 downto 0):= (0 => x"00000000");
---------------------------------------------------------------------------------------------------
-- Signals --
---------------------------------------------------------------------------------------------------
......@@ -301,13 +348,14 @@ architecture rtl of spec_masterfip_mt is
signal spec_led : std_logic_vector(7 downto 0);
signal fd_txd : std_logic;
--=================================================================================================
-- architecture begin
--=================================================================================================
begin
---------------------------------------------------------------------------------------------------
-- Fixed signals --
-- FIXED SIGNALS --
---------------------------------------------------------------------------------------------------
ext_sync_dir_o <= '0'; -- Direction fixed to: B -> A
ext_sync_oe_n_o <= '0'; -- Output fixed to: enabled
......@@ -322,7 +370,7 @@ begin
---------------------------------------------------------------------------------------------------
-- Mock Turtle core --
-- MOCK TURTLE CORE --
---------------------------------------------------------------------------------------------------
cmp_mock_turtle : spec_node_template
generic map
......@@ -383,7 +431,7 @@ begin
---------------------------------------------------------------------------------------------------
-- Crossbar to masterFIP core --
-- 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
......@@ -412,7 +460,7 @@ begin
---------------------------------------------------------------------------------------------------
-- masterFIP core --
-- FMC MASTERFIP CORE --
---------------------------------------------------------------------------------------------------
cmp_masterFIP_core : fmc_masterFIP_core
generic map
......@@ -498,7 +546,6 @@ begin
led_red_o <= not rst_n_sys;
end rtl;
--=================================================================================================
-- architecture end
......
top/spec/synthesis_descriptor.vhd
View file @ cf087b1f
-------------------------------------------------------------------------------
-- Title : TDC FMC SPEC (Simple VME FMC Carrier) SDB descriptor
-- Project : TDC FMC (fmc-tdc-1ns-5cha)
-------------------------------------------------------------------------------
-- File : synthesis_descriptor.vhd
-- Author : Evangelia Gousiou
-- Company : CERN
-- Created : 2013-04-16
-- Last update: 2013-04-16
-- Platform : FPGA-generic
-- Standard : VHDL'93
-------------------------------------------------------------------------------
-- Description: SDB descriptor for the top level of the FD on a SPEC carrier.
-- Contains synthesis & source repository information.
-- Warning: this file is modified whenever a synthesis is executed.
-------------------------------------------------------------------------------
--
-- Copyright (c) 2013 CERN / BE-CO-HT
--
-- This source file is free software; you can redistribute it
-- and/or modify it under the terms of the GNU Lesser General
-- Public License as published by the Free Software Foundation;
-- either version 2.1 of the License, or (at your option) any
-- later version.
--
-- This source is distributed in the hope that it will be
-- useful, but WITHOUT ANY WARRANTY; without even the implied
-- warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
-- PURPOSE. See the GNU Lesser General Public License for more
-- details.
--
-- You should have received a copy of the GNU Lesser General
-- Public License along with this source; if not, download it
-- from http://www.gnu.org/licenses/lgpl-2.1.html
--
-------------------------------------------------------------------------------
--_________________________________________________________________________________________________
-- |
-- |SPEC masterFIP| |
-- |
-- CERN, BE/CO-HT |
--________________________________________________________________________________________________|
---------------------------------------------------------------------------------------------------
-- |
-- synthesis_descriptor |
-- |
---------------------------------------------------------------------------------------------------
-- File synthesis_descriptor.vhd |
-- |
-- Description SDB descriptor for the top level of the masterFIP on a SPEC carrier. |
-- Contains synthesis & source repository information. |
-- |
-- Platform FPGA-generic |
-- |
---------------------------------------------------------------------------------------------------
-- GNU LESSER GENERAL PUBLIC LICENSE |
-- ------------------------------------ |
-- This source file is free software; you can redistribute it and/or modify it under the terms of |
-- the GNU Lesser General Public License as published by the Free Software Foundation; either |
-- version 2.1 of the License, or (at your option) any later version. |
-- This source is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; |
-- without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. |
-- See the GNU Lesser General Public License for more details. |
-- You should have received a copy of the GNU Lesser General Public License along with this |
-- source; if not, please download it from http://www.gnu.org/licenses/lgpl-2.1.html |
---------------------------------------------------------------------------------------------------
library ieee;
use ieee.STD_LOGIC_1164.all;
use work.wishbone_pkg.all;
......@@ -46,12 +41,12 @@ constant c_sdb_synthesis_info : t_sdb_synthesis :=
syn_commit_id => "00000000000000000000000000000000",
syn_tool_name => "ISE ",
syn_tool_version => x"00000147",
syn_date => x"20160128",
syn_date => x"20172202",
syn_username => "egousiou ");
constant c_sdb_repo_url : t_sdb_repo_url :=
(
repo_url => "http://svn.ohwr.org/projects/masterFIP "
repo_url => "git@ohwr.org:cern-fip/masterfip/masterfip-gw.git "
);
end package synthesis_descriptor;
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