Forum: FPGA, VHDL & Co. True Dual-Port Verifikation


von Martin S. (strubi)


Lesenswert?

Kennt jemand eine offen verfuegbare Referenz-Testbench fuer TDP-RAMs in 
Verilog die Verifikation der verschiedenen Eigenschaften 
(write-through/Transparenz, read-before-write, usw.) in der 
OpenSource-Cloud erlaubt?
Nahe ran kommt 
https://github.com/kowsyap/Physical-Design-and-Verification-of-DPRAM-using-SV-UVM-and-Semi-Custom-Design, 
aber der Knackpunkt ist dieselbe Clock fuer beide Ports, ich brauche 
unterschiedliche fuer Port A/B, was die Sache besonders knifflig macht.
Bevor jetzt kommt: "Selbermachen", oder "Anpassen": Es sollte moeglichst 
unveraendert und 'third party' sein, denn selber ist man oft mal 
betriebsblind.
Ein funktionales Modell reicht erst mal, es muss auch nicht der letzte 
Glitch abgedeckt werden. Ideen?

von Meßprofi (Gast)


Lesenswert?

Wenn du nicht die glitches haben willst, was willst du testen?

Und wegen betriebsblind: Wenn du unbedingt etwas willst, was ein anderer 
gebaut hat, so bekommst du etwas, was er für wichtig gehalten hat, also 
das Ergebnis seiner Betriebsblindheit.

von Achim M. (minifloat)


Lesenswert?

Martin S. schrieb:
> ich brauche unterschiedliche fuer Port A/B, was die Sache besonders
> knifflig macht.

Mindestens einen musst du einsynchronisieren. Damit läuft der DP-RAM 
entweder auf Takt A oder eben einem eigenen.

Martin S. schrieb:
> Es sollte moeglichst unveraendert und 'third party' sein, denn selber
> ist man oft mal betriebsblind

Nimm dir den DP-RAM und ein Modul für Einsynchronisieren eines 
Datenbusses getrennt aus irgendeinem Hersteller-Appnote oder Lib.

mfg mf

von Martin S. (strubi)


Lesenswert?

Nochmal zur Klarstellung: Ich suche die opensource-Referenz-Testbench, 
nicht das TDP-RAM-Funktionsmodell, davon habe ich bereits einige.
Die Hersteller geben natuerlich ihre TB kaum raus, und wenn, erlauben 
deren Lizenzen keine Distribution in der Cloud.
Das Ziel ist, dass beispielsweise jemand sein gewrapptes 
(Opensource)-TDP-RAM-Modell ins gemachte Nest (alias Browser-VM) setzen 
kann und eine Testmatrix entsprechend des Verhaltens rausbekommt (was 
passiert bei nahezu gleichzeitigem R/W auf gleichen/unterschiedlichen 
Ports, werden Kollisionen abgefangen, usw).
Was das RAM-Modell selber macht, ist a priori 'black box', also wie es 
intern mit den beiden Clocks umgeht, ist sekundaer, solange es den 
Glitch-Test besteht. Einsynchronisieren auf eine Clock waere fuer ein 
TDP-RAM-Modell schon mal ein grosses rotes FAIL, die 'guten' Modelle 
machen das asynchron mit internen Delays, wie z.b. die Lattice-DP16KD.
Ist mir auch klar, dass das Ganze nicht so ganz trivial ist, waere 
insofern nicht ueberrascht, wenn die OpenSource nichts bietet.

von Tobi (Gast)


Lesenswert?

Martin S. schrieb:
> wenn die OpenSource nichts bietet.
... dann liegt es sicher auch daran, dass diejenigen Entwickler, die 
vertieft in der Thematik der Verifikation von FPGAs und ASICs involviert 
sind, RAMs in allen Lagen evaluieren und geraume Zeit an solchen 
Testbenches arbeiten, solche ausgereiften, Programmier- und Steuerbaren 
Benches nicht einfach unter die Leute bringen (dürfen), weil ihre AG 
dies alles bezahlen, daraus einen Wettbewerbsvorteil schöpfen, den sie 
nicht dadurch vernichten möchten, daß andere Firmen, die solche 
Ingenieure nicht bezahlen, es sich einfach machen können und alles per 
open source laden können. :-)

Oder auf Deutsch:

