[CALU] Integration der Module in die Pipelinestufen
- From: Günther Wimpassinger <e0525147@xxxxxxxxxxxxxxxxxxxx>
- To: "CALU G. Wimpassinger" <calu-ss2010-tuwien@xxxxxxxxxxxxx>
- Date: Thu, 6 May 2010 23:02:40 +0200
Hallo Kollegen,
ich möchte einige Wörter über die Integration der Module in unser
Pipeline-Design verlieren.
Grundsätzliches:
Jede Stufe beginnt mit einem großen Register, dem Pipeline-Register. In
diesem Register werden die Ergebnisse der Stufe davor bei einer
steigenden Taktflanke übernommen.
Das sieht bsp. für EX in etwa so aus:
ex_pipe:process(clk,reset) is
begin
if reset=RESET_ACTIVE then
-- clear pipeline register with pipe init id2ex_reg <=
id2ex_empty;
elsif rising_edge(clk) then
if flush then
-- clear pipeline register
id2ex_reg <= id2ex_empty;
elsif stall then
-- preserve pipeline register, do nothing
else
-- store input values
id2ex_reg <= id2ex;
end if;
end if;
end procress;
Die Predicates/Register die in einer Stufe gespeichert werden, sind aus
meiner Sicht auch ein Teil des großen Pipelineregisters. Nur werden sie
nicht direkt von einer anderen Stufe übernommen, sondern es existiert
ein zusätzliche kombinationistische Logik (kombinatorisch klingt so
nach (n über k)) die das Schreiben übernimmt. Lesen ist ja sowieso kein Problem.
Diese komb. Schreibprozess macht nichts anderes als bestimmt wohin und
ob ein Wert aus WB überhaupt übernommen wird.
pred_regs: process(clk,reset) is
begin
if reset = RESET_ACTIVE then
preds <= preds_reset_value;
elsif rising_edge(clk) then
preds <= preds_next;
end if;
end process;
-- Bei den Predicates kommt der komplett neue Satz
-- an Werten daher, bei den Registern hat man nur
-- einen neuen Wert, den man an eine bestimmte
-- Register-Adresse schreiben muss.
pred_comb:process(wb2ex) is
begin
preds_next <= preds;
if wp_en='1' and <other things> then
preds_next <= some_logic;
end if;
end process;
pred_sel:process(id2ex,wb2ex) is
begin
-- forwarding not used here for clarity
pa_val <= preds(TO_INTEGER(unsigned(id2ex.ra)));
pb_val <= preds(TO_INTEGER(unsigned(id2ex.rb)));
end process;
Momentan hat Martin seine Register noch in einer eigenen Entity.
Prinzipiell kein Problem, wenn es so klar gekennzeichnet ist, wie in
seinem Fall. Man muss nur darauf achten, dass man nicht den Überblick
verliert, was wann wo gespeichert wird.
Um obiges Konzept umzusetzen habe ich ein 2stufiges
Typedefinitionsschema angewendet. Daten die zwischen Pipeline-Stufen
ausgetauscht werden, werden
über Records im File "pipeline_types.vhd" definiert. Um Daten innerhalb
einer Stufe zu verschieben, gibt es "xx_stage_types.vhd". Das dabei verwendete
Namensschema ist einfach <stage>2<module>_type oder
<module>2<stage>_type bzw. <stagefrom>2<stage>_type. Das ist aber
Geschmackssache. Hab das aus HW-Mod so übernommen.
lg
Günther
Other related posts:
