KEMBAR78
FPGA IP Cores Explained | PDF | Field Programmable Gate Array | Vhdl
0% found this document useful (0 votes)
69 views129 pages

FPGA IP Cores Explained

The document discusses programmable logic devices and focuses on intellectual property (IP) cores, microprocessors that can be used in FPGAs, and hardware description languages. It provides details on hard and soft IP cores, examples of common IP cores for FPGAs, and how IP cores can be used and verified. It also covers some examples of hard IP blocks in modern FPGAs like DSP and memory blocks, and discusses using microprocessors within the programmable logic of an FPGA.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
69 views129 pages

FPGA IP Cores Explained

The document discusses programmable logic devices and focuses on intellectual property (IP) cores, microprocessors that can be used in FPGAs, and hardware description languages. It provides details on hard and soft IP cores, examples of common IP cores for FPGAs, and how IP cores can be used and verified. It also covers some examples of hard IP blocks in modern FPGAs like DSP and memory blocks, and discusses using microprocessors within the programmable logic of an FPGA.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 129

Programmable Logic Devices

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

FPGA Hard IP Some chip area is dedicated for the


hard IP functionality.

☺ better area efficiency (for the


CM CLB CLB CLB CLB CLB CLB CM
given functionality)
CLB CLB CLB CLB CLB CLB CLB CLB ☺ lower power consumption
CLB CLB CLB CLB CLB CLB
☺ higher performance
Procesor ☺ can contain analog electronics
CLB CLB CLB CLB CLB CLB

 available only in some FPGA


CLB CLB CLB CLB CLB CLB CLB CLB
families
CM CLB CLB CLB CLB CLB CLB CM  less flexible (fixed functionality)
 when not used we pay extra
money for nothing (dead silicon)

page 9 kubicek@vutbr.cz
IP cores

FPGA: common Hard IPs


❑ RAM memories
❑ Clock managers
❑ DSP blocks: multipliers 18 x 18 bit, 48bit MAC
❑ High speed transceivers: up to 56 Gb/s over a single differential pair
❑ Standard interfaces: PCI-Express MAC, Ethernet MAC, SDR/DDR memory controllers
❑ Microprocessors: PowerPC (405, 440), ARM Cortex-M3, ARM Cortex-A9
❑ Mixed-signal blocks: AD converters...
❑ Some other blocks: AES and SHA cipher blocks...

page 10 kubicek@vutbr.cz
IP cores

FPGA Soft IP Some of the general purpose logic is


dedicated for the soft IP functionality

 larger chip area


CM CLB CLB CLB CLB CLB CLB CM
 higher power consumption
CLB CLB CLB CLB CLB CLB CLB CLB
 lower performance
CLB CLB CLB CLB CLB CLB  only digital functionality
Procesor

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

FPGA: common Soft IPs


❑ DSP blocks: FIR and CIC filters, FFT, DDS, CORDIC...
❑ Standard interfaces: PCI, CAN, PCI-Express a Ethernet MAC, SDR/DDR memory controllers...
❑ Microprocessors: PicoBlaze, MicroBlaze, Nios-II, ARM Cortex-M1, x51...
❑ Arithmetic blocks: dividers and multipliers (fixed/floating point)...
❑ FEC: Reed-Solomon, Viterbi, 802.16e, DVB-S2...

❑ Audio and video codecs: LCD VGA/HDMI drivers, JPEG, H.264...


❑ Other blocks: ciphering cores of AES a SHA...

http://opencores.org

page 12 kubicek@vutbr.cz
IP cores

How to use an IP core


IP cores are usually distributed as ready-to-use components with defined
interfaces. Very often the internal functionality is hidden and only the interfaces
are known ("black box"). Thus there are basically only two options:
❑ Structural description (HDL)
❑ Schematic (only in some CAD tools)
The cores often feature a standard interface
▪ AXI (full, lite, stream)
▪ Wishbone
▪ AHB
▪ ...

page 13 kubicek@vutbr.cz
IP cores

Xilinx Vivado IP cores


Hard IP and Soft IP are
not separated!!!

Soft IP may use some


Hard IP blocks internally
(DSP, BRAM, clock
managers, transceivers...)

Hard IP often utilize some


general purpose FPGA logic
to connect to a custom
design (glue logic)

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

Virtex-6,7 DSP48E1 slice (638 MHz), up to 11904 per FPGA

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

Clock management blocks


