BEs dienen ausschließlich als Grenze zwischen picoPIPE-Fabric und FPGA-Frame. Sie sind dafür zuständig, bei ankommenden Daten „Data Tokens“ aus dem Frame in „Data Tokens“ in der picoPIPE-Fabric zu verwandeln. Umgekehrt konvertieren sie bei abgehenden Daten die „Data Tokens“ in der Fabric in „Data Tokens“ im Frame. Jedes Signal, das in die picoPIPE-Fabric hinein oder aus ihr herauskommt, durchläuft somit die Boundary-Elemente (Bild 4).
Wichtig ist der Hinweis, dass pico- PIPE-Stufen auch keine Daten enthalten können. Es gibt also drei gültige Zustände, nämlich Data-1, Data-0 und No-Data. Dies ist einer der Gründe dafür, dass das Hinzufügen einer Pipelinestufe nicht zu einer Veränderung der berechneten Logikfunktion führt.
Die picoPIPE-Fabric implementiert synchrone Logik durch die Wahrung eines exakt äquivalenten Verhaltens. Ermöglicht wird diese Äquivalenz durch mehrere besondere Merkmale der Achronix-FPGAs und der pico- PIPE-Technologie. FEs übernehmen die kombinatorischen Berechnungen und implementieren die von der eingegebenen RTL-Beschreibung definierte Logik. CEs sind sowohl für die Konnektivität (lokales und globales Routing) als auch für die Speicherung (Register) zuständig, die eine synchrone Berechnung ermöglichen. In der FPGA-Architektur enthalten die LUTs sowohl FEs als auch CEs, während sich in den Switch-Blöcken ausschließlich CEs befinden.
Der konventionelle I/O-Frame gewährleistet, dass jedes „Data Token“ genau bei einer Taktflanke in den picoPIPE-Core eintritt und dass auch jedes „Data Token“, welches den pico- PIPE-Core verlässt, genau bei einer Taktflanke herausgetaktet wird. Die funktionale Beziehung der Ein- und Ausgänge zwischen dem von der RTLBeschreibung spezifizierten Design und der an den Außengrenzen des Frame zu beobachtenden, tatsächlich implementierten Funktionalität ist sichergestellt. Die Grenz-Elemente bieten die Gewähr, dass jedes gültige „Data Token“ im Frame (Daten am Eingang bei einer Eingangs-Taktflanke) zu einem „Data Token“ im picoPIPECore wird. Ähnlich ist es am Ausgang: Jedes „Data Token“, welches den picoPIPE-Core verlässt, wird zu einem gültigen Datensignal, sobald es in den Frame getaktet wird (d.h., wenn ein Datensignal aus dem Core herausgetaktet wird). Die Zahl der „Data Tokens“, die in den picoPIPE-Core hinein- und aus ihm herauskommen, ist identisch mit der Zahl, die sich bei der Implementierung des Cores mit konventioneller Logik ergeben würde.
Eine weitere Überlegung betrifft die Zahl der Speicherelemente im ursprünglichen Design. In getakteter Logik traditioneller Art wird jedes Speicherelement mit einem Register implementiert, welches sein eigenes internes „Data Token“ erzeugt. Da CEs für den State-Holding-Modus konfiguriert werden können, wird für jedes Speicherelement im ursprünglichen Design ein CE initialisiert, um ein anfängliches „Data Token“ hinzuzufügen. Die Zahl der in der picoPIPE-Implementierung spezifizierten internen „Data Tokens“ stimmt deshalb mit derjenigen im ursprünglichen Design genau überein.
Es ist den fein strukturierten Pipelinestufen zu verdanken, dass Achronix- FPGAs einen höheren Durchsatz erzielen als existierende FPGAs. Im Unterschied zu den bestehenden FPGA-Implementierungen können diese Pipelinestufen an beliebigen Stellen eines Designs automatisch eingefügt werden, ohne dass sich dessen logische Funktionalität verändert.
Wie Bild 5 zu entnehmen ist, befinden sich häufig mehrere Logik-Ebenen zwischen den Speicherelementen. Daten benötigen eine gewisse Zeit, um vom Q-Ausgang eines Registers durch die kombinatorische Logik bis an den D-Eingang des nächsten Registers zu gelangen und sich dort zu stabilisieren. Da die Taktflanke erst dann kommen darf, wenn sich alle Datensignale eingeschwungen haben, darf die Taktperiode nicht kürzer sein als die Signallaufzeit auf dem längsten Signalweg in der betreffenden Taktdomäne. Die Daten auf sämtlichen Pfaden, die kürzer sind als der längste Pfad (per Definition also auf allen Pfaden minus einem), müssen auf den längsten Pfad warten.
In krassem Gegensatz dazu stehen die Verhältnisse in der picoPIPE-Technologie, die ein optimales Pipelining ohne Abändern der Logik-Funktionalität ermöglicht (Bild 5). Jede Pipelinestufe hat eine geringere Logiktiefe und führt ihre Operationen dementsprechend sehr schnell aus. Die Rate der „Data Tokens“ durch die Logik lässt sich dadurch anheben, was wiederum die effektive Taktrate erhöht (zur Erinnerung: In der picoPIPETechnologie sind „Data Tokens“ eine Kombination aus gültigen Daten und einer Taktinformation).