Thema: HW/CPU/VHDL-Fragen

[Dimension]

Kann man auf einen internen Cache im selben Takt von mehreren parallelen Prozessen (VHDL) aus lesend zugreifen? Wie sieht es beim schreibenden Zugriff aus? Um zu entspannen denke ich zwischen dem Programmieren in Java ein wenig über massiv parallele HW-Architekturen nach.

Eine Reihe von Fragen, welche ich notiert habe:
- Sollen ausführbare Instruktionen eine kompakte Form von Schlüssel-Wert-Paaren enthalten?
- Könnten Adressen ausschließlich über Hashtables aufgelöst werden, um sich die Relokalisierung zu sparen?
- Könnten Konstanten ausschließlich im RAM liegen?
- Kann der Code teilweise oder vollständig im Cache gehalten werden?
- Können die Einheiten innerhalb der CPU über einen(mehrere) spezielle Busse mit "Adressleitung" Aufgaben untereinander verteilen?
- Inwiefern kann die Kommunikation hierarchisch organisiert werden, sodass mehrere parallele Tasks ihre Instruktionen auf mehrfach vorhandene Einheiten verteilen und diese die Ergebnisse im Speicher ablegen können?
- Kann jede instruktion ihre eigene Pipeline haben? (Die Takte einer jeweiligen Instruktion sind konstant)
- Wie verhalten sich Pipelines bei einem geänderten Ausführungspfad, anders gefragt: Kann der Code statisch (oder dynamisch) nach dem definitiven oder warscheinlichsten Pfad analysiert werden?

Edit: Das hier soll hauptsächlich ein Thread zu VHDL-Fragen werden. Auf die letzteren Fragen/Ideen erwarte ich natürlich keine definitive Antwort, gerne jedoch Kommentare.

[Svenska]

Hallo,

Kann man auf einen internen Cache im selben Takt von mehreren parallelen Prozessen (VHDL) aus zugreifen?

Das hängt davon ab, was du als Cache definierst. Das kann schnell angebundener Speicher sein, der FPGA-interne SRAM oder auch ein Flipflop-Grab. Um das als Cache zu benutzen, brauchst du dann einen Cache-Controller, dessen Ausgang mit einer Art Bussystem verbunden ist - und damit sind die Daten überall da verfügbar, wo du sie haben willst. Wenn du aber mehrere unterschiedliche Anfragen gleichzeitig an deinen Cache schicken willst, brauchst du ein deutlich komplexeres System, was die Zugriffe u.U. serialisieren muss.

Könnten Konstanten ausschließlich im RAM liegen?

Ja. Das hängt auch mit der CPU-Architektur zusammen (von Neumann / Harvard).

Kann der Code teilweise oder vollständig im Cache gehalten werden?

Ja.

Können die Einheiten innerhalb der CPU über einen(mehrere) speziellen Bus und ein Protokoll Aufgaben untereinander verteilen?

Selbstverständlich geht das. Allerdings ist das Problem, was man wie wohin verteilt, nicht trivial und hängt auch von den Fähigkeiten der einzelnen Einheiten ab. Das Problem mit AMP (asymmetrischen Multiprozessorsystemen) kommt bei ARM jetzt auf, eventuell finden sich ein paar schöne Algorithmen. Aber auch bei SMP-Systemen ist das relativ kompliziert.

Inwiefern kann die Kommunikation hierarchisch organisiert werden?

Wenn du ein hierarchisches Bussystem definierst, dann geht das.

Kann jede instruktion seine eigene Pipeline haben? (Die Takte einer Instruktion sind konstant)

Selbstverständlich.

Wenn du nur ja/nein-Fragen stellst, wirds schwierig mit guten Antworten. Massive Parallelität ist noch ein gutes Forschungsthema, auch in Bezug auf die Ausfallsicherheit.

Gruß,
Svenska

[Dimension]

Kann man auf einen internen Cache im selben Takt von mehreren parallelen Prozessen (VHDL) aus zugreifen?

