ahb i2c verification

1

February 22-24, 2006

Guidelines for creating a formal verification testplan

There is no substitute for thinking!

Harry Foster - Mentor Graphics CorpLawrence Loh - Jasper Design AutomationBahman Rabii - GoogleVigyan Singhal - Oski Technology

Harry Foster, 2006 2

Agenda• Observation• Verification Testplanning Process• Seven Steps of Formal Testplanning• AHB-I2C Example


Observation

• Successful verification is not ad hoc in nature– Success depends on methodical verification planning combined with

systematic verification processes. • The key to success is the verification testplan.


Verification Testplan

• A project’s functional verification testplan is the specification for the verification process. – Developing this testplan usually involves the entire engineering team

• architects, designers, and verification engineers

• In general, the verification testplan defines exactly – what functionality will be verified, – how it will be verified

• the verification strategy and resource allocation

– when the verification process is complete• metrics for measuring progress or completion criteria


FV for bug hunting or assurance?

Bug hunting AssuranceMany RTL assertions One comprehensive specPushbutton tools Semi-automated toolsSuccess: # bugs found Success: ckt meets spec

Testplan critical!

Bug hunting

Assurance

Bugs Rate

TimeRev 0 RTL Tapeout


Where to apply formal?

• Formal verification of properties on RTL designs is a known hard problem

– Formal verification algorithm complexity• Exponential in the size of the designs

– Naïve application of formal verification• State-space explosion

• Impractical computer run- times

• Our first step is to identify appropriate blocks for formal

– Prior to creating a formal testplan


Where to apply formal

• One coarse measure of prediction of the tractability– number of state-holding elements in the cone of influence of the property

IrrelevantLogic

Cone ofInfluence

DesignBlock

Property


Where to apply formal• Real examples include:

• Common characteristic: concurrency, multiple data streams

- Interrupt controller- Memory controller- Token generator- Credit manager block- Standard interface (AMBA, PCI Express, …)- Proprietary interfaces- Clock disable unit

- Arbiters of many different kinds- On-chip bus bridge- Power management unit- DMA controller- Host bus interface unit- Scheduler, implementing multiple

virtual channels for QoS

Multiple, concurrent streams

Hard to completely verify using simulation

“10 bugs per 1000 gates”

-Ted Scardamalia, IBM


Where not to apply formal• Examples of designs not appropriate for formal include:

(I’m not talking about theorem proving!)

• Floating point unit

• Graphics shading unit

• Convolution unit in a DSP chip

• MPEG decoder

• Common characteristic: often sequential in nature, potentially involves some type of data transformation (math)

Single, sequential/functional streams

“2 bugs per 1000 gates”-Ted Scardamalia, IBM


Control versus datapath

DesignVerification

Data Transport Data Transform

Control Datapath


Simulation versus formal testplans

• What vs. how– Two key differences between a formal and simulation testplan:

• A strict separation of checks (observability) and input scenarios (stimulus)

• A preference of a more general specification style

– In simulation checkers and stimulus can be tightly coupled

– In formal verification, properties are defined in terms of:• Generic behavior, independent of particular input scenarios.

• Minimal correctness criteria

– Avoid cycle accurate specification when possible


Compositional Reasoning

• The process of reducing an analysis of a larger concurrent system to reasoning about its individual functional pieces– Effective for managing proof complexity and state explosion– Transfers the burden of proof from the global level to the local functional

component level

• When possible, prove assumptions on neighboring blocks– Assume - guarantee

Block B assert . . .Block AA

B

A

B

assert always !(A & B);

assume always !(A & B);


Compositional Reasoning

Cone ofInfluence

a

bIrrelevant

Logic

Cone ofInfluence

DesignBlock

PropertyAnalysisRegion

Free VariablesAbstracted Inputs

Formal Abstraction


Seven steps of a formal testplan

Identify good candidates

assert_never ();

Formal description

Englishlist

Block

Requirementsinputs

outputs

describe

Defineinterface

identify

Requirementschecklist

Formaldescription

Verificationstrategy

Coveragegoals

1

2

3

4

5

6

7


AHB Lite to I2C Example

BridgeBridge I/OMergeI/O

MergeI2CI2CAMBA

AHB LiteAMBA

AHB Lited[31:0]

a[31:0]

size

clk_eni2c_data_vldi2c_data_outi2c_data_in

SCL

bridge_ready

d_ready

i2c_data_start

One bit serial connectionHigh speed, high

bandwidth bus

SDA

Great candidate for formal!Identify goodcandidates

assert_never ();

Formal description

Englishlist

Block

Requirementsinputs

outputs

µ-arch

Defineinterface

identify


Formaldescription


Coveragegoals

1

2

3

4

5

6

7

I2C ClockingBridge (with 64 byte write FIFO)


Step 2. Describe Intent Identify goodcandidates

assert_never ();

Formal description

Englishlist

Block

Requirementsinputs

outputs

µ-arch

Defineinterface

identify


Formaldescription


Coveragegoals

1

2

3

4

5

6

7NOTE: This can be a video taped

white-board discussion!

The commands flow one direction from AHB to I2C, but the data flows both ways. For the write direction, data are written into a FIFO. When the FIFO is full, the AHB signal HREADYout is deasserted until there is room in the FIFO again. Upon receiving the write data, as long as there is room in the FIFO, the AHB bus is free for other devices sharing the AHB to proceed to their transactions. A read-cycle, however, will hold up the bus until the data is ready (because a SPLIT transaction is not supported by the bridge). Therefore, the read transaction has priority over the write transaction except when there is a coherency issue. For example, if a read address matches the write address of one of the entries in the. . . . .


Step 3. Define Interface Identify goodcandidates

assert_never ();

Formal description

Englishlist

Block

Requirementsinputs

outputs

