ΗΜΥ 408 ΨΗΦΙΑΚΟΣ ΣΧΕΔΙΑΣΜΟΣ ΜΕ fpgas Εαρινό … 9- fpga.pdf · both...

ΗΜΥ408 Δ09 FPGA IP Cores & Video.1 © Θεοχαρίδης, ΗΜΥ, 2016

ΗΜΥ 408 ΨΗΦΙΑΚΟΣ ΣΧΕΔΙΑΣΜΟΣ ΜΕ

FPGAs Εαρινό Εξάμηνο 2016

IP Cores & Video

ΧΑΡΗΣ ΘΕΟΧΑΡΙΔΗΣ

Επίκουρος Καθηγητής, ΗΜΜΥ ([email protected])


Design Process Steps (Review)

Definition of system requirements. Example: ISA (instruction set architecture) for CPU. Includes software and hardware interfaces including timing. May also include cost, speed, reliability and maintainability

specifications.

Definition of system architecture. Example: high-level HDL (hardware description language)

representation - this is not required in ECE 664 but is done in the real world).

Useful for system validation and verification and as a basis for lower level design execution and validation or verification.



Refinement of system architecture In manual design, descent in hierarchy, designing increasingly

lower-level components In synthesized design, transformation of high-level HDL to

“synthesizable” register transfer level (RTL) HDL

Logic design or synthesis In manual or synthesized design, development of logic design in

terms of library components Result is logic level schematic or netlist representation or

combinations of both. Both manual design or synthesis typically involve optimization of

cost, area, or delay.



Implementation Conversion of the logic design to physical implementation Involves the processes of:

Mapping of logic to physical elements, Placing of resulting physical elements, And routing of interconnections between the elements.

In case of SRAM-based FPGAs, represented by the programming bitstream which generates the physical implementation in the form of CLBs, IOBs and the interconnections between them



Validation (used at number of steps in the process) At architecture level - functional simulation of HDL At RTL level- functional simulation of RTL HDL At logic design or synthesis - functional simulation of gate-level

circuit - not usually done in ECE 408/664 At implementation - timing simulation of schematic, netlist or

HDL with implemention based timing information (functional simulation can also be useful here)

At programmed FPGA level - in-circuit test of function and timing


Hardware design in general

Logic (RTL) design Logic simulation Logic debugging

RTL code (Verilog)

Placement & routing

Timing simulation

Timing analysis

Netlist & Gate delay

(SDF) GDSII

Semiconductor fabrication GDSII & Test-vector

Logic synthesis

Gate-level simulation

Gate-level debugging

Netlist (EDIF)

RTL code & Target library

Logic synthesis

Placement & routing FPGA

bit-stream RTL code &

FPGA library

FPGA BOARD

FPGA Debugging

Logic synthesis RTL compilation

Placement & routing

H/W Platform

General Hardware Design Flow / Methodologies.


Xilinx HDL/Core Design Flow

DESIGN ENTRY

CORE GENERATION RTL HDL EDITING

RTL HDL-CORE SIMULATION

SYNTHESIS

IMPLEMENTATION

TIMING SIMULATION

FPGA PROGRAMMING & IN-CIRCUIT TEST


Xilinx HDL/core Design Flow – Core Generation

CORE GENERATOR

Select core and specify input parameters

HDL instantiation module for core_name

EDIF netlist for core_name

Other core_name files


Xilinx HDL/core Design Flow - HDL Functional Simulation

Compile HDL Files

Waveforms or List Files

Set Up and Map work library RTL HDL Files

Test Inputs or Force Files

HDL instantiation module for core_name

EDIF netlists for core_names

Functional Simulate

Testbench HDL Files

HDLSIMULATOR


All HDL Files

Gate/Primitive Netlist Files (EDIF or XNF)

Xilinx HDL Design Flow - Synthesis

Select Top Level

Select Target Device

Edit XST Synthesis Constraints

Synthesize

Synthesis/Implement-ation Constraints

Synthesis Report Files

EDIF netlists for core_names

XST


Model Extraction

Xilinx HDL/core Design Flow - Implementation

Netlist Translation

Map

Place & Route