• Based on PLL or DLL
• Clock frequency synthesis, delay compensation, phase shifting, jitter filtering, duty
cycle correction...

page 19 kubicek@vutbr.cz
Hard IP

Standard interface IP blocks


❑ Tri-speed Ethernet (10/100/1000)
❑ 100G Ethernet
❑ 150G Interlaken
❑ PCI Express (x1, x2, x4, x8, 16x)
Gen1 (2.5 Gb/s), Gen2 (5 Gb/s), Gen3 (10 Gb/s), Gen4
❑ Memory controller
DDR, DDR2, DDR3, DDR4, QDRII+, mobile DDR, RLDRAM3, HMC...

page 20 kubicek@vutbr.cz
Processors in FPGA

CM CLB CLB CLB CLB CLB CLB CM

CLB CLB CLB CLB CLB CLB CLB CLB

CLB CLB CLB CLB CLB CLB

Procesor

CLB CLB CLB CLB CLB CLB

CLB CLB CLB CLB CLB CLB CLB CLB

CM CLB CLB CLB CLB CLB CLB CM

page 21 kubicek@vutbr.cz
Processors in FPGA, SoC

Digital function: use an FPGA or a processor?


❑ Generally, the selection depends on required speed of the digital function:
• Nanoseconds – logic, which requires maximum speed, minimum and well defined latency.
Suitable for FPGA implementation.
• Microseconds – designer must evaluate all the options to make the best choice between
FPGA and processor
• Milliseconds – slow processes, often related to user interface (driving LEDs,
button/keyboard input). Suitable for processors.
The choice must cover many other factors: price of the silicon device, development time,
design reusability, testability, certification requirements, power consumption...

page 22 kubicek@vutbr.cz
Processors in FPGA, SoC

Processor and FPGA together?


❑ Most (all) current systems utilizing FPGA feature some sort of processor
❑ Three variants of processor implementation:
• Independent processor – a discrete integrated circuit (part) on a PCB or within the same
package with FPGA.
• FPGA with processor HARD IP – part of the FPGA silicon area is dedicated to processor,
which is tightly coupled to the FPGA logic (high throughput interfaces). There are several
FPGAs with integrated processor hard IPs (several versions of ARM cores, Intel Xeon).
• FPGA with Soft IP processor core – the processor is implemented as an HDL design
using general purpose FPGA logic. Virtually any processor (even a custom one) can be
implemented and customized (modifying instruction set, peripherals, cache memories...).

page 23 kubicek@vutbr.cz
FPGA processor HARD IP overview

CM CLB CLB CLB CLB CLB CLB CM

CLB CLB CLB CLB CLB CLB CLB CLB

CLB CLB CLB CLB CLB CLB

Procesor

CLB CLB CLB CLB CLB CLB

CLB CLB CLB CLB CLB CLB CLB CLB

CM CLB CLB CLB CLB CLB CLB CM

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

ARM Cortex A9 (NEON extension)


❑ Xilinx ZYNQ-7000 ("extensible processing platform")
Processors in FPGA overview – HARD IP

ARM Cortex A9 (NEON extension)

page 28 kubicek@vutbr.cz
Processors in FPGA overview – HARD IP

ARM Cortex A9 (NEON extension)


❑ Intel (Altera) Cyclone SoC a Aria SoC

page 29 kubicek@vutbr.cz
Processors in FPGA overview – HARD IP

Zynq UltraScale+ MPSoC


❑ APU: Quad ARM Cortex-A53 MPCore with CoreSight
❑ RTPU: Dual ARM Cortex-R5 MPCore with CoreSight
❑ GPU: ARM Mali™-400 MP2; 64KB L2 Cache
❑ Video Codec: H.265, H.264 (4Kx2K @ 60 fps)
❑ Interface: PCI Express Gen. 3 x16, USB 3.0, SATA 3.0, DisplayPort 1.2a, 150 Gb/s
Interlaken, 100 Gb/s Ethernet...
❑ FPGA: Up to 522k LUTs, 1045k F-Fs, 3528 DSP slices, 70 Mbit RAM (BRAM + Ultra
RAM), 11 CMT, 1.6 Tb/s full-duplex transceiver throughput (GTH + GTY).

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

Intel Atom + Altera Aria FPGA


❑ FPGA co-processing for embedded systems

page 34 kubicek@vutbr.cz
Processors in FPGA overview – HARD IP

