Towards A C based Design Methodology Facilitating Sequential Equivalence Checking

1
Towards A C based Design Methodology
Facilitating Sequential Equivalence Checking

• Venkat Krishnaswamy, Calypto Design Systems, Inc.
• Philippe Georgelin, STMicroelectronics

2
Methodology Goals
Maximize code reuse across models
3
Talk Outline

• C Modeling
• Achieving Code Reuse
• Modeling Hardware Intent
• Target Model
• Experimental Results
• Conclusions and Future

4
Hardware Modeling in C/C

• Many applications for C/C models
• Algorithm exploration
• System prototyping
• Architecture partitioning
• Performance tuning
• RTL verification
• SW development
• Simulation speed and functional accuracy primary
  concerns
• Tools and methods around these models largely
  home-grown

Code reuse across models improves productivity
and reduces the chance of model functionality
diverging
5
Achieving Code Reuse
Transactional Communication
Computation

• Module Computation and inter-module Communication
  are distinct tasks
• Separating computation from communication is
  necessary for reuse
• computational code can be reused from model to
  model
• communication detail changes depending on the
  application of a specific model
• The level of detail in inter-module communication
  is a first order determinant of overall
  event-simulation speed
• events are generated in communication
• the lower the level of communication detail the
  more events generated

6
Computational Model Terminology

• Slave mode
• no attempt at communication from within the body
  of computational code
• complete execution in zero time
• no explicit parallelism
• communication detail can be specified in wrappers
• Master mode
• may communicate from within the computational
  code
• communication is at an API level
• lends itself to TLM styles
• implementation of communication APIs determines
  level of communication

7
Implementing Slave Mode Computation

• Two methods to model computation in slave mode

• Classes
• Enable multiple instantiations w/ low effort

• Globally Scoped Functions
• Model state with statics

typedef int16 sc_intlt16gt class fir_filter
public fir_filter () virtual fir_filter
() int16 run(int16 in, int16
coeffs8) for (int i 7 i gt 0
--i) regsi regs i - 1 regs0
in int tmp 0 for (int i 0 i lt 8
i) tmp coeffsi regsi return (tmp
gtgt 16) private int16 regs8
typedef int16 sc_intlt16gt void fir_filter (int16
in, int16 coeffs8, int16 out) static int16
regs 8 for (int I 7 i gt 0
--i) regsi regsi-1 regs0 in int
tmp 0 for (int i 0 i lt 8 i) tmp
coeffsi regsi out tmp gtgt 16
8
Coding Computational Master Models

• TLM techniques should be used
• considerable work in literature on defining and
  implementing TLM APIs
• OSCI TLM working group - tlm-group_at_systemc.org
• TLM methodologies well suited to scale across
  levels of communication detail
• PV
• PVT
• CC

9
Modeling Communication

• Wrappers can be written around slave mode
  functions to implement communication
• level of detail in wrappers adjusted to purpose
  for whichmodel is intended
• SystemC provides excellent facilities with which
  to implement wrappers at different levels of
  detail
• Level of communication dictates detail
• Architecture exploration untimed with function
  interfaces
• SW prototyping coarsely timed with API level
  interfaces
• RTL verification detailed timing with pin level
  interfaces
• For models coded using master mode, TLM
  techniques should be used
• considerable work in literature on defining and
  implementingTLM APIs
• Ghenassia et al

10
Using Wrappers to Model Communication

• Wrappers for C Models
• Provide exo-skeleton
• Clock, reset, other timing related ports as
  required
• Pin level I/O which can be mapped with RTL model
• Intent is to avoid touching computation code
• C code can be modified in isolation from wrappers
• Wrappers are written for Throughput1, Latency1

11
Enabling a System to RTL design flow

• EDA tools to must be able to infer hardware
  intent from C/CC models
• Sequential Equivalence Checkers (SEC)
• High level synthesis (HLS)
• Static Analysis
• SEC reasons about equivalence of hardware models
  and C/C models
• Model compilation
• Hardware intent extraction
• Static reasoning

12
Hardware Intent in C

• It is necessary to define a set of rules for
  writing computational code
• SEC statically creates an abstract HW model
• Extraction of efficient HW models
• Similar to existing behavioral synthesis rules
• Not required for communication code outside SEC
  wrappers
• Rules preclude use of certain common programming
  idioms
• Dynamic memory allocation/de-allocation
• Pointer aliasing
• Standard library header files
• Statically indeterminate loop bounds

13
Dynamic Memory Allocation (malloc)

• Dynamic allocation of memory to size a
• The size of a could depend on runtime parameters

• Static allocation
• Integer a is an array of 100 elements

//In this code fragment, a is statically //sized
and therefore can be reasoned // about in
hardware inferencing //In general, very large
arrays that are //sparsely populated can
impact // simulation performance. It is
therefore //a good idea to isolate such
memories // to modules which can be
hierarchically // isolated int a100
int a //This is a runtime call to the OS //to
ask for memory allocation from //the kernel.
//In general, it is impossible to reason //
about size statically a (int) malloc (100
sizeof (int)) ... free (a)
14
Pointer Aliasing

• Occurs if a single pointer points to multiple
  memory locations over its lifetime
• Some tools support a limited form of aliasing
• Single array indexing

• Linked list traversal example

int x int a100, int b100 for (x a x lt
(a100) x) a 0xf for (x b x lt
(b100) x) b 0xf //x points to several
locations over its //lifetime. Another example is
list traversal //In general, impossible to
statically //determine what x points to
my_struct a, first, a first while (a !
NULL) a a--gtnext //linked list traversal
example // //impossible to extract a HW
abstraction //from a complex instance of aliasing
15
Case StudyModeling Style and Design

• Video Pipe Subsystem
• Untimed C model
• slave mode functions
• Four algorithm blocksDCT, IDCT, QUANT, IQUANT
• functionality defined by sequential top level
  calls
• RTL hierarchy for each block

• Coding Style
• Adherence to separation of computation and
  communication
• Algorithm blocks proven by realistic vectors
• RTL created from C code using behavioral
  synthesis
• SEC tool (SLEC) driver files automatically created

16
Case StudyEquvalence Checking and Results

• SEC done at block level
• Pin accurate wrappers created for each block
• Coarse clock notion Throughput1 and Latency1
• Initial SEC runs generated counter examples
• Wrapper issues
• Throughput and latency mismatches
• Final SEC runs successful
• Full formal equivalence proofs
• Runs under 30 minutes per block

17
Case Study Benefits from a structured C/C
methodology

• Model reuse
• Efficiency between design phases and designers
• C/C for HW design
• Ability to quickly make system trade offs
• Automated RTL generation from HLS
• Comprehensive verification
• Leverage C/C verification directly onto RTL
• No testbench development using SEC
• Exhaustive simulation of these models would have
  taken years.

18
Conclusions

• Separation of computation and communication are
  essential to achieving re-use
• Proper attention to such separation enables teams
  to build models at different levels with freedom
  to choose simulation infrastructure
• Most model writers should only care about writing
  computation blocks
• Enabling a multi-hierarchy communication
  infrastructure involves more C expertise than
  an algorithmic designer/architect has time for
• Coding with hardware intent in mind enables tools
  and methods such as sequential equivalence
  checking and high level synthesis
• Value brought to bear by these tools is worth the
  effort of coding within guidelines
• It is important to continue to expand the range
  of constructs from which hardware intent can be
  inferred in a tool independent manner