Delay - Quartus II - async Design - ModelSim Simulation

[Andi (loopy83)]

Hallo zusammen,
 
ich habe folgendes Problem:
Ich habe als Zielplattform einen Stratix II FPGA und möchte darin ein 
asynchrones Design umsetzen.
Kern des Designs ist eine Taktgenerierung mittels XOR und Delay Element. 
Eingehende Signale werden also kombinatorisch zu einem Takt verschaltet, 
an den dann weitere Logik und LUTs gekoppelt sind.
 
Das Design synchron zu realisieren ist leider nicht möglich, da durch 
das samplen der eingehenden Signale schon zu viel Zeit verloren geht und 
dadurch die „Grenzfrequenz“ zu niedrig ist.
Ich habe es dennoch versucht und das delay mit einem counter 
realisiert.  Hat funktioniert, lief alles wie gewünscht, nur leider zu 
langsam, weil ich immer mindestens einen Takt verliere.
 
Nun habe ich das Delay Element wie folgt umgesetzt_

entity nand_delay is
  generic (
    gatter_number : integer := 100
    );
  port (
    sig_in                   : in  std_logic;
    dly_sig_out    : out std_logic
    );
end;
 
y_vec(0) <= sig_in;
   
g_step : for s in 0 to gatter_number-1 generate
nand_gatter_1: nand_gatter
port map (a       => y_vec(s),
                     b       => y_vec(s),
                     y       => y_vec(s+1));
end generate;
 
dly_sig_out <= y_vec(gatter_number);

 
Dabei werden mit dem generic NAND Gatter aneinander gereiht, um die 
Gatterlaufzeiten für das Delay zu nutzen.
Im Modelsim habe ich davor das delay einfach mit sig_out <= sig_in after 
X ns; simuliert und die kombinatorische Logik funktioniert tadellos.
Nur leider ist es so im Quartus nicht synthetisierbar, daher der Umweg 
über die zahlreichen Instanzen.
 
Nun möchte ich eine Timing Simulation machen.
Ich komme von Xilinx und ISE und habe daher noch etwas Probleme mit 
Quartus.
 
Wie kann ich der Synthese beibringen, dass die NAND Gatter nicht heraus 
optimiert werden (vielleicht so eine Art keep constraint)?
Wie erstelle ich nach der Synthese und dem Fitter ein Modell auf, das 
ich dann im Modelsim importieren und simulieren kann.
Wie muss ich die constraints setzen, wenn ich keinen Takt habe?
Ist meine Idee bzw. Herangehensweise so im FPGA realisierbar, oder gibt 
es Bedenken?
 
Vielen Dank!
Andreas
 

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Andreas B. schrieb:
> Ist meine Idee bzw. Herangehensweise so im FPGA realisierbar,
Ja.
> oder gibt es Bedenken?
Massive.

Warum willst du dich auf ein derartig unreproduzierbares 
Gatterlaufzeitgebastel (wobei die meiste Laufzeit hier vom Routing und 
nicht vom Gatter kommt) einlassen? Was willst du damit erreichen?

[Christian R. (supachris)]

Fraglich ist, ob du das asynchrone Geraffel wirklich brauchst ? In den 
meisten Fällen ist das nicht nötig, und deine Beschreibung des 
eigentlichen Problems ist äußerst nebulös. Höchstwahrscheinlich liegt 
das nämlich wo ganz anders.

[Andi (loopy83)]

Hallo Lothar,

Reproduzierbarkeit ist vorerst kein Kriterium.

Ich habe zwei zueinander versetzte Signale, mit gleicher Periode, wobei 
bei jeder Flanke eine Art Taktimpuls generiert werden soll. Da es zwei 
Signale mit je einer steigenden und einer fallenden Flanke sind, sollen 
pro Periode vier Taktimpulse generiert werden.
Die Länge der Taktimpulse ist egal, Hauptsache sie können ausgewertet 
werden. Es brauch also kein sauberes 50/50 Signal entstehen.
Von daher nehme ich an, dass die Konstanz meiner 
Routing-/Gatterlaufzeiten nebensächlich ist. Daher diese Idee...

Vielen Dank!
Andreas

[Andi (loopy83)]

Christian R. schrieb:
> Fraglich ist, ob du das asynchrone Geraffel wirklich brauchst ? In den
> meisten Fällen ist das nicht nötig, und deine Beschreibung des
> eigentlichen Problems ist äußerst nebulös. Höchstwahrscheinlich liegt
> das nämlich wo ganz anders.

Die Eingangssignale können schnell und langsam kommen, ich müsste also 
immer mit einem extrem hohen Sampletakt arbeiten. Mir stehen aber leider 
nur 25-30MHz zur Verfügung. Bei einer maximalen Eingangsfrequenz von ca. 
24MHz muss ich asynchron arbeiten.

