Ich habe ein Verilog-Submodul, das ich unabhängig teste. Dieses Modul hat zu viele Top-Level-Pins, um in mein FPGA zu passen, also habe ich einige der Pins als virtuell eingestellt, damit es kompiliert, ohne die entsprechenden Signale wegzuoptimieren.
Ich bin jedoch besorgt, dass die Timing-Analyse durch das Setzen dieser Pins als virtuell beeinflusst wird. Ich habe das Gefühl, dass die Stifte effektiv falsch gepfadet sind.
Beeinflusst das Setzen von Top-Level-Pins als virtuell in Quartus II das Timing? Wenn ja, wie kann ich sicherstellen, dass die Timing-Analyse so ist, als hätte das FPGA zu Beginn genügend Pins?
Ich habe gerade ein Projekt am Kundenstandort abgeschlossen, das eine IP mit über 2700 IOs abbildet. In den ersten Schritten des Projekts haben wir einen Wrapper verwendet, um alle Signale in ein riesiges Schieberegister zu legen, um sicherzustellen, dass sie nicht optimiert wurden. Aber später haben wir die virtuellen IOs verwendet, um das Timing des Designs korrekt festzulegen und die richtige Schätzung der benötigten Ressourcen für das Projekt zu erhalten.
Die Verwendung von Virtual IO hat meiner Erfahrung nach keinen Einfluss auf das Timing Ihres Designs. Sie können diese Signale "FALSE PATH" machen, wenn Sie möchten, aber wenn Sie dies nicht tun und diese Signale mit einer Ihrer Uhren verbunden sind, erhalten Sie die richtige Zeitanalyse dieser Signale.
Sie müssen ein weiteres Modul in Ihrem FPGA erstellen, das mit all diesen Signalen verbunden ist und auch Verbindungen zu echten Pins auf Ihrem FPGA hat. So etwas wie ein langes Schieberegister – denken Sie an eine JTAG-Kette. Dies zwingt die Synthesewerkzeuge dazu, alle diese Signale als echt zu behandeln und die richtigen Zeitbeschränkungen auf sie anzuwenden.
Virtuelle Pins werden als Speisung der Eingangs-LUT in einem freien ALM platziert, das sehr nahe an Ihrer Designlogik platziert werden kann. Das Timing zur zugewiesenen LUT wird wie gewohnt überprüft, einschließlich aller kombinatorischen Ausgänge, die Ihr Block auf diesem Pfad hat. Dies ist das, was Sie möchten, wenn Sie die Komplexität des Blocks untersuchen, obwohl das tatsächliche Ziel während der Integration viel weiter entfernt sein könnte.
Wenn Sie sich ChipPlanner ansehen, finden Sie das Submodul dicht gepackt in der Mitte mit virtuellen IO-Pins. Wenn Sie zu physischen Pins routen und davon ausgehen, dass genügend vorhanden sind, werden Sie feststellen, dass sich das Design wie ein Spinnennetz ausdehnt, während der Monteur versucht, das Timing einzuhalten (und höchstwahrscheinlich nicht kann). Da der größte Teil des IO wahrscheinlich durch Busse von dedizierten Hard-PCS-Blöcken von HSSI-Pads in IP-Kernen kommt, macht es keinen Sinn, es an Hard-Pins anzuschließen.
Update: Was Sie vielleicht ausprobieren möchten, ist das Hinzufügen einer Designpartition für Ihren Block und das Einrichten einer Logiksperrregion für diese Partition, die ein kleiner Unterabschnitt des gesamten Chips ist. Dadurch erhalten Sie ein kleines Quadrat an Fläche, in dem der Kern das Timing treffen muss, wobei eine unbegrenzte Anzahl von Verbindungen an der Peripherie herauskommt. Dies gibt Ihnen dann eine Timing-Analyse der Ein-/Ausgänge bis zu einer strengen Grenze, die realistischer sein kann als willkürliche/günstig positionierte virtuelle Pins LUTs.
Quartus-Hilfe: def_virtual_pin
FarhadA