BIT File

Create Bitstream

Timing Model Gen

Gate/Primitive Netlist Files (XNF or EDN)

Standard Delay Format File

HDL or EDIF for Implemented Design

XILINX DESIGN MANAGER


Xilinx HDL/core Design Flow- Timing Simulation

Test Inputs, Force Files

MODELSIM

Compile HDL Files

Waveforms or List Files

Set Up and Map work Directory

Compiled HDL

HDL Simulate

Standard Delay Format File HDL or EDIF for Implemented Design

Testbench HDL Files


Xilinx HDL Design Flow - Programming and In-circuit Verification

Bit File

FPGA Board

iMPACT

I/O Port

Input Byte

Human Inputs

Outputs


The Xilinx Libraries

Useful only if you have to instantiate (in your HDL) Xilinx primitives or macros (not all can be instantiated) from the Libraries guide.

Note selection guide includes CLB counts and section at front on notation used to describe macros.


Design Practices Use synchronous design.

CLBs are actually reading functions from SRAM! Avoid clock gating. Avoid ripple counters. Avoid use of direct sets and resets except for initialization. Synchronize asynchronous signals as needed. Study timing issues handout.


System Design Trend

Tens to hundreds of chips

Chip-set

Single chip

Integration

Complexity


Traditional System Design

Chip Vendor

Chip Vendor

Custom ASIC

Reuse Integration


How to Implement The SoC?

SoC Core Provider

IP (Intellectual Property)

Reuse

Integration


Design Technology Status Problems * Productivity gap * Shorter time-to-market * Designer shortage Solutions * Higher levels of abstraction * New reuse methodology * New business model


Why Do We Need Reuse?

Reuse practice is everywhere

It has been a common practice in software developments for years.

It has been a common practice in electronic product developments for years.

=> Goal: makes our life easier!!!


Reuse in Software Development

Software

Procedure

Function

Reuse

Reduce program complexity Increase manageability

Package


Reuse in Chip Design

RTL/Logic Library

Cell Library AND

OR Layout

RTL/Logic schematic

ALU

AND Reuse


What are IPs (VCs)?

IP = Intellectual Property.

VC = Virtual Component.

Soft IP: synthesizable HDL description.

Firm IP: gate-level netlist.

Hard IP: silicon block.


IP Reuse for SOC Design

IP1

IP2 ASIC

IP1

Intellectual Property (IP) Virtual Component (VC)

Virtual Socket Interface(VSI)


IP-Centric System Design Model

System design division

System/IPs In-house core providers

Reuse

IP provider IP provider


IP Business Model

IP Tool Developer

IP Provider

IP Business

IP Integrator


Essential Issues for IP Reuse

Essential Issues for IP Reuse

IP Provider IP Business IP Integrator

Library Documentation

Quality Assurance Standardization

Service

Business Model Legal Issues

Security

Exploration Integration

Methodology & Environment

Standardization

IP Tools


Three Approaches for System Design

Platform-based.

Core-based.

Synthesis-based.

CU DP

Processor Memory I/O

Cores

IP

IP Core Glue


System Integration Issues

Platform to evaluate various VC blocks to make their choices and to integrate the blocks for their design verification.

To verify the hardware design at system level, designers need to co-simulate or co-emulate the design flow using different computational models.

Debugging and diagnosis environment to support system integration.


System Integration Issues (Cont’d)

Verification methodologies supporting multi-level design process.

Multi-level design models - accuracy and consistency.

Multiple design teams are formed to work on specific parts of the design.

It’s very difficult to develop realistic and comprehensive test benches.


System Integration Issues (Cont’d)

Functional and architectural level modeling should be used extensively for system function definition and architectural trade-offs.

Interface timing errors between subsystems (IPs) increase dramatically.

Experiencing multiple design iterations and/or respins due to functional bugs.

Pre-existing IP may need to be constantly redesigned.


Design Flow for System Design

Application spec.

Analysis System-level synthesis

Software spec.

Code generation

Object code

Hardware spec.

System integration

Verification


Design Tasks

Definition of system-level design specification (C-based, HDLs).