Intel Atom + Altera Aria FPGA


❑ 3D graphics, Memory Controller...

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

CM CLB CLB CLB CLB CLB CLB CM

CLB CLB CLB CLB CLB CLB CLB CLB

CLB CLB CLB CLB CLB CLB CLB CLB

CLB CLB CLB CLB CLB CLB CLB CLB

CLB CLB CLB CLB CLB CLB CLB CLB

CM CLB CLB CLB CLB CLB CLB CM

page 41 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs

Several different cores available


❑ Cores optimized for FPGA implementation (MicroBlaze, Nios) – usually proprietary
❑ Cores that are instruction compatible with classic processors (ARM, x51...). There
are also OpenSource versions.

❑ Large cores (32b) – C-programmable ARM(-like) cores. Capable of running fully-featured


OS, if required.
❑ Little cores (8b) – can often efficiently replace complex state machines (but beware of
software certification in critical applications)

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

AXI-4 bus No Yes


connections

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

Intel (Altera): processor core overview


Soft processor cores suitable for FPGAs

Intel (Altera): processor core overview

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

How to use a processor in an FPGA


❑ It is relatively simple to describe (write an HDL code) and
implement a processor core into an FPGA.
❑ But what about the program???
For every available FPGA-targeted processor there is a set of tools that enable:
1) Create the core in the target FPGA – configure processor and its
peripherals, including its address space
2) Develop the application – SW development tool (often Eclipse-based)
that automatically extracts all the necessary information from the HW
configuration tool and enables development of both OS-based and bare-
metal application codes (as needed). In-system programming and debug is
a commonplace.

page 61 kubicek@vutbr.cz
Soft processor cores suitable for FPGAs

Development tool – HW configuration


Soft processor cores suitable for FPGAs

Development tool – software


Soft processor cores suitable for FPGAs

Some problems of processors in FPGA


❑ Program memory
There is only limited amount of memory in the FPGA (only tens of kB) ➔ often
only bootloader is present, an external SRAM, SDRAM or FLASH memory is used
as the main processor memory.
❑ Efficiency of implementation ($/MIPS, $/mm2)
It is possible to use soft-IP processor cores to run fully-featured OS, but it is
usually very inefficient (external processor is cheaper and more powerful)
❑ For certain applications all the software must be certified
HW must pass DO-254 certification, in addition any software must pass DO-
178B certification. Typical for Airspace, Military, Automotive, Medical...

page 64 kubicek@vutbr.cz
VHDL and other HDL languages

page 65 kubicek@vutbr.cz
VHDL and other HDL languages

VHDL (VHSIC Hardware Description Language)


❑ VHSIC = Very High Speed Integrated Circuit
Sometimes VHDL = Verification and Hardware Description Language

❑ 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

VHDL version support


❑ It is necessary to check which VHDL revisions and functions are supported by
particular tool (synthesizer and simulator).
❑ Some functions defined in VHDL-93 (and even VHDL-87) are still not supported,
VHDL-2008 is supported only partially (if at all).
Example: Xilinx synthesis tool (XST)
C:\...\Xilinx\14.7\ISE_DS\ISE\doc\usenglish\isehelp\xst.pdf
C:\...\Xilinx\14.7\ISE_DS\ISE\doc\usenglish\isehelp\xst_v6s6.pdf

Xilinx simulator (ISIM)


http://www.xilinx.com/cgi-bin/docs/rdoc?l=en;v=13.4;t=sw+manuals;d=plugin_ism.pdf

page 67 kubicek@vutbr.cz
VHDL and other HDL languages

Levels of abstraction

page 68 kubicek@vutbr.cz
VHDL and other HDL languages

VHDL and Verilog

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

SystemVerilog: Unified Language

page 75 kubicek@vutbr.cz
VHDL and other HDL languages

HDL languages - usage

page 76 kubicek@vutbr.cz
VHDL and other HDL languages

HDL languages – DESIGN usage

page 77 kubicek@vutbr.cz
VHDL and other HDL languages

HDL languages – VERIFICATION usage

page 78 kubicek@vutbr.cz
VHDL and other HDL languages

Verification: checking design functionality


❑ Every HDL source code should have its corresponding testbench

❑ 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!

❑ For verification it is necessary to check the design outputs automatically ➔


much more complex testbench. About 60-80% of the system design time (HDL
coding) is reserved for verification (writing testbenches).

❑ 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

