Case Struktur in Single Cycle Timed Loop

Hallo, ich möchte auf einen FPGA eine Case Struktur in einem Single Cycle Timed Loop unterbringen.

In der LabVIEW Hilfe steht dazu folgendes:

Inside single-cycle Timed Loop—When you use a Case structure inside a single-cycle Timed Loop, the combinatorial logic delay required to evaluate the case selector is proportional to the width of the selector input data type and the number of cases. The combinatorial logic delay introduced by output tunnels is proportional to the number of cases.


Ich bin immer davon ausgegangen, dass ein Iterationsschritt pro Clock Cycle ausgeführt wird.
Wie kann es dann sein, dass eine Struktur wie Case dann mehrere Cycles benötigt ?

Was hat das für Auswirkungen ?
Wird dann die Clock langsamer ?

Ich denke, dass ich irgendetwas nicht verstanden habe ?!?

Falls jemand eine Beispiel hätte bei dem Verzögerungen durch eine Case Struktur entstehen, wäre das schön.

MfG

Anzeige

' schrieb:Hallo, ich möchte auf einen FPGA eine Case Struktur in einem Single Cycle Timed Loop unterbringen.

In der LabVIEW Hilfe steht dazu folgendes:

Inside single-cycle Timed Loop—When you use a Case structure inside a single-cycle Timed Loop, the combinatorial logic delay required to evaluate the case selector is proportional to the width of the selector input data type and the number of cases. The combinatorial logic delay introduced by output tunnels is proportional to the number of cases.
Ich bin immer davon ausgegangen, dass ein Iterationsschritt pro Clock Cycle ausgeführt wird.
Wie kann es dann sein, dass eine Struktur wie Case dann mehrere Cycles benötigt ?

Was hat das für Auswirkungen ?
Wird dann die Clock langsamer ?

Ich denke, dass ich irgendetwas nicht verstanden habe ?!?

Falls jemand eine Beispiel hätte bei dem Verzögerungen durch eine Case Struktur entstehen, wäre das schön.

MfG

innerhalb der SCTL wird der "Overhead" der gebraucht wird um das Datenfluss-Modell auf dem FPGA abzubilden aufgehoben (Stichwort "enable chain"), => der Code kann vom Compiler optimiert werden so dass es möglich ist innerhalb eines Tics mehrere "Einzelbefehle" abzuarbeiten. Das hat natürlich auch seine Grenzen, das kann man recht schnell ausprobieren, in dem man einen "langen Datenpfad" in einer SCTL aufbaut, irgendwann meckert der Compiler dann, dass dieser Code nicht mehr in einen Tic passt, und man doch bitte was anderes probieren soll (ich glaube er rät dann zu Pipelining ...) und dann hat man die Grenze erreicht, auf die du auch stoßen kannst, wenn du die Case-Struktur mit zu vielen Fällen ausstattest, weil zur Laufzeit für jeden Fall mehr oder weniger ein Vergleich mit der Eingangsgröße durchgeführt werden muss.

Die Clock wird defintiv NICHT langsamer

' schrieb:innerhalb der SCTL wird der "Overhead" der gebraucht wird um das Datenfluss-Modell auf dem FPGA abzubilden aufgehoben (Stichwort "enable chain"), => der Code kann vom Compiler optimiert werden so dass es möglich ist innerhalb eines Tics mehrere "Einzelbefehle" abzuarbeiten. Das hat natürlich auch seine Grenzen, das kann man recht schnell ausprobieren, in dem man einen "langen Datenpfad" in einer SCTL aufbaut, irgendwann meckert der Compiler dann, dass dieser Code nicht mehr in einen Tic passt, und man doch bitte was anderes probieren soll (ich glaube er rät dann zu Pipelining ...) und dann hat man die Grenze erreicht, auf die du auch stoßen kannst, wenn du die Case-Struktur mit zu vielen Fällen ausstattest, weil zur Laufzeit für jeden Fall mehr oder weniger ein Vergleich mit der Eingangsgröße durchgeführt werden muss.

Die Clock wird defintiv NICHT langsamer

Vielen Dank für die Antwort.
Nun, an diese Grenzen werd ich sicherlich bald kommen, aber wenn der Compiler das mitkriegt, ist das ja dann nicht so schlimm.
Wichtig für mich ist nur, dass pro Tick genau eine Iteration ausgeführt wird.

MfG