Behavioural Modelling

Introduction

Modelling of hardware behaviour is an important stage in the hardware design task. There are a variety of methods to undertake the modelling activities. 

Some projects utilise formal methods to specify the model and use formal model checking as the verification of the design. Some projects use more visual methods of representing a model to describe the hardware behavior, this can be helpful on larger projects to help communication and shared understanding among a team. Other projects look to develop executable software models of system behaviour. These help engineers convey complex ideas without encoding all the details needed by other methods. If there is a very clear and precise specification for the project then a more formal approach to design refinement my be most efficient. If the definition of the system is less clear a more iterative approach to creation and testing of models may be more efficient. Here the term design space exploration is often used where designers iteratively prepare models and use simulation based testing to examine the operational characteristics of alternative options in hardware design.

Model Representation

This stage of the hardware design task creates a "Behavioural Model" of the system consisting of behavioural blocks often described using various high level description languages. How models are represented can take various forms. In a software/hardware co-design approach the model may be represented in a software language such as C++ this is then translated by High Level Synthesis into an RTL description. An RTL description might be translated into a C++ representation to run as part of a simulation for verification. Usually the representation taken forward to the next stages of the hardware development process is and RTL description.  

In the digital domain Transaction-Level Modelling (TLM) can create a behavioural description of a system with enough detail to allow verification of the design by simulation. Behavioural models for the analogue domain use forms of mathematical approximation, linear or non-linear regression, neural networks, etc. to define relations between inputs and outputs. 

Behavioural Modelling within a System on Chip design context

Within SoC Labs the aim is to provide significant parts of the System on Chip as pre-verified IP and design patterns. The hope is this enables efficient co-design of the unique custom IP for the academic project need within an existing efficient system architecture. The unique IP could range from domain-specific compute accelerators to designs that provide real world monitoring / actuation or system security capabilities. These custom blocks can be modelled and developed independently and then integrated into one of a number of different SoC reference designs each with different operational characteristics. 

Part of any engineering or hardware design task is developing a solution within some externally imposed envelope of constraints within which the overall system has to operate.  The SoC Labs reference designs and design patterns help the project develop hardware blocks within a known view of a deliverable target system platform.

The aim of SOC Labs is simplify the integration of the RTL description of the custom hardware into the RTL description of the full SoC reference design for the full SoC that can be taken to physical fabrication and beyond that exercised as a system with an operational software system to exercise the custom hardware with real world workloads and obtain real world measurement of system performance. Creating an executable Behavioural model of the custom hardware allows for a software/hardware co-design approach where the eventual operational software can be developed in parallel and also become part of the verification assets for the custom hardware at various stages of the hardware design task.

Behavioural Design Decomposition 

In any system design task, the prior phase of Architectural Design is further decomposed into behavioural design models and patterns. Parts of the system may be worked on in isolation by separate individuals or teams with each behavioural block having a verification process performed on it before integrating into a complete System on Chip. This means the Behavioural Modelling task may be iterated through a number of times, each pass through adding to the overall system design and verification assets. 

Behavioural Design Patterns

Design patterns have been defined for many ways engineers commonly develop solutions to design challenges. Behavioral design patterns aid the design decomposition process, often dealing with the interactions between the various parts of the overall system. Engineers often get confused between the intellectual process of design decomposition and the tool they currently have in their hand. You will see statements such as 'written this way' or 'instantiated in this type of object'. Well conceived design patterns are ambiguous to implementation choices or tool chains. The  Transaction Level Modelling (TLM) mentioned above is not a new approach to design just a refinement of the principle of 'separation of concerns', etc. It focuses on the interactions between parts of the system while allowing the implementation of the parts to be deferred to another design task.

Examples of Behavioural Design Patterns

Below is not an exhaustive list but are illustrative to get the reader to consider using existing design patterns rather than trying to do what has been done many times yet again from scratch. 

Chain of Responsibility

In this design pattern the interaction between the various parts of the system consist of passing the communication along a chain of the parts. Each part can independently decide to take action and/or to pass it to the next in the chain for their action. It can be used to implement actions within the system that need to be performed sequentially. One example is at system bring up where it is important that one part of the system is in a known state before other parts that depend on it start to use it. The 'system reset' communication can be passed along the Chain of Responsibility ensuring that parts that need to have their state established before others are placed before each other in the chain. This pattern was recently discussed for use by the SoC Labs team looking to implement a Memory Controller for DDR4 memory. 

Behavioural Design for Machine Learning / Artificial Intelligence 

There are a lot of software frameworks that provide for model development, model optimization and deployment.  It is well known that model development is both compute and memory intensive. It is also know that model optimization can reduce resource utilisation, especially for deployments of inference and operations on edge based computation resources.  Within the SoC Labs activity there is an interest sections dedicated to the Machine Learning topic. 

You will find a number of projects that have developed specialist models that are aimed at efficient inference using custom hardware accelerators that are integrated into the different SoC reference designs depending on a number of the demands of the application and model.

The initial stages of design utilising ML/AI models is no different than other design tasks, defining the scope of the application, constraints, etc. Likewise the usual build/reuse decision. Is there an existing model that will suffice. Obviously in an academic perspective an educational example might use and existing model but the drive of research it to develop new models that improve on the current. Here the build/reuse decision become a build/benchmark decision. The researcher finds existing models and looks for ways to develop an improved model which can be shown to be a improvement by some metric. 

Model development has tended to be a slightly separated software/hardware co-design task. Often models are developed in compute fabrics that have significant resources and look to increase accuracy. A separate task then looks to optimse the model towards the deployment while minimising accuracy loss. Benchmarking is viewed as an acceptable gain in some other system characteristic, energy, latency, etc. against some nominal loss in accuracy. There have been a few examples of where diligent engineering has shown  gain in system characteristics without accuracy loss and it should be remembered that the accuracy benchmark has been computed on a software platform that by its nature is limited. There is nothing to suggest a custom hardware solution should not outperform a classic CPU compute resource in terms of accuracy. 

This section will not attempt to replicate the many resources available on model development frameworks. The interest sections dedicated to the Machine Learning topic will hopefully expand on how SoC Labs implementations benefit from and interact with such model development frameworks.