Das hängt davon ab, was du als Cache definierst. Das kann schnell angebundener Speicher sein, der FPGA-interne SRAM oder auch ein Flipflop-Grab. Um das als Cache zu benutzen, brauchst du dann einen Cache-Controller, dessen Ausgang mit einer Art Bussystem verbunden ist - und damit sind die Daten überall da verfügbar, wo du sie haben willst. Wenn du aber mehrere unterschiedliche Anfragen gleichzeitig an deinen Cache schicken willst, brauchst du ein deutlich komplexeres System, was die Zugriffe u.U. serialisieren muss.

Heisst das, dass der Zugriff auf ein Register (FPGA oder Flipflop/Latch) prinzipiell, etwa über doppelte Leitungen, parallel (innerhalb eines Taktes) erfolgen kann? Der Cache-Controller (Identifier->Hashtable->Bucket->Adresse) müsste demnach ebenfalls mehrfach verdrahtet sein bzw. parallel vorliegen.  Der eigentliche Cache-Speicherbereich, auf den sich meine Frage bezieht soll mit Adressbus(ssen) angesprochen werden.

Auf eine minimales Beispiel reduziert würde die Frage lauten, ob man beim nächsten Takt den Status aus einem Latch mit 2 Leitungen abgreifen und in der folgenden Logik an 2 Stellen verwenden kann.

[Dimension]

Meine nächste Frage ist, ob man nebenläufige Logik theoretisch beliebig lang verschachteln kann (abgesehen von Latenz), oder ob irgendwann der Strom knapp wird. Die Frage stellte sich mir, da ich mich gefragt habe, ob sich ein Hashtable-Algorithmus nebenläufig realisieren lässt, wenn der Ausgang der einen Logik direkt als Eingang der nächsten verwendet werden würde. Ist eigentlich mehr ein Gedankenexperiment, aber ich möchte dennoch alle Schleifen vermeiden und die benötigten Taktzyklen möglichst gering halten.

Oh, und Frage Nummer 3: Kann man Busse mit einer höheren (mehrfachen) Frequenz zur Pipeline takten? Diese müsste dann halt einen Takt warten und den Bus für diese Adresse sperren, damit es nicht transparent wird. Ich gehe mal davon aus, dass die Latenz von Logik von den Transistoren kommt und nicht etwa mit der Länge der Leitungen (Bus) zu tun hat?

Frage Nummer 4: Wie werden Kreuzungen von Leitungen auf Silizium realisiert, falls das überhaupt möglich ist. Mehrere Schichten wie bei Leiterplatten?

[MasterLee]

Schau dir mal folgendes Spiel an, das zeigt einiges recht anschaulich:
http://www.zachtronicsindustries.com/play-kohctpyktop/
Alles weiter kannst du hier nachlesen:
http://de.wikipedia.org/wiki/Integrierter_Schaltkreis#Herstellung_integrierter_Schaltungen

[Svenska]

Heisst das, dass der Zugriff auf ein Register (FPGA oder Flipflop/Latch) prinzipiell, etwa über doppelte Leitungen, parallel (innerhalb eines Taktes) erfolgen kann?

Ja, du kannst ein Signal gleichzeitig an mehreren Eingängen zur Verfügung stellen.

Auf eine minimales Beispiel reduziert würde die Frage lauten, ob man beim nächsten Takt den Status aus einem Latch mit 2 Leitungen abgreifen und in der folgenden Logik an 2 Stellen verwenden kann.

Ja.

Meine nächste Frage ist, ob man nebenläufige Logik theoretisch beliebig lang verschachteln kann (abgesehen von Latenz), oder ob irgendwann der Strom knapp wird.

In realen Bussystemen (als Vergleich bietet sich der VESA Local Bus an, der elektrische Probleme bei höheren Taktfrequenzen hatte) sinkt die maximale Taktfrequenz, mit der das System stabil läuft. Grund sind die parasitäre Kapazitäten, die der Treiberbaustein überbrücken muss, wozu er in einer gewissen Zeit mehr Energie benötigt. Wenn du Ausgänge mit Eingängen verbinden willst, ist jeder Transistor oder jeder TTL-Gatterbaustein mit einer zentralen Stromversorgung verbunden, also Strom ist genug da.