Verification: checking design functionality


For reliable verification modern complex systems require much more
than automatic check of tested design outputs:
❑ Code Coverage
❑ Functional Coverage
❑ Constrained-Random Testing
❑ Assertion-Based Verification
➔ SystemVerilog, OSVVM (Open Source VHDL Verification Methodology)
❑ SystemVerilog complexity
➔ OVM/UVM

page 80 kubicek@vutbr.cz
VHDL and other HDL languages

Verification: checking design functionality

page 81 kubicek@vutbr.cz
VHDL and other HDL languages

page 82 kubicek@vutbr.cz
VHDL and other HDL languages

Some useful links

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;

Give access to previously analyzed (compiled) entities and architectures


(prepared blocks for structural coding)

But there are no definitions of data types, operators, functions...

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

Packages (Xilinx ISE 14.7 XST)


......\Xilinx\14.7\ISE_DS\ISE\vhdl\xst\src\

IEEE packages: Synopsys packages:


numeric_std std_logic_arith
numeric_bit std_logic_unsigned
std_logic_1164 std_logic_misc
math_complex std_logic_signed
math_real std_logic_textio

Standardized packages Non-standard packages

page 88 kubicek@vutbr.cz
VHDL – packages

std_logic_1164 IEEE standard


❑ Type definition std_ulogic, std_logic (_vector)
❑ Operators AND, NAND, XOR, OR, NOT... for operands of type
std_ulogic, std_logic (_vector), bit, bit_vector
❑ Conversion functions bit<=>ulogic<=>logic and their vectors

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;

SUBTYPE std_logic IS resolved std_ulogic;


TYPE std_logic_vector IS ARRAY ( NATURAL RANGE <>) OF std_logic;

-- overloaded logical operators


FUNCTION "and" ( l : std_ulogic; r : std_ulogic ) RETURN UX01;
FUNCTION "nand" ( l : std_ulogic; r : std_ulogic ) RETURN UX01;
FUNCTION "or" ( l : std_ulogic; r : std_ulogic ) RETURN UX01;
...

-- vectorized overloaded logical operators


FUNCTION "and" ( l, r : std_logic_vector ) RETURN std_logic_vector;
FUNCTION "nand" ( l, r : std_logic_vector ) RETURN std_logic_vector;
...

FUNCTION rising_edge (SIGNAL s : std_ulogic) RETURN BOOLEAN;


FUNCTION falling_edge (SIGNAL s : std_ulogic) RETURN BOOLEAN;

page 90 kubicek@vutbr.cz
VHDL – packages

numeric_std IEEE standard


❑ Type definition unsigned, signed
Array of STD_LOGIC
❑ Arithmetic and relation operators for operands of type unsigned, signed

+ - * / MOD REM < > <= >= = /=


❑ Rotations and bit-shifts for operands of type unsigned, signed

❑ Conversion functions
std_(u)logic_vector, integer <=> (un)signed

page 91 kubicek@vutbr.cz
VHDL – packages

numeric_bit IEEE standard


❑ Type definition unsigned, signed
Array of BIT
❑ Arithmetic and relation operators for operands of type unsigned, signed

+ - * / MOD REM < > <= >= = /=


❑ Rotations and bit-shifts for operands of type unsigned, signed

❑ 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

+ - < > <= >= = /=


❑ Bit-shifts 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

+ - * / MOD REM < > <= >= = /=


❑ Bit-shifts 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

+ - < > <= >= = /=


❑ Conversion functions
integer <= std_logic_vector
Vectors are interpreted as unsigned integer numbers.

page 95 kubicek@vutbr.cz
VHDL – packages

std_logic_signed Synopsys
❑ Arithmetic and relation operators for operands of type std_logic_vector

+ - < > <= >= = /=


❑ Conversion functions
integer <= std_logic_vector
Vectors are interpreted as signed integer numbers.

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;

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 CONV_INTEGER(ARG: STD_LOGIC_VECTOR) return INTEGER;

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;

...

function "+"(L: STD_LOGIC_VECTOR; R: STD_LOGIC_VECTOR) return STD_LOGIC_VECTOR is


constant length: INTEGER := maximum(L'length, R'length);
variable result : STD_LOGIC_VECTOR (length-1 downto 0);
begin
result := UNSIGNED(L) + UNSIGNED(R);
return std_logic_vector(result);
end;

...

page 98 kubicek@vutbr.cz
VHDL – packages

