H3.1.3c) "Möglichst geringe Latenz"

akmon
Windoof-User
Windoof-User
Beiträge: 27
Registriert: 20. Okt 2009 18:58

H3.1.3c) "Möglichst geringe Latenz"

Beitrag von akmon »

Hi,

wir sind uns nicht ganz einig was mit der "möglichst geringen Latenz" gemeint ist.

Heißt es, das in einem Takt das Ergebnis berechnet werden soll? Oder reicht es, wenn die Anzahl der Takte, die benötigt werden um das Ergebnis zu berechnen kleiner ist als die Anzahl der Bits der Polynome datain_a bzw. datain_b?

Thorti
BSc Spammer
BSc Spammer
Beiträge: 1047
Registriert: 1. Dez 2003 11:52
Wohnort: Frankfurt
Kontaktdaten:

Re: H3.1.3c) "Möglichst geringe Latenz"

Beitrag von Thorti »

Hallo,

wenn ihr es in 1 Takt schafft, ist das natürlich super. Schaut mal was ihr so hinbekommt.

Gruß
Thorsten
Assistent zur Vorlesung TGDI im WS 11/12

Linh
Erstie
Erstie
Beiträge: 17
Registriert: 13. Dez 2010 16:12

Re: H3.1.3c) "Möglichst geringe Latenz"

Beitrag von Linh »

Hallo,

bedeutet das, lieber einen Takt, der wenn das Modul synthetisiert und verkabelt ist, der eine höhere Taktperiode besitzt, als mehrere Takte, der wenn das das Modul synthetisiert und verkabelt ist, eine niedrigere Taktperiode besitzt?
Also z.b 1 Takt mit 10ns vs 3 Takte mit 2 ns?

Also im Zweifel versuchen die ganze Rechnung auf eine kombinatorische Schaltung zu optimieren, obwohl diese am Ende eine längere Zeit zu Berechnung brauchen könnte, durch die ettliche Anzahl an verwendeten Gattern?

Danke

Gruß Linh

Thorti
BSc Spammer
BSc Spammer
Beiträge: 1047
Registriert: 1. Dez 2003 11:52
Wohnort: Frankfurt
Kontaktdaten:

Re: H3.1.3c) "Möglichst geringe Latenz"

Beitrag von Thorti »

Hallo,

wir betrachten ja sowieso keine Ergebnisse nach dem Place & Route. Von daher zählt hier die möglichst geringe Anzahl Takte.

Gruß
Thorsten
Assistent zur Vorlesung TGDI im WS 11/12

Benutzeravatar
Ibliss
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 209
Registriert: 11. Apr 2008 04:08
Wohnort: Darmstadt

Re: H3.1.3c) "Möglichst geringe Latenz"

Beitrag von Ibliss »

Thorti hat geschrieben:Hallo,

wir betrachten ja sowieso keine Ergebnisse nach dem Place & Route. Von daher zählt hier die möglichst geringe Anzahl Takte.

Gruß
Thorsten
Ich habe für beide Teilaufgaben rein kombinatorische Lösungen. Sie liefern Ergebnisse in einem Takt. Meine Module besitzen keine Register. Ist es mir zugelassen den Eingang clk zu ignorieren?
"Honesty is the first chapter in the book of wisdom.
Alien vs Predator 2 is the movie version of that book."

franzose
BASIC-Programmierer
BASIC-Programmierer
Beiträge: 146
Registriert: 9. Okt 2009 00:08

Re: H3.1.3c) "Möglichst geringe Latenz"

Beitrag von franzose »

Ibliss hat geschrieben: Ich habe für beide Teilaufgaben rein kombinatorische Lösungen. Sie liefern Ergebnisse in einem Takt. Meine Module besitzen keine Register. Ist es mir zugelassen den Eingang clk zu ignorieren?
diese Frage würde mich auch interessieren, denn meine Ergebnisse sind valid, sobald enable gesetzt ist. Also benötige ich clk und reset auch nicht.

Thorti
BSc Spammer
BSc Spammer
Beiträge: 1047
Registriert: 1. Dez 2003 11:52
Wohnort: Frankfurt
Kontaktdaten:

Re: H3.1.3c) "Möglichst geringe Latenz"

Beitrag von Thorti »

Hallo,

wenn ihr eine rein kombinatorische Lösung habt, braucht ihr den Takt nicht zu verwenden.

Gruß
Thorsten
Assistent zur Vorlesung TGDI im WS 11/12

daehn
Erstie
Erstie
Beiträge: 16
Registriert: 5. Okt 2010 13:42

Re: H3.1.3c) "Möglichst geringe Latenz"

Beitrag von daehn »

Haben die Teilaufgaben 3.1 a) und 3.1 c) unterschiedliche Zielvorgaben im Sinne von: grundlegend andere Implementierungen?
In a) verstehe ich "Achten Sie auf eine effiziente Implementierung." vor allem als "verwenden Sie möglichst wenige Gatter" und weniger als Optimierung auf Geschwindigkeit.
In b) dagegenen ist "Achten Sie auf eine möglichst geringe Latenz." wie hier schon besprochen als "Das Ergebnis muss in möglichst wenigen Takten am Ausgang anliegen" zu verstehen, insbesondere eine kombinatorische Lösung, bei der das Ergebnis in 1 Takt bzw sofort anliegt also das Optimum.