Design evaluation and exploration. Hardware/software codesign. Co-verification: co-simulation and co-emulation. Debugging and diagnosis. Rapid prototyping.


Reuse Complex IPs/Cores with an RTL Design Flow

RTL Spec

RTL/Logic Synthesis

Netlist

RTL Comp. Library

Cell-based Library

Complex Core Lib.

How???


Core-based IP Integration Methodology

High-level Spec

RTL/Logic Synthesis

Netlist

RTL Comp. Library

Cell-based Library

Complex Core Lib.

High-level Synthesis

Automatically reuse complex macros/cores

Design exploration

RTL Spec


How to Reuse a Core?

VCR Operating procedure

Cores ???

Usage (Interface)


Usable-Function

C <= A + B S0 + [8]

in1 in2

out

ci co

A[8] B[8]

C[8]

+ [8]

in1 in2

out

ci co

A[16] B[16]

C[16]

co, C[0:7] <= A[0:7]+B[0:7]

C[8:15] <= A[8:15]+B[8:15]+co

S0

S1

8-bit addition 16-bit addition


Usable-Function (Cont’d)

+ [8]

in1 in2

out

ci co

A[8] B[8]

C[16]

CNT<=8; Q<=B; P<=0;

Q(0)= “1”

Q(0)= “0” P <= P + A

P & Q >> “1”; CNT<=CNT-1;

C <= P & Q

CNT<>”0”

S0

S1

S2

S3

S4

8X8 multiplication


Usage-based Core Database

Core

Control interface 1

Control interface n

Usable Function 1

Usable Function n

8-bit adder 8-bit

addition

8X8 multiplication


Core-based Synthesis Flow

High-level Design Spec.

Compilation

Core Selection and Exploration

Allocation, Inference, and Instantiation Of Cores

Interface Generation

Design Integration

RTL Design


Design Exploration

Core

IP

IP

IP

Core

Core

Which IPs/cores I should reuse??? What is the design cost and performance by reusing these IPs/cores???


The IP/Core Reuse Story Several years ago semiconductor industry raised the productivity

crisis in the forthcoming SoC era.

Intuitively, integrate existing designs to form an SoC design can bridge the productivity gap.

IP-business and SoC design approaches have been emerged in semiconductor industry.

Many ASIC design houses/divisions try to re-packaging their existing designs into IPs/Cores.

Many system design houses start to investigate the SoC design methodology.


Current Status on IP Reuse Many system companies tried IP-reuse but not very successful due to

the following reasons:

=> Complex contract negotiation process

=> inadequate quality assurance from the IP providers that often results in failed projects

=> Designers’ resistance to adopt reuse guideline

On the IP business side:

=> Many so-called 3rd-party IP providers are gone.

=> A small business venue (417M/1999, 51% revenue are dominated by three big players: ARM, MIPS, and RamBus).


Designers’ Perspective on Reuse Should I reuse some existing IPs/cores or just design them starting

from scratch?

The main goal for IP/core reuse is to minimize the overall design effort and thus speed up the time-to-market.

How to justify whether “reuse” will be benefit to my design project?

What’s designers’ main concerns on the “reuse” practice?

=> If I can fully control my own destiny, I will reuse some IPs for my design!!! The problem is who can give me such guarantee???


Designers’ Technical Concerns on IP Reuse

Is the IP source (provider) reliable?

How can I make sure the functional correctness of the IP?

How much effort do I have to invest in test-bench development for design verification with reused IP?

What if I need to modify part of IP design?

What if the final timing is not satisfied due to the IP?

What’s the risk of the design project due to any possible defect caused by the IP?

What’s the worst scenario when reuse the IP and what are the damage control plan?


Designers’ Concerns on Legacy-Core Development and Reuse

Take too much effort to develop a reusable core:

=> “I have my dead-line to meet!”

=> “What’s my incentive to develop a reusable core!”

It’s difficult to reuse a legacy core, if

=> the documentation is incomplete (the original core was not developed for the reuse purpose)

=> the original core designer is gone

=> the original core has known problems or bugs (it will be much easier to redesign it than reuse it)


SoC Design Issues Management and culture change

Design methodology issues

