Behavioral Synthesis Methodology for HDL-Based ... - CiteSeerX

Behavioral Synthesis Methodology for HDL-Based Specification and Validation D. Knapp, T. Ly, D. MacMillen, R. Miller Synopsys Inc. 700B E. Middlefield Rd Mountain View, CA USA 94043

Abstract This paper describes a HDL synthesis based design methodology that supports user adoption of behavioral-level synthesis into normal design practices. The use of these techniques increases understanding of the HDL descriptions before synthesis, and makes the comparison of pre- and post-synthesis design behavior through simulation much more direct. This increases user confidence that the specification does what the user wants, i.e. that the synthesized design matches the specification in the ways that are important to the user. At the same time, the methodology gives the user a powerful set of tools to specify complex interface timing, while preserving a user’s ability to delegate decision-making authority to software in those cases where the user does not wish to restrict the options available to the synthesis algorithms.

1.0 Overview This paper describes a synthesis methodology that uses high-level synthesis (HLS) of behavioral hardware-description language (HDL) descriptions. HLS has the distinguishing characteristic that operations are automatically scheduled, i.e. assigned to states, as opposed to lower-level synthesis, in which operations are assigned to states by the user [1, 2, 3]. For example, in an HDL description of a square root function, an operand x would be loaded, a series of operations would follow, and a single result r would be returned. The read x and the write r might be fixed to particular states or times by a communication protocol, but the internal operations that compute the square root would be automatically scheduled. A prospective user of HLS will then ask a number of questions. These will likely include the following: • How can I constrain I/O operations to fall into particular cycles, or range of cycles, to meet existing protocols? • How can I constrain I/O operations to have particular timing relationships? For example, how can I constrain a data ready strobe to be synchronous with data on data ports? • How can I be confident that my interface timing specification really works with the surrounding hardware? • How can I give the scheduling software optimization opportunities when my timing specification is not rigid? For example, I might not care exactly when data was transferred, as long as a corresponding strobe remains synchronized with the data. Thus the strobe and data should be locked together, but the locked strobe/ data pair of operations could move. • How can I be confident that the synthesized hardware will really do what I want it to:

1. In the sense that it computes the right result, 2. In the sense that scheduling of I/O operations does not ‘break’ its I/O protocols. These questions can be reformulated as requirements on the HDL description methodology to be used in conjunction with HLS: • The original HDL description should be simulatable. • There should be a mode wherein the cycle by cycle I/O timing of the original HDL description is preserved exactly; i.e., no I/O timing difference will be allowed between the pre-and post-synthesis descriptions. This will allow direct comparison, on a cycle by cycle basis, of the pre- and post-synthesis designs; it will also allow the user to meet the most rigid cycle-based timing protocols. • There should be a mode wherein timing relationships between I/O signals can be simply and easily preserved across synthesis, but where ‘stretching’ (cycle level delay insertion) is permitted, so that the user does not have to specify exactly how many cycles a computation will take. This mode should allow manual constraints. Such a mode allows comparison of pre- and post-synthesis I/O timing between “similar points” of the pre- and post-synthesis waveforms. • There should be a mode in which the user explicitly specifies all timing constraints without reference to the simulation behavior of the HDL; the only timing constraints inferred from the HDL description are ordering constraints among I/O operations sharing a port. This mode gives the greatest flexibility, both for optimization and for specification of complex timing relationships; it is also the most difficult to use. We call these three modes the cycle-fixed IO scheduling mode, the superstate-fixed IO scheduling mode, and the free-floating IO scheduling mode respectively. Each has consequences for the style of HDL description and validation methodology. These modes give the user a wide range of choices in specifying I/O timing, with a corresponding range of ways in which validation of the specification and comparison of the implementation with the specification can be performed.

1.1

1.2 Copyright 1995 ACM.. This is a preprint, to appear in the DAC ‘95 proceedings. Permission to copy without fee all or part of this material is granted, provided that copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.

Structure of this paper

The balance of this paper is structured as follows. In Section 1.2, related work in this field is discussed. Following that, in Section 2, some mode-independent considerations and assumptions are described. In Section 3, the cycle-fixed mode is described in detail. Then in Section 4, the superstate-fixed mode is described. In Section 5, the free-floating mode is described. In Section 6, experience with the current software is described; finally, in Section 7 the paper is summarized and conclusions are drawn.

Related Work

High-level synthesis has been well described in the literature; see, for example, Camposano[1], Gajski[2], Maerz[3]. These tutorial papers describe the basics of HLS systems. CALLAS [4] describes work in the area of maintaining simulated behavior that is exactly the same pre- and post-synthesis; this idea is reflected

in the cycle-fixed mode described here. The superstate-fixed mode is related the High Level State machine of of [5], and to the behavioral finite state machines (BFSM’s) of [6]. Our approach of validation through simulation is typical of current industry practice; it complements, but cannot completely replace, more formal methods [7].

2.0 Basic assumptions The circuit to be synthesized by HLS consists of a collection of always blocks (VHDL processes); each always block will be mapped to hardware consisting of a datapath and a control FSM. Each will be synthesized separately. Control over timing makes use of clocking statements in the source HDL. In Verilog, this can be done by use of @(posedge clock) or @(negedge clock) statements1. These are used to separate I/O events that are to happen in different clock cycles. Event triggers using other signals are specifically disallowed, with the exception of asynchronous reset and a special gating methodology described in Section 2.2, used for synchronizing I/O.

2.1

Reset

In order to handle resets in an intuitively appealing way, we call attention to the always block (VHDL process) that will be scheduled. In our methodology this block contains a single all-encompassing, nonterminating loop, here called reset_loop. always begin: b1 begin: reset_loop // reset sequence behaviors forever begin // normal mode behaviors end end end Inside reset_loop is a reset sequence; this consists of all behaviors associated with reset. For example, in a microprocessor the reset sequence would clear the program counter, disable interrupts, and initialize the stack pointer. The reset sequence may contain many clock cycles, e.g. to initialize a RAM. Following the reset behavior is the ‘normal mode’ loop, which does not terminate either; this loop contains behaviors that are executed until the next reset occurs. In a microprocessor, for example, the normal mode loop would be the fetch / execute cycle. In order to simulate the effect of synchronous resets correctly in the source HDL description, the user must insert a statement of the form2 if (reset == 1’b1) disable reset_loop; after every @posedge statement. This disable has the effect of restarting the block (process) following a clock edge upon which reset is found to be true. Simulation of synchronous resets can be matched both pre- and post-synthesis. Another capability can also be provided in which the user declares a reset pin to the synthesis software, which then synthesizes the reset; but because the reset behavior is not encoded in the HDL, resets cannot be simulated correctly before synthesis using this technique. Scheduling cannot handle exits triggered by a reset in the same way as other exits, because there may be read-before-write accesses in

1. In VHDL “wait until clock’event and clock = ‘1’;” gives us a rising-edge clock. 2. In VHDL this would be “when reset = ‘1’ exit reset_loop”.

the HDL. Consider the following: In this situation, the assignments begin: reset_loop outport