µ-arch

Defineinterface

identify


Formaldescription


Coveragegoals

1

2

3

4

5

6

7

Signal Name Description Size DirectionHCLK AHB Clock 1-bit In

HRESETnMaster Reset(active low)

1-bit In

HADDR AHB Address 7-bit InHBURST AHB Burst length 3-bit InHTRANS AHB Transaction Type 2-bit InHSIZE AHB Transfer Size 3-bit InHWRITE AHB Write 1-bit InHSEL AHB Select 1-bit InHREADYin AHB HReady 1-bit InHWDATAHWDATA AHB Write Data 32-bit InHRDATA AHB Read Data 32-bit OutHRESP AHB Response 2-bit OutHREADYout AHB HREADYOUT 1-bit OutSDA I2C Data 1-bit In/OutSCL I2C Clock 1-bit Outi2c_clk_ratio HCLK to I2C Clock ratio 2-bit In

DUT

RequirementModel

inputs outputs


Step 4. Requirements Checklist Identify goodcandidates

assert_never ();

Formal description

Englishlist

Block

Requirementsinputs

outputs

µ-arch

Defineinterface

identify


Formaldescription


Coveragegoals

1

2

3

4

5

6

7AMBA AHB-Lite interface requirements.In general, we can partition AMBA AHB-Lite requirements into two categories: master requirements and slave requirements. 1. Slave must assert HREADYOUT after reset 2. Slave must provide zero wait-state HREADYOUT=1 response to IDLE transaction3. Slave must provide zero wait-state HREADYOUT=1 response to BUSY transaction4. . . .I2C interface requirements. 1. SDA should remain stable when SCL is high2. There should not be another start after a start until an end occurs in the I2C bus.3. The data between a start and an end should be divisible by 9 (8 bit/transfer + 1-bit ack)4. . . .End-to-end requirements. 1. Data is not dropped, duplicated, or corrupted for a read-cycle2. Data is not dropped, duplicated, or corrupted for a write-cycle3. …


Step 5. Formalize RequirementsIdentify goodcandidates

assert_never ();

Formal description

Englishlist

Block

Requirementsinputs

outputs

µ-arch

Defineinterface

identify


Formaldescription


Coveragegoals

1

2

3

4

5

6

7

To demonstrate the formal specification process, we convert thefollowing I2C requirement into both PSL and SVA:

There should not be another start after a start until an endoccurs in the I2C bus.

NOTE: In this example, i2c_startand i2c_end represent modeling code associated with the assertion, composed of SCL and SDA.

default clock = HCLK;A_no_start: assert (always i2c_start ->

next(~i2c_start until i2c_end)) abort (~RESETn);

PSL

property P_no_start;@(posedge HCLK) disable iff (~HRESETn)

i2c_start |=> ~i2c_start[*0:$] ##1 i2c_end;endpropertyA_no_start: assert property (P_no_start);

SVA


Step 6. Strategy Identify goodcandidates

assert_never ();

Formal description

Englishlist

Block

Requirementsinputs

outputs

µ-arch

Defineinterface

identify


Formaldescription


Coveragegoals

1

2

3

4

5

6

7

• In this step, you will define the verification plan and proof strategy.

• For example, you might choose to prove certain requirements by initially applying a set of restrictions – Add constraints to restrict the explored behavior to only read-mode transaction, or

only write-mode transactions.

– This approach lets you focus the verification on specific modes of operation, and simplifies the verification process.

– Once the various modes function correctly, the restrictions are removed and the

IP is verified under all modes of operation.


Step 6. Strategy

• Compositional Reasoning– Partitioning

• Strict Mode– Applying restrictions initially, and then loosening them

over a sequence of steps• Abstraction

Identify goodcandidates

assert_never ();

Formal description

Englishlist

Block

Requirementsinputs

outputs

µ-arch

Defineinterface

identify


Formaldescription


Coveragegoals

1

2

3

4

5

6

7


Step 7. Coverage Identify goodcandidates

assert_never ();

Formal description

Englishlist

Block

Requirementsinputs

outputs

µ-arch

Defineinterface

identify


Formaldescription


Coveragegoals

1

2

3

4

5

6

7

• Define a set of coverage goals that must be met during the verification process. – To ensure that you are verifying what you think you are verifying, check that

constraints on specific states in your requirements model have not over-constrained the states.

• The checking procedure varies depending on your verification process. – For formal verification, you can check to see if specific states in your requirement

model are reachable.

– For simulation-based approaches, you can apply functional coverage to various states or sequences of states in the requirements model.


Step 7. Coverage Identify goodcandidates

assert_never ();

Formal description

Englishlist

Block

Requirementsinputs

outputs

µ-arch

Defineinterface

identify


Formaldescription


Coveragegoals

1

2

3

4

5

6

7

Set 1: Input coverage – Read/write access with different burst types, sizes, and lengths, and with HREADYOUT asserted and deasserted.

Set 2: Output coverage – Read/write with acknowledgment, no acknowledgement.

Set 3: Internal main state-machines – I2C state-machines, AHB state-machines where they can enter and exit each state.


Seven steps of a formal testplan

Identify good candidates

assert_never ();

Formal description

Englishlist

Block

Requirementsinputs

outputs

describe

Defineinterface

identify


Formaldescription


Coveragegoals

1

2

3

4

5

6

7

28

February 22-24, 2006

Guidelines for creating a formal verification testplan

There is no substitute for thinking!

Harry Foster - Mentor GraphicsLawrence Loh - Jasper Design AutomationBahman Rabii - GoogleVigyan Singhal - Oski Technology

ahb i2c verification

Documents

google vigyan singhal

state hreadyout 1 response

identify good candidates

formal testplanning ahb

formal verification testplanthere

apply formal

formal verification

formal testplanidentify