A preliminary architecture for a basic data-flow processor

Dennis, Jack B.; Misunas, David P.

doi:10.1145/641675.642111

Cited by 131 publications

(41 citation statements)

References 5 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Classic dataflow architectures such as [7,1] trigger instructions when tokens associated with input data is ready. Multiple pipeline stages are devoted to marshalling tokens, distributing tokens, and scoreboarding which instructions are ready.…”

Section: Autonomous Pesmentioning

confidence: 99%

Triggered instructions

Parashar

Pellauer

Adler

et al. 2013

Proceedings of the 40th Annual International Symposium on Computer Architecture

View full text Add to dashboard Cite

In this paper, we present triggered instructions, a novel control paradigm for arrays of processing elements (PEs) aimed at exploiting spatial parallelism. Triggered instructions completely eliminate the program counter and allow programs to transition concisely between states without explicit branch instructions. They also allow efficient reactivity to inter-PE communication traffic. The approach provides a unified mechanism to avoid over-serialized execution, essentially achieving the effect of techniques such as dynamic instruction reordering and multithreading, which each require distinct hardware mechanisms in a traditional sequential architecture.Our analysis shows that a triggered-instruction based spatial accelerator can achieve 8× greater area-normalized performance than a traditional general-purpose processor. Further analysis shows that triggered control reduces the number of static and dynamic instructions in the critical paths by 62% and 64% respectively over a program-counter style spatial baseline, resulting in a speedup of 2.0×.

show abstract

Section: Autonomous Pesmentioning

confidence: 99%

Triggered instructions

Parashar

Pellauer

Adler

et al. 2013

Proceedings of the 40th Annual International Symposium on Computer Architecture

View full text Add to dashboard Cite

show abstract

“…Gordon et al discuss a general dataflow like approach called StreamIt [24]. Similar to historical dataflow machines [21,3] the PLUG architecture implements dataflow execution but in a coarse granularity of code blocks and network messages. The conflictfree operation of PLUG pipelines is similar to systolic arrays that execute in a very regular fashion.…”

Section: Related Workmentioning

confidence: 99%

Plug

Carli

Pan²,

Kumar

et al. 2009

Proceedings of the ACM SIGCOMM 2009 Conference on Data Communication

View full text Add to dashboard Cite

New protocols for the data link and network layer are being proposed to address limitations of current protocols in terms of scalability, security, and manageability. High-speed routers and switches that implement these protocols traditionally perform packet processing using ASICs which offer high speed, low chip area, and low power. But with inflexible custom hardware, the deployment of new protocols could happen only through equipment upgrades. While newer routers use more flexible network processors for data plane processing, due to power and area constraints lookups in forwarding tables are done with custom lookup modules. Thus most of the proposed protocols can only be deployed with equipment upgrades.To speed up the deployment of new protocols, we propose a flexible lookup module, PLUG (Pipelined Lookup Grid). We can achieve generality without loosing efficiency because various custom lookup modules have the same fundamental features we retain: area dominated by memories, simple processing, and strict access patterns defined by the data structure. We implemented IPv4, Ethernet, Ethane, and SEATTLE in our dataflow-based programming model for the PLUG and mapped them to the PLUG hardware which consists of a grid of tiles. Throughput, area, power, and latency of PLUGs are close to those of specialized lookup modules.

show abstract

“…Activation frames are certainly not a new idea The use of presence-bits to detect enabled operations is represented in the earliest static dataflow architectures(l5, 16,28].…”

Section: Related Workmentioning

confidence: 99%

Monsoon

Papadopoulos

Culler

1998

25 Years of the International Symposia on Computer Architecture (Selected Papers)

121

View full text Add to dashboard Cite

Dataflow architectures tolerate long unpredictable communication delays and support generation and coordination of parallel activities directly in hardware, rather than assumiug that program mapping will cause these issues to disappear. However, the proposed mechanisms are complex and introduce new mapping complications. This paper presents a greatly simplified ag preach to dataflow execution, called the ezplicil ioken store (ETS) architecture, and its current realization in Monsoon. The essence of dynamic dataflow execution is captured by a simple transition on state bits associated with storage local to a processor. Low-level storage management is performed by the compiler in assigning nodes to slots in an acliunfion frame, rather than dynamically in hardware. The processor is simple, highly pipelined, and quite general. It may be viewed as a generalization of a fairly primitive von Neumann architecture. Although the addressing capability is restrictive, there is exactly one instruction executed for each action on the dataflow graph. Thus, the machine oriented ETS model provides new understanding of the merits and the real cost of direct execution of dataflow graphs.Address I :

show abstract

A preliminary architecture for a basic data-flow processor

Cited by 131 publications

References 5 publications

Triggered instructions

Triggered instructions

Plug

Monsoon

Contact Info

Product

Resources

About