Die Frage stellte sich mir, da ich mich gefragt habe, ob sich ein Hashtable-Algorithmus nebenläufig realisieren lässt, wenn der Ausgang der einen Logik direkt als Eingang der nächsten verwendet werden würde.

Asynchrone Schaltungen in FPGAs sollte man grundsätzlich vermeiden. Also sollte zwischen Aus- und Eingängen ein getakteter Buffer: Bei FPGAs sind die Signallaufzeiten verglichen mit den Gatterlaufzeiten extrem kurz und können von Draht zu Draht extrem unterschiedlich sein, je nach Routing.

Ja, es geht, aber in einem Takt löst sich das dann nicht. Wobei dich niemand hindert, intern eine höhere Taktfrequenz zu benutzen, als extern zugeführt wird. Dafür gibt es PLLs.

Ich gehe mal davon aus, dass die Latenz von Logik von den Transistoren kommt und nicht etwa mit der Länge der Leitungen (Bus) zu tun hat?

Innerhalb eines FPGAs entsteht die Latenz hauptsächlich durch die Leitungslänge, die du nicht beeinflussen kannst (das macht der Routingalgorithmus). Daher sind asynchrone Schaltungen doof.

Wie werden Kreuzungen von Leitungen auf Silizium realisiert, falls das überhaupt möglich ist. Mehrere Schichten wie bei Leiterplatten?

Ja.

Gruß,
Svenska

[erik.vikinger]

Hallo,

Schau dir mal folgendes Spiel an, das zeigt einiges recht anschaulich:
http://www.zachtronicsindustries.com/play-kohctpyktop/

Nett! Wenn ich nicht was besseres mit meiner knappen Lebenszeit anzufangen wüsste könnte ich da glatt süchtig werden.

ob man nebenläufige Logik theoretisch beliebig lang verschachteln kann (abgesehen von Latenz), oder ob irgendwann der Strom knapp wird.

Ja, Du kannst beliebig viele Logik-Ebenen zwischen 2 getakteten D-FFs packen, nur die Taktfrequenz muss niedrig genug sein damit das dann auch funktioniert. In absoluter Performance scheint es auf den ersten Blick sogar Sinn zu ergeben genau so zu verfahren. Jedes Flip-Flop kostet immer auch etwas Latenz für jeden einzelnen Pfad, es gibt eine Latenz vom Flip-Flop selber (die neuen Daten liegen nicht unmittelbar sofort nach der Taktflanke am Datenausgang an sondern erst minimal später) und dann muss noch die Hold-Zeit eingehalten werden (die neuen Daten müssen nicht erst unmittelbar vor der Taktflanke ankommen sondern sie müssen schon ein klein wenig eher am Dateneingang anliegen damit diese auch zuverlässig übernommen werden). Wenn Du also eine Logik hast die Du über 3 Takte verteilst und mit der Frequenz X laufen lässt dann wird die mögliche Frequenz etwas mehr als ein Drittel betragen wenn Du das zu einem Takt umbaust indem Du die zwei mittleren FF-Ebenen entfernst. Dafür geht Dir das Pipeline-Prinzip verloren und weil Du mit der 3-stufigen Pipeline in minimal mehr als der selben Zeit 3 Ergebnisse bekommst bist Du damit effektiv wieder schneller. Jetzt könnte man wieder versuchen die Schaltung in noch mehr Stufen aufzuteilen aber dem sind natürlich Grenzen gesetzt weil es einfach immer schwieriger wird sinnvolle Teilschritte zu finden. Auch wird es nur selten möglich sein mit einer Verdoppelung der Stufen den Takt zu verdoppeln weil es kaum möglich ist in einem asynchronen Logik-Geflecht genau in der Mitte aller Laufzeiten (für alle möglichen Wege) aufzutrennen, desto feiner man das aufteilen will desto eher wird man da suboptimale Kompromisse eingehen müssen. Es läuft letztendlich auf einen Trade-Off hinaus bei dem man das gesamte System berücksichtigen muss weil es auch nicht praktikabel ist jede Teilschaltung mit einer eigenen Taktfrequenz laufen zu lassen (durch das korrekte Überführen der Daten von einer Takt-Domäne zu einer anderen entstehen auch erhebliche Latenzen, nebst dessen dass das keine triviale Angelegenheit ist).

