[CALU] Pipeline-Register
- From: Günther Wimpassinger <e0525147@xxxxxxxxxxxxxxxxxxxx>
- To: "CALU G. Wimpassinger" <calu-ss2010-tuwien@xxxxxxxxxxxxx>
- Date: Tue, 4 May 2010 18:42:57 +0200
Hallo,
hat sich von euch schon jemand überlegt wie wir die Pipeline-Register
implementieren?
a) Jede Stufe in der Pipeline hat eine VHDL Entity. Zur Stufe selbst
gehört auch das Register, das am Anfang der Stufe steht (in weiterer
Folge Eingangsregister genannt) und übernimmt bei jedem Taktzyklus die
Ergebnisse der davorliegenden Stufe. Dieses Eingangsregister besitzt
auch ein Enable-Signal mit dem die Übernahme der Daten verhindert
werden kann (STALL) und ein Clear-Signal (FLUSH).
In der Architecture (für diese Entity) dieser Stufe werden dann die
Komponenten, die zu dieser Stufe gehören instantiiert und mit Signalen
verbunden.
Den oben beschriebenen Ansatz findet ihr exemplarisch in:
http://www.soc.tuwien.ac.at/files/marca
Unsere Arbeitsaufteilung passt im Moment nicht ganz zu dieser Art der
Implementierung.
b) Nach logischen Einheiten getrennt, Distributed-Pipeline-Register.
Ich versuche es Anhand der SRAM (Daten-RAM) Implementierung
beispielhaft zu erklären. Die Teile des Pipeline-Registers, welche für
den Zugriff auf das SRAM von Bedeutung sind, werden zusammen mit dem
SRAM Zugriff implementiert, und das SRAM Modul übernimmt die Daten von
der EX-Stufe (ohne ein zusätzliches Register).
Schema (ohne Records, sonst wird es unübersichtlich)
[pseusocode]
-- SRAM (WB)
entity SRAM is
port(
clk : std_logic;
stall : std_logic; -- update pipeline reg on rising_edge(clk)
sram_op : sram_op_type; -- NOP, LD , ST (from ID)
rx_val : std_logic_array(DATA_WIDTH-1 downto 0); -- register value of st
alu_val : std_logic_array(DATA_WIDTH-1 downto 0); -- calc'ed address by alu
p_val : std_logic; -- perform operation
...
);
end entity SRAM;
-- ALU (EX)
entity ALU is
port(
clk : std_logic;
stall : std_logic; -- update pipeline reg on rising_edge(clk)
aluop : alu_op_type;
op1 : std_logic_vector(DATA_WIDTH-1 downto 0);
op2 : std_logic_vector(DATA_WIDTH-1 downto 0);
alures : std_logic_vector(DATA_WIDTH-1 downto 0);
aluflags: std_logic_vector(FLAG_WIDTH-1 downto 0);
...
);
end entity ALU;
[/pseusocode]
Bei der Instantiierung von ALU und SRAM wird dann das Signal
"alures" von der Entity ALU mit dem Signal "alu_val" von SRAM
verbunden.
Der Nachteil dieser Methode ist, dass wir mehrere Register haben, die
den selben Inhalt speichern. Beispielsweise wird "alures" sowohl in
SRAM alsauch in STACK benötigt.
*********************
Ich bin am Überlegen, ob es nicht sinnvoll wäre, wenn wir uns am
Mittwoch oder Donnerstag kurz treffen würden, um Fragen und Probleme zu
diskutieren oder zu klären. Oder eine Gruppendiskussion in einem
IM-System (Skype?) das Gruppengespräche zulässt, dann muss ich nicht
extra nach Wien fahren (ca. 75min pro Richtung).
lg
Günther
p.s. @Martin: Hast du das Mail vom Puffitsch bezüglich "generischen
Typen (aka integer/boolean)" gelesen/bekommen? Es sollte theoretisch
auch an die Mailing-List gegangen sein, ich hab sie aber nur einmal
bekommen, darum bin ich mir nicht sicher, ob ihr sie auch bekommen habt.
Other related posts:
- » [CALU] Pipeline-Register - Günther Wimpassinger
