Transaction-Level Verilog (TL-Verilog) is an emerging extension to SystemVerilog that supports a new design methodology, called transaction-level design. A transaction, in this methodology, is an entity that moves through structures like pipelines, arbiters, and queues, A transaction might be a machine instruction, a flit of a packet, or a memory read/write. Transaction logic, like packet header decode or instruction execution, that operates on the transaction can be placed anywhere along the transaction's flow. Tools produce the logic to carry signals through their flows to stitch the transaction logic. We implemented a small library of TL-Verilog flow components, and we illustrate the use of these components in a top-down design methodology. We construct a hypothetical microarchitecture simply by instantiating components. Within the flows created by these components, we add combinational transaction logic, enabling verification activities and performance evaluation to begin. We then refine the model by positioning the transaction logic within its flow to produce a high-quality register-transfer-level (RTL) implementation.
While circuit complexity continues to scale exponentially, it is not practical for the size of design teams nor the duration of projects to scale accordingly. This necessitates continual adoption of higher-level design practices. Register-transfer-level (RTL) modeling, however, has remained the norm for over 30 years and 1/25,000 transistor scaling. Design teams continue to grow, projects are limited in scope, and project durations lengthen. The industry is at its breaking point. While adoption of high-level modeling methodologies is necessary, it has been slow by the facts that high-level modeling languages are failing to offer sufficient simplification to justify the loss of direct control over details.
Recently, a timing-abstract design methodology has been demonstrated which preserves RT-level control while enabling designs to remain abstract [1]. Timing-abstraction is provided in Transaction-Level Verilog (TL-Verilog) by a pipeline construct. All logic belongs to a pipeline and exists within a pipeline stage. The stage of a logic expression is purely a physical implementation attribute. It has no impact on behavior, so timing details can be refined safely without impacting behavior. While the resulting expression of the design contains identical detail, it is simpler, smaller, and both easier and safer to manipulate.
Transaction-level design builds upon timing-abstract design. It extends the notion of transactions flowing through pipelines to transactions flowing through arbitrary “flow elements,” such as FIFOs, arbiters, and queues. This paper presents an early view of the use of transaction-level design using TL-Verilog in a top-down design methodology. As a showcase, we developed a rudimentary library of microarchitectural components [5], and we used them to construct and refine a hypothetical microarchitecture. Though we believe this showcase to be reflective of real-world use, we leave real-world examples to future research. We study a top-down approach not to imply that transaction-level design is a top-down methodology, but rather to demonstrate that a top-down approach is, indeed, possible. Top-down design has long been explored, but it is, today, generally understood to be infeasible. We show that it is not.
The remainder of the paper is organized as follows. Section II describes transaction-level design methodology in TL-Verilog. Section III describes a property of TL-Verilog termed “lexical reentrace”. Section IV describes how transaction-level design with lexical reentrance enables the development of library components that are infeasible in RTL and the use of these components in a top-down design flow. Section V quantifies the results, followed by conclusions in Section VI.
Our showcase design is depicted in Fig. 1. It implements a transaction flow from various flow components in our library. This design connects four equivalent logic blocks (ports) on a ring. Each cycle, each port is able to generate a transaction that will pass through a pipeline, a FIFO, and a back-pressured pipeline. If destined for a different port, the transaction will travel the ring to its destination, flow through another pipeline, arbitrate with local traffic, flow through another pipeline and into another FIFO.
A transaction is a collection of signals, or fields . The transaction flow defines the path by which these fields travel through the machine. Unlike structures, transactions “change shape” as their fields are operated upon by transaction logic . Each field travels along its flow from the point at which is is produced to the downstream locations in which it is consumed.
$ANY = $select ? /in1 $ANY : /in2 $ANY ;
Transaction flow is supported in TL-Verilog by one very simple mechanism. $ANY can be used in a logic expression in place of an output signal and one or more input signals.
The expression must be one that transfers an $ANY input to the $ANY outputs, unaltered. An example would be the ternary operator, shown in Fig. 2, which implements a multiplexer, selecting one of two possible input transactions. We call such an expression a flow expression .
Flow expressions can be chained to form a directed graph that defines a flow like the one in Fig. 1. Having established such a flow, fields of the transaction can be assigned anywhere along the flow and consumed anywhere downstream in the flow. They will traverse the flow from their assignments to their downstream uses, as illustrated for the field $priority in Fig. 3.
This creates a decoupling of flow logic and transaction logic, depicted in Fig. 4, similar to the decoupling of timing and behavior in timing-abstract design. Logic expressions can be moved upstream or downstream along their flows by cutting and pasting expressions. While this may affect the implementation dramatically, overall behavior remains unchanged. An expression, of course, cannot be moved upstream of its producers nor downstream of its consumers. The flow takes care of the sequ
This content is AI-processed based on open access ArXiv data.