Kann man Busse mit einer höheren (mehrfachen) Frequenz zur Pipeline takten?

Klar kann man das, es gibt dafür auch Beispiele aber in der Praxis ist das trotzdem ziemlich selten weil ein Bus ja eben über weitere Strecken kommunizieren soll und deswegen mit deutlich längeren Signallaufzeiten zu rechnen ist als innerhalb einer kompakten Logik-Wolke.

Auf eine minimales Beispiel reduziert würde die Frage lauten, ob man beim nächsten Takt den Status aus einem Latch mit 2 Leitungen abgreifen und in der folgenden Logik an 2 Stellen verwenden kann.

Ja, das geht, ansonsten könnte man keine digitale Schaltung bauen. Du kannst auch innerhalb der Logik-Wolke das Ergebnis jedes Einzelelementes (AND/OR/XOR/...) mehrfach weiter benutzen. Du musst nur berücksichtigen da ein höherer Fan-Out auch mehr Last für das treibende Element bedeutet und damit die Laufzeit dieses Signals für alle Empfänger etwas länger wird. Die FPGA-Synthese-Tools berücksichtigen das aber wenn sie die maximal mögliche Taktfrequenz Deiner Schaltung errechnen.

Kann man auf einen internen Cache im selben Takt von mehreren parallelen Prozessen (VHDL) aus lesend zugreifen? Wie sieht es beim schreibenden Zugriff aus?

Wenn Du mit Cache klassischen SRAM (was auch die Basis für den RAM innerhalb von FPGAs ist) meinst dann nicht. Die RAM-Blöcke in FPGAs sind typischerweise als Dual-Port-SRAM ausgelegt (es gibt da zwar eine spezielle Ausnahme aber das lassen wir jetzt mal lieber, wenn es Dich interessiert dann schau Dich einfach auf tabula.com um) und arbeiten immer taktsynchron. Das bedeutet das wenn Du auf eine bestimmte Stelle im RAM zugreifen möchtest musst Du eine Adresse und ein Lese-Kommando an einen der Ports anlegen und das wird dann mit der nächsten Taktflanke übernommen. Dann gibt es üblicherweise 2 Betriebsarten: entweder die Daten kommen noch kurz vor der darauf folgenden Taktflanke an den Ausgangspins raus so das Du diese eventuell noch mit einer kurzen Logik-Wolke verarbeiten und schließlich in (mehreren) Flip-Flops abspeichern kannst oder die Daten kommen erst kurz nach der darauf folgenden Taktflanke raus so das Du eine größere Logik-Wolke dahinter hängen kannst bevor Du diese (verarbeiteten) Daten dann in (mehreren) Flip-Fops abspeicherst. Die zweite Variante ist der Pipeline-Betrieb und ermöglicht es den RAM mit höheren Taktfrequenzen laufen zu lassen aber dafür bekommst Du einen Takt zusätzliche Latenz bei theoretisch höherem Durchsatz. Bei beiden Varianten kann man mit jedem Takt eine andere Adresse angeben und bekommt dann die Daten in der selben Reihenfolge (entsprechend verzögert) ausgeliefert. Schreiben funktioniert ähnlich nur das man da zusammen mit der Adresse und dem Schreib-Kommando auch noch die zu schreibenden Daten angeben muss, auch lässt sich Lesen und Schreiben beliebig mischen. Es muss nur beachtet werden das die gerade geschriebenen Daten nicht sofort wieder gelesen werden können. Dadurch das diese RAMs Dual-Ported sind hat man eben 2 solcher Ports zur Verfügung die man sogar mit unterschiedlichen Taktfrequenzen betreiben kann aber natürlich fordert auch hier die Physik ihren Tribut indem es u.a. nicht möglich ist auf die selbe Speicherstelle von beiden Ports aus gleichzeitig zu schreiben (das wird aber nicht im RAM irgendwie verhindert sondern der speichert dann einfach Quatsch ab sondern Du als Programmierer musst Dir überlegen wie Du das verhinderst damit nur sinnvolle Daten im RAM landen) und auch wenn ein Port schreibt kann der andere Port diese Speicherstelle erst nach einer gewissen Zeit zuverlässig lesen (ansonsten kommt nur Quatsch raus, vor allem wenn man mit unterschiedlichen Taktfrequenzen arbeitet ist es recht kompliziert festzulegen ab wann mit dem anderen Port zuverlässig gelesen werden kann). Ich schlage vor Du schaust Dir einfach mal die Datenblätter bei den verschiedenen FPGA-Herstellern an, empfehlen würde ich da Actel, Altera, Lattice und Xilinx (die Reihenfolge ist keine Wertung), glücklicherweise sind die FPGA-Hersteller keine notorischen Geheimniskrämer (zumindest die 4 großen, bei den kleineren FPGA-Herstellern ist das leider anders aber auch da ist es relativ einfach schaffbar alles lesenswerte zu bekommen).