Wide-spread IP reuse and exchange may be a long way to go

Most today’s IPs are unusable, but IP reuse is necessary for SoC designs

IP development strategy for easy-reuse needs to be studied further

SoC design methodology needs to be studied further


Understand SoC and IPs

SoC

System

Hardware Software

OS Application Processors Memories

IOs

Consumer Wireless

Set-top box PDA ……

ASICs


Understand SoC and IPs (Con’t) Systems define IPs not IPs define the system!!! From systems’ point of views, the basic IPs include: => Hardware IPs -> Processor-cores -> Memories -> IOs -> ASICs => Software IPs -> OS -> Application


Concerns!!! “There is no viable RTL market for IP. There just is no business” –

Gary Smith Chief Analyst, Dataquest “IP that is designed in at the RTL stage is not successful. To be

successful, it has to be designed in at the system level” – Gary Smith “We have spent so much time evaluating purchased IP cores and we

have concluded that it would be better use of engineering hours to develop the blocks in-house” – Steve Shulz, TI

“Verifying IPs is absolute nightmare. It’s really hard. We don’t trust anything we get – we verify the hell out of everything.” “IP has no self-life without support.” – Vig Sherrill, ASIC International


SoC and IPs (Con’t) The quality of IPs and support will be the key to the success of the

IP business

Need to pay much attention on software IP issues

Need application and system design expertise

Core-based design is effective on IP/core integration

Need to develop a combining platform- and core-based design methodology/environment for system designs


Behavioral Simulation

CORE Generator

Synthesis

Implementation

Download

Functional Simulation

Timing Simulation

In-Circuit Verification

HDL COREGen

Instantiate optimized IP within the HDL code


Behavioral Simulation

Synthesize, Implement, Download Design Verification

Synthesis

Implementation

Download

Functional Simulation

Timing Simulation

In-Circuit Verification

HDL COREGen

Synthesize, Implement, and Download the bitstream, similar to the original design flow


Xilinx CORE Generator

List of available IP from or

Fully Parameterizable


IP CENTER http://www.xilinx.com/ipcenter

$P Reed Solomon $3GPP Turbo Code $P Viterbi Decoder $P Convolution Encoder $P Interleaver/De-interleaver P LFSR P 1D DCT P DA FIR P MAC P MAC-based FIR filter Fixed FFTs 16, 64, 256, 1024 points P FFT - 32 Point P Sine Cosine P Direct Digital Synthesizer P Cascaded Integrator Comb P Bit Correlator P Digital Down Converter

P Asynchronous FIFO P Block Memory modules P Distributed Memory P Distributed Mem Enhance P Sync FIFO (SRL16) P Sync FIFO (Block RAM) P CAM (SRL16)

P Binary Decoder P Two's Complement P Shift Register RAM/FF P Gate modules P Multiplexer functions P Registers, FF & latch based P Adder/Subtractor P Accumulator P Comparator P Binary Counter

P Multiplier Generator - Parallel Multiplier - Dyn Constant Coefficient Mult - Serial Sequential Multiplier - Multiplier Enhancements P Divider P CORDIC Base Functions

$P PCI 64/66 $PS PCI 32/33 $P PCI-X 64/66

8B/10B Encoder/Decoder $ POS-PHY L3 $ POS-PHY L4 $ Flexbus 4 $ RapidIO PHY Layer $S HDLC 1 and 32 channel $S G.711 PCM Cores $S ADPCM 32 & 64 channel

Memory Functions DSP Functions

PCI

Math Functions

Networking

$ - License Fee, P - Parameterized, S - Project License Available, BOLD – Available in the Xilinx Blockset for the System Generator for DSP

Xilinx IP Solutions: Core Gen


Core Generator: Summary

CORE Generator Advantages

Can quickly access and generate existing functions No need to reinvent the wheel and re-design a block if it meets

specifications IP is optimized for the specified architecture

Disadvantages IP doesn’t always do exactly what you are looking for Need to understand signals and parameters and match them to your

specification Dealing with black box and have little information on how the function is

implemented


Relative Placement

Other logic has no effect on the core

Fixed Placement & Pre-defined Routing

Guarantees Performance

Guarantees I/O and Logic Predictability

Fixed Placement I/Os

Xilinx Smart-IP Technology

200 MHz

200 MHz

200 MHz

Core Placement Number of Cores Device Size

200 MHz

Pre-defined placement and routing enhances performance and predictability

Performance is independent of:


On-Chip Verification

Control

USER FUNCTION

ILA

USER FUNCTION

USER FUNCTION

ILA

ILA

Chipscope ILA

PC running ChipScope

MultiLINX Cable or Parallel Cable III

JTAG Connection

Target Board

Target FPGA with ILA cores

JTAG

ChipScope ILA System Diagram


CoreGenerator

Use in lab 4 at your own responsibility/risk!

Useful in creating modules such as memory, FIFO queues, custom arithmetic modules, etc.

Start by creating a new project in CoreGenerator, or a new CoreGenerator module in Xilinx ISE.

Make sure your FPGA specs are fed into the CoreGenerator project properties!!!

Once you specify the targeted FPGA, then you can browse through the components.


Core Generator Start Window


Project Properties


IP Blocks


IP Customizer (Single Port Block Memory)


Page 2


Page 3


Page 4


Memory Editor


VGA Controller – Basic Video Output Processing

Supplementary Lecture on Video Handling


Dots to a Picture Brain can make this into something recognizable

Images from howstuffworks.com


Many Still Images Video (and movies) are a series of stills

If it goes fast enough 50-60 Hz or more to not see flicker

Your brain interprets as moving imagery

Electron beam scans across

Turned off when Scanning back to the left (horizontal retrace) Scanning to the top (vertical retrace)


Simple Scanning TV


Scanning TVs use interlacing

Every other scan line is swept per field Two fields per frame (30Hz) Way to make movement less disturbing

Computers use progressive scan Whole frame refreshed at once 60Hz or more, 72Hz looks better


VGA Timing You supply two pulses, hsync and vsync, that let the monitor lock onto

timing

One hsync per scan line

One vsync per frame

Image from dell.com


Horizontal Timing Terms hsync pulse

Back porch (left side of display)

Active Video Video should be blanked (not sent) at other times

Front porch (right side)


Standards 640 x 480 (60Hz) is “VGA”

You can also try for 800x600 at 60 Hz (40 MHz exactly)

or 800x600 at 72 Hz (50 MHz exactly)


Color Depth Example with Spartan-II

Voltage of each of RGB determines color

2-bit color here (4 shades)

Turn all on for white


PC Display Standards Monochrome Display Adapter (MDA)

Earliest display system for IBM PCs Text-only – 80x25 characters, each character is 9x14 pixels Effective resolution 720x350 @ 50 Hz, but pixels not individually addressable

IBM provided extra characters in its character set that allowed primitive graphics (boxes, lines, etc.) to be “drawn” in MDA

Hercules Graphics Card Third-party system, adds monochrome graphics to MDA text

Color Graphics Adapter (CGA) First mainstream color system for IBM PC Text up to 80x25, graphics range from 640x200 in monochrome to 160x200 in

16 colors Text displayed with lower quality than MDA (8x8 pixels/char)


PC Display Standards Enhanced Graphics Adapter (EGA)

16 colors out of palette of 64 at 640x350, 80x25 text at 60 Hz Minimum requirement for Windows 3.x

Video Graphics Adapter (VGA) Last really accepted standard defined by IBM (consequence of IBM

losing control of the “PC”) 256 colors at 320x200, 16 colors at 640x480 Not 256 colors at 640x480, even though that’s what most people accept

when they say “VGA Resolution”

Super VGA and other formats Much less well-defined VESA standards developed for software compatibility between

different cards


Back porch Front porch

Back porch


Horizontal Timing

Pixel clock = 25 MHz Pixel time = 0.04 µs Horizontal video = 640 pixels x 0.04 µs = 25.60 µs Back porch, BP = 16 pixels x 0.04 µs = 0.64 µs Front porch, FP = 16 pixels x 0.04 µs = 0.64 µs Sync pulse, SP = 128 pixels x 0.04 µs = 5.12.µs Horizontal Scan Lines = SP + BP + HV + FP = 128 + 16 + 640 + 16 = 800 pixels x 0.04 µs = 32 µs 1/60 Hz = 16.67 ms / 32 µs = 521 horizontal scan lines per frame

