cachemodul, Simulation ok, aber auch bereit für die Synthese?

[Christian G. (Gast)]

Hallo,

ich möchte eine simplen Instruction-cache (kein write-back) für das 32mb 
sdram des terrasic DE0-nano boards erzeugen und hab mir dafür einen 
directmappedcache (Anhang) zusammengebastelt.
In der Simulation mit Modelsim funktioniert es so wie es soll jedoch 
habe ich so eine Vorahnung das die Umsetzung durch Quartus in den FGPA 
so nicht ohne weiteres funktionieren wird da.
Ich rate jetzt mal ins Blaue drauf los, und schätze das irgendwie 
sichergestellt werden muss das was der Kombinatorische Teil macht (Daten 
aus dem Cache, Tag und Valid Speicher holen) mit dem Prozess der 
sozusagen die Steuerung übernimmt synchronisiert werden muss, also quasi 
das die Daten auch wirklich bei der Steigenden Flanke der clock (hier 
soll es ein Takt von 100MHz sein) vorhanden und stabil sind.
Kann man das in diesem Falle über timing constraints regeln oder bin ich 
da absolut auf dem Holzweg und mein Versuch kann so gar nicht umgesetzt 
werden?
Und wenn es über constraints geht, wie mache ich das dann?
Habe mich bei meinen bisherigen Spielereien immer darauf verlassen das 
Quartus schon einen Weg findet es zum Laufen zu bringen und bis jetzt 
klappte das auch, aber hier bin ich mir wie gesagt nicht mehr sicher. Es 
wäre schön wenn jemand der sich wirklich auskennt ein paar Minuten Zeit 
findet und nen Blick drauf werfen könnte.
Btw. falls jemand Bedenken hat sein Wissen zu teilen, für mich ist es 
reine Übung (Hobby) und soll in keinster Weise irgendwie zu Geld gemacht 
werden.

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

Christian G. schrieb:
> In der Simulation mit Modelsim funktioniert es so wie es soll
Da bin ich mir nicht ganz sicher, wenn ich diesen interessanten 
Konstrukt da so sehe:

  process
  begin
    if (reset = '1') then
      :
      wait for 4 ns; --- nur für die Simulation, bleibt sonst hängen...
    else
      wait until rising_edge(clock);

Dir ist hoffentlich klar, dass die nicht vorhandene Sensitivliste 
unvollständig ist? Dort müsste reset rein...

Kann dein Synthesizer diesen Konstrukt eigentlich umsetzen? Hast du das 
mal probiert? Oder braucht der für einen asynchronen Reset die 
traditionelle Schreibweise?

Wenn du nur 1 Takt im Design (und evtl. daraus mit einem Taktmanager 
abgeleitete weitere Takte) hast, dann gib einfach dessen Taktfrequenz 
an. Den Rest im FPGA richtet dann die Toolchain.

[Christian G. (Gast)]

Lothar M. schrieb:
> Kann dein Synthesizer diesen Konstrukt eigentlich umsetzen? Hast du das
> mal probiert?
Ich habe es noch nicht ausprobiert ob Quartus das umsetzen kann

Lothar M. schrieb:
> Oder braucht der für einen asynchronen Reset die
> traditionelle Schreibweise?
ich muss jetzt raten was mit traditionelle Schreibweise gemeint ist, so 
was in der Richtung?

process(clock, reset...)
  begin
    if (reset = '1') then
      :
      wait for 4 ns; --- nur für die Simulation, bleibt sonst hängen...
    else if (clock'event and clock = '1') then
  ...

aber im Prinzip darf der reset auch ruhig synchron sein z.B.:

process
  begin
    wait until rising_edge(clock); 
    if (reset = '1') then
      :
    else
      :

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

Christian G. schrieb:
> so was in der Richtung?
Die Richtung stimmt, aber sowas hat in einem synthesefähigen Code nichts 
zu suchen:
> wait for 4 ns;
Siehe den 
Beitrag "Re: Simulation - Bei Abtastung anliegendes Signal übernehmen" und 
die Links in diesem Post.

> aber im Prinzip darf der reset auch ruhig synchron sein z.B.:
Im Prinzip ja. Aber wie du es bei der speziellen FPGA-Familie machen 
solltest, steht in deren Datenblatt.
Bei Altera/Intel gilt die Devise: der Reset darf asynchron beschrieben 
werden, er muss aber taktsynchron deaktiviert werden. Also: den Reset 
auf die jeweilige Taktdomäne eintakten.

[Christopher C. (trihexagon)]

Christian G. schrieb:
> aber im Prinzip darf der reset auch ruhig synchron sein z.B.:process
>   begin
>     wait until rising_edge(clock);
>     if (reset = '1') then
>       :
>     else
>       :

Ist hier den sicher, dass der Reset im Simulator ausgelöst wird? Müsste 
hier nicht eine Sensitivliste mit dem Resetsignal sein (clock natürlich 
nicht)?

[Markus F. (mfro)]

Christopher C. schrieb:
> Christian G. schrieb:
>> aber im Prinzip darf der reset auch ruhig synchron sein z.B.:process
>>   begin
>>     wait until rising_edge(clock);
>>     if (reset = '1') then
>>       :
>>     else
>>       :
>
> Ist hier den sicher, dass der Reset im Simulator ausgelöst wird? Müsste
> hier nicht eine Sensitivliste mit dem Resetsignal sein (clock natürlich
> nicht)?

Ein Prozess, der ein wait-Statement enthält, kann/darf keine 
Sensitivliste haben.

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

Markus F. schrieb:
> Ein Prozess, der ein wait-Statement enthält, kann/darf keine
> Sensitivliste haben.
Aber jeder Pfad muss in das selbe "wait for xx" eingebunden sein. 
Deshalb geht bei dem Kostrukt aus dem ersten Post sogar schon die 
Simulation schief...

[Markus F. (mfro)]

Natürlich. Aber da waren wir uns doch schon einig, oder?