Um zu entspannen denke ich zwischen dem Programmieren in Java ein wenig über massiv parallele HW-Architekturen nach.

Hm, aha.

- Sollen ausführbare Instruktionen eine kompakte Form von Schlüssel-Wert-Paaren enthalten?

Hä, von was schreibst Du da? Meine Befehle werden in der internen Darstellung (die aus dem Decoder hinten raus kommt und so in der gesamten Pipeline verwendet wird) immer einen OpCode, die Ausführungsbedingung, ein paar Attribute, die Register-Nummern aller benutzten Register (bis 5 Stück) und noch ein Immediate (mit voller Größe) enthalten. Was davon alles benutzt wird hängt natürlich von dem konkreten Befehl ab der im OpCode kodiert ist.

- Könnten Adressen ausschließlich über Hashtables aufgelöst werden, um sich die Relokalisierung zu sparen?

Auch hier verstehe ich nicht was Du möchtest, vielleicht solltest Du solche Fragen anhand einer konkreten Beschreibung Deines eigentlichen Vorhabens stellen.

- Könnten Konstanten ausschließlich im RAM liegen?

Ja, das kann man machen, aber für Konstanten die normal innerhalb des VHDL-Codes benutzt werden ist das eher nicht geeignet. Das würde sich eher für Konstanten lohnen die mit den eigentlichen Nutzdaten in irgendeiner Form verrechnet werden. Bis auf die von Actel erlauben es eigentlich alle FPGAs das man die internen RAM-Blöcke mit bestimmten Daten vorbelegt wenn der FPGA erwacht so das Du diese Konstanten nicht erst zur Laufzeit dort mühsam mit irgendeiner Logik hineinpacken musst.

- Kann der Code teilweise oder vollständig im Cache gehalten werden?

Ja. Du kannst sogar den Code erst hinter dem Decoder cachen, das hat mal der Pentium 4 so gemacht, um Dir die Latenz des Decoders bei Sprüngen zu sparen, in meiner CPU möchte ich das machen.

- Können die Einheiten innerhalb der CPU über einen(mehrere) spezielle Busse mit "Adressleitung" Aufgaben untereinander verteilen?
- Inwiefern kann die Kommunikation hierarchisch organisiert werden, sodass mehrere parallele Tasks ihre Instruktionen auf mehrfach vorhandene Einheiten verteilen und diese die Ergebnisse im Speicher ablegen können?

Das ist beides nur von Deiner Fantasie und Deinen Fähigkeiten als VHDL-Programmierer begrenzt. Solange es technisch möglich ist sollte es auch umsetzbar sein.

