Synthese mit Synplify bei ungültiger Konfiguration eines Moduls stoppen

[Michi (Gast)]

Hallo,

ich verwende Lattice Diamond mit dem integrierten Synplify als 
Synthesetool.

Für ein universell nutzbares Modul habe ich verschiedene 
Konfigurationseinstellungen im GENERIC-Bereich untergebracht - das 
funktioniert auch seit Jahren einwandfrei. Je nach übergebener 
Konfiguration werden im universell nutzbaren Modul über "GENERATE" 
verschiedene Module instanziiert.

Sofern ich jedoch eine "ungültige" oder "nicht unterstützte" 
Konfiguration übergebe, wird entsprechend auch kein "GENERATE" 
durchgeführt und in Lattice Diamond erhalte ich keinerlei Fehlermeldung 
und die Synthese läuft komplett durch - was auch verständlich ist. Nur 
im Simulationstool sehe ich über eine ASSERT-Anweisung mit REPORT im 
Code eine Warnung.

Wie kann ich die Synthese in Lattice Diamond "automatisch stoppen" 
lassen, sofern dem universell nutzbaren Modul eine "ungültige" oder 
"nicht unterstützte" Konfiguration übergeben wird?

Was für Möglichkeiten gibt es direkt im VHDL-Code die Synthese zu 
stoppen, sofern im Code / Konfiguration eines Moduls nicht unterstützte 
Zustände auftreten?

Bin auf eure Tipps gespannt :-)

[Christoph Z. (christophz)]

Michi schrieb:
> ASSERT-Anweisung mit REPORT im
> Code eine Warnung.

Einfach die severity auf "Failure" setzen. Dann sollte auch Synplify 
stoppen. Hatte schon das selbe Bedürfnis und habe es so gelöst und mag 
mich daran erinnern, dass dies auch für die Synthese funktioniert hat.

[Michi (Gast)]

Im Simulationstool funktioniert dies, Lattice Diamond mit Synplify als 
Synthesetool lässt sich zumindest bei mir davon nicht beeindrucken...

Lattice Diamond baut das Programm weiterhin ganz normal durch...

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Also ich kann das nicht nachvollziehen. Synplify macht mit den 
Assertions genau das was es soll. Ein sinnloses aber funktionsfaehiges 
Beispiel habe ich mal angehaengt. Ist das Generic auf false laeuft die 
Synthese durch, ist es auf true wirft es einen Fehler. Sogar mit 
entsprechender Meldung im report Statement.

Starting: "prj_run Synthesis -impl impl1"

************************************************************
**  Synplify Pro                                          **
************************************************************

...

Post processing for work.toplevel.rtl
Running optimization stage 1 on toplevel .......
Running optimization stage 2 on toplevel .......
ERROR - Z100 :"Lattice/Assertion_Test/toplevel.vhd":22:9:22:35|"SIM_FAST is not Supported"
Process took 0h:00m:01s realtime, 0h:00m:01s cputime
# Wed Jul 22 14:51:13 2020

###########################################################]
@END
Process took 0h:00m:01s realtime, 0h:00m:01s cputime
# Wed Jul 22 14:51:13 2020

###########################################################]


Synthesis exit by 9.
Done: error code 9

[Martin S. (strubi)]

Synplify macht's richtig, aber die Diamond 'IDE' kriegt den Fehler nicht 
mit, zumindest wurde seit Jahren der Fehlercode nicht ausgewertet und 
der Bug-Report dazu nie bearbeitet.
Wenn man 100% sichergehen will, dass Source und Bitfile in Sync sind, 
hilft nur, die Synthese-Verarbeitungskette per Makefile aufzurufen.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Martin S. schrieb:
> Synplify macht's richtig, aber die Diamond 'IDE' kriegt den Fehler nicht
> mit, zumindest wurde seit Jahren der Fehlercode nicht ausgewertet und
> der Bug-Report dazu nie bearbeitet.
> Wenn man 100% sichergehen will, dass Source und Bitfile in Sync sind,
> hilft nur, die Synthese-Verarbeitungskette per Makefile aufzurufen.

Das stimmt allerdings und ist auch echt nervig (koennte mir vorstellen 
dass Lattice langsam aber sicher sich von Synplify losloesen will und an 
solchen Krankheiten schon garnicht mehr arbeit). Aber dass wie oben 
beschrieben die Synthese einfach durchlaeuft kann ich definitiv nicht 
bestaetigen. Da muss ein Fehler in der Assertion vorliegen.

[Michi (Gast)]

@ von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite
22.07.2020 14:55

Herzlichen Dank für deine Rückmeldung mit Beispiel, nun funktioniert es 
auch bei mir :-)

Mein Fehler war, dass ich die Überprüfungen mit den ASSERTs gesammelt in 
einem separaten Modul ausgelagert habe und die Werte normal per "PORT 
MAP" übergeben habe. In der Simulation funktioniert dies einwandfrei.
-> Mit "PORT MAP" erfolgt bei Diamond bei mir keinerlei Abbruch der 
Synthese :-(
-> Mit "GENERIC MAP" erfolgt bei Diamond wie gewünscht der Abbruch mit 
der entsprechenden Fehlermeldung :-)

Kleine Änderung mit großer Wirkung...

Herzlichen Dank!

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Ahh, ja das ist klar. Assertions koennen nur statisch ausgewertet 
werden. Da du bei Ports Signale weiter gibst, kann Synplify nicht 
auswerten was mit diesen zur Laufzeit passiert.

Lesson learned. :-)