Hallo,
ich beschäftige mich in letzter Zeit mit FPGA Design und SoC's in
Verbindung mit dem Cyclone V SoC Atlas Board von Terasic. Leider gehe
ich etwas in der Doukumentation unter und aus meiner Sicht ist diese
etwas lückenhaft.
Könnte mir vielleicht einen Tip geben wo ich Informationen darüber finde
wie am besten mit Block Symbolen in Quartus gearbeitet wird und was
dahinter steckt?
Ich würde gerne mein Projekt mit Block Symbolen aufbauen, damit das
nachher etwas übersichtlicher wird bzgl. Architektur.
Wenn ich z.B. ein Block Symbol von einem aus QSys erzeugten HPS in meine
Top Level Entity (.bsf Datei) importiere und anschließend kompiliere
bekomme ich folgende Error:
Error: The auto-constraining script was not able to detect any instance
for core < hps_sdram_p0 >
Error: Verify the following:
Error: The core < hps_sdram_p0 > is instantiated within another
component (wrapper)
Error: The core is not the top-level of the project
Error: The memory interface pins are exported to the top-level of the
project
Error: Alternatively, if you are no longer instantiating core <
hps_sdram_p0 >,
Error: clean up any stale SDC_FILE references from the QSF/QIP files.
Gruß
Electron84
Electron84 schrieb:> Ich würde gerne mein Projekt mit Block Symbolen aufbauen, damit das> nachher etwas übersichtlicher wird bzgl. Architektur.
Ob das eine gute Idee ist und tatsächlich der Übersichtlichkeit dient,
sei mal bezweifelt. Me thinks Du versuchst, eine Dampflok vor einen ICE
zu spannen, um den besser zu verstehen.
Electron84 schrieb:> von einem aus QSys erzeugten HPS
"Höhere ProgrammierSprache" ??? Oder was?
Electron84 schrieb:> Error: The auto-constraining script was not able to detect any instance> for core < hps_sdram_p0 >> Error: Verify the following:> Error: The core < hps_sdram_p0 > is instantiated within another> component (wrapper)> Error: The core is not the top-level of the project> Error: The memory interface pins are exported to the top-level of the> project> Error: Alternatively, if you are no longer instantiating core <> hps_sdram_p0 >,> Error: clean up any stale SDC_FILE references from the QSF/QIP files.
Die Fehlermeldung scheint darauf hinzudeuten, daß der "aus seinem
Kontext gerissene" Qsys-Block vom Synthesetool beim Abarbeiten der
.sdc-Constraints nicht mehr gefunden wird. Du hast irgendwo ein
.sdc-File, das eine Instanz der Komponente "hpd_sdram_p0" referenziert.
Und die wird nicht gefunden.
Wie heißt der Qsys-Block in deinem grafischen Toplevel?
Markus F. schrieb:> Ob das eine gute Idee ist und tatsächlich der Übersichtlichkeit dient,> sei mal bezweifelt. Me thinks Du versuchst, eine Dampflok vor einen ICE> zu spannen, um den besser zu verstehen.
Nun ja irgendeinen Grund muss es ja geben, dass man auch Block Symbole
verwenden kann, vielleicht auch soll?
Woher kommt das historisch mit den Blocksymbolen?
Genau deswegen frage ich ja auch nach dem Verwendungszweck und nach Doku
zu diesem Thema, dann könnte ich mich einarbeiten...
Markus F. schrieb:> "Höhere ProgrammierSprache" ??? Oder was?
HPS = Hard Processor System
Electron84 schrieb:> Nun ja irgendeinen Grund muss es ja geben, dass man auch Block Symbole> verwenden kann, vielleicht auch soll?> Woher kommt das historisch mit den Blocksymbolen?> Genau deswegen frage ich ja auch nach dem Verwendungszweck und nach Doku> zu diesem Thema, dann könnte ich mich einarbeiten...
Block Symbole sind super!
--> aber leider nur, wenn man gerade einen Workshop leitet und die
Teilnehmer ihren selbst erstellten Block über drag and drop in ein
vorbereitetes Projekt einfügen soll. Dann hat man einen schnellen
erfolg, kann aufs Compile Knöpfchen klicken und alles ist bestens.
Ich habe einen Referenten einmal gefragt, ob er die grafische Eingabe
für eigene Projekte empfehlen kann. Hiervon hat er dringend abgeraten.
Unter anderem weil sich der Code nicht in Repositories verwalten lässt.
Ich hatte schon einmal das Glück einen Fehler in einem grafischen
Projekt suchen zu dürfen. Leider ließ sich keine Entwicklungsumgebung
mehr auftreiben, mit der die Projektdateien fehlerfrei angezeigt wurden.
Lediglich der Export in Abel war noch möglich, sodass ich die Funktion
register für Register nachvollziehen konnte/musste. Keine schöne
Erfahrung. Da lobe ich mir einen sauber dokumentierten Code.
RekordHalter schrieb:> Hiervon hat er dringend abgeraten.
Das kann Ich nachvollziehen! Ich mache das auch nicht mehr. Die Symbole,
die Quartus erzeugt sind grauenhaft, oft kaputt und verdrillt und bei
jedem update geht irgendwas schief,
> Unter anderem weil sich der Code nicht in Repositories verwalten lässt.
Ok, man kann es nicht im Team bearbeiten, mergen und diffs machen, aber
einchecken geht schon. Ist im Grunde dasselbe wie Labview. Eine
Zeichnung und fertig.
Blocksymbole sind was für Weicheier und Anfänger sowie die, die zuviel
Zeit haben und gerne malen weil sie sich als Künstler sehen. Wer als
Entwickler mit einigermassen Projekterfahrung immer noch mit den
Symbolen herumhantiert, dem gehört eins hinter die Löffel!
Aus Kosten- und Projektsicht ist nicht zu akzeptieren, was da abgeht:
Geringer Nutzen bei maximalem Aufwand! Andauernd muss bereits geleistete
Arbeit neu gemacht werden, weil das Aktualisieren nicht klappt, das
Symbol versaut wird und komplett neu aufgebaut werden muss und das
Herummalen mit Linien zu ungewollten Verbindungen oder
Mangelverbindungen führt.
Theoretisch mag das ja ganz hübsch und sinnvoll sein, aber die
Hierarchierung des Design und Handhabung von Modulen mit Grafiken ist
derart schlecht und zeitraubend, daß man das besser mit einfachen
händischen Grafiken in Visio erledigt und ansonsten im Textmodus bleibt.
VHDL ist Softwareentwicklung, das sollte man endlich mal einsehen und
damit taugt ein Schaltplaneingabesystem nicht zum Programmieren. In C
werden auch keine Funktionen mit Strichen hingemalt, es sei denn, man
ist FAE bei Mathworks. Bei der Signalführung in VHDL kann man leicht
Anmerkungen hinschreiben und Alternativen programmieren und bedingte
Verdrahtungen für verschiedene Ausbauzustände von Designs managen.
Mach das mal in Grafik.
Spätestens beim nächsten größeren Software-Update der
Entwicklungsumgebung muss viel neu- und umgezeichnet werden und auch
weggeworfen werden und eine Portierung auf ein anderes FPGA ist höchst
problematisch. Ein Wechsel ghar auf einen anderen Hersteller ist
komplett unmöglich. Alles muss neu gemacht werden, während man eine
Visiozeichnung mit Copy und Paste und kleinen Änderungen direkt fürs ein
neues Projekt verwenden kann - samt Cide.
Das Gleiche gilt für die FPGA-Entwicklung unter Labview. Alles ein
riesiger Drahtverhau, wo sich keiner mehr auskennt. Klickibunti ist
alles nur der Strategie der Anbieter geschuldet, die Kunden mit Tricks
an ihre Tools und damit ihre Bauteile zu binden.
Sieht man sich in den Firmen so um, dann stellt man fest, dass es
hauptsächlich die Studenten sind, die die Grafikeingabe als
Vorgehensweise zur VHDL-Erstellung in die Teams einschleppen und es erst
nach ein paar Jahren verwerfen, wenn sie es satt sind oder es ihnen
rechtzeitig untersagt wurde.
