Code beeinflusst Geschwindigkeit, Richtlinien

Was da glaube ich am meisten hilft ist das Verständnis wie die 
Beschreibung in einem FPGA umgesetzt wird. Und wie das mit dem Takt so 
ist.
Das ist ein sehr weites Feld.

Grundsätzlich würde ich sagen dass der Takt umso höher werden kann je 
weniger Logik zwischen den Registern ist. Aber welche Beschreibung zu 
wie viel Logik führt ist anfangs schwer abzuschätzen.

Wenn du Code hast, der optimiert werden soll, dann zeig der hier gerne 
her. Am Beispiel sind manche Dinge einfacher zu erklären.
Und du kannst dir natürlich auch angucken was die Toolchain aus deiner 
Beschreibung gemacht hat. Da siehst du genau was zwischen Registern 
abläuft.

Ja, stimmt, aber was ist das Ziel?
Ist das Ziel ein möglichst hoher Takt? Dann muss man optimieren was 
geht. Wenig Logik zwischen Register und viel Pipelines bauen. Das ist 
aber ein Kompromiss aus Takt und Latenz.
Oft ist das Ziel aber nicht ein möglichst hoher Takt, sondern ein 
bestimmter Takt. Also um etwas zu erreichen muss der Takt mindestens 50 
MHz betragen. Und da gibt es keinen Sinn weiter zu optimieren wenn das 
Design den Takt schafft. Man macht das also nur so optimiert wie nötig.

Was du aber auf jeden Fall machen solltest:
Die Frequenz der Eingangstakte solltest du über Constraints der 
Toolchain mitteilen.
Du solltest keine Takte durch Flipflops teilen. Ja, kann man machen, 
aber nur wenn man weiß was man tut.
Und wenn du mehrere Takte verwendest dann achte auf einen sauberen 
Übergang von Signalen aus der einen in die andere Taktdomäne. Dafür gibt 
es einige Techniken. Und auch da muss man Constraints setzen, dass die 
Toolchain weiß, dass die Takte nicht synchron sind.

Paul schrieb:
> low-cost-FPGA, der so ca. 300 MHz max.

Diese Datenblatt Taktangaben sind selten zu gebrauchen. Um welches FPGA 
geht es denn und wie hast du das zu lösen versucht?

Paul schrieb:
> Ich habe zig verschiedene Varianten ausprobiert und recherchiert, aber
> da war leider nichts dabei, wodurch die Anforderungen erfüllt worden
> wären.

Wenn du dein Design durch die Toolchain schickst, und das das Timing 
nicht schafft, dann kannst du dir ganz genau angucken wo das nicht 
geschafft wird. Also welcher Pfad an welcher Stelle zu langsam ist. Oft 
sind das Rechnungen die man dann auf mehrere Takte aufteilen kann. Oder 
man baut eine Pipeline ein oder ... oft fehlen auch schlicht 
Constraints. Dann ist es so, dass die Toolchain sagt, das Timing wird 
nicht geschafft, aber das stimmt nicht weil ein set_false_path fehlt.

Paul schrieb:
> Hättest du einen Vorschlag für einen maximal optimierten Code
> (Verilog) für ein solches PWM-Modul?

Kannst du das nochmal genauer erklären?
Ich verstehe vorallem nicht was du mit Trägerfrequenz meinst in Bezug 
auf PWM und deine Signale.
So wie ich das verstanden habe hast du einen 60 kHz Sinus und darauf ist 
dann mit FM ein Audiosignal moduliert.
Welche Werte bekommt das FPGA, also was stellen diese 12 Bit dar? Sind 
das Abtastwerte von einem AD-Wandler? Wenn ja, welche Abtastrate macht 
der? Außerdem ist noch wichtig welche Auflösung die PWM haben soll.

Gustl B. schrieb:
> Grundsätzlich würde ich sagen dass der Takt umso höher werden kann je
> weniger Logik zwischen den Registern ist. Aber welche Beschreibung zu
> wie viel Logik führt ist anfangs schwer abzuschätzen.

Du musst nur die Groessen der LUTs des Ziel FPGAs kennen. Dann kannst du 
schon sehr frueh sehen wieviele kaskadiert werden muessen. Das bekommen 
auch Anfaenger hin, sobald sie mit dem Konzept des FPGAs vertraut sind.