- Kann jede instruktion ihre eigene Pipeline haben? (Die Takte einer jeweiligen Instruktion sind konstant)

Also für jede einzelne Instriktion würde ich das nicht machen wollen, das sind üblicherweise ne ganze Menge. Aber bei den größeren CPUs arbeitet man mit mehreren Ausführungseinheiten parallel. Da kann man z.B. mehrere ALUs haben in die alle einfachen Rechenbefehle (die meisten brauchen ja auch nur einen Takt) rein kommen, dazu dann noch eine/mehrere FPU-Einheit(en) (hier brauchen eigentlich alle Befehle mehrere Takte) und noch Speicherzugriffeinheiten usw.. Nur zu viele solcher Einheiten sollten es nicht werden da natürlich jede Einheit Logik braucht und auch mit Befehlen versorgt werden will (gerade das ist ja eine der Schwächen der aktuellen Bulldozer-CPUs von AMD, der Decoder schafft es nicht für die vielen Ausführungseinheiten immer genügend Befehle nachzuliefern damit die sich nicht langweilen müssen).

- Wie verhalten sich Pipelines bei einem geänderten Ausführungspfad, anders gefragt: Kann der Code statisch (oder dynamisch) nach dem definitiven oder warscheinlichsten Pfad analysiert werden?

Typische Pipelines reagieren auf Verzweigungen im Programmablauf eher schlecht, das liegt an der Länge da ja das Ziel einer Verzweigung oft erst am Ende der Pipeline fest steht kommt es da zu teilweise erheblichen Latenzen bis die neuen Befehle (vom Sprungziel) wieder Ergebnisse liefern können. Gerade bei bedingten Verzweigungen ist das ein ernstes Problem. In der Oberliga nutzt man dazu spekulative Ausführung, die bei bedingten Verzweigungen eben den Pfad der mit höherer Wahrscheinlichkeit ausgeführt werden wird schon mal in die Pipeline lässt. Solange diese Vorhersage stimmt ist alles prima aber wenn diese Vorhersage falsch liegt gibt es noch mehr Straftakte da ja erst mal die Pipeline von diesen falschen Befehlen gesäubert werden muss.


Grüße
Erik

[Dimension]

http://de.wikipedia.org/wiki/Integrierter_Schaltkreis#Herstellung_integrierter_Schaltungen

Ja, die Grafik zeigt recht deutlich, wie Leiterbahnen auf mehreren Ebenen liegen.

Folglich besteht der aktive Teil einer CPU lediglich aus den Transistoren in der unteren Ebene und den Kupferleitungen darüber. Demnach hat sich auch meine Frage nach den Verzweigungen von Signalwegen geklärt. Wie ich jetzt herauslesen konnte verhalten  sich FPGA ebenfalls entsprechend.

Woher kommt jedoch die hohe Laufzeit von langen Signalwegen bei FPGAs? Bestehen dort die Leitungen aus Transistoren? Dachte die Latenz hätte was mit der Schaltgeschwindigkeit zu tun, im Kupferleiter sollte die Ausbreitung des Signals mit etwa 60% der Lichtgeschwindigkeit gehen.

Gegen die parasitären Kapazitäten würde ich spontan mit GND abschirmen. Mehrere verschiedene Takte würde ich vermeiden, höchstens ein Vielfaches des Pipeline-Takts für den Bus, um bei vielen Teilnehmern den Durchsatz zu erhöhen, falls es denn technisch möglich ist.

Frage 1 [ x ]
Frage 2 [ x ]
Frage 3 [ 1/2 ]
Frage 4 [ x ]

[Svenska]

Hallo,

ein FPGA ist programmierbar. Das geht nicht durch Umlöten.

Guckst du hier, da ist erklärt, wie ein FPGA aufgebaut ist. Die Verbindung zweier Lookup-Tables erfolgt nicht durch einen Kupfer- oder Aluminiumdraht (innerhalb von ICs wird meist Aluminium eingesetzt), sondern durch ein Bussystem.

