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.

Example DUT

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:

INPUT INTERFACES OUTPUT INTERFACES
D
A
T
A




F
L
O
W
S
CTRL IN EXT_IN CTRL OUT RAM EXT_IN EXT OUT
WR_REG
RD_REG RD_REG_RESP
WRITE READ EXT_WR
READ EXT_RD
TX_IRQ EXT_IRQ
EXT_WR WRITE
EXT_RD_RESP RX_EXT_RD_RESP WRITE
EXT_RD READ EXT_RD_RESP
EXT_IRQ RX_IRQ

 

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:

CTRL_IN Operations data flows

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.

Comments

Taahir Ahmed April 19th, 2016 20:08:30

Very Nice Article !!!!!AMIQ blogs are always refreshing.


Shalin April 28th, 2016 11:42:00

What is the tool you used to create these diagrams? You can find more data flow diagram templates and examples in creately diagram community.


Leave a Comment:

Your comment will be visible after approval.

(will not be published)

This site uses Akismet to reduce spam. Learn how your comment data is processed.