[CALU] Re: decode-stage, Simulation+Dokumentation

  • From: Elshuber Martin <e9825286@xxxxxxxxxxxxxxxxxxxx>
  • To: calu-ss2010-tuwien@xxxxxxxxxxxxx
  • Date: Mon, 17 May 2010 09:31:58 +0200

Am 16.05.2010 23:14, schrieb Benedikt Huber:
Hallo,
die Implementation scheint ja schon ziemlich weit fortgeschritten zu sein, sehr cool, und Dank an die fleissigen!
Das VHDL Moduldesign sieht uebrigens sehr huebsch aus.

Aufgrund der enormen Mengen VHDL Code die ins Repo gespuelt werden, ist es allerdings nicht mehr ganz einfach den Ueberblick zu behalten. Es waere wirklich gut, wenn zumindest pipeline_types.vhd anstaendig kommentiert waere, sowie kurze READMEs / HOWTOs fuer die anderen (ich hab mit src/README und pisp/SIMULATION.HOWTO begonnen). Ich hab das wahrscheinlich auf der Mailing Liste verpasst, aber es waren (a) neue VHDL files fuer die Testbench notwendig und (b) ein rom.hex File musste in den src Ordner kopiert werden, um die Simulation laufen zu lassen.

Was micht zur id_decode stage bringt:
Die Tests schauen schauen ganz gut aus (pred, branch und loadstore sind noch nicht fertig getestet, ich hoff das geht sich heute noch aus). Die seltsame Namensgebung fuers branching allerdings entzieht sich meinem Verstaendniss: - Laut VHDL Code ist bmiss_sel eine Kontrollleitung, die bestimmt wie die Instruktion den program counter veraendert (PC_NEXT,PC_STACK, PC_MISSTGT??). b_op scheint ein Alias fuer (bmiss_sel != PC_NEXT) zu sein. Aber ich versteh noch immer nicht, was bmiss_sel und PC_MISSTGT bedeuten soll - koennte das jemand (in pipeline_types.vhd?) verstaendlich erlaeutern?

lg, benedikt

p.s.:defunct code (ich weiss, ich bin ein schlechtes Vorbild) sollte man nicht in den master pushen
p.s.s.:
ldc r0, 4095
ldc12 r0, 4095
schaut ohne forwarding uebel aus, oder?

zu den branch leitungen.

b_op: gibt an ob der befehl überhaupt ein springbefehl ist oder nicht. wenn (b_op=0) dann wird immer PC_NEXT (alsu normale sequenzielle execution) gewählt, ansonsten wird entschieden ob der sprung richtig oder falsch war. im falle einer miss prediction gibt es 2 quellen wo die korrekte addresse herkommt:
  1) stack (ret,iret)
  2) miss-tgt (b,call)
ad 1) es sollte klar sein warum die quelle der stack ist
as 2) im ersten moment könnte man denken das man den wert für einen fehlgeleiten spurng einfach durch die alu schicken kann (ralu-sel: addresse, lalu-sel: zero, alu_op or), das würde auch für 'b' funktionoiren bei einem call sieht das ganze anders aus: (@ prefix bedeutet absolute adresse)
  bsp: im imem and addresse @5 steht "call @17"
lt spez. soll der proz. annehmen das der sprung nicht ausgeführt wird. die rücksprung adresse ist @6, miss-tgt ist @17, die nächste instr. steht an @6 in der wb-stufe muß bei einem predikat wert von 1 folgendes gemacht werden:
    a) @6 kommt auf den stack
    b) @17 muß in den PC und alle stufen (id/ex/wb) werden geflushed
es müssen also beider adressen bis zum wb gelangen und das geht über die alu aleine nicht.
  daher gibt die leitung miss-tgt (Misspredction Target)

lg martin

Other related posts: