Conclusions and Possible Extensions

In this chapter, I presented a strategy for exposing timing constraint violations in high-speed asynchronous pipelines, including pipelines with forks and joins. I showed that our test- ing strategies are applicable by giving examples from three different pipeline styles: GasP_,

MOUSETRAP_{, and}HC_{. This testing strategy is non-intrusive for linear pipelines and minimally-} intrusive for pipelines containing forks and joins. In addition, all of these tests can be con- ducted using low-speed testing equipment.

I also demonstrated one specific application of this strategy. Using MOUSETRAP _{as an} example, I showed how our testing strategies work for both straight paths and paths with forks and joins. We also showed how to generate test patterns forMOUSETRAP_{that are robust to}

the non-deterministic nature of errors caused by timing constraint violations. This method leverages past ATPG tools.

There are several natural future opportunities to this work. Although many delay con- straints are either forward or reverse constraints, there are still other kinds of timing con- straints to identify and develop test strategies for. By testing pipelines with forks and joins, this work took one step towards testing pipelines with arbitrary topologies. We still need to incorporate testing of more complex pipeline stages, such as data dependent conditional forks. In addition, one could apply the testing strategies presented here to circuits with non-trivial combinational logic.

Finally, there is a subtle limitation of the current test approach forMOUSETRAP_{: the setup} fault test approach will actually not be able to expose a setup violation in a stage if data has accumulated positive margins in prior stages. In particular, positive timing margins in prior stages sometimes rescue a small timing violation in a later stage, very much like time borrowing in synchronous systems, allowing the pipeline to still operate correctly. While this feature makesMOUSETRAP_{even more robust, if the intent of the test strategy, however, is to} expose even these types of violations, then this setup fault test strategy needs to be enhanced further.

Chapter 7

Circuit Designs

7.1

Introduction

In previous chapters, all the pipelined circuits introduced and discussed were assumed to have efficient and robust implementations. Moreover, these implementations were also assumed to be capable of modular composition with other stages (i.e. preceding and succeeding stages need not be aware of the internal behavior or implementation). This chapter introduces the implementation of five types of special-purpose pipeline stages: conditional split, conditional select, conditional join, merge without arbitration, and an arbitration stage.

Together with pipeline stage designs introduced in previous literature [55], these stages form a comprehensive suite of circuits that can be combined modularly to create any of the hierarchical circuits described in previous chapters. The circuits presented here represent one possible set of circuits that can be used to implement any of the hierarchical, dataflow circuits that are the focus of this thesis.

Section 7.2 first presents background work on the MOUSETRAP _{pipelines that the new} circuits are designed to work with. Section 7.3 then goes on to describe the behavior of components that are needed to implement each type of construct used by analysis algorithm of Chapter4: sequential, parallel, conditional, and iterative constructs.

ponent is described using gate-level diagrams, and the operation of the component is given in detail. In addition, many of the components have several different implementations that rep- resent tradeoffs between speed and robustness. Each circuit includes a synchronization point performance analysis, which will yield the performance metrics necessary to complete the type of analysis presented in Chapter4. The description of each implementation also includes the forward and reverse timing constraints, which are an important part of the testing method introduced in Chapter6.

7.2

Background

The work of [55] presents the MOUSETRAP _{pipeline style.} MOUSETRAP _{is a two-phase} pipeline style that uses transition signaling. A transition from high to low or from low to high on the request line indicates that a new data is present, and a similar transition on an acknowledge line indicates that the data has been received and stored.

7.2.1

Linear

Pipeline Stage

The MOUSETRAP _{linear pipeline has a very simple implementation, which uses only one} xnoras the control element. Figure7.1shows a linear pipeline stage implementation, as first described in [55].

The forward and reverse delay metrics for aMOUSETRAP_{stage are given below.} Forward Latency: tlatch+tlogic

Reverse latency: txor+tlatch

7.2.2

Fork

Figure7.2 shows aMOUSETRAP_{stage that is capable of sending requests to and processing} acknowledges from two successor stages. The MOUSETRAP _{fork stage takes one incoming}

req

ack

ack

req

data

_data

Figure 7.1: A basicMOUSETRAPstage from [55]

c req_P ack₀ ack1 req_N ack_P

Figure 7.2: AMOUSETRAP_{fork stage from [55]}

request from its predecessor stage and forks the outgoing requests to its successor stages. In the figure, the same request signalreqN is sent to both of the successor stages.

The fork combines the incoming acknowledges from the successor stages with a c-element. As a result, the latch controller will not signal the latch to become transparent until after both acknowledges have arrived.

7.2.3

Join

Figure7.3shows aMOUSETRAP_{stage that can receive requests from two predecessor stages} and send a combined request on to a successor stage. TheMOUSETRAP_{join stage combines}

c

req₀

req₁ reqN

ack_N

ack_P

Figure 7.3: AMOUSETRAP_{join stage from [55]}

together the incoming requests from two separate stages using a c-element. The outgoing request does not change untilbothof the incoming requests have changed. The logic within a particular join stage will determine what calculations take place using the joined data.