How To Graphically Represent DUT’s Data Flows

In this post I will explain how to analyse the DUT’s data flows and represent them graphically in an intuitive way.

I use data flow analysis to create meaningful diagrams to be included in the verification specifications(e.g. see How To Read a Specification, section Read the spec with a meaningful goal).

You won’t need more than a pencil and some paper to get started.

Data Flows

A data flow is a sequence of transactions with functional and temporal dependencies between them. A data path is a set of input and output interfaces(either internal or external) on which the transactions of a data flow are observed.

The data flow sequence of transactions contains at least one transaction, which is the cause-transaction that triggered the data flow. Depending on the cause-transaction type, the data flow can be either handled internally by DUT or continued with a series of one or more effect-transactions on the output interfaces. As a rule of thumb: cause-transactions are those observed on input interfaces, while effect-transactions are those collected on output interfaces.

Data flow analysis is a transaction level analysis, which means that you can ignore the small details of protocol implementation(i.e. timing, transaction structure etc.) and focus on high level aspects(i.e. operation, dependencies).

The Example

The example DUT is a generic communication controller that transfers data between two systems under the control of a CPU. The DUT has two interfaces(i.e. RAM, EXT_*) for data transfer and one interface (i.e. CTRL_*) used by CPU to request transfers.

The CPU can send/receive control transactions over the CTRL_IN interface in order to:

• write internal registers (WR_REG), read internal registers (RD_REG)
• copy data to remote system (WRITE), read data from remote system (READ), send an interrupt message to the remote system (TX_IRQ)

On the CTRL_OUT interface transactions can be:

• register read response (RD_REG_RESP)
• received external read response (RX_EXT_RD_RESP)
• received an external interrupt (RX_IRQ)

On the RAM interface transactions can be:

• read (READ), includes the read response
• write(WRITE)

On the EXT_OUT/EXT_IN interface transactions can be:

• write (EXT_WR)
• read (EXT_RD)
• read response(EXT_RD_RESP)
• interrupt (EXT_IRQ)

Table-Based Representation

You can create a table-based representation of the data flows by following these steps:

• add a column for each interface, the input interfaces being positioned at the most left of the table
• add a line for each data flow (or cause-transaction)
• add cause-transaction on the corresponding input interface
• add effect-transaction(s) on the corresponding output interface(s)

You should get a table like the one below:

The table is intuitive, it shows the relation between cause- and effect-transactions, but it misses to illustrate the time dependency (i.e. the sequencing) between transactions. No worries, the next section should help.

UML Sequence-Based Representation

You can transform the table into an UML sequence diagrams which will also include timing/sequencing information.
You need to represent a lifeline(i.e. a vertical line) for the DUT and one for each of the interfaces. The next step is to connect the various transactions of each data flow with horizontal lines. You can create one diagram for each data flow or group more data flows into a bigger diagram.

In the figure below I illustrate the UML sequence diagrams for three data flows triggered over the CTRL_IN interface:

Further Study

There are few exercises you can solve as further study:

• represent the data flows triggered by transactions received over EXT_IN
• represent data flows for the DUT you are currently working on, eventually including lifelines for the internal interfaces
• represent test scenario flows in a similar manner to data flows (e.g. use a lifeline for each sequence, the “main” sequence/run phase to the most left, connect lifelines by arrows indicating start of a sequence, etc). You should include the test scenario flow diagrams in the verification specification or environment’s presentations to ease knowhow hand-over.