[Christian R. (supachris)]

Hm, und die "Abtast"-Frequenz intern mit DLL/PLL erhöhen geht nicht? 
Oder wenigstens um 90° Schritte verschobene Takte, da könntest du 
immerhin 4x pro Periode abtasten. Weil den Spike den du erzeugst musst 
du ja weiter verarbeiten, das zieht ja einen Rattenschwanz von 
asynchronen Sachen nach sich...

[Andi (loopy83)]

Hallo,

vom erzeugten Peak ist dann nur die Flanke entscheidend, damit werden 
dann die LUTs "getaktet".

Hat denn jemand schon eine derartige Simulation mit Quartus/Modelsim 
gemacht und kann mir ein wenig Starthilfe geben?

Vielan Dank!
Andreas

[ben (Gast)]

PLL !

[Christian R. (supachris)]

Andreas B. schrieb:
> vom erzeugten Peak ist dann nur die Flanke entscheidend, damit werden
> dann die LUTs "getaktet".

Das wird ja immer schlimmer. Ein asynchron erzeugter Glitch als "Takt" 
für Logik. Na herrlich :)
Einmal den FPGA anhauchen und schon läufts nicht mehr wie gewollt.

[Andi (loopy83)]

Hallo,

bei ASICs ist es auch möglich, solche delay-Elemente zu erzeugen bzw. 
einzusetzen. Auch da kann ein so erzeugtes Signal als Takt für weitere 
Logik verwendet werden.
Nur ist das dort eingesetzte delay-Element eine Blackbox in einer Libary 
der Fab.

Da ich keinen ASIC bauen will, muss ich für meinen Testaufbau auf einen 
FPGA zurückgreifen und möchte gerne diese Delay-Geschichte "nachbilden".

Nun war die Frage nach der Umsetzung und Machbarkeit, die von Lothar, 
dessen fachliche Kompetenz ich persönlich nie in Frage stellen würde, 
mit Ja beantwortet wurde.

Wenn so etwas im FPGA nicht realisierbar ist, dann lasse ich mich gerne 
belehren und muss mir dann etwas anderes einfallen lassen. Aber bis 
dahin wollte ich Meinungen und Anregungen dazu sammeln.

Dennoch vielen Dank für die kritischen Meinungen zu meiner 
unkonventionellen Herangehenswrise. :)

Andreas

[SuperWilly (Gast)]

Ein paar Constraints für die Platzierung der "nand_gatter" können die 
Reproduzierbarkeit erhöhen.

VG, SuperWilly

[Christian R. (supachris)]

Machbar ist das schon, aber wie gesagt nicht wirklich reproduzierbar. 
Wir hatten so ein Spaß auch mal für kurze Ausgangs-Impulse gemacht, aber 
bei jedem Routing-Durchlauf kam was anderes raus, und das ganze war sehr 
von Temperatur abhängig und damit im praktischen Einsatz nicht wirklich 
brauchbar.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Andreas B. schrieb:
> Nun war die Frage nach der Umsetzung und Machbarkeit, die von Lothar
> mit Ja beantwortet wurde.
Hmmm...
Ich habe aber massive Bedenken dagegengestellt. Es wird schon 
irgendwie gehen, aber schon neu Routen kann dir das Signal sauber 
zerlegen. Und wenn du dann mit diesem Spike auf einem Taktnetz rumfährst 
wird das nicht besser.

> Wenn so etwas im FPGA nicht realisierbar ist...
Dann fahr eben aus dem FPGA raus und wieder rein. Wenn schon gebastelt 
werden soll, dann würde ich da die Verzögerung durch ein IO-Pad in 
Augenschein nehmen. Die ist auf jeden Fall schon mal länger als das, was 
du innerhalb des FPGAs ohne Handstand hinbekommst...

Aber es ist schon so: Murks bleibt Murks. Das sollte dir bewusst sein.

[J. S. (engineer)]

Die Methodik funktioniert in FPGAs nicht so ganz einfach, weil die 
Gatter in Gruppen zusammenliegen und LUT-weise verzögern. Ich hatte mal 
so eine APP und wollte das mit dem FPGA EDitor setzen, kam aber rasch 
dahin, dass man beim Stratix nur maximal 8 delays verschalten kann, beim 
9. kommt dann eine grosse Laufzeit hinzu. Es lassen sich also nicht alle 
gewünschten delayd einstellen.

Was mich verwundert ist einerseits die Darstellung, ein Takt sie zu 
stark verzögern, andererseits sollen 100 Delay = thereotisch schon > 
1,5ns aufgebaut werden.

Warum nicht einfach das Signal oversampeln mit zwei 2 verschobenen 
Eingängen lesen? Die Stratix IOs lassen sich auf 50ps genau schieben.