Der Chef von Tobi zahlt 7 (Sieben!) Wochen Erstellung von generalen 
Testbenches, Analyse des Testplans, Einarbeitung in TBs, Dokumentation 
der TB und Testfälle, Ausarbeitung der Abweichungen zu den 
kommunizierten Timings des Herstellers, Dokumentation und Analyse der 
Abweichungen zu den Messungen, Optimierung des RAM-Models zusammen mit 
dem Hersteller, endlose Kommunikation mit der FAB, der SW-Abteilung, 
Anpassungen des PCB-Modells zum Einarbeiten der Microtimings und gibt 
dafür rund 30.000 Euro aus.

Chef von Strubi zahlt 1 Tag, den Strubi nutzt, um open souce runter zu 
laden, es einzustellen und kann drauflos testen. Damit sind die 
Produkte, die Strubis Chef vertickt, billiger und Chef von Tobi kann 
nichts mehr verkaufen. Dann fragt sich Chef: "Tobi or not Tobi that is 
the question", macht die Bude zu und Tobi wird entlassen. Ok, ganz soooo 
arg wird es nicht kommen, aber mal im Ernst:

Seht euch an, wieviele Startups und Firmen in allenmöglichen Ländern mit 
billigen Ingenieuren loslegen, die nichts anderes tun, als vorgefertigte 
Schaltungen zusammenzukopieren und dazu neben der Xilinx-ware auch noch 
OS nutzen. Alles Firmen, die auf der Basis der Anderen Kasse machen. Es 
gibt einige Firmen, die mit Cores Geld verdient haben und dann sehen 
mussten, wie sie von open source überholt wurden. In einem Fall hatte 
der Entwickler eines Kunden einfach Code weitergenutzt und umgeschieben, 
dann hochgeladen und bevor es erkannt und gelöscht wurde, hatten es 
andere kopiert.

Wäre OC so strukturiert, dass die, die etwas beitragen, etwas dafür 
bekommen, könnte man das machen, aber so ...

von Martin S. (strubi)


Lesenswert?

Gratuliere, Tobi hat die OpenSource-Prinzipien offenbar verstanden.

Aber auch nochmal auf Deutsch: Strubi hat kein Interesse, ein weiteres 
TDP-RAM-Design zu entwickeln, sondern moechte fuer OpenSource-Projekte 
ebenfalls OpenSource einsetzen, damit andere Nutzer legal (ohne 
blackboxed binaerblob) die Ergebnisse auch nachvollziehen koennen. Das 
ist eine ganz andere Kiste als die 7-Wochen-TB fuer ein spezifisches 
Design. Konkret ist da HDL eines Herstellers im Spiel, der explizit auf 
Opensource setzt.

Was ich ueberdies weitaus oefters feststelle: Ein Haufen Firmen mit 
kleinem sowie auch bekannten Namen nutzen kommerziell Opensource, klauen 
sich entweder schamlos die Ideen raus oder ignorieren schlicht die 
Lizenzbedingungen, sprich es werden Binaries verteilt, aber die von 
einer Schar billiger outgesourcter Coder augmentierter Sourcen nicht 
mehr herausgegeben. Die FSF hilft da uebrigens in den mir bekannten 
konkreten Faellen nicht, und wenn, wird eine alte kaum funktionierende 
Revision rausgegeben oder auf ein NDA gedraengt.

Nu, so laeuft das halt.

Aber da das vom Thema abweicht: Lassen wir mal die Kirche im Dorf.
Scheint wohl ein gordischer Knoten, mit dem sich ganze Teams in 
OpenSourceprojekten wie elphel, yosys, etc. herumschlagen.

von Tobi (Gast)


Lesenswert?

Martin S. schrieb:
> fuer OpenSource-Projekte
Welche?

Martin S. schrieb:
> Konkret ist da HDL eines Herstellers im Spiel,
Welche?

Martin S. schrieb:
> Ein Haufen Firmen mit
> kleinem sowie auch bekannten Namen nutzen kommerziell Opensource
Welche?

von Mark (Gast)


Lesenswert?

Für so etwas hätte ich auch Verwendung. Seid ihr inzwischen fündig 
geworden? Würde mich
um Hinweise freuen!

von Strubi (Gast)


Lesenswert?

Im ueblichen OpenSource-Pool haben wir nichts passendes gefunden. Hat 
sich schliesslich als einfacher erwiesen, die bestehende Testbench 
aufzubohren und verifiziert zu bekommen.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.