עד כה יכולנו להריץ פקודה אחת בכל פעם במעבד, אך גם ב-$MultiCycle$ יש מקום לשיפור שכן עדיין יש רכיבים שעומדים ולא עושים כלום למשך זמן מה.
כעת אנו עומדים לצנרר את המעבד, זה ייתן לנו שיפור ב-$throuput$ אך לאור העובדה שכל פקודה כעת צריכה לעבור את כל השלבים, זאת בניגוד ל-$MultiCycle$, וגם לאור העובדה שאין פלופים אידיאליים - ה-$latency$ יהיה גבוהה יותר - שזה רע.

כך נראה מעבד מצונרר:
​
נוכל לבצע אבסטרקציה ולקבל:
​
לכאורה נראה שרימינו פה - אנו משתמשים ב-$regfile$ פעמיים - איך זה יכול להיות?

• קריאה מהרגיסטר, שזה הדבר היחיד שמתבצע בשלב ה-$decode$, היא אסינכרונית ולכן יכולה להתבצע בכל זמן.
• כתיבה לרגיסטר, שזה הדבר היחיד שמתבצע בשלב ה-$writeBack$, היא סינכרונית ולכן נוכל לבצע אותה שכן אנו לא מבצעים עוד פניות סינכרוניות לרגיסטר.

בשונה מ-$MultiCycle$ אנו לא צריכים את ה-$MicroCodeController$ ואנו יכולים להשתמש ב-$ROM$ רגיל.
אך יש לנו בעיה - אנו צריכים סיגנלי בקרה מסויימים עבור כל שלב בצינור - איך נפתור זאת? נשרשר את סיגנלי הבקרה באמצעות רגיסטרים גם כן.
כדי שזה יהיה יעיל, אנו נעביר רק את הסיגנלים שאנחנו צריכים:
​

$Hazard$

יש לנו שלושה סוגי האזארדים:

1. מבני -$Structural$
2. נתונים - $Data$
3. בקרה - $Control$

מבני

הבעיה: שתי פקודות או יותר מתחרות על גישה לאותו משאב פיזי.
פתרון 1: גישה סדרתית, לפי תור, למשאב. חלק מהפקודות נאלצות להמתין.
פתרון 2: הוספת חומרה למכונה.

נתונים

אם נניח יש לנו שתי פקודות שמשתמשות ברגיסטר כאשר הראשונה משנה אותו והשניה משתמשת בו והן בהפרש הקטן מ-$4$ פקודות, הערך החדש של הרגיסטר לא ישמר.
​
איך נוכל לדאוג שזה לא יקרה?

1. נוכל לפתור זאת באמצעות השהייה אבל, אנו נקבל בועה. כלומר, לא תתבצע שום פקודה עד שהפקודה תשמר.
2. נוכל לפתור זאת בדרך טובה יותר באמצעות קידום נתונים. פה אנו שולפים את האופרנד ישירות משלב בצינור במקום להמתין לכתיבה שלו בחזרה ב-$RegFile$.
   ​
   וכך זה נראה ב-$datapath$:
   ​

add x1,x1,x2
add x1,x1,x3
add x1,x1,x4

$DataHazard$ כפול

נממש כעת את הביעבוע הזה שהוא האפשרות היחידה שלנו לפתור את הבעיה שראינו.
​
במבחן הם ידרשו להגיד לנו האם למעבד יש $Hazard\;Detection\;Unit$ או לא - אנחנו לא אמורים לדעת לבד.

בקרה

נניח ואנו מבצעים פקודת $branch$, הקפיצה תבוצע לכל הפחות בשלב ה-$execute$ אך עד שהיא תקרה, שתי הפקודות הבאות יכנסו לצינור.
אם אנו קפצנו, שתי הפקודות הללו לא היו אמורות להתבצע.
⟸ על מנת לפתור זאת, אם הקפיצה כן נלקחת, נבצע $flash$ ע"י המרת הפקודות הללו ל-$NOP$.
⟸ כל $branch$ שנלקח ב-$pipeline$ פשוט עולה לנו ב-$2$ מחזורים 'ריקים'.

על מנת לשפר ביצועים, ניתן להשתמש ב"חיזוי קפיצות" כדי לנחש את כיוון ה-$branch$ מוקדם יותר ב-$pipeline$.
⟸ רק במקרה שהחיזוי התגלה כשגוי נבצע $flash$.

תרגול

main: addi t1,x0,1
      lw t0, 0(x0)
loop: sub t0,t0,t1
	  bne t0,x0,loop
	  addi t2,x0.0xf
	  nop
	  nop
	  nop
	  nop
	  nop

פתרון א':
​

פתרון ב':
התוכנית תקח עד אשר כל הפקודות יתבצעו לא כולל ה-$nop$-ים ולכן, $14$ מחזורי שעון!

lw t2, 1000(t5)
add t3,t1,t2
sub t2,t1,t2
addi t0,t2,10

תחילה אנו רואים שאנו טוענים את $t_{2}$ ואז ישר משתמשים בו בפקודה הבאה ולכן, נדרש פה לבצע הכנסה של $nop$ כדי להשהות את ביצוע התוכנית למשך מחזור שעון אחד.
כעת, בזכות הכנסת ה-$nop$, נוכל לבצע $Forwarding$ מ-$WB$ ל-$EXE$
לאחר מכן אנו שוב משתמשים ב-$t_{2}$ בפקודה הבאה, אך הפעם זה לאחר שעשינו $nop$ אחד ולכן, נוכל לבצע $Forwarding$ מ-$WB$ ל-$ID$.
לאחר מכן אנו שוב משתמשים ב-$t_{2}$ ולכן, מכיוון שזה ערך חדש וזו פקודה שמגיעה ישר אחרי, נוכל לבצע $Forwarding$ מ-$MEM$ ל-$EX$.

אנו יודעים כי לא יכולים להיות לנו בעיות $data$ או $load$ ולכן כל תוכנית אשר מכילה פקודות $R\;type$ בלבד תרוץ כהלכה.
אם הקפיצה תתרחש בשלב ה-$decode$ אז נגלה יותר מוקדם מה אנו נדרשים לבצע ואז לקפוץ מוקדם יותר ולבצע $flash$ מוקדם יותר, אך נשים לב כי זה לא מתרחש עבור כל תוכנית, אלא רק בתוכנית עם $branch$ שקופץ.
בהתאם להנ"ל - 2 לא נכון גם כן.
אם אנו מקבלים החלטה על $branch$ בשלב ה-$WB$, כפי שנתון בשאלה, והפקודה הבאה היא $sw$ ששומרת בזיכרון, היא כבר הגיעה לשלב ה-$MEM$ והיא שומרת שם ערך כשאנחנו לא אמורים ולכן תוכנית זו לא תרוץ כהלכה. (טענה 3 נכונה)

בהמשך לשאלה, אם נוסיף למעבד $forwarding,\;hazard\;det ection\;unit$, זה לא ישנה כלום!!