Damit erübrigt sich deine Frage, hoffe ich.

Gruß,
Svenska

[Dimension]

Damit erübrigt sich deine Frage, hoffe ich.

Nicht ganz. Dass die Schaltung in den FPGA geladen wird und dies kein Löten erfordert ist mir klar. Diese Schaltmatrix besteht laut Wikipedia doch aus SRAM, also Transistoren, die bestimmen wie verdrahtet wird?

Edit: Ein Bussystem, sagst du? Kann man damit von der einen Seite quer über den Chip mit der anderen Seite kommunizieren?
Edit2: Ich sollte den Artikel erst lesen.
Edit3: Nicht dass ich hier irgendwo genügend Geld rumliegen hätte, aber ich glaube designen will ich für echtes ASIC.

[Dimension]

Nur damit ich das Datum in meinem Kalender richtig eintrage: In welcher Größenordnung liegen die Kosten zur Fertigung von ASICs mit aktueller Strukturgröße? Habs grad gefunden. Es gibt Anbieter wie MOSIS, die mehrere Designs auf eine Maske packen. Kosten in meinem Fall etwa 20k.

[MasterLee]

stellen wir uns vor du willst ein OR(e1∨e2=a) bilden dann könntest du das wie folgt verdrahten wenn du nun NAND bausteine hast:
(e1⊼e1)⊼(e2⊼e2)=a
Wenn du jetzt aber einen FPGA hättest der auch zwei ein und einen Ausgang hat aber ansonsten frei konfigurierbar wäre so würde der wie folgt aussehen:
(((((e1⊼e1)⊼(e2⊼e2))⊼((e1⊼e1)⊼(e2⊼e2)))⊼k0)⊼(((e1⊼(e2⊼e2))⊼(e1⊼(e2⊼e2)))⊼k1))
⊼(((((e1⊼e1)⊼(e2⊼e2))⊼((e1⊼e1)⊼(e2⊼e2)))⊼k0)⊼(((e1⊼(e2⊼e2))
⊼(e1⊼(e2⊼e2)))⊼k1))⊼(((((e1⊼e1)⊼e2)⊼((e1⊼e1)⊼e2))⊼k2)⊼(((e1⊼e2)⊼(e1⊼e2))⊼k3)
⊼((((e1⊼e1)⊼e2)⊼((e1⊼e1)⊼e2))⊼k2)⊼(((e1⊼e2)⊼(e1⊼e2))⊼k3))=a
wobei k0 bis k1 die Konfiguration des mini-FPGAs ist. Und nun kannst du selber überlegen warum ein FPGA langsamer ist während du prüfst ob die Formel richtig ist.
Wie teuer ein ASIC wird weiß ich nicht genau aber 20k$ dürften zu wenig sein.
http://opencores.org/donation

[Dimension]

Ja, ich glaube den Bus mit höherer Taktrate kann ich mir erst mal schenken. Vielleicht sind mehrere parallele Busse und ein Demultiplexer ne Option.

[MasterLee]

Kannst dir mal den Wishbone BUS anschauen:
http://en.wikipedia.org/wiki/Wishbone_(computer_bus)

[erik.vikinger]

Hallo,

Woher kommt jedoch die hohe Laufzeit von langen Signalwegen bei FPGAs? Bestehen dort die Leitungen aus Transistoren? Dachte die Latenz hätte was mit der Schaltgeschwindigkeit zu tun, im Kupferleiter sollte die Ausbreitung des Signals mit etwa 60% der Lichtgeschwindigkeit gehen.

Zum einen sind die Leitungen ja nicht schnurgerade und zum anderen gibt es bei FPGAs eben auch immer die Routing-Logik (also die Transistoren die die vielen kurzen Leitungssegmente mit einander verbinden um damit ein Signal quer durch den FPGA zu leiten). Und 60% Lichtgeschwindigkeit sind bei Periodenlängen im Bereich weniger Nanosekunden bis unter einer Nanosekunde auch nur noch eine Strecke die gegenüber der Größe des Silizium-Dies bereits ziemlich klein ist.