Packages... which to use???


The PROBLEM: entity PORTs shall be of type std_logic / std_logic_vector

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.

If it ain't broke, don't fix it!!!


page 99 kubicek@vutbr.cz
VHDL – packages

Entity PORTs shall be of type std_logic / std_logic_vector


LIBRARY IEEE; LIBRARY IEEE;
use IEEE.std_logic_1164.ALL; use IEEE.std_logic_1164.ALL;
use IEEE.numeric_std.ALL; use IEEE.std_logic_unsigned.ALL;

ENTITY ALU IS
PORT ( A,B: IN STD_LOGIC_VECTOR (7 DOWNTO 0);
SUM: OUT STD_LOGIC_VECTOR (7 DOWNTO 0));
END ALU;

ARCHITECTURE one OF ALU IS ARCHITECTURE two OF ALU IS


SIGNAL Auns,Buns,SUMuns: BEGIN
unsigned(7 DOWNTO 0); SUM <= A + B;
BEGIN END two;
Auns <= unsigned(A);
Buns <= unsigned(B);
SUMuns <= Auns + Buns;
SUM <= std_logic_vector(SUMuns);
END one;

page 100 kubicek@vutbr.cz


VHDL – packages

Entity PORTs shall be of type std_logic / std_logic_vector


LIBRARY IEEE; LIBRARY IEEE;
use IEEE.std_logic_1164.ALL; use IEEE.std_logic_1164.ALL;
use IEEE.numeric_std.ALL; use IEEE.std_logic_unsigned.ALL;

ENTITY ALU IS
PORT ( A,B: IN STD_LOGIC_VECTOR (7 DOWNTO 0);
SUM: OUT STD_LOGIC_VECTOR (7 DOWNTO 0));
END ALU;

ARCHITECTURE one OF ALU IS ARCHITECTURE two OF ALU IS


BEGIN BEGIN
SUM <= std_logic_vector( SUM <= A + B;
unsigned(A) + unsigned(B)); END two;
END one;

page 101 kubicek@vutbr.cz


VHDL – packages

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

page 102 kubicek@vutbr.cz


VHDL – packages

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

page 103 kubicek@vutbr.cz


VHDL – packages

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

page 104 kubicek@vutbr.cz


VHDL – packages

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

page 105 kubicek@vutbr.cz


VHDL – packages

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

page 106 kubicek@vutbr.cz


VHDL – packages

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

page 107 kubicek@vutbr.cz


VHDL – packages

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;
...

STD_LOGIC_VECTOR <= INTEGER a_VEC <= STD_LOGIC_VECTOR(TO_UNSIGNED(a_INT,xx));


STD_LOGIC_VECTOR <= UNSIGNED a_VEC <= STD_LOGIC_VECTOR(a_UNS);

UNSIGNED <= INTEGER a_UNS <= TO_UNSIGNED(a_INT,xx);


UNSIGNED <= STD_LOGIC_VECTOR a_UNS <= UNSIGNED(a_VEC);

INTEGER <= UNSIGNED a_INT <= TO_INTEGER(a_UNS);


INTEGER <= STD_LOGIC_VECTOR a_INT <= TO_INTEGER(UNSIGNED(a_VEC));

page 108 kubicek@vutbr.cz


VHDL – packages

VHDL is strongly typed, is that wrong?


NO!

❑ Strongly typed = very strong error detection built in the compiler


❑ In other programming languages (like Verilog) it is necessary to
take much more care on coding.

page 109 kubicek@vutbr.cz


User packages in VHDL

page 110 kubicek@vutbr.cz


VHDL – packages

Often used for


❑ Constant declaration and definition
the usual goal is to have all the parameters in one place (file); the constants can
set bus widths, communication interface speeds, processor address space...

❑ Definition of custom data types


very often RECORDS are defined here

❑ Definition of commonly used (general purpose) blocks


signal synchronizers, counters, debouncers...

❑ Functions and procedures definition


especially for testbenches

page 111 kubicek@vutbr.cz


VHDL – packages

Example of a package with constants


--------------------------------------------------------------------------------
library IEEE;
use IEEE.std_logic_1164.ALL;
use IEEE.numeric_std.ALL;
--------------------------------------------------------------------------------
PACKAGE param_pkg IS
--------------------------------------------------------------------------------

CONSTANT HW_build : STD_LOGIC_VECTOR( 7 DOWNTO 0) := X"0C";


