Ich hab das 2.te diagramm mal erweitert und 2 forwarding stufen eingebaut. 1) das alu ergebnis kann als eingabe für die nächste op (ra,rb,rx) dienendas ist möglich da das predikat schon in dieser stufe bekannt ist, (es wird vom WB weitergeleitet)
2) das wb.ergebnis kann als eingabe für das rx, im WB dienen pred r1>r2, p1add r2,r2,r2 (p1) // kein stall notwendig, forwarding des predikats in die EX stufe xor r3,r2,r1 // kein stall notwendig (predikat von add schon bekannt, forwarding möglich)
ld r1,r3+5 add r2,r1,r2 // stall 1 cycle in der EX stufe ld r1,r3+5st r1,r3+5 // kein stall nötig r1 (rx) kann von WB nach WB weitergeleitet werden
meiner meinung nach sollte man das forwarding schon implementieren warum? 1) natürlich performance2) wir brauchen sowieso hardware um data hazards zu erkennen. ob man dann noch eine multiplexer leitung dazubaut oder nicht ist meiner ansicht nach schon fast egal
was emint ihr? g martin Am 02.05.2010 12:58, schrieb Elshuber Martin:
ich hab eine 2te versaion des block diagrammes gebastelt. änderungen:prediacate werden in der EX stufe gelesen: das vermindert stalls, und den kritischen pfad im WBweiters wäre es dadurch denkbar forwarding besser zu imlementierendie kosten sind allerdings das wir ein forwadring vom WB nach EX für predikate basteln müstenshaut es euch mal an g martin Am 30.04.2010 02:09, schrieb Elshuber Martin:das ding schaut schaut leider ein bischen wild aus, da ich ziemlich alle leitungen eingezeichnet habe. die predicates die vor dem stack sind verlängen den kritischen pfad nicht, da nur die preds (alle 16) in den stack gemuxed werden. sie sind allerdings schon immer am anfang des zyklus stabil am ausgang, da predpush, bzw der interupt controller den wert der predikate nicht vverändern können/müssen.wümsche, beschwerden anregungen bitte an mich. lg martinps.: ich habe auch die predikat semantik gemacht, und das diagramm in diverse formate exportiert.