Gegen die parasitären Kapazitäten würde ich spontan mit GND abschirmen.

Aha, dann hast Du die selbe Kapazität nicht mehr zwischen 2 Signalen sondern zwischen einem Signal und GND. Parasitäre Kapazitäten kann man nur mit größeren Abständen (was bei der heutigen Miniaturisierung eher nicht so toll funktioniert), kleineren Flächen (was schon eher realistisch ist) oder einer geringeren Permittivität des dazwischen liegenden Materials (woran zur Zeit intensiv geforscht und auch teilweise in der Chipherstellung bereits umgesetzt wird) bekämpfen. Wenn Du Dir anschaust aus welchen Parametern sich die Kapazität eines Kondensators ergibt dann gibt es auch keine anderen Stellschrauben.


Mit dem Wishbone-BUS hab ich schon gearbeitet, der ist relativ einfach zu nutzen (wenn man nicht unbedingt maximale Performance will) und es gibt dazu gute Tools (für die nötigen Routing-Elemente). Für den Einstieg ist das auf jeden Fall eine gute Wahl. Wenn Du später mal was deutlich besseres aber auch deutlich anspruchsvolleres haben möchtest solltest Du einen Blick auf den AIX (aus der AMBA-Familie) von ARM werfen (Xilinx setzt den in seinen besseren IP-Cores gerne ein und die Zinq-Plattform wird auch darauf aufbauen).


Grüße
Erik

[Dimension]

Ich konzipiere endlich mal meine Speicherverwaltung und konnte nicht widerstehen dazu gleich die passende nebenläufige Logik zu entwerfen. Die Aufgabe ist es in einer 1mBits großen Bitmask die erste 1 zu finden. Dazu verbinde ich nacheinander alle Bits mit OR und setze eine entsprechende Konstante, wenn eines der Bits 1 und alle Bits davor 0 sind. Die resultierende Logik umfasst somit auf einem FPGA mehrere Milliarden Transistoren. Ist damit eine realistische Signallaufzeit im Verhältnis zur getakteten Logik gegeben, oder soll ich eine Pipeline vorsehen?

Edit: Dämliche Frage. Antwort: Nein, mehrfach kürzere Logik ist entsprechend um ein vielfaches schneller. Wobei man ausloten könnte, wie man durch geschicktes Zusammenfassen der Bits den vorhandenen Takt voll ausnutzen und den Scan beschleunigen kann.

[Svenska]

Für hinreichend geringe Taktgeschwindigkeit reicht ein Takt. Aber das hatte ich schonmal geschrieben.
Die reale maximale Taktfrequenz lässt sich bei einem FPGA erst nach dem Routing (und nach der Synthese) feststellen. Zumindest die Xilinx ISE hat das auch ermittelt und angezeigt.

[Dimension]

Wenn ichs mir recht überlege ist mir so eine Logik eh viel zu umfangreich und Platz raubend. Da es den freien Speicher sowieso im Hintergrund sucht und der getaktete Scan als Pipeline fungiert, kann zumindest eine gewisse Menge an Speicher in konstanter Zeit zugewiesen werden. Auf x86 bleibt auch erstmal nur der Scan, optional mit REP SCAS.

[Dimension]

Was ich schon immer mal fragen wollte: Wie man einen Takt teilt, kann ich noch einigermaßen nachvollziehen, aber wie man einen Takt verdoppeln kann, ist mir nicht ganz klar. Naja, werd mich dann mal wieder meinen Hashtables widmen.

[Svenska]

Eine Taktverdopplung macht man mit PLLs. Das sind geregelte Schwingkreise, die schneller schwingen als der zugeführte Takt und sich auf dessen Phase einregeln, so dass du am Ende ein Vielfaches der Taktfrequenz hast. Deswegen sind Takte, die aus einer PLL kommen, erst nach einer gewissen Zeitspanne (der Einschwingzeit) stabil.