Horizontal VideoBP FP

SP

HS

Horizontal Scan Lines

144 784


Vertical Timing

Vertical VideoBP FP

SP

VS

Vertical Scan Lines

Pixel clock = 25 MHz Horizontal scan time = 32 µs Vertical video = 480 lines x 32 µs = 15.360 ms Back porch, BP = 29 lines x 32 µs = 0.928 ms Front porch, FP = 10 lines x 32 µs = 0.320 ms Sync pulse, SP = 2 lines x 32 µs = 0.064 ms Vertical Scan Lines = SP + BP + VV + FP = 2 + 29 + 480 + 10 = 521 lines x 32 µs = 16.672 ms 1/60 Hz = 16.67 ms

31 511


How to Make the Video Work!

Basically, driving a VGA display involves doing the video decoder operation in reverse.

Start with a digital representation of the image

Hardware (video DAC) converts digital pixels into analog voltages used by the monitor Different display standards have used either analog or digital

signals in the past

Your hardware has to drive the control signals to the display and provide pixel values at the right rate DAC just does conversion


VGA Timing


General Operation Operation

See datasheet and manual* for supported modes

You are responsible for managing the timing of the VGA signal Clock rate/time per line will give you the max number of pixels/line

you can drive Number of lines on the screen determined by ratio of time/frame

and time/screen FPGA has to drive HSYNC and VSYNC signals directly

You are strongly advised to read chapter 6 from the Spartan-3E 1600E User Guide


Driving the VGA Chip

CLK used to latch input registers

24-bit pixel input bus carries color of each pixel

BLANK* signal specifies blanking interval Assert this, don’t just drive a color that should be black

SYNC* inserts sync pulse on IOG output Does not override any other data Use only during blanking interval


Making VGA Work 1. You may start with say an 8 bit per pixel image (see below).

2. Generate an image in the appropriate 8-bit format • For video capture, you could use an 8-bit RGB spectrum, with 3 bits of

red, 3 of green, and 2 of blue (human eyes are less sensitive to blue) • Previously, students reported they’d found routines to convert an RGB

image into 8-bit format and generate the optimal palette for that image

3. Drive the image pixels to the DAC with appropriate timing signals


Reference Designs http://www.xilinx.com/products/boards/s3estarter/reference_designs.ht

m

SEARCH THE INTERNET – GOOGLE IS YOUR FRIEND


VGA Timing


VGA Generation


Example…


Links VGA Timing

http://www.epanorama.net/documents/pc/vga_timing.html http://appsrv.cse.cuhk.edu.hk/~ceg3480/Tutorial7/tut7.doc

Code (more complex than you want) http://www.stanford.edu/class/ee183/index.shtml

Interesting http://www.howstuffworks.com/tv.htm http://computer.howstuffworks.com/monitor.htm http://www.howstuffworks.com/lcd.htm http://plc.cwru.edu/ Liquid Crystals by S. Chandrasekhar, Cambridge Univ. Press

http://server.oersted.dtu.dk/personal/sn/31002/?Materials/vga/main.html (Really Good VHDL)

http://www.epanorama.net/documents/pc/vga_timing.html

http://appsrv.cse.cuhk.edu.hk/~ceg3480/Tutorial7/tut7.doc

http://www.stanford.edu/class/ee183/index.shtml

http://www.howstuffworks.com/tv.htm

http://computer.howstuffworks.com/monitor.htm

http://www.howstuffworks.com/lcd.htm

http://plc.cwru.edu/

http://server.oersted.dtu.dk/personal/sn/31002/?Materials/vga/main.html

http://server.oersted.dtu.dk/personal/sn/31002/?Materials/vga/main.html

ΗΜΥ 408 ΨΗΦΙΑΚΟΣ ΣΧΕΔΙΑΣΜΟΣ ΜΕ fpgas Εαρινό … 9- fpga.pdf · both...

Documents