Ich weiss nicht ob ein Buch so effektiv ist um damit einzusteigen. Das 
ist einfach alles Erfahrung. Und nicht nur Erfahrung mit FPGAs im 
Allgemeinen, sondern auch Hersteller- und Toolchain spezifisch. Denn 
genauso wie du durch Code Optimierungen deine Zielgeschwindigkeit 
verbessern kannst, kannst du auch durch das Finden der richtigen Tool 
Settings (angepasst auf dein Design) einiges erreichen. Kleines 
Beispiel: Register Balancing.

Das lernt man am besten indem man einfach anfaengt. Loslegen und wenns 
Probleme gibt, nachfragen. Und immer im Hinterkopf behalten: Man lernt 
nie aus. :-)

Paul schrieb:
> Die Taktfrequenz des FPGAs musste vorzugsweise sehr hoch sein
> (ideal deutlich über 200 MHz), wegen weiterer Module, die das brauchten.
Man muss nicht das gesamte FPGA mit der theoretisch maximalen 
Geschwindigkeit fahren. Oft muss man nur einzelne Module lokal mit hoher 
Taktfrequenz anfahren. Die Datenrate "nach aussen" ist dann wesentlich 
niedriger.

Paul schrieb:
> Hättest du einen Vorschlag für einen maximal optimierten Code
> (Verilog) für ein solches PWM-Modul?
Wenn du die Möglichkeiten eines speziellen FPGAs ausreizen musst, dann 
musst du "das Modul" erst mal als Schaltung so auslegen, dass die Logik 
(LUTs) samt der Register (Flipflops) gut auf das FPGA passt. Und diese 
Schaltung beschreibst du mit der gewünschten 
HardwareBESCHREIBUNGsssprache (=HDL, in deinem Fall Verilog) diese 
optimale Schaltung in der Hoffnung, dass der Synthesizer aus deiner 
Beschreibung das macht, was du gerne willst. Ob der Synthesizer deine 
Beschreibung verstanden hat und du das bekommen hast, was du wolltest, 
kannst du z.B. im RTL Schaltplan ansehen.
Wie du bestimmte Komponenten so beschreiben musst, dass der Synthesizer 
darin bestimmte Hardwarekomponenten erkennt, steht im jeweiligen 
Handbuch zum Synthesizer.

Hast du gemerkt, dass in meinen Text das Wort "Code" nicht vorgekommen 
ist? Denn allzu leicht verwechselt der Anfänger das dann mit "C-Code" 
und "programmiert" halt wie aus der Softwareentwicklung gewohnt 
irgendwie vor sich hin und wundert sich, was herauskommt.

Paul schrieb:
> Es ging mir eher um eine allgemeine Aussage, die wohl nicht so leicht
> möglich ist.
Doch, genau diese allgemeine Aussage habe ich gemacht. Wenn man das 
beachtet, was ich da geschrieben habe, dann kann man den Code so 
schreiben, dass der Synthesizer die gewünschte Schaltung daraus macht.

Dadurch, dass ich mich an diese Arbeitsweise halte, kann ich die 
Toolchain über Constraints so steuern, dass mein Ziel erreicht wird.

Oder andesrum: wenn ich vermurksten, dem Synthesizer unverständlichen 
Code schreibe, dann kann ich hinterher mit Constraints auch nichts mehr 
geradebiegen.

Fpgakuechle K. schrieb:
> Es ist die Hardwarestruktur (i.e. Pipeling, Fan out/in, parallele versus
> serielle Abarbeitung) und das Routing das die max. erreichbare
> Geschwindigkeit für den jeweiligen Teil des Designs bestimmt.

Genau das beschreibt man mit Code. Das macht einen sehr großen 
unterschied bei teilweise sehr einfachen Dingen.
Ein Vergleich einer Zahl (unsigned) mit einem Wert wird deutlich 
komplizierter als nur der Vergleich eines Bits auf 1 oder 0. Daher 
erreichen Zähler eine höhere Geschwindigkeit wenn man ihnen 1 Bit mehr 
gibt und auf Überlauf oder eher Unterlauf mit dann nur dem MSB prüft.
Aber das ist der Code den man schreibt, auch Pipelines baut man im Code 
und Register Balancing geht auch nur oder bringt nur was wenn man das 
vorher im Code berücksichtigt hat.
Welchen Maximaltakt das Design erreicht hängt am FPGA, der Toolchain und 
deren Einstellungen, und dann am eigenen Code samt IPs und Constraints.

Für optimierten Code braucht man Verständnis über die Hardware und man 
sollte sich auch angucken was die Toolchain macht. Und ihr alles 
mitteilen in Form von Constraints. Es ist hier aber nicht so wie in C 
oder anderen Programmiersprachen, dass wenig oder kurzer Code schneller 
läuft. Oft ist es sogar umgekehrt und mehr Code führt vielleicht zu mehr 
Logik, auch nicht zwingend, erlaubt aber den höheren Takt.
Weil das so ist sollte man den Code schön lesbar schreiben und so, dass 
ihn die Toolchain versteht, mit der unterhält man sich quasi über den 
Code.

Paul schrieb:
> vom AD
> kommen 12 Bit parallel, es wird ein Audiosignal digitalisiert,
> Samplingfrequenz weiß ich nicht mehr, halt im üblichen Bereich. Daraus
> soll der FPGA dann die PWM machen mit 60kHz Trägerfrequenz.

Trägerfrequenz kenne ich zwar als was Anderes, aber ist sehe das jetzt 
mal als die Frequenz mit der die PWM neue Werte ausgibt.
Ja, leider fehlen weiterhin viele Informationen wie Auflösung der PWM, 
FPGAFamilie, ...

Für 60 kHz und 12 Bits brauchst du 1/(60 kHz *2**12) = 4,069 ns je Bit, 
macht einen Takt von 245,8 MHz. Das sollte man schon schaffen können.

Edit:
Du hast da sehr wahrscheinlich mehrere Taktdomänen, eine für den ADC und 
eine für die PWM. Idal wäre es ja, wenn du mit dem 2**12 fachen Takt der 
ADC Abtastrate die PWM ausgibst. Oder anderes herum wenn der ADC 
tatsächlich mit 60 kSample/s neue Werte liefert.

Fpgakuechle K. schrieb:
> Erst wählt man die
> notwendige Counter/Timer- Architektur ( ripple, carry-chain,
> shiftregister, LFSR, ..)
> http://www.prevailing-technology.com/publications/counter_examples
> ,dann schreibt das in HDL so, das das vom Synthese-tool erkannt wird,
> und das 'einbaut' was gewollt ist.

Richtig, genau das sollte man machen wenn einem die Ressourcen oder das 
Timin wichtig sind. Wenn einem das egal ist, weil das FPGA groß genug 
ist und der Takt nicht hoch sein muss, dann kann man VHDL schon auch 
hinschreiben ohne daran zu denken was da genau draus wird.

Ich habe dazu einen Thread aufgemacht:
Beitrag "Vergleich von Zählern"

Wenn man einen Zähler einfach so hinschreibt wie man das ohne große 
Kenntnis über FPGAs machen würde, dann reicht auch das für sehr viele 
Anwendungen. Klar ist nicht optimal, aber eben für viele Fälle gut genug 
und spart Denkarbeit. Ich sage nicht, dass man das so machen sollte und 
schon gar nicht, dass man das nur so machen sollte.
Wenn ich Code schreibe achte ich erstmal auf Lesbarkeit, damit man den 
auch nach etwas Zeit wenn man den wieder liest auch noch versteht. Der 
Code ist oft gut genug. Wenn es dann irgendwo hakt, dann denke ich da 
länger drüber nach und optimiere.

Weltbester FPGA-Pongo schrieb im Beitrag #6643217:
> In welchem Projekt sind die nicht wichtig??

In den meisten Projekten. Ja, fast in jedem Projekt ist eines der Beiden 
wichtig, aber nicht überall. Wenn ich also einen kritischen Pfad habe 
der mein Timing limitiert, dann kann ich trotzdem an anderer Stelle im 
FPGA etwas haben das das Timing locker schafft. Wenn ich das Andere also 
noch weiter optimiere, dann gewinne ich nichts an besserem Timing.