Unit 10: Integration and Verification - Linköping University and... · Unit 10: Integration and Verification - Linköping University ... rtl

by Dake Liu: [email protected]© Copyright of Linköping University, all rights reserved ®

10/3/2017 Unit 10 of TSEA26 – 2017 –H1 1

Design of Embedded DSP

Processors

Unit 10: Integration and

Verification

mailto:[email protected]


10/3/2017 Unit 10 of TSEA26 – 2017 –H1 2

Three integrations1. Hardware integration (Integration of

RTL codes)

2. Integration of the behavior model

(the simulator)

3. Phy integration (HW protocol, clock

/power domains, and critical paths)



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 3

Contents

1. Integration of an IP core

2. Integration of SoC

3. Introduction to verification

4. Write testbench



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 4

Integration of a

(processor) core



Some cores are complicated

10/3/2017 For teachers use the book 5

A power core



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 6

Some cores are simple

ALU

MAC

AG

U

accelerator PM

Control path

PC

FS

M

Inst

ruct

ion

dec

od

er

RF

DM

s

Datapath

Addressing path

mem subsystem

Memory bus Register bus Control signals

Integrate datapath, data access, accelerators, and control path into a core



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 7

It is not just connections

1. Functional: Be sure all instructions can be executed

– with available HW and connections, no structural hazard

– Reachable: All special registers/ports can be accessed

2. Structural: HW arch follows the instruction-set

– Combinational: bus matches, width, endian, direction

– Sequential: pipeline modification and balancing

3. Physical: speed, power consumption, silicon cost

– New hidden critical path, unnecessary toggling or even

bugs after integration (missing keeper, missing default).

– Clock and power domains

SoC

Micro arc

RTL

layout

behavior

function structure

physical



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 8

E.g. integration for move/load/store

DM0: Data

memory 0

DM1: Data

memory 1 General

register file

Special registers

in AGU

Accumulator

register in MAC

Special registers

in control path

I/O port

registers

Immediate data

from control path

General RF to all, so that all are reachable via general RF



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 9

Move instructions based on busses

1. Should be a move instruction if a

connection is available

2. Move must be emulated if there

is no direct connection available



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 10

Emulate when there is no HW

Operation From To Emulation

Move DM0 DM1 Load DM0 to GRF; Store GRF to DM1

Move DM1 DM0 Load DM1 to GRF; Store GRF to DM0

Load I/O port DM1/0 Load I/O port to GRF; Store GRF to DM1/0

Store DM1/0 I/O port Load DM1/0 to GRF; Store GRF to I/O port

Load DM0 ACR Load DM0 to GRF; Move GRF to ACR (G,H,L)

Store ACR DM0 Move ACR (G,H,L) to GRF; Store GRF to DM0

Load DM1 ACR Load DM1 to GRF; Move GRF to ACR (G,H,L)

Store ACR DM1 Move ACR (G,H,L) to GRF; Store GRF to DM1

Load DM0/1 SRF Load DM0/1 to GRF; Move GRF to SRF

Store SRF DM0/1 Move SRF to GRF; Store GRF to DM0/1



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 11

Data Format Conversion While

Accessing ACR

Instruction Operation

Load ACR lower part ACR <= {ACR[39:16], Ra[15:0]}

Load ACR high part ACR <= { ACR[39:32], Ra[15:0]; ACR[15:0]}

Load ACR guard ACR <= { Ra[7:0], ACR[31:0]}

Load ACR high and guard ACR <= { {8{Ra[15]}}, Ra[15:0]; 16’b0}