Ist es also notwendig in a) z.B. mit sequentieller Logik arbeiten zu müssen, weil andernfalls die Anzahl der Gatter zu groß wird? Oder wäre hier eine kombinatorische Lösung ebenfalls korrekt, weil sie zwar viele Gatter verwendet, aber ja auch "mehr leistet" als eine sequentielle Schaltung?

Sete
Erstie
Erstie
Beiträge: 20
Registriert: 18. Mai 2010 14:00

Re: H3.1.3c) "Möglichst geringe Latenz"

Beitrag von Sete »

daehn hat geschrieben:Haben die Teilaufgaben 3.1 a) und 3.1 c) unterschiedliche Zielvorgaben im Sinne von: grundlegend andere Implementierungen?
In a) verstehe ich "Achten Sie auf eine effiziente Implementierung." vor allem als "verwenden Sie möglichst wenige Gatter" und weniger als Optimierung auf Geschwindigkeit.
In b) dagegenen ist "Achten Sie auf eine möglichst geringe Latenz." wie hier schon besprochen als "Das Ergebnis muss in möglichst wenigen Takten am Ausgang anliegen" zu verstehen, insbesondere eine kombinatorische Lösung, bei der das Ergebnis in 1 Takt bzw sofort anliegt also das Optimum.

Ist es also notwendig in a) z.B. mit sequentieller Logik arbeiten zu müssen, weil andernfalls die Anzahl der Gatter zu groß wird? Oder wäre hier eine kombinatorische Lösung ebenfalls korrekt, weil sie zwar viele Gatter verwendet, aber ja auch "mehr leistet" als eine sequentielle Schaltung?
Ich schließe mich der Frage an. :wink:

Thorti
BSc Spammer
BSc Spammer
Beiträge: 1047
Registriert: 1. Dez 2003 11:52
Wohnort: Frankfurt
Kontaktdaten:

Re: H3.1.3c) "Möglichst geringe Latenz"

Beitrag von Thorti »

Hallo,

der grundlegende Unterschied ist eigentlich, dass in a) das Polynom nicht vorgegeben ist.
In a) ist eine sequentielle Lösung in Ordnung. Das effizient bezieht sich hier darauf, sich bei der Implementierung Gedanken zu machen wie man es möglichst gut in Hardware umsetzt. Hierbei darf die Latenz ruhig größer als 1 Takt sein. Falls der gewählte Lösungsweg rein kombinatorisch ist, wäre das auch OK. Die Vor/Nachteile der gewählten Lösung (und evtl. auch ein Vergleich mit einer nicht gewählten Lösung und Begründung für die Wahl) gehören in Teil b).
In c) ist explizit gefordert, dass die Latenz (Anzahl der Takte) möglichst gering sein soll. Wie gering sie ist, kommt auf den Lösungsweg an.

Gruß
Thorsten
Assistent zur Vorlesung TGDI im WS 11/12

AlexanderF
BASIC-Programmierer
BASIC-Programmierer
Beiträge: 140
Registriert: 2. Mai 2010 17:55

Re: H3.1.3c) "Möglichst geringe Latenz"

Beitrag von AlexanderF »

Thorti hat geschrieben: In a) ist eine sequentielle Lösung in Ordnung. Das effizient bezieht sich hier darauf, sich bei der Implementierung Gedanken zu machen wie man es möglichst gut in Hardware umsetzt. Hierbei darf die Latenz ruhig größer als 1 Takt sein. Falls der gewählte Lösungsweg rein kombinatorisch ist, wäre das auch OK.
Also wenn man a) auch kombinatorisch lösen darf, ist es dann also in Ordnung wenn die Lösung der Aufgabe a) fast genauso aussieht wie die Lösung der Aufgabe c) ?
(also bis auf den Unterschied dass einmal das Polynom fest ist und einmal per input übergeben wird)

mit freundlichen Grüßen,
Alexander

Thorti
BSc Spammer
BSc Spammer
Beiträge: 1047
Registriert: 1. Dez 2003 11:52
Wohnort: Frankfurt
Kontaktdaten:

Re: H3.1.3c) "Möglichst geringe Latenz"

Beitrag von Thorti »

AlexanderF hat geschrieben:Also wenn man a) auch kombinatorisch lösen darf, ist es dann also in Ordnung wenn die Lösung der Aufgabe a) fast genauso aussieht wie die Lösung der Aufgabe c) ?(also bis auf den Unterschied dass einmal das Polynom fest ist und einmal per input übergeben wird)
Kommt drauf an, was du unter fast verstehst. c) soll davon profitieren, dass das Polynom fest vorgegeben ist.

Gruß
Thorsten
Assistent zur Vorlesung TGDI im WS 11/12

AlexanderF
BASIC-Programmierer
BASIC-Programmierer
Beiträge: 140
Registriert: 2. Mai 2010 17:55

Re: H3.1.3c) "Möglichst geringe Latenz"

Beitrag von AlexanderF »

naja c) könnte dadurch provitieren, dass Synthesetools erkennen könnten, dass sich, auf Grund des fixen Polynoms, effizientere Hardware drauß machen lässt.

Ober das reicht dann wohl nicht bei der c) nehme ich an?

mit freundlichen Grüßen, Alexander

Antworten

Zurück zu „Archiv“