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?
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.
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
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.
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 ...
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.
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?
Für so etwas hätte ich auch Verwendung. Seid ihr inzwischen fündig geworden? Würde mich um Hinweise freuen!
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.