FPGA IP Cores Explained
FPGA IP Cores Explained
Tutorial 10
Michal Kubíček
Department of Radio Electronics, FEEC BUT Brno
Vytvořeno za podpory projektu OP VVV Moderní a otevřené studium techniky CZ.02.2.69/0.0/0.0/16_015/0002430.
Tutorial 10
FPGAs in detail
❑ IP cores
❑ Microprocessors in FPGAs
❑ VHDL and other HDL languages
❑ VHDL advanced: PACKAGES, RECORDS...
page 2 kubicek@vutbr.cz
IP cores
page 3 kubicek@vutbr.cz
IP cores
IP Cores
❑ IP = Intellectual Property; does not mean exactly what the "IP core" really is when
speaking about FPGAs, but the term is widely used.
❑ The IP cores are prepared standard / often used subsystems (FFT, FIR, Ethernet
MAC, processor cores...) that find utilization across many different designs (wide
adoption is expected).
❑ Why to use IP cores?
• Not to "reinvent the wheel", for standard systems there are often ready-to-use solutions (free or payed)
• Immediately available; time = BIG money (time to market)
• Usually fully tested (guaranteed functionality), especially the payed ones
• Usually better optimized (performance, power, area), often even with respect to target FPGA type
• Some Hard IP feature analog circuitry (cannot be implemented in FPGA logic cells)
page 4 kubicek@vutbr.cz
IP cores
IP jádra = IP Cores
page 5 kubicek@vutbr.cz
IP cores
IP jádra = IP Cores
page 6 kubicek@vutbr.cz
IP cores
IP jádra = IP Cores
page 7 kubicek@vutbr.cz
IP cores
IP cores
❑ Two variants:
• Hard IP – there is a dedicated area on the FPGA chip that is used for the IP
functionality. This dedicated chip area cannot be used for anything else.
• Soft IP – the required functionality is created using a general purpose FPGA logic
(LUTs, Flip-Flops, DSP blocks, BRAMs...). Some IP cores are in a form of an HDL
code, however the more complex ones are often payed and as such distributed as
encrypted.
page 8 kubicek@vutbr.cz
IP cores
page 9 kubicek@vutbr.cz
IP cores
page 10 kubicek@vutbr.cz
IP cores
CLB CLB CLB CLB CLB CLB ☺ independent on target FPGA family
(almost)
CLB CLB CLB CLB CLB CLB CLB CLB
☺ usually more flexible (settings)
CM CLB CLB CLB CLB CLB CLB CM ☺ consumes no chip area when not
used
page 11 kubicek@vutbr.cz
IP cores
http://opencores.org
page 12 kubicek@vutbr.cz
IP cores
page 13 kubicek@vutbr.cz
IP cores
page 14 kubicek@vutbr.cz
IP cores
Verification IP cores
❑ IP cores that are targeted for simulation only.
❑ Intended to verify full functionality of complex functions (typically industry-standard
interfaces, like AXI, USB...).
❑ Some verification IPs are certified ➔ once a custom design passes complete test with
such verification IP, it is virtually assured that the following certification process will run
smoothly.
Verification ≠ simulation!!!
page 15 kubicek@vutbr.cz
Hard IPs in modern FPGAs
page 16 kubicek@vutbr.cz
Hard IP
page 17 kubicek@vutbr.cz
Hard IP
BRAM
Properties:
• True Dual Port
• Works at FPGA core clock frequency
• Synchronous, optional output registers
• Native support of ECC
Usage
• Fast memories (RAMs, CACHEs)
• Core of a FIFO memory
• Frame/packet buffers
• ROM memories
page 18 kubicek@vutbr.cz
Hard IP
page 19 kubicek@vutbr.cz
Hard IP
page 20 kubicek@vutbr.cz
Processors in FPGA
Procesor
page 21 kubicek@vutbr.cz
Processors in FPGA, SoC
page 22 kubicek@vutbr.cz
Processors in FPGA, SoC
page 23 kubicek@vutbr.cz
FPGA processor HARD IP overview
Procesor
page 24 kubicek@vutbr.cz
Processors in FPGA overview – HARD IP
IBM PowerPC
❑ High-performance 32b RISC processor
❑ Operating frequency up to 500 MHz
❑ 2 x 32kB Cache, MMU, APU, PLB interface
❑ JTAG debug interface
❑ Suitable also for "big" operation systems
❑ Featured in Xilinx Virtex-II Pro (2002), Virtex-4FX (2004) and
Virtex-5FXT (2006)
❑ Up to two cores in a single FPGA
❑ Obsolete, no longer supported.
page 25 kubicek@vutbr.cz
Processors in FPGA overview – HARD IP
IBM PowerPC
page 26 kubicek@vutbr.cz
Processors in FPGA overview – HARD IP
page 28 kubicek@vutbr.cz
Processors in FPGA overview – HARD IP
page 29 kubicek@vutbr.cz
Processors in FPGA overview – HARD IP
page 30 kubicek@vutbr.cz
Processors in FPGA overview – HARD IP
Processors in FPGA overview – HARD IP
Zynq UltraScale+ EG
Processors in FPGA overview – HARD IP
Zynq UltraScale+ RFSoCs
Processors in FPGA overview – HARD IP
page 34 kubicek@vutbr.cz
Processors in FPGA overview – HARD IP
page 35 kubicek@vutbr.cz
Processors in FPGA overview – HARD IP
page 36 kubicek@feec.vutbr.cz
Processors in FPGA – data centers
Data Centers
page 37 kubicek@vutbr.cz
Processors in FPGA – data centers
page 38 kubicek@vutbr.cz
Processors in FPGA overview – HARD IP
ARM Cortex M3
❑ SmartFusion, SmartFusion2 FPGA
page 39 kubicek@vutbr.cz
Processors in FPGA overview – HARD IP
SOFT IP processor cores - overview
page 41 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
page 42 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
S1 Core
❑ SPARC-V9 core (Sun Microsystems)
❑ Available under GNU license, but the source code must be made public
❑ Size up to 60000 LUT (Virtex-5) = very large (consumes a lot of FPGA resources)
❑ So far the only 64b processor soft IP core for FPGA
page 43 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
LEON (2, 3, 4)
❑SPARC-V8 core (Aeroflex
Gaisler AB), 32b
❑ Available under GPL – free for
open-source hardware
❑ There are many IP cores for the
processor in the GRLIB library
❑ Suitable for aerospace
applications (fault-tolerant version
available)
page 44 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
RISC-V
• Open standard instruction set architecture (ISA)
• 32b, 64b or 128b
https://riscv.org/risc-v-cores/
https://en.wikipedia.org/wiki/RISC-V
OpenRISC
• Open-source hardware
• RISC
• 32b or 64b
https://en.wikipedia.org/wiki/OpenRISC
page 45 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
MicroBlaze
❑ RISC, 32b, close to DLX core
❑ Only for Xilinx FPGAs
❑ Utilizes AXI interface
❑ Available with ISE/Vivado for free
❑ Optimized for FPGA ➔ performance on par with LEON core but features smaller FPGA
footprint (lower resource requirements)
❑ There are open-source clones available – compatible instruction set, platform independent,
but larger FPGA footprint and slightly lower performance (maximum frequency)
page 46 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
MicroBlaze
MicroBlaze MCS MicroBlaze
Configurable Fixed Peripherals and I/O, processor Up to 70 different configuration options
configuration
Pipeline 3-stage 3-stage or 5-stage selectable
Memory 4kB-64kB Local memory only (Block RAM) Local or External through virtual
memory management up to 4GB
Streaming Ports No Yes
Peripherals UART, interrupt controller with optional low Multiple peripherals are supported
latency interrupts, 4 programmable interval through the Embedded Edition IP
timers, 4 fixed interval times, 4 general catalog
purpose outputs, 4 general purpose inputs,
I/O bus
page 47 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
MicroBlaze
page 48 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
Nios II
❑ Very similar to MicroBlaze core
❑ Only for Intel (Altera) FPGAs or ASICs
❑ Open-source clones available
page 49 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
MP32
❑ 100% MIPS compatible core
❑ Optimized for Intel (Altera) FPGAs
page 50 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
Freescale V1 ColdFire
❑ Included in Intel (Altera) FPGA design environment for free
❑ Optimized for Intel (Altera) FPGAs
page 51 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
page 53
Soft processor cores suitable for FPGAs
Lattice Mico32
❑ Similar to MicroBlaze core
❑ Open-sorce, free to use
❑ FPGA vendor independent (can be used on any FPGA)
page 54 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
TSK3000
❑ RISC, 32b
❑ Wishbone Compatible
❑ Used to be available for free in Altium Designer
❑ Any target FPGA (vendor independent)
page 55 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
ARM Cortex
❑ Many different cores available
❑ Some are for free for specific FPGA model/architecture
❑ Both open-source and proprietary versions, more or less optimized for target architecture
page 56 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
PicoBlaze: KCPSM3
❑ Very simple core ➔ very small FPGA footprint
❑ Limited program memory (max. 1023) ➔ typically assembly language is used
❑ Only basic development environment
❑ Suitable as a replacement of complex state machines (where speed is not that critical)
❑ There are often many PicoBlaze cores in a single FPGA (even hundreds)
❑ Optimized for Xilinx FPGA (proprietary, vendor-fixed) but there are many open-source
clones with compatible instruction set.
page 57 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
PicoBlaze: KCPSM6
❑ PicoBlaze version for newer FPGA families (Xilinx 6-series and 7-series)
❑ Adjustable program memory (from 125 to 4095 instructions)
❑ Two register banks (2 x 16 registers)
❑ Adjustable RAM (64B, 128B or 256B)
❑ Instructions for direct output of a constant (OUTPUTK)
❑ Better support for text strings
❑ Version control (time stamp, HW version attribute)
❑ JTAG loader for in-system programming (no need to regenerate the whole FPGA bitstream
when the PicoBlaze core changes) ➔ rapid development
page 58 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
Lattice Mico8
❑ Open-source RISC, 8b
❑ Similar to PicoBlaze (both properties and usage)
page 59 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
page 60
Soft processor cores suitable for FPGAs
page 61 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs
page 64 kubicek@vutbr.cz
VHDL and other HDL languages
page 65 kubicek@vutbr.cz
VHDL and other HDL languages
❑ IEEE Standard Std 1076-xxxx (1987, 1993, 2000, 2002, 2008, 2019)
❑ First only for simulation of large digital systems
❑ Only a subset of the language can be used for synthesis ("synthesizable subset"),
some code cannot be synthesized or is not synthesized efficiently
• Most WAIT statements
• Some arithmetic operators (/, MOD, REM)
• Loops are very tricky (FOR, WHILE)
• There are strict coding rules. Violation of these (incomplete sensitivity list...) often
leads to a lethal mismatch between simulation and implementation.
page 66 kubicek@vutbr.cz
VHDL and other HDL languages
page 67 kubicek@vutbr.cz
VHDL and other HDL languages
Levels of abstraction
page 68 kubicek@vutbr.cz
VHDL and other HDL languages
page 69 kubicek@vutbr.cz
VHDL and other HDL languages
Verilog-95
page 70 kubicek@vutbr.cz
VHDL and other HDL languages
VHDL
page 71 kubicek@vutbr.cz
VHDL and other HDL languages
page 72 kubicek@vutbr.cz
VHDL and other HDL languages
SystemVerilog: Verilog-2001
page 73 kubicek@vutbr.cz
VHDL and other HDL languages
SystemVerilog: Enhancements
page 74 kubicek@vutbr.cz
VHDL and other HDL languages
page 75 kubicek@vutbr.cz
VHDL and other HDL languages
page 76 kubicek@vutbr.cz
VHDL and other HDL languages
page 77 kubicek@vutbr.cz
VHDL and other HDL languages
page 78 kubicek@vutbr.cz
VHDL and other HDL languages
❑ The simplest case: the testbench is used only as a signal generator that evokes
some typical use cases of the tested design (directed test). The design
functionality is checked by observing signal waveforms in simulator GUI. This is
not the verification, such approach should be avoided!
❑ The HDL design and the testbench are written by different designers to avoid
double errors.
page 79 kubicek@vutbr.cz
VHDL and other HDL languages
page 80 kubicek@vutbr.cz
VHDL and other HDL languages
page 81 kubicek@vutbr.cz
VHDL and other HDL languages
page 82 kubicek@vutbr.cz
VHDL and other HDL languages
https://fedoraproject.org/wiki/Electronic_Lab?rd=ElectronicLab_Spin
http://www.edaplayground.com/
http://www.geda-project.org/
https://www.synflow.com
https://verificationacademy.com/
page 83 kubicek@vutbr.cz
VHDL: Libraries and Packages
page 84 kubicek@vutbr.cz
VHDL – libraries
Libraries
LIBRARY WORK; -- implicit
LIBRARY STD; -- implicit
LIBRARY IEEE;
LIBRARY UNISIM;
page 85 kubicek@vutbr.cz
VHDL – packages
Packages
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.NUMERIC_STD.ALL;
...
Packages contain declarations and definitions of VHDL objects, that can be used in
the following code.
Interpretation: In the IEEE library there is a compiled package STD_LOGIC_1164
Similar to INCLUDE directive used in some other programming languages.
page 86 kubicek@vutbr.cz
VHDL – packages
Slohy
LIBRARY WORK;
LIBRARY STD;
USE STD.STANDARD.ALL; -- implicit
USE STD.TEXTIO.ALL;
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.NUMERIC_STD.ALL;
...
page 87 kubicek@vutbr.cz
VHDL – packages
page 88 kubicek@vutbr.cz
VHDL – packages
page 89 kubicek@vutbr.cz
VHDL – packages
package STD_LOGIC_1164 is
TYPE std_ulogic IS (...
TYPE std_ulogic_vector IS ARRAY ( NATURAL RANGE <> ) OF std_ulogic;
page 90 kubicek@vutbr.cz
VHDL – packages
❑ Conversion functions
std_(u)logic_vector, integer <=> (un)signed
page 91 kubicek@vutbr.cz
VHDL – packages
❑ Conversion functions
bit_vector, integer <=> (un)signed
page 92 kubicek@vutbr.cz
VHDL – packages
std_logic_arith Synopsys
❑ Type definition unsigned, signed
Array of STD_LOGIC
❑ Arithmetic and relation operators for operands of type unsigned, signed
❑ Conversion functions
std_(u)logic_vector, integer <=> (un)signed
page 93 kubicek@vutbr.cz
VHDL – packages
std_logic_arith Mentor
❑ Type definition unsigned, signed
Array of STD_LOGIC
❑ Arithmetic and relation operators for operands of type unsigned, signed
❑ Conversion functions
std_(u)logic_vector, integer <=> (un)signed
std_logic_vector <= integer
page 94 kubicek@vutbr.cz
VHDL – packages
std_logic_unsigned Synopsys
❑ Arithmetic and relation operators for operands of type std_logic_vector
page 95 kubicek@vutbr.cz
VHDL – packages
std_logic_signed Synopsys
❑ Arithmetic and relation operators for operands of type std_logic_vector
page 96 kubicek@vutbr.cz
VHDL – packages
package STD_LOGIC_UNSIGNED is
function "+"(L: STD_LOGIC_VECTOR; R: STD_LOGIC_VECTOR) return STD_LOGIC_VECTOR;
function "+"(L: STD_LOGIC_VECTOR; R: INTEGER) return STD_LOGIC_VECTOR;
function "+"(L: INTEGER; R: STD_LOGIC_VECTOR) return STD_LOGIC_VECTOR;
function "+"(L: STD_LOGIC_VECTOR; R: STD_LOGIC) return STD_LOGIC_VECTOR;
function "+"(L: STD_LOGIC; R: STD_LOGIC_VECTOR) return STD_LOGIC_VECTOR;
...
page 97 kubicek@vutbr.cz
VHDL – packages
package STD_LOGIC_UNSIGNED is
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
...
...
page 98 kubicek@vutbr.cz
VHDL – packages
std_logic_1164
numeric_std std_logic_arith
IEEE standard, late adoption, no std_logic_unsigned
problems with signed/unsigned std_logic_signed
numbers in a single code, need to
convert from/to std_logic_vector Industry „standard“, should not be used,
but there are mane ready-to-use codes
around, signed/unsigned conflict.
ENTITY ALU IS
PORT ( A,B: IN STD_LOGIC_VECTOR (7 DOWNTO 0);
SUM: OUT STD_LOGIC_VECTOR (7 DOWNTO 0));
END ALU;
ENTITY ALU IS
PORT ( A,B: IN STD_LOGIC_VECTOR (7 DOWNTO 0);
SUM: OUT STD_LOGIC_VECTOR (7 DOWNTO 0));
END ALU;
Addition (UNSIGNED)
library IEEE;
use IEEE.STD_LOGIC_1164.ALL; The correct code
use IEEE.NUMERIC_STD.ALL; (standard IEEE package)
-----------------------------------------------
ALU
ENTITY ALU IS
PORT (A,B: IN STD_LOGIC_VECTOR (7 DOWNTO 0); A
SUM: OUT STD_LOGIC_VECTOR (7 DOWNTO 0)); SUM
END ALU; B
-----------------------------------------------
ALU
ARCHITECTURE Behavioral OF ALU IS
BEGIN A
SUM <= STD_LOGIC_VECTOR(UNSIGNED(A) + UNSIGNED(B)); + SUM
END Behavioral; B
Addition (UNSIGNED)
library IEEE; Functional, but not
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL; ! recommended, deprecated
(non-standard package)
-----------------------------------------------
ALU
ENTITY ALU IS
PORT (A,B: IN STD_LOGIC_VECTOR (7 DOWNTO 0); A
SUM: OUT STD_LOGIC_VECTOR (7 DOWNTO 0)); SUM
END ALU; B
-----------------------------------------------
ALU
ARCHITECTURE Behavioral OF ALU IS
BEGIN A
SUM <= UNSIGNED(A) + UNSIGNED(B); + SUM
END Behavioral; B
Addition (UNSIGNED)
library IEEE; Non-standard package, but is
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL; ! sometimes still tolerated for
simple blocks (counters,
unsigned adders)
-----------------------------------------------
ALU
ENTITY ALU IS
PORT (A,B: IN STD_LOGIC_VECTOR (7 DOWNTO 0); A
SUM: OUT STD_LOGIC_VECTOR (7 DOWNTO 0)); SUM
END ALU; B
-----------------------------------------------
ALU
ARCHITECTURE Behavioral OF ALU IS
BEGIN A
SUM <= A + B; + SUM
END Behavioral; B
Addition (SIGNED)
library IEEE;
use IEEE.STD_LOGIC_1164.ALL; The correct code
use IEEE.NUMERIC_STD.ALL; (standard IEEE package)
-----------------------------------------------
ALU
ENTITY ALU IS
PORT (A,B: IN STD_LOGIC_VECTOR (7 DOWNTO 0); A
SUM: OUT STD_LOGIC_VECTOR (7 DOWNTO 0)); SUM
END ALU; B
-----------------------------------------------
ALU
ARCHITECTURE Behavioral OF ALU IS
BEGIN A
SUM <= STD_LOGIC_VECTOR(SIGNED(A) + SIGNED(B)); + SUM
END Behavioral; B
Addition (SIGNED)
library IEEE; Functional, but not
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL; ! recommended, deprecated
(non-standard package)
-----------------------------------------------
ALU
ENTITY ALU IS
PORT (A,B: IN STD_LOGIC_VECTOR (7 DOWNTO 0); A
SUM: OUT STD_LOGIC_VECTOR (7 DOWNTO 0)); SUM
END ALU; B
-----------------------------------------------
ALU
ARCHITECTURE Behavioral OF ALU IS
BEGIN A
SUM <= SIGNED(A) + SIGNED(B); + SUM
END Behavioral; B
Addition (SIGNED)
library IEEE; Very problematic package,
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_SIGNED.ALL; X avoid its usage!
-----------------------------------------------
ALU
ENTITY ALU IS
PORT (A,B: IN STD_LOGIC_VECTOR (7 DOWNTO 0); A
SUM: OUT STD_LOGIC_VECTOR (7 DOWNTO 0)); SUM
END ALU; B
-----------------------------------------------
ALU
ARCHITECTURE Behavioral OF ALU IS
BEGIN A
SUM <= A + B; + SUM
END Behavioral; B
Conversion functions
use IEEE.NUMERIC_STD.ALL;
...
SIGNAL a_VEC : STD_LOGIC_VECTOR (7 DOWNTO 0);
SIGNAL a_UNS : UNSIGNED (7 DOWNTO 0);
SIGNAL a_INT : INTEGER RANGE 0 TO 255;
...
--------------------------------------------------------------------------------
END param_pkg;
--------------------------------------------------------------------------------
RECORD
VHDL records are a collection (agregate) of signals in one
named object, similar to structs in C.
TYPE t_data_interface IS
RECORD
data : STD_LOGIC_VECTOR(15 DOWNTO 0);
data_valid : STD_LOGIC;
data_error : STD_LOGIC
);
END RECORD;
RECORDS
TYPE t_data_interface IS
RECORD
data : STD_LOGIC_VECTOR(15 DOWNTO 0);
data_valid : STD_LOGIC;
data_error : STD_LOGIC);
END RECORD;
GTP_0_status_vect
GTP_1_status_vect
:
:
OUT
OUT
STD_LOGIC_VECTOR(15
STD_LOGIC_VECTOR(15
DOWNTO
DOWNTO
0);
0);
ENTITY MAC_core IS
GTP_2_status_vect
GTP_3_status_vect
:
:
OUT
OUT
STD_LOGIC_VECTOR(15
STD_LOGIC_VECTOR(15
DOWNTO
DOWNTO
0);
0); PORT(
HOST_stat_ctrl_out
HOST_reg_data_rd_0
HOST_reg_data_rd_1
:
:
:
OUT
OUT
OUT
STD_LOGIC_VECTOR(
STD_LOGIC_VECTOR(
STD_LOGIC_VECTOR(
7
7
7
DOWNTO
DOWNTO
DOWNTO
0);
0);
0);
clk : IN STD_LOGIC;
HOST_reg_data_rd_2
HOST_reg_data_rd_3
:
:
OUT
OUT
STD_LOGIC_VECTOR(
STD_LOGIC_VECTOR(
7
7
DOWNTO
DOWNTO
0);
0)); rst : IN STD_LOGIC;
rst_MAC_0 : IN STD_LOGIC;
rst_MAC_1 : IN STD_LOGIC;
rst_MAC_2 : IN STD_LOGIC;
rst_MAC_3
rst_PCS_PMA_0
:
:
IN
IN
STD_LOGIC;
STD_LOGIC;
GTP_0_AN_irq : OUT STD_LOGIC;
rst_PCS_PMA_1
rst_PCS_PMA_2
rst_PCS_PMA_3
:
:
:
IN
IN
IN
STD_LOGIC;
STD_LOGIC;
STD_LOGIC;
GTP_1_AN_irq : OUT STD_LOGIC;
rst_GTP_0 : IN STD_LOGIC;
rst_GTP_1 : IN STD_LOGIC;
rst_GTP_2
rst_GTP_3
:
:
IN
IN
STD_LOGIC;
STD_LOGIC; .....
GTP_0_AN_rst : IN STD_LOGIC;
GTP_1_AN_rst : IN STD_LOGIC;
GTP_2_AN_rst : IN STD_LOGIC;
GTP_3_AN_rst
GTP_0_cfg_vect
:
:
IN
IN
STD_LOGIC;
GTP_0_AN_adv_cfg_vect_valid
:
:
IN
IN
STD_LOGIC_VECTOR(15
STD_LOGIC;
DOWNTO 0);
END MAC_core;
GTP_1_AN_adv_cfg_vect_valid : IN STD_LOGIC;
GTP_2_AN_adv_cfg_vect_valid : IN STD_LOGIC;
GTP_3_AN_adv_cfg_vect_valid : IN STD_LOGIC;
TYPE t_MAC_core_OUT IS
RECORD
GTP_0_AN_irq : STD_LOGIC;
GTP_1_AN_irq : STD_LOGIC;
GTP_2_AN_irq : STD_LOGIC;
GTP_3_AN_irq : STD_LOGIC;
GTP_0_AN_rst : STD_LOGIC;
GTP_1_AN_rst
GTP_2_AN_rst
:
:
STD_LOGIC;
STD_LOGIC; rst_MAC_3 : STD_LOGIC;
GTP_3_AN_rst : STD_LOGIC;
GTP_0_cfg_vect_valid : STD_LOGIC;
ENTITY MAC_core IS
PORT(
clk : IN STD_LOGIC;
rst : IN STD_LOGIC;
MAC_core_IN : IN t_MAC_core_IN;
MAC_core_OUT : OUT t_MAC_core_OUT);
END MAC_core;
This method (one RECORD for inputs, other RECORD for outputs) is called Gaisler method,
and is well supported by all tools (simulation, synthesis).
There is an alternative method where signals in the RECORD are declared as INOUT. This
enables further simplification of interface but some tools (including Xilinx Vivado Synthesis) are
not able to handle such description and there is no hope for near future fixes.
MAC_core_1 : MAC_core
PORT MAP(
clk => clk,
rst => rst,
MAC_core_IN => MAC_core_IN_1,
MAC_core_OUT => MAC_core_OUT_1);
MAC_core_2 : MAC_core
PORT MAP(
clk => clk,
rst => rst,
MAC_core_IN => MAC_core_IN_2,
MAC_core_OUT => MAC_core_OUT_2);
Attributes
❑ Provide access to object parameters
❑ Included in VHDL language definition
❑ Very useful for writing generic code
clk 7 6 5 4 3 2 1 0
PROCESS (clk) BEGIN
IF rising_edge(clk) THEN
shreg <= shreg(shreg'HIGH-1 DOWNTO 0) & shreg(shreg'HIGH);
END IF;
END PROCESS;
File handling
(TBD)