CONSTANT clock_speed : INTEGER := 31250000; -- 31.25 MHz

CONSTANT C_BUS_width : INTEGER := 64; -- 8/16/32/64

CONSTANT UART_period : INTEGER := 271; -- 115.200 Bd @ 31.25 MHz


CONSTANT I2C_clk_div : INTEGER := 250; -- 0.0625 MHz @ 31.25 MHz
CONSTANT C_I2C_SFP_clk_DIV : INTEGER := 125; -- 83 kb/s @ 31.25 MHz

CONSTANT c_request_period : UNSIGNED(31 DOWNTO 0) := TO_UNSIGNED(12500000,32);


CONSTANT c_rq_timeout_threshold : UNSIGNED(31 DOWNTO 0) := TO_UNSIGNED(25000000,32);

--------------------------------------------------------------------------------
END param_pkg;
--------------------------------------------------------------------------------

page 112 kubicek@vutbr.cz


VHDL – packages

Example of a package with component declaration


--------------------------------------------------------------------------------
library IEEE;
use IEEE.std_logic_1164.ALL;
--------------------------------------------------------------------------------
PACKAGE modules_pkg IS
--------------------------------------------------------------------------------
COMPONENT sync_data_1b
PORT(
sig_async : IN STD_LOGIC; -- signal in original clock domain
clk : IN STD_LOGIC; -- target clock domain
sig_sync : OUT STD_LOGIC); -- signal synchronized to target clock domain
END COMPONENT;
------------------------------------------------------------------------------
COMPONENT sync_data
GENERIC(
data_width : INTEGER := 8);
PORT(
sig_async : IN STD_LOGIC_VECTOR( (data_width-1) DOWNTO 0); -- async signal
clk : IN STD_LOGIC; -- target clock domain
sig_sync : OUT STD_LOGIC_VECTOR( (data_width-1) DOWNTO 0)); -- synced signal
END COMPONENT;
--------------------------------------------------------------------------------
END modules_pkg;
--------------------------------------------------------------------------------

page 113 kubicek@vutbr.cz


VHDL – packages

Custom packages in the code


--------------------------------------------------------------------------------
library IEEE;
use IEEE.std_logic_1164.ALL;
use IEEE.numeric_std.ALL;
use WORK.param_pkg.ALL;
use WORK.modules_pkg.ALL;
--------------------------------------------------------------------------------
ENTITY Inerlink_interface IS
PORT(
CLK_FPGA_P : IN STD_LOGIC;
CLK_FPGA_N : IN STD_LOGIC;

Interlink_DATA_i : IN STD_LOGIC_VECTOR( C_BUS_WIDTH-1 DOWNTO 0);


Interlink_DATA_o : OUT STD_LOGIC_VECTOR( C_BUS_WIDTH-1 DOWNTO 0);
...
END Inerlink_interface;
--------------------------------------------------------------------------------
ARCHITECTURE Behavioral OF Inerlink_interface IS
--------------------------------------------------------------------------------

SIGNAL Interlink_data_in : STD_LOGIC_VECTOR( C_BUS_WIDTH-1 DOWNTO 0);


SIGNAL Interlink_data_out : STD_LOGIC_VECTOR( C_BUS_WIDTH-1 DOWNTO 0);
...
--------------------------------------------------------------------------------

page 114 kubicek@vutbr.cz


VHDL records

page 115 kubicek@vutbr.cz


VHDL records

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;

page 116 kubicek@vutbr.cz


VHDL records

RECORDS
TYPE t_data_interface IS
RECORD
data : STD_LOGIC_VECTOR(15 DOWNTO 0);
data_valid : STD_LOGIC;
data_error : STD_LOGIC);
END RECORD;

SIGNAL DATA_ADC_1 : t_data_interface;


...
DATA_ADC_1.data <= X"0000";
DATA_ADC_1.data_valid<= '0';
DATA_ADC_1.data_error <= '1';
...
DV_1_OUT <= DATA_ADC_1.data_valid;
...

IF DATA_ADC_1.data_error = '1' THEN...

page 117 kubicek@vutbr.cz


VHDL records

RECORDS are suitable for entities with large