Load ACR ACR<={ {8{Ra[15]}, Ra[15:0]; Rb[15:0]}

Store ACR higher part Rd <= ACR[31:16]

Store ACR lower part Rd <= ACR[15:0]

Store guard bits in ACR Rd [7:0] <= ACR[39:32]

Store result Rd<=Saturation (round(ACR[31:16]))



Integrate RF / ALU / MAC into a core

10/3/2017 Unit 10 of TSEA26 – 2017 –H1 12

• Operands and results

– Supply operands from memories and RF

– Shuffling multi operands to avoid conflicts

– Data forwarding for ALU, MAC, AGU

• Control signals

– Supply correct control signals at right time

– Manage critical path @ control signal fanout



Integrate control path into a core

10/3/2017 Unit 10 of TSEA26 – 2017 –H1 13

• Avoid structural hazard

– Sufficient availalbe HW or remove instructions

– Careful memory partition, pipeline shimming

• Avoid pipeline hazard

– Check all pipeline execution tables

– Check control signals arrive at right pipelines

• Controls for clock / Power gating



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 14

Be sure there is no missing (explicit

and hidden) function All micro-operations in an assembly instruction

Imp

licit

mic

ro-o

pera

tio

ns:

for

ex

am

ple

bu

s tr

an

sacti

on

s,

an

d i

nst

ructi

on d

ecod

ing

Explicit micro-operations specified in assembly manual:

Explicit micro-operations specified in assembly

code and binary machine code:

Implicit micro-

operations not

specified in

assembly code:

For example

flag ops and

PC<=PC+1

Data

mem

ory

ad

dre

ssin

g

Op

era

nd

s

Dest

inati

on

Op

era

tio

n

Ex

pli

cit

specif

iers

Targ

et

ad

dre

ssin

g



Sufficient exposes to SoC

1. Memory (mapped / addressed) I/O

2. Connection to interrupt controller and timer

3. DMA / memory interface design

4. Data input / output design

5. Design for program loading and POR

6. Host interface and SoC bus interface

7. Nonfunctional (DFT, debug, trace, gatings)

10/3/2017 Unit 10 of TSEA26 – 2017 –H1 15



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 16

Datapath physical integration

• Critical path in a function block (such as

MAC) and critical path in the core

– To simplify pipeline of a core, combinational pins

may exist between function blocks.

– Hidden critical path will be exposed, mostly are

“false path” – not existing in specification.

• What is and how to manage “false path”



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 17

Physical critical paths in DP

ACR1

ACR2

ACRm

ACRn

Guard and concatenate on inputs

A[15:0] B[15:0]

17x17 bits

multiplier

Signed B Unsigned B

Pipeline

0 1

Registers

…

…

Memory ports

…



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 18

Physical critical paths in DP

D-mem 1 D-mem 2 D-mem 3 D-mem 4 Constant RF OPA

32 to1

RF OPB

32 to1

Long wires Long wires

Very heavy fan out here!

Multiplier

signed unsigned

pipeline-op



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 19

Pipeline balancing

Moving functions between pipelines

Pre-processing’

Post-processing’

Kernel processing

Pre-processing

Post-processing

Kernel processing

(a) Before pipeline modification (b) After pipeline modification



10/3/2017 For teachers use the book 20

Kernel arithmetic component:

RA[17:0] <= {AA[16:0], 1’b1} + {AB[16:0], Carry_in}

A+B, A-B, B-A, A+1, B+1, A-1, B-1

AA

<=

OP

A

AB

<=

IN

V (

OP

B)

OPA <= {A[15], A[15:0]}; OPB <= {B[15], B[15:0]}

AA

<=

OP

A

AB

<=

OP

B

AA

<=

IN

V(O

PA

)

AB

<=

OP

B

AA

<=

OP

A, A

B <

= 1

AA

<=

1,

AB

<=

OP

B

AA

<=

OP

A, A

B <

= -

1

AA

<=

-1

, A

B <

= O

PB

SRA[15:0] <=

SAT (RA[17:1]) SRA [15:0]

<= RA[16:1]

yes

Carry and saturation flag

saturation

Finish

A+B, A-B, B-A, A+1, B+1, A-1, B-1

AA

<=

OP

A

AB

<=

IN

V (

OP

B)

OPA <= {A[15], A[15:0]}; OPB <= {B[15], B[15:0]}

AA

<=

OP

A

AB

<=

OP

B

AA

<=

IN

V(O

PA

)

AB

<=

OP

B

AA

<=

OP

A, A

B <

= 1

AA

<=

1,

AB

<=

OP

B

AA

<=

OP

A, A

B <

= -

1

AA

<=

-1

, A

B <

= O

PB

SRA[15:0] <=

SAT (RA[17:1]) SRA [15:0]

<= RA[16:1]

yes

Carry and saturation flag

saturation

Finish

Logic above for Pre-processing

Pipeline register

(a) (b)

Pipeline register

Kernel arithmetic component:

RA[17:0] <= {AA[16:0], 1’b1} + {AB[16:0], Carry_in}

Pip

elin

e b

alan

cin

g:

Mov

ing

fun

ctio

ns

bet

wee

n p

ipel

ines



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 21

Integrate

a DSP subsystem



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 22

A DSP subsystem

• Definition:

– A DSP subsystem (not yet a chip)

consists of one or several DSP cores,

data memories and program memories,

peripheral modules (interrupt controller,

DMA ctrl, timer, and main memory

interface), and accelerators



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 23

A DSP subsystem example BBP

MCU (the baseband controller)

Baseband connection network

Symbol processor

DFE

Symbol processor

Matrix

LLR

processor

FEC

processor

Host interface

Memory interface

ADC port

DAC port

Bit

processor

Symbol processor

FFT



The integration includes

10/3/2017 Unit 10 of TSEA26 – 2017 –H1 24

1. Functional: inter-core communication (data, ctrl)

– Data communication: use/not use system DDR

– Inter module FIFO, resource/memory sharing hardware

– Control semaphore: APB (flex)? custom design (quality)?

2. Structural: NoC IP or custom connections

– Combinational: Avoid inter-core combinational logic

– Sequential: convention: all latches are on the receiver side

3. Physical: OBS! Extra critical path! What to do?

– Add SoC pipelines, use communication / bus protocols,

GALS manage multi clock domains, clock/power gating



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 25

SoC

Integration



SoC definition

• Very confusing, most chips can be a SoC

• Several functional IP cores + IP modules +

controller as a master (run OS and main) +

on chip main memories + peripherals

• Could be even without a master (dataflow

processor) (NPU or GPU master can be in

another chip)

10/3/2017 Unit 10 of TSEA26 – 2017 –H1 26



A typical high-end SoC

• A smartphone chip from Qualcomm/MTK

– Include all RF + ADC + DAC + digital baseband +

ARM Application processor cluster with NEON +

Mali core + Rendering IP + ISP + video / audio

codec + GSM module + CDMA2000 module + WiFi

module + BT module + GPS module + AHB/CCI +

chip level cache + LPDDR controller/phy + LED

driver + MIPI controller/phy + USB controller/phy +

APB bridge + always-on + human peripherals + …...

10/3/2017 Unit 10 of TSEA26 – 2017 –H1 27



Oracle SPARC M7: A 20 nm 32-Core 64

MB L3 Cache 1TOPS Processor 2016

10/3/2017 Unit 10 of TSEA26 – 2017 –H1 28



A typical low-end SoC

• An IoT chip: Intel Edison

– dual-core Intel Quark x86 CPU, Bluetooth

module, WiFi module, ADC, DAC, UART

(connect to a micro USB), I2C (connect to

SD memory)

• A NB-IoT chip......

10/3/2017 Unit 10 of TSEA26 – 2017 –H1 29



Non-functional modules

• A module not for customer functions

• DFT: (ATPG, BIST, SoC, Boundary scan)

– What are that? Challenges (SoC test time)?

– DFT challenged by large combinational blocks

– DFT challenged by many memory blocks

• Trace

– Real time probing and buffering

• Power control module, clock gating module

10/3/2017 Unit 10 of TSEA26 – 2017 –H1 30



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 31

SoC of an embedded system

DSPs

L1: RF

PM DM1 DMn …

DP+CP

DMA I/F

MCU

L1: RF

PM DM1 DMn …

DP+CP

DMA I/F

Accelerators

PM DMn

DP+CP

DMA I/F

SoC connection network and its arbitration / routing / control

Main on-chip memory Off-chip DRAM Nonvolatile memory I/F I/F I/F

DM

A

…



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 32

System-on-chip level hardware integration

Interconnection

network NoC

Connection and arbitrate

protocol

Data and addressing

protocols

Po

int

to p

oin

t n

etw

ork

Tra

dit

ion

al b

us

2D

cro

ssb

ar n

etw

ork

Ro

ute

r IP

sy

nth

esiz

er

HW

: D

aisy

ch

ain

Pri

ori

ty a

rbit

rati

on

Fir

st r

equ

est

firs

t ta

ken

Ro

und

ro

bin

Sim

ple

dat

a

Dat

a li

nk

co

ntr

ol

pro

toco

l

Dat

a co

rrec

tio

n p

roto

col

Glo

bal

mem

ory

ad

dr.

Sy

nch

and

clo

ckin

g

Dri

vin

g a

nd

sp

eed

Ro

uti

ng

alg

ori

thm

Dis

trib

ute

d m

emo

ry a

dd

r.

Physical

issues

SoC integration (in another course)



Finally: Build a SoC simulator

A SoC simulator is the chip behavior model

You may not have it, just use FPGA emulator

1.SW architecture: Speed, scalable, debug

2.Cycle accurate/behavior CORE simulation

3.SoC cycle accurate transactional simulation

4.Host adaptation to speed up SoC simulation

10/3/2017 Unit 10 of TSEA26 – 2017 –H1 33



Design for reuse

1. Designed to solve a general problem – easily configurable to

fit different applications.

2. Designed for use in multiple technologies – For soft IP, the

synthesis scripts make quality results with different libraries.

3. Designed for simulation with a variety of simulators – With

both Verilog and VHDL versions, verification test-benches,

and work with all the major commercial simulators.

4. Designed with standards-based interfaces – Unique or

custom interfaces should not be used.

10/3/2017 Unit 10 of TSEA26 – 2017 –H1 34



Design for reuse

10/3/2017 Unit 10 of TSEA26 – 2017 –H1 35

5. Verified independently to any SoC – IP has full, stand-

alone test-benches, verification suites, full test coverage.

6. Verified to a high level of confidence – Need a MPW

prototype, in an actual system running real software.

7. Fully documented applications and restrictions –valid

configurations and parameter values are documented.

Any restrictions on configurations or parameter values

are clearly stated. Interfacing requirements, restrictions

on how the IP can be used are documented.



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 36

Verification



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 37

Verification in general

• HW Verification is to demonstrate the functional

correctness of a design - Janick Bergeron,

• To prove the consistency between the final functional

design and the paper specification.

• System verification: To verify the application function

• Hardware verification: To verify the HW compliance

• Verification versus HW test (fab follows the design)



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 38

Re-convergence path

Transformation

Verification

Specification Design

Transformation

Verification

Paper doc

Transformation from

a paper document

With re-convergence Without re-convergence



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 39

Verification methodology

Top HW function specification

Partition and bus design

Block level design

RTL coding

System verification

Bus level verification

Block level verification

Classic verification flow Concurrent verification flow



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 40

Compliance test

• To verify HW not to the system– Execute instructions correctly

• To verify that the design complies with the specification– the specification is the hardware design documents.

– Not the specification of applications.



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 41

Compliance test• Check operations following the instruction set manual

– Consuming the right number of clock cycles

– Writing back during correct cycles

– Checking all memory addressing models

– Checking all register addressing models

– Checking all branch instructions and conditions

– Checking all jump target addresses calculations

– Checking all configurations to every instruction

– Checking all acceleration functions



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 42

Corner testCorner test• Corner means

– Irregular, designs based on informal methods

– To limits, cross boundaries, finite precision

• Find possible corners– Data boundary: flags, carry-out, scaling, saturation,

overflow, underflow, rounding, forwarding, etc.

– Address boundary: memory address, stack, register file boundaries

– Irregular: split / merge bus, fractional +1 problem…



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 43

Datapath Corner test (optional)

• In the integer (fractional) datapath:

– All data truncation points, data concatenation points

– All guards, rounds, saturate, and flags

• All result patterns affecting flag values

– Corner cases to set and reset each flag

– Which instructions change / keep flags

• All cases changing data formats

– Change data types between ALU and MAC

– Change other data formats (such as the fractional

multiplication, saturation for unsigned)



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 44

Control / M Corner test (optional)

• All control and status registers are cleaned after system reset (while clocks are off by gating)

• All registers can be accessed according to the hardware specifications

• Reaction of all specified exceptions induced by

– Data dependency, Computing exception

– Overflow and underflow of the hardware stack

– FIFO limiters (top and the bottom registers)

• Corners of memory / register addressing (MAX/MIN)

• PC corners, values such as destinations of branches

• Starting/stopping points of hardware loop functions



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 45

Random test• Run the same randomly generated test vectors

on the behavioral model and the RTL code

• A result consistency check gives results of the random test

• The method to run random tests is – (1) to generate a random stimuli-set (instruction

and data), run on instruction simulator first.

– (2) to run the same stimuli-set on RTL code

– (3) to compare results from the instruction set simulator and results from RTL code.



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 46

Real code testReal code test – run applications

• Supply programs and related stimuli to the instruction set simulator to get results / cycle cost

• The same results and cycle cost should be from the RTL code

• Test of the C-compiler



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 47

Hierarchical verification

Test benches

=

Assembly

instruction set

simulator

RTL codes



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 48

Test suit and DUT



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 49

Testbench Example (1)

DUT

DSP_Core

clk_gen

reset_gen

clk

reset_n

input_genin_port

ouput_saveout_port



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 50

Testbench Example (2)

• clk_gen

architecture bahav of clk_gen is

begin

process

begin

clk <= ‘1’;

wait for 10 ns;

clk <= ‘0’;

wait for 10 ns;

end process;

end behav;

• reset_gen

architecture bahav of reset_gen is

signal res_int_n :std_logic

begin

res_int_n <= ‘0’,

‘1’ after 10 ns;

reset_int_n <= reset_n;

end behav;



10/3/2017 Unit 10 of TSEA26 – 2017 –H1 51

Testbench Example (3)• output_save

use ieee.std_logic_textio.all;

file output_file : text

is out “/data/out.txt”;

variable l : line;

process(clk)

begin

if (rising_edge(clk)) then

write(l, out_port);

writeline(output_file, l);

end if;

end process;

• input_gen

use ieee.std_logic_textio.all;

file input_file : text

is in “/data/in.txt”;

variable l : line;

variable slv: std_logic_vector(15 downto 0);

process(clk)

begin

if (rising_edge(clk)) then

if not (endfile(input_file)) then

readline(input_file, l);

read(l, slv);

in_port <= slv;

end if;

end if;

end process;



Review on integration

and verification

Integration and verification

Micro architecture

1. Functional: Be sure that all instructions mapped

and can be executed (with available connections). All special registers/ports can be accessed (in)directly

2. Structural: HW arch adapted to instruction-set Combinational: bus matches, width, endian, direction

Sequential: pipeline compliance with the specification

3. Physical: speed, power consumption, and cost New

hidden critical path, unnecessary toggling or even bugs

after integration (missing keeper, default).

Register file

ALU: Arithmetic & Logic

MAC: MUL and ACC

Memory and data access

Program flow control

Assembly coding tools

Firmware plan & design

10/3/2017 Unit 10 of TSEA26 – 2017 –H1 52

Skills

Con

cep

ts

SoC

Micro arc

RTL

layout

behavior

function structure

physical



Self reading after the lecture

• The book was written in 2006, 10 years

old. The integration engineering has been

very much changed!

• Follow my slides and take chapter 19, 15,

and 16 as references.

• Essential: Core integration is the essential

part and will be in exam.

10/3/2017 Unit 10 of TSEA26 – 2017 –H1 53



Exciting time now!

Let us discuss• Whatever you want to discuss and

related to HW

• You will have the chance after each

lecture (Fö), do take the chance!

• Prepare your Qs for the next time

10/3/2017 Unit 10 of TSEA26 – 2017 –H1 54



LOGO

Dake Liu, Room 554 coridoor B, Hus-B, phone 281256, [email protected]

Welcome to ask any

questions you want to

• I can answer

• Or discuss together

• I want to know what you want


Documents

Unit 10: Integration and Verification - Linköping University and... · Unit 10: Integration and Verification - Linköping University ... rtl