Dringlichkeit vs Frühzeitigkeit Folie 126

[mProg]

Ich verstehe hier nicht, warum enq_item starven würde, wenn infifo ein Wert hätte und outputfifo auch Platz hätte. Ich verstehe nicht, wo genau wir eine write<read Konflikt bekommen, der dazu führt dass enq_item starvt. Ich habe diesen Code geschrieben:

Code: Alles auswählen

	module mkFifo();
		Reg#(int) bubbles <- mkReg(0);
		FIFO#(int) outfifo <- mkSizedFIFO(10); // to buffer incoming requests
		FIFO#(int) infifo <- mkFIFO;
		Reg#(int) state <- mkReg(0);
		Foo foo <- mkFifoModule;
		Reg#(int) max_bubble <- mkReg(4);
		// Connect flow of requests from stimulus generator to DUT
		
		rule infifoin;
			$display("infifoin(%d)",$time);
			infifo.enq(10);
		endrule
		//(* descending_urgency = "enq_item, enq_bubble" *)
		rule enq_item;
			$display("enq_item (%d)", $time);	
			outfifo.enq(infifo.first);infifo.deq;
			bubbles <= 0;
		endrule
		
		rule enq_bubble;
			$display("enq_bubble (%d)", $time);
			outfifo.enq(5);
			max_bubble <= max(max_bubble,bubbles);
		endrule
		
		rule finisher;
			if(state == 5)$finish;
			state <= state +1;
		endrule
			
		rule inc_bubbles;
			$display("inc_bubble (%d)", $time);
			bubbles <= bubbles + 1;
		endrule
		
		
	endmodule

Und da outfifo Platz hat und in infofo Wert vorhanden ist, starvt enq_item nicht.

[Roey]

ich glaube, dass der konflikt daraus resultiert, dass enq_item _write auf bubbles anwenden will, inc_bubbles jedoch auch read. Folglich wäre die Reihenfolge _write < _read (da enq_item < inc_bubbles) welches jedoch der Reihenfolge von Registern (_read < _write) widerspricht und daher wird der Kompiler enq_item die Freigabe entziehen.

Korrigiert mich wenn ich mich irre ^^

/edit : PS. ich beziehe mich dabei auf den Code der von dir gegebenen Folie

[mProg]

Dann würde erst inc_bubbles und dann im selben Takt enq_item ausgeführt werden. Aber enq_item würde nicht starven, sondern beide werden im selben Takt ausgeführt werden. Jedoch wurde in der Aufzeichnung gesagt, dass enq_item starven würde. Das verstehe ich nicht

[Roey]

oh habe mich ohnehin verlesen. ist
(* descending_urgency="enq_item, enq_bubble" *)

und nicht

(* descending_urgency="enq_item, inc_bubble" *)



aber denke dennoch , dass es einen konflikt gibt weil beide auf das selbe Register schreiben.
Bin mal gespannt, was die Begründung ist ^^

[Fabian Czappa]

Hallo ihr 2,

ich hab den Code einfach mal kompiliert (mit ein paar kleinen Änderungen), dazu die Compilerwarnung:

Code: Alles auswählen

Warning: "test.bsv", line 3, column 9: (G0010)
  Rule "enq_item" was treated as more urgent than "enq_bubble". Conflicts:
    "enq_item" cannot fire before "enq_bubble":
      calls to
	bubbles.write vs. bubbles.read
	outfifo.enq vs. outfifo.enq
    "enq_bubble" cannot fire before "enq_item":
      calls to outfifo.enq vs. outfifo.enq
Warning: "test.bsv", line 3, column 9: (G0117)
  Rule `enq_item' shadows the effects of `inc_bubbles' when they execute in
  the same clock cycle. Affected method calls:
    bubbles.write

Da ist ersichtlich, was genau das Problem ist:
Man kann nicht lesen, nachdem man geschrieben hat und man kann nicht 2 Items im gleichen Takt einfügen. Merke hier, dass enq_item tatsächlich als wichtiger als enq_bubble behandelt wurde, obwohl ich innerhalb des Codes keinen Einfluss auf die Reihenfolge genommen habe. Bei mir würde es also nicht "starven".

Viele Grüße
Fabian

[mProg]

Ich hab den Code einfach mal kompiliert (mit ein paar kleinen Änderungen)

Aus Interesse, was musstest du ändern? Der Code hat doch funktioniert?

[Fabian Czappa]

Hay,
Ich hab oben

Code: Alles auswählen

import FIFO::*;

eingefügt,

Code: Alles auswählen

Foo foo <-mkFifoModule;

entfernt und das Scheduling-Attribut

Code: Alles auswählen

(* descending_urgency = "enq_item, enq_bubble" *)

erst einmal einkommentiert und danach rausgelöscht. Ohne bzw. mit die/ den oberen 2 Zeilen hat es nicht funktioniert.
Viele Grüße
Fabian