Hallo zusammen, bisher nutze ich das Spartan 3an Starter Kit und bin damit auch recht zufrieden. Der FPGA selbst besitzt allerdings nicht sehr viele Logikgatter, so dass ich jetzt an der Leistungsgrenze des Boards angekommen bin. Auf dem Board ist eine XC3S700AN verbaut. Diese Serie gibt es auch noch als 1400er mit rund der doppelten Leistung. Jedoch habe ich hierzu kein Starter Kit gefunden. Grundsätzlich benötige ich etwa 10 digitale I/O Pins sowie A/D und D/A Wandler (jeweils 2 mindestens). Kann mir jemand ein passendes Board empfehlen? Eventuell gibts auch Boards ohne die Wandler, die sich aber per Expansion Card erweitern ließen? Für eure Tips wäre ich dankbar! Grüße Hans
Hans schrieb: > Der FPGA Der Array? Oder eher: das Array? > Der FPGA selbst besitzt allerdings nicht sehr viele Logikgatter, so dass > ich jetzt an der Leistungsgrenze des Boards angekommen bin. Was hast du darauf gepackt? > sowie A/D und D/A Wandler (jeweils 2 mindestens). Wie schnell und wie breit? > Diese Serie gibt es auch noch als 1400er mit rund der doppelten Leistung. Leistung? Woher hast du diesen Begriff? FPGAs werden nach Ressourcen (Logikzellen, RAM, Recheneinheiten, CPU-Cores) oder allgemein nach "Größe" bewertet. Muss es unbedingt ein S3 Board sein?
:
Bearbeitet durch Moderator
Wegen AD/DA-Wandlern: Wenn die langsam sind, also für Audio, dann kann man sich die auch selber basteln, also ein IO Pin Reicht für PWM Audio oder einen 1-Bit ADC. Für die Digilent Boards gibt es auch PMODS, also Zusatzplatinen für alles Mögliche. Sonst bin ich sehr positiv überrascht vom OpenADC, der passt auch an zwei PMOD Buchsen der Digilent Boards. Ich würde derzeit was mit einem Artix kaufen, die haben doch eine ordentliche Ausstattung und sogar eingebaute ADCs. Ztex hat da ein paar Platinen und auch Digilent das Nexys4.
:
Bearbeitet durch User
Lothar Miller schrieb: > Hans schrieb: >> Der FPGA > Der Array? Oder eher: das Array? > >> Der FPGA selbst besitzt allerdings nicht sehr viele Logikgatter, so dass >> ich jetzt an der Leistungsgrenze des Boards angekommen bin. > Was hast du darauf gepackt? > >> sowie A/D und D/A Wandler (jeweils 2 mindestens). > Wie schnell und wie breit? > >> Diese Serie gibt es auch noch als 1400er mit rund der doppelten Leistung. > Leistung? Woher hast du diesen Begriff? > FPGAs werden nach Ressourcen (Logikzellen, RAM, Recheneinheiten, > CPU-Cores) oder allgemein nach "Größe" bewertet. > > Muss es unbedingt ein S3 Board sein? Derzeit generiere ich digitale Signale (Rechteck) bis 180ns Pulsbreite und ein analoges Sinussignal (um 200Hz) die ich rausgebe. Außerdem muss ich mir für unterschiedliche Frequenzen Zeiten auf einer Sinuswelle berechnen. Für eine feste Frequenz könnte ich die Zeitwerte in einer LUT hinterlegen, da die Frequenz aber variabel ist muss ich ständig 128 Zeitpunkte auf meinem Sinus berechnen. Hierzu muss ich durch die aktuelle Frequenz teilen - die Zählerwerte sind in einer LUT gespeichert. Das frisst wohl recht viele Logikzellen... Ich hatte zunächst vermutet, dass die For Schleife soviele Resourcen benötigt, jedoch ist kein Unterschied zu einer Ausformulierung der 128 Berechnungsschritte festzustellen. Liegt es an der Verwendung der vielen Divisionen? Die A/D haben 14bit und die D/A 12 bit bei 1,5 MHz. Es muss nicht unbedingt ein S3 Board sein, jedoch wäre es schon nett, wenn man zusätzlich ein paar Switches und Kommunikationsschnittstellen (z.B. seriell) hätte. Ein typisches Starterkit oder Eval-Kit. Mir würde das Spartan 3AN mit mehr Logikzellen (15TSD+) ja genügen. Leider habe ich mit googlen noch nichts passendes gefunden.
Gustl Buheitel schrieb: > ie haben doch eine > ordentliche Ausstattung und sogar eingebaute ADCs Die sind aber eher für Spannungsüberwachungsaufgaben gedacht und keinesfalls für Audio oder Messaufgaben mit höherer Genauigkeit.
Also die XADC in den Xilinx 7 FPGAs sind 12Bit und bis zu 1MSps, damit lässt sich locker Audio machen. Sonst empfehle ich den OpenADC, aber der hat glaube ich eine minimale Samplerate von 5MSps und "nur" 10 Bits. Digilent hat aber auch PMOD AD/DA Wandler. Die kann man dann auch an das Nexys4 mit dickem Artix ranstecken. Serielle und Knöpfe und Zeug hat das auch.
Hans schrieb: > die Zählerwerte sind in einer LUT gespeichert. Das frisst wohl recht > viele Logikzellen... Wenn man die LUT nicht richtig beschreibt und kein BlockRAM verwendet, dann schon. Ich empfehle hier den XST Users Guide und die XAPP463... > Ich hatte zunächst vermutet, dass die For Schleife > soviele Resourcen benötigt, jedoch ist kein Unterschied zu einer > Ausformulierung der 128 Berechnungsschritte festzustellen. Liegt es an > der Verwendung der vielen Divisionen? Kann sein, mir schwant da Übles... Man könnte das evtl. beurteilen, wenn du die VHDL-Dateien postest.
Lothar Miller schrieb: > Hans schrieb: >> die Zählerwerte sind in einer LUT gespeichert. Das frisst wohl recht >> viele Logikzellen... > Wenn man die LUT nicht richtig beschreibt und kein BlockRAM verwendet, > dann schon. Ich empfehle hier den XST Users Guide und die XAPP463... > >> Ich hatte zunächst vermutet, dass die For Schleife >> soviele Resourcen benötigt, jedoch ist kein Unterschied zu einer >> Ausformulierung der 128 Berechnungsschritte festzustellen. Liegt es an >> der Verwendung der vielen Divisionen? > Kann sein, mir schwant da Übles... > Man könnte das evtl. beurteilen, wenn du die VHDL-Dateien postest. Die Rechnung die 65 mal pro Takt (20ns) in einem Prozess durchgeführt wird ist: C1*Signal/C2 C1 ist eine Konstante und C2 eine konstante 2er Potenz. Signal ist eine Variable, die in jedem Berechnungsschritt errechnet werden muss. Alle 65 Ergebnisse werden in einem Array abgespeichert. Kann man das eleganter lösen?
Hans schrieb: > Die Rechnung die 65 mal pro Takt (20ns) in einem Prozess durchgeführt > wird ist: C1*Signal/C2 (Warum) muss das so oft und schnell passieren? Übrigens: es ist egal, ob diese Berechnung in einem Prozess durchgeführt wird oder nicht. Denn auf der Hardware gibt es keine Prozesse mehr... > C2 eine konstante 2er Potenz. Dann ist da keine Division nötig und wird sicher auch nicht eingesetzt. > Signal ist eine Variable, die in jedem Berechnungsschritt errechnet > werden muss. Was ist ein "Berechungsschritt"? > Alle 65 Ergebnisse werden in einem Array abgespeichert. Auf der Hardware gibt es keine Arrays. Dort gibt es nur Luts, Register, RAMs, Multiplizierer und so Zeug. Dein Array muss irgendwie darauf abgebildet werden. > Kann man das eleganter lösen? Das weiß man nur, wenn man die Aufgabe (woher und wie schnell kommen die Daten, was muss mit ihnen wie oft passieren und wo gehen sie letztendlich hin) und den jetzigen VHDL Code kennt...
:
Bearbeitet durch Moderator
> Ich hatte zunächst vermutet, dass die For Schleife > soviele Resourcen benötigt, jedoch ist kein Unterschied zu einer > Ausformulierung der 128 Berechnungsschritte festzustellen Weil die For Schleife automatisch "ausformuliert" wird in VHDL... Es sollte also kein Unterschied zu sehen sein. Wenn du die berechnungen nacheinander ausführen willst, dann mußt du das über eine Statemachine machen. Denn eine Schleife mit for wird "ausgeklappt" und die Berechnung findet auf allen Elemten gleichzeitig (parallel) statt.
Also, die berechnung muss in jedem takt (das meinte ich mit berechnungsschritt) erfolgen weil ich zeitkritische signale rausgeben muss. Hierzu muss ich wissen wo ich mich gerade auf dem sinus befinde (jedenfalls im rahmen der 65 diskreten berechneten positionen) und das für unterschiedliche frequenzen. Das eingangssignal also die frequenz kann sich jederzeit ändern. Theoretisch würde es auch reichen wenn ich alle 0, 01s die positionswerte neu berechnen würde aber die anzahl der logikbausteine bleibt dann dieselbe. Ich brauche eine effiziente möglichkeit 64 werte pro takt zu berechnen die abhängig sind von einer variablen.
Hans schrieb: > die berechnung muss in jedem takt erfolgen > ... > würde es auch reichen wenn ich alle 0, 01s ... neu berechnen würde Ja, was denn jetzt? > aber die anzahl der logikbausteine bleibt dann dieselbe. Nein, ganz und gar nicht: du brauchst dann nämlich nur noch 1 einzige Recheneinheit, die nacheinander die paar wenigen Ergebnisse ausrechnet. Und sogar die langweilt sich noch zu Tode. Denn 10ms ("ausreichend" oft) im vergleich zu 10ns (bei 100MHz "in jedem takt") sind immerhin 6 Zehnerpotenzen... :-o So ähnlich wie auf dem Kinderspielplatz: da reicht eine einzige Schaukel auch für viele Kinder, wenn die nicht gleichzeitig schaukeln. Und Nachts ist sie sogar leer... So wird es übrigens auch auf ALLEN uC und Prozessoren gemacht: eine (mehr oder weniger komplexe) Recheneinheit reicht für alles aus...
> Nein, ganz und gar nicht: du brauchst dann nämlich nur noch 1 einzige > Recheneinheit, die nacheinander die paar wenigen Ergebnisse ausrechnet. > Und sogar die langweilt sich noch zu Tode. Denn 10ms ("ausreichend" oft) > im vergleich zu 10ns (bei 100MHz "in jedem takt") sind immerhin 6 > Zehnerpotenzen... :-o > So ähnlich wie auf dem Kinderspielplatz: da reicht eine einzige Schaukel > auch für viele Kinder, wenn die nicht gleichzeitig schaukeln. Und Nachts > ist sie sogar leer... > So wird es übrigens auch auf ALLEN uC und Prozessoren gemacht: eine > (mehr oder weniger komplexe) Recheneinheit reicht für alles aus... Also brauche ich dann deutlich weniger bausteine wenn ich pro takt nicht die vollen 64 Berechnungen ausführe sondern nur ein teil? Und die gleiche Schaltung wird dann für alle Rechnungen nacheinander verwendet?
Hans schrieb: > Also brauche ich dann deutlich weniger bausteine wenn ich pro takt nicht > die vollen 64 Berechnungen ausführe sondern nur ein teil? Du brauchst z.B. statt 64 Multiplizierern dann nur 1 einzigen. Nur solltest du dann dein "Array" auch in ein RAM packen, denn dort bekommst du dann den nötigen Multiplexer zur Umschaltung der Rechendaten (Operanden und Ergebnis) umsonst dazu... > Und die gleiche Schaltung wird dann für alle Rechnungen nacheinander > verwendet? Wenn die Zeit ausreicht.
Lothar Miller schrieb: > Hans schrieb: >> Also brauche ich dann deutlich weniger bausteine wenn ich pro takt nicht >> die vollen 64 Berechnungen ausführe sondern nur ein teil? > Du brauchst z.B. statt 64 Multiplizierern dann nur 1 einzigen. Nur > solltest du dann dein "Array" auch in ein RAM packen, denn dort bekommst > du dann den nötigen Multiplexer zur Umschaltung der Rechendaten > (Operanden und Ergebnis) umsonst dazu... > >> Und die gleiche Schaltung wird dann für alle Rechnungen nacheinander >> verwendet? > Wenn die Zeit ausreicht. Also zum Beispiel in den BRAM? Könntet ihr eventuell einen effizienten Beispielcode posten für die Durchführung zweier Multiplikation z.B A= K*Signal_v B= K*Signal_v wobei pro Takt nur eine der Berechnungen ausgeführt und das Ergebnis als Array in einen RAM geschrieben wird. Für weitere Berechnungen soll das Array erst zur Verfügung stehen, sobald alle Arrayeinträge berechnet wurden.
Hans schrieb: > Könntet ihr Oha, Pluralis Majestatis... ;-) > Könntet ihr eventuell einen effizienten Beispielcode posten für > die Durchführung zweier Multiplikation z.B > A= K*Signal_v > B= K*Signal_v Dafür nimmt man kein RAM. Deshalb kann es auch keinen effizienten Code mit einem RAM dafür geben. Ein RAM muss über Adressleitungen angesteuert erden und hat Datenleitungen als Ein- und Ausgang. DU musst jetzt deinen Algorithmus so anpassen, dass er gut damit funktioniert. > Könntet ihr eventuell einen effizienten Beispielcode posten für > die Durchführung zweier Multiplikation Sagen wir mal, du willst 64 Multiplikationen machen und das RAM mit Ergebnissen füllen, dann ergibt das mehr Sinn. Also nehmen wir mal sowas und basteln uns ein RAM: http://www.lothar-miller.de/s9y/archives/20-RAM.html
1 | ...
|
2 | |
3 | type speicher is array(0 to 63) of STD_LOGIC_VECTOR(7 downto 0); |
4 | signal memory : speicher; |
5 | singal adresse: integer range 0 to 63 :=0; |
6 | signal result : STD_LOGIC_VECTOR(7 downto 0); |
7 | ...
|
8 | |
9 | process begin -- Verwaltung der Adresse |
10 | wait until rising_edge(CLK); |
11 | if aktiv='0' then adresse<=0; |
12 | elsif adresse<63 then adresse<=adresse+1; |
13 | end if; |
14 | end process; |
15 | |
16 | result <= PassendeKonvertierung(K*Signal_v); -- kann laufend ausgerechnet werden |
17 | |
18 | process begin -- RAM mit Daten füllen |
19 | wait until rising_edge(CLK); |
20 | if (aktiv='1') then |
21 | memory(to_integer(unsigned(adresse))) <= result; |
22 | end if; |
23 | end process; |
24 | |
25 | ...
|
:
Bearbeitet durch Moderator
Warum macht es keiner Unterschied in der Anzahl der genutzten Logik-Zellen, wenn ich auf einmal alle Werte berechne oder pro Takt nur ein Wert berechne? Code 1:
1 | |
2 | type t_memory_position_x is array(0 to 64) of Integer; |
3 | signal c_sine_position_x : t_memory_position_x; |
4 | signal c_sine_position_x_fertig : t_memory_position_x; |
5 | signal aktiv : std_logic := '0'; |
6 | signal adresse : integer range 0 to 64 := 0; |
7 | signal result : integer; |
8 | signal c_rising_edges : INTEGER RANGE 2000 to 2500 := 2270; |
9 | constant c_divisor : INTEGER := 8192; |
10 | |
11 | constant c_sine_value_x : t_memory_position_x := (0, ..., 2048); -- enthält 65 Werte |
12 | |
13 | begin
|
14 | |
15 | process begin |
16 | wait until rising_edge(CLK); |
17 | if aktiv='0' then |
18 | adresse <= 0; |
19 | aktiv <= '1'; |
20 | elsif adresse<64 then |
21 | adresse <= adresse + 1; |
22 | else
|
23 | aktiv <= '0'; |
24 | end if; |
25 | end process; |
26 | |
27 | result <= c_sine_value_x(adresse) * c_rising_edges/c_divisor; |
28 | |
29 | process begin |
30 | wait until rising_edge(CLK); |
31 | if (aktiv='1') then |
32 | c_sine_position_x(adresse) <= result; |
33 | else
|
34 | c_sine_position_x_fertig <= c_sine_position_x; |
35 | end if; |
36 | end process; |
Code 2:
1 | type t_memory_position_x is array(0 to 64) of Integer; |
2 | signal c_rising_edges : INTEGER RANGE 2000 to 2500 := 2270; |
3 | constant c_divisor : INTEGER := 8192; |
4 | signal c_sine_position_x : t_memory_position_x; |
5 | |
6 | begin
|
7 | |
8 | c_sine_position_x <= (0 * c_rising_edges/c_divisor, ..., 2048 * c_rising_edges/c_divisor); -- enthält 65 Multiplikationen |
Vermutlich wird da alles bei der Synthese berechnet. Kommen da Werte von aussen rein? c_sine_position_x <= (0 * c_rising_edges/c_divisor, ..., 2048 * c_rising_edges/c_divisor); kann mit constant c_divisor : INTEGER := 8192; auch sehr stark vereinfacht werden. Ich weiß ja nicht wie Multiplikationen mit Integer gemacht werden, aber ich würde vermuten, dass c_rising_edges/c_divisor immer Null ergibt wenn c_rising_edges > c_divisor. Denn mit c_divisor = 8192 kann man schreiben c_rising_edges/8192, das ist das Gleich, wie wenn du c_rising_edges um 13 Stellen nach rechts verschiebst. Da c_rising_edges aber immer kleiner 8192 ist sind dann alle stellen leer, also Null. Im ersten Teil wird das bei der Synthese vermutlich genauso wegoptimiert.
Hans schrieb: > enthält 65 Multiplikationen Sieht das der Synthesizer auf so? Wird irgendwo von dem Array auch gelesen und irgendwas ausgegeben? Wenn nicht, dann sagt sich der Synthesizer: "Nutzlos, kann alles wegoptimiert werden!" > Anzahl der genutzten Logik-Zellen Und die ist wie hoch?
:
Bearbeitet durch Moderator
Lothar Miller schrieb: > Hans schrieb: >> enthält 65 Multiplikationen > Sieht das der Synthesizer auf so? Wird irgendwo von dem Array auch > gelesen und irgendwas ausgegeben? Wenn nicht, dann sagt sich der > Synthesizer: "Nutzlos, kann alles wegoptimiert werden!" Es wird in mehreren if-Abfragen aus dem Array gelesen. Das hatte ich bei der ersten Betrachtung nicht beachtet und deswegen hat der Synthesizer es wegoptimiert. >> Anzahl der genutzten Logik-Zellen > Und die ist wie hoch? Wenn ich jetzt aus dem Array lese, erhalte ich folgende Ausnutzung Code 1: Number of Slices: 3361 (57%) Number of Slice Flip Flops: 1552 (13%) Number of 4 input LUTs: 5322 (45%) Number of bonded IOBs: 26 (6%) Number of MULT18X18SIOs: 2 (10%) Number of GCLKs: 1 (4%) Code 2: Number of Slices: 2657 (45%) Number of Slice Flip Flops: 114 (0%) Number of 4 input LUTs: 5086 (43%) Number of bonded IOBs: 26 (6%) Number of MULT18X18SIOs: 20 (100%) Number of GCLKs: 1 (4%) Sollte die Ausnutzung der Logik-Zellen bei dem Code 1 nicht wesentlich geringer sein?
Hans schrieb: > Wenn ich jetzt aus dem Array lese Wie liest du aus dem Array? Das Problem hier ist nämlich ganz einfach dass du offenbar von 2 Stellen aus dem Array liest (einmal dort, wo gerechnet wird und einmal dort, wo du die Werte ausgeben willst). Und wie muss ein Bauteil aussehen, das zwei Lese-Ports bietet? Wie muss so ein Bauteil beschrieben werden? Stichworte: XST Users Guide und XAPP463 (für S3)
:
Bearbeitet durch Moderator
Lothar Miller schrieb: > Hans schrieb: >> enthält 65 Multiplikationen > Sieht das der Synthesizer auf so? Wird irgendwo von dem Array auch > gelesen und irgendwas ausgegeben? Wenn nicht, dann sagt sich der > Synthesizer: "Nutzlos, kann alles wegoptimiert werden!" > >> Anzahl der genutzten Logik-Zellen > Und die ist wie hoch? In diesem Beispiel wurde nur der dargestellte Code synthetisiert. Hier werden in beiden Fällen etwa 75 Zellen benötigt. Wenn ich das oben dargestellte in den restlichen Code einbinde, also das Array auch abfrage, dann ist die Variante mit BRAM sogar deutlich aufwendiger bezüglich der Resourcennutzung. Aber ich habe es genau so eingebunden wie oben im Beispiel dargestellt. Kurzum, die Nutzung des BRAM hat zu einer Verschlechterung bzw. bin ich im Gesamtprojekt von 103% auf 128% Slices gerutscht. Die Nutzung des BRAM oben ist aber richtig umgesetzt? In der Simulation jedenfalls schreibt er pro Takt auch nur ein Ergebnis in das Array...müsste also weniger Aufwand pro Schritt haben und weniger Slices nutzen. Tut er aber nicht... :( @Gustl Wenn er die Multiplikationen so durchführen würde, dann wäre mein Array ja immer mit Nullen gefüllt. Ist es aber nicht. Ich denke, dass er erst die Multiplikation ausführt und dann durch 8094 teilt. So ist es auch gedacht. Grundsätzlich hätte ich mit einer Kommazahl Multiplizieren müssen, diese multipliziere ich mit 8094 um einen Integer Vorfaktor zu erhalten (hier zwischen 0...2048). Der Vorfaktor wird dann mit dem variablen Frequenzsignal (c_rising_edges) multipliziert und anschließend erfolgt die Division durch 8094, um das richtige Ergebnis zu erhalten. Darum steht in dem Array auch das Richtige drin. Eine Multiplikation mit Kommazahlen wäre ja nicht synthetisierbar oder?
Lothar Miller schrieb: > Hans schrieb: >> Wenn ich jetzt aus dem Array lese > Wie liest du aus dem Array? Das Problem hier ist nämlich ganz einfach > dass du offenbar von 2 Stellen aus dem Array liest (einmal dort, wo > gerechnet wird und einmal dort, wo du die Werte ausgeben willst). Und > wie muss ein Bauteil aussehen, das zwei Lese-Ports bietet? Wie muss so > ein Bauteil beschrieben werden? Stichworte: XST Users Guide und XAPP463 > (für S3) Ich lese mit der folgenden for-Schleife aus dem Array:
1 | for i in 1 to c_position_x/2 loop |
2 | if (counter_position >= c_sine_position_x(i-1) and counter_position < c_sine_position_x(i)) then |
3 | position := i; |
4 | end if; |
5 | end loop; |
Aber warum lese ich dort, wo gerechnet wird, aus dem Array? Dort schreibe ich die berechneten Werte doch nur ins Array.
Hans schrieb: > Dort schreibe ich die berechneten Werte doch nur Ich habe es gerade erst gesehen... :-o Es ist aber sowieso viel viel schlimmer:
1 | c_sine_position_x_fertig <= c_sine_position_x; |
Hier wird alles komplett auf einen Schwung "umkopiert". Und dann: > Ich lese mit der folgenden for-Schleife aus dem Array: Eine Loop bedeutet in VHDL immer "alles parallel und gleichzeitig". Das kann in beiden Fällen nie&nimmer ein RAM geben! In welchem Bauteil sollte denn parallel ein kompletter Speicherbereich in einen anderen kopiert werden können? Oder wie sollte ein RAM (ja, diese schwarzen Käfer mit Adress- und Datenleitungen) alle Daten parallel an seinen Pins ausgeben können? Ich kenne keinen solchen Baustein, aber der Synthesizer baut dir deine Beschreibung freundlicherweise wie gewünscht aus vielen, vielen kleinen einzelnen Speicherelementen auf. Kurz&knackig: bei einem RAM kann immer nur auf 1 einziges Element zugegriffen werden. Wenn du das nicht tust, dann wird kein RAM daraus. Du musst also die erwähnten Dokumente LESEN, VERSTEHEN und ANWENDEN. Dann wird dein "großes" Design plötzlich ganz klein...
:
Bearbeitet durch Moderator
Und nochmal: Wenn du die berechnungen nacheinander ausführen willst, dann mußt du das über eine Statemachine machen. Denn eine Schleife mit for wird "ausgeklappt" und die Berechnung findet auf allen Elemten gleichzeitig (parallel) statt.
Okay, das macht Sinn. Heißt das auch, dass ich pro Takt nur auf ein Element im BRAM zugreifen kann? Dann würde ich nämlich einige Takte brauchen und somit mit meinem Timing nicht mehr hinkommen. Gibts Alternativen, ansonsten muss ich ihn die Multiplikationen wie oben ausgeführt berechnen lassen.
...und noch was. Wenn ich eine loop mache, dann ist das doch identisch mit den ausgeschriebenen Zeilen anhängig von den Schleifendurchläufen. Wenn das Ganze in einem Prozess steht, dachte ich, dass die Zeilen dann sequentiell abgearbeitet werden. Innerhalb der loop passiert das dann nicht?
Hans schrieb: > ...und noch was. Wenn ich eine loop mache, dann ist das doch > identisch > mit den ausgeschriebenen Zeilen anhängig von den Schleifendurchläufen. > Wenn das Ganze in einem Prozess steht, dachte ich, dass die Zeilen dann > sequentiell abgearbeitet werden. Innerhalb der loop passiert das dann > nicht? Hat sich erledigt^^
Hans schrieb: > Hat sich erledigt^^ Falls trotzdem mal einer fragt: Wieso? Der Denkfehler ist hier: > Wenn das Ganze in einem Prozess steht, dachte ich, dass die Zeilen dann > sequentiell abgearbeitet werden. Nur der Simulator rechnet sich den Prozess "von oben her" aus. Und damit "gewinnt" z.B. die letzte Signalzuweisung. Aber auf der Hardware wird ein Prozess nicht "abgearbeitet". Er wird nur vom Synthesizer so umgesetzt, dass auch hier die letzte Signalzuweisung gewinnt. Trotzdem ist der komplette "Prozessinhalt" komplett, parallel und gleichzeitig in der Hardware vorhanden.
:
Bearbeitet durch Moderator
> Okay, das macht Sinn. Heißt das auch, dass ich pro Takt nur auf ein > Element im BRAM zugreifen kann? Dann würde ich nämlich einige Takte > brauchen und somit mit meinem Timing nicht mehr hinkommen. Der 700er hat doch 20 mal 18kBit Dualport BlockRAMs drinne. Du kannst also z.B. BlockRAM3(n)=BlockRAM1(n) x BlockRAM2(n) + BlockRAM2(n) rechnen oder was auch immer und wenn du noch enen Brauchst du hast 20 stück a 18kBit da drinne und die sind auch noch jedes für sich Dualported.
ich empfele dir mal das Datenblatt durchzulesen, wie die S3s aufgebaut sind: http://www.xilinx.com/support/documentation/data_sheets/ds557.pdf
uwe schrieb: > die sind auch noch jedes für sich Dualported. Allerdings kann man auch die nicht parallel hin- und her kopieren. Nicht mal eine eigene Resetleitung zum definierten Zurücksetzen des gesamten Speichers haben die... > die sind auch noch jedes für sich Dualported. Und dann muss man die Doku zum Synthesizer lesen, wie der gerne ein DP-RAM beschrieben haben möchte, dass er es richtig erkennt. Oder man muss es manuell instantiieren, dann kommt man schon gar nicht auf die Idee, zu meinen, dieses Bauteil wäre einfach so ein Array.
:
Bearbeitet durch Moderator
Da ich sehr zeitkritische Signale schalten muss nehme ich jetzt den höheren Slice Aufwand in Kauf und lasse mir alle Werte in einem Takt berechnen. Ich habe an anderer Stelle optimiert, so dass ich wieder über 50% Slices frei habe. Das sollte mir für die weiteren Schritte reichen, allerdings würde mich trotzdem noch interessieren, ob es nicht ein ähnliches Board gibt wie das Spartan 3an nur mit mehr Slices? Nur den FPGA zu wechseln 700er gegen 1400er ist ja nicht wie bei einem Prozessor möglich... Das Datenblatt werde ich mir auf jeden Fall mal anschauen, könnte den BRAM vielleicht an anderer Stelle sinnvoll verwenden! Danke auf jeden Fall für die Informationen ;)
Hans schrieb: > sehr zeitkritische Signale Hast du dazu eine Zahl? Was sind dad für Signale? Und wie passen die zu den schnarchlangsamen 10ms?
Lothar Miller schrieb: > Hans schrieb: >> sehr zeitkritische Signale > Hast du dazu eine Zahl? Was sind dad für Signale? Und wie passen die zu > den schnarchlangsamen 10ms? Grundsätzlich gilt bei meiner Anwendung, je schneller desto besser. Jedoch gibt es Signale die nicht unbedingt so schnell berechnet werden müssen. Die Ausgabe meiner Steuersignale erfolg mit 20ns (Quarztakt) jedoch könnte ich einen Fehler in Kauf nehmen wenn, beispielsweise die angesprochenen Zeitabschnitte auf dem Sinus langsamer aktualisiert werden. 10ms war hier nur beispielhaft genannt, mir ging es erstmal darum den Code weniger Resourcenverbrauchend zu gestalten. Gibt es eine Art Mengenbegrenzung der verwendeten Signale? In meinem Design meckert er beim Implementieren, dass er nicht alle Signale automatisch routen kann. Verwende ich ein Signal (beliebiges) weniger, so funktioniert das Ganze wieder. Ich benutze die WEB ISE...vielleicht gibt es dort eine Begrenzung?
Hans schrieb: > Gibt es eine Art Mengenbegrenzung der verwendeten Signale? Nein, P&R bekommt dann einfach die Komponenten nicht mehr verdrahtet, weil keine Routing-Kapazitäten mehr frei sind. Da kann das FPGA auch erst "halb voll" sein... Du kannst evtl. noch an den P&R Einstellungen herumschrauben und den "Effort" hochdrehen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.