RECORDS number of signals propagating through many
ENTITY MAC_core IS
PORT(
clk : IN STD_LOGIC;
levels of design hierarchy.
rst : IN STD_LOGIC;

GTP_0_AN_irq : OUT STD_LOGIC;


GTP_1_AN_irq : OUT STD_LOGIC;
GTP_2_AN_irq : OUT STD_LOGIC;
GTP_3_AN_irq : OUT STD_LOGIC;

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;

STD_LOGIC_VECTOR( 4 DOWNTO 0);


HOST_reg_addr_H : IN STD_LOGIC_VECTOR( 7 DOWNTO 0);
GTP_1_cfg_vect
GTP_2_cfg_vect
GTP_3_cfg_vect
:
:
:
IN
IN
IN
STD_LOGIC_VECTOR(
STD_LOGIC_VECTOR(
STD_LOGIC_VECTOR(
4
4
4
DOWNTO
DOWNTO
DOWNTO
0);
0);
0);
HOST_reg_data_wr_0 : IN STD_LOGIC_VECTOR( 7 DOWNTO 0);
GTP_0_cfg_vect_valid
GTP_1_cfg_vect_valid
:
:
IN
IN
STD_LOGIC;
STD_LOGIC;
HOST_reg_data_wr_1 : IN STD_LOGIC_VECTOR( 7 DOWNTO 0);
GTP_2_cfg_vect_valid
GTP_3_cfg_vect_valid
:
:
IN
IN
STD_LOGIC;
STD_LOGIC; HOST_reg_data_wr_2 : IN STD_LOGIC_VECTOR( 7 DOWNTO 0);
GTP_0_AN_adv_cfg_vect
GTP_1_AN_adv_cfg_vect
GTP_2_AN_adv_cfg_vect
:
:
:
IN
IN
IN
STD_LOGIC_VECTOR(15
STD_LOGIC_VECTOR(15
STD_LOGIC_VECTOR(15
DOWNTO
DOWNTO
DOWNTO
0);
0);
0);
HOST_reg_data_wr_3 : IN STD_LOGIC_VECTOR( 7 DOWNTO 0);
GTP_3_AN_adv_cfg_vect

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;

HOST_sel : IN STD_LOGIC_VECTOR( 1 DOWNTO 0);


HOST_stat_ctrl_in : IN STD_LOGIC_VECTOR( 7 DOWNTO 0);
HOST_reg_addr_L : IN STD_LOGIC_VECTOR( 7 DOWNTO 0);
HOST_reg_addr_H : IN STD_LOGIC_VECTOR( 7 DOWNTO 0);
HOST_reg_data_wr_0 : IN STD_LOGIC_VECTOR( 7 DOWNTO 0);
HOST_reg_data_wr_1 : IN STD_LOGIC_VECTOR( 7 DOWNTO 0);
HOST_reg_data_wr_2 : IN STD_LOGIC_VECTOR( 7 DOWNTO 0);
HOST_reg_data_wr_3 : IN STD_LOGIC_VECTOR( 7 DOWNTO 0);
END MAC_core;

page 118 kubicek@vutbr.cz


VHDL records

RECORDS one RECORD: all the outputs

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_status_vect : STD_LOGIC_VECTOR(15 DOWNTO 0);


GTP_1_status_vect : STD_LOGIC_VECTOR(15 DOWNTO 0);
GTP_2_status_vect : STD_LOGIC_VECTOR(15 DOWNTO 0);
GTP_3_status_vect : STD_LOGIC_VECTOR(15 DOWNTO 0);

HOST_stat_ctrl_out : STD_LOGIC_VECTOR( 7 DOWNTO 0);


HOST_reg_data_rd_0 : STD_LOGIC_VECTOR( 7 DOWNTO 0);
HOST_reg_data_rd_1 : STD_LOGIC_VECTOR( 7 DOWNTO 0);
HOST_reg_data_rd_2 : STD_LOGIC_VECTOR( 7 DOWNTO 0);
HOST_reg_data_rd_3 : STD_LOGIC_VECTOR( 7 DOWNTO 0);
END RECORD;

page 119 kubicek@vutbr.cz


VHDL records

RECORDS second RECORD: all the inputs


(except CLK and RST)
TYPE t_MAC_core_IN IS
RECORD
rst_MAC_0 : STD_LOGIC;
rst_MAC_1 : STD_LOGIC;
rst_MAC_2 : STD_LOGIC;
rst_MAC_3 : STD_LOGIC;
TYPE t_MAC_core_IN IS
rst_PCS_PMA_0 : STD_LOGIC;
rst_PCS_PMA_1
rst_PCS_PMA_2
:
:
STD_LOGIC;
STD_LOGIC;
RECORD
rst_PCS_PMA_3 : STD_LOGIC;
rst_MAC_0 : STD_LOGIC;
rst_GTP_0 : STD_LOGIC;
rst_GTP_1
rst_GTP_2
:
:
STD_LOGIC;
STD_LOGIC;
rst_MAC_1 : STD_LOGIC;
rst_MAC_2 : STD_LOGIC;
rst_GTP_3 : 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 : STD_LOGIC_VECTOR( 4 DOWNTO 0);


GTP_1_cfg_vect
GTP_2_cfg_vect
:
:
STD_LOGIC_VECTOR(
STD_LOGIC_VECTOR(
4
4
DOWNTO
DOWNTO
0);
0); .....
GTP_3_cfg_vect : STD_LOGIC_VECTOR( 4 DOWNTO 0);

GTP_0_cfg_vect_valid : STD_LOGIC;

HOST_reg_data_wr_1 : STD_LOGIC_VECTOR( 7 DOWNTO 0);


GTP_1_cfg_vect_valid : STD_LOGIC;
GTP_2_cfg_vect_valid : STD_LOGIC;
GTP_3_cfg_vect_valid : STD_LOGIC;

GTP_0_AN_adv_cfg_vect : STD_LOGIC_VECTOR(15 DOWNTO 0); HOST_reg_data_wr_2 : STD_LOGIC_VECTOR( 7 DOWNTO 0);


GTP_1_AN_adv_cfg_vect : STD_LOGIC_VECTOR(15 DOWNTO 0);
GTP_2_AN_adv_cfg_vect
GTP_3_AN_adv_cfg_vect
:
:
STD_LOGIC_VECTOR(15
STD_LOGIC_VECTOR(15
DOWNTO
DOWNTO
0);
0);
HOST_reg_data_wr_3 : STD_LOGIC_VECTOR( 7 DOWNTO 0);
GTP_0_AN_adv_cfg_vect_valid : STD_LOGIC; END RECORD;
GTP_1_AN_adv_cfg_vect_valid : STD_LOGIC;
GTP_2_AN_adv_cfg_vect_valid : STD_LOGIC;
GTP_3_AN_adv_cfg_vect_valid : STD_LOGIC;

HOST_sel : STD_LOGIC_VECTOR( 1 DOWNTO 0);


HOST_stat_ctrl_in : STD_LOGIC_VECTOR( 7 DOWNTO 0);
HOST_reg_addr_L : STD_LOGIC_VECTOR( 7 DOWNTO 0);
HOST_reg_addr_H : STD_LOGIC_VECTOR( 7 DOWNTO 0);
HOST_reg_data_wr_0 : STD_LOGIC_VECTOR( 7 DOWNTO 0);
HOST_reg_data_wr_1 : STD_LOGIC_VECTOR( 7 DOWNTO 0);
HOST_reg_data_wr_2 : STD_LOGIC_VECTOR( 7 DOWNTO 0);
HOST_reg_data_wr_3 : STD_LOGIC_VECTOR( 7 DOWNTO 0);
END RECORD;

page 120 kubicek@vutbr.cz


VHDL records

RECORDS The resulting entity declaration

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.

page 121 kubicek@vutbr.cz


VHDL records

RECORDS Significantly simplified and much more readable


component declaration and instantiation
COMPONENT MAC_core
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 COMPONENT;
.....

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);

page 122 kubicek@vutbr.cz


VHDL records

RECORDS Significantly simplified and much more readable


component declaration and instantiation
.....
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);
....

Access to signals included in RECORD:

MAC_core_IN_2.rst_MAC_0 <= rst_MAC_2_0;

MAC_2_GTP_0_AN_irq <= GTP_0_AN_irq. MAC_core_OUT_2;

page 123 kubicek@vutbr.cz


Attributes

page 124 kubicek@vutbr.cz


VHDL – Attributes

Attributes
❑ Provide access to object parameters
❑ Included in VHDL language definition
❑ Very useful for writing generic code

page 125 kubicek@vutbr.cz


VHDL – Attributes

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;

page 126 kubicek@vutbr.cz


VHDL

File handling
(TBD)

strana 127 kubicek@vutbr.cz


VHDL

Functions and procedures


(TBD)

strana 128 kubicek@vutbr.cz


Thank You for Your Attention!

You might also like