Hallo zusammen, hat jemand von Euch schon mal VHDL Code automatisch z.B. mit HDL Coder erzeugen lassen? Welche Merkmale weist ein generierter VHDL Code auf? Denn wir haben VHDL-Sourcecode von einer anderen Firma bekommen und vermuten, dass diese nicht "selbst geschrieben" wurden. Uns fällt es auf z.B.: Sehr saubere Kommentarblöcke, besonders diese "--" nach dem Text "KOMMENTAR" und die angepasste Strichlänge --------------- -- KOMMENTAR -- --------------- ---------------------------- -- EIN LÄNGERER KOMMENTAR -- ---------------------------- und in einem getakteten Prozess befinden sich alle Signale auf der rechten Seite (nach dem Zuweisungsoperator <=) in der Sensitivity-Liste. Ein normaler VHDL-Entwickler würde das nie tun (oder ???), denn der Takt und max. noch ein asynchrones Reset-Signal sollen sich in dieser Liste befinden. und fast alles wurde groß geschrieben, außer Port-Deklarationen z.B. PORTi, PORTo Ich danke Euch im Voraus für Eure Tipps. Hanel
Hanel schrieb: > wir haben VHDL-Sourcecode von einer anderen Firma bekommen und > vermuten, dass diese nicht "selbst geschrieben" wurden. Okay. Was genau wäre das Problem, wenn der Code nicht zu 100% durch einen Menschen geschrieben wurde, sondern zumindest teilweise automatisiert? Hanel schrieb: > Sehr saubere Kommentarblöcke, besonders diese "--" nach dem Text > "KOMMENTAR" und die angepasste Strichlänge Hanel schrieb: > und > fast alles wurde groß geschrieben, außer Port-Deklarationen z.B. PORTi, > PORTo Saubere Kommentare sowie eine durchgehend einheitliche Formatierung zeugen von einem guten Stil. Sie machen den Code übersichtlicher und "lesbarer" und sind daher ein Anhaltspunkt dafür, dass Eurer Lieferant Euch als Kunden "respektiert" und Euch nicht einfach einen Haufen Spaghetticode vor die Füße schmeißt. Hanel schrieb: > in einem getakteten Prozess befinden sich alle Signale auf der rechten > Seite (nach dem Zuweisungsoperator <=) in der Sensitivity-Liste. Ein > normaler VHDL-Entwickler würde das nie tun (oder ???), denn der Takt und > max. noch ein asynchrones Reset-Signal sollen sich in dieser Liste > befinden. Das kommt darauf an, was erreicht werden soll. Ich persönlich bevorzuge es, die Sensitivity-List komplett wegzulassen, aber ohne nähere Kenntnis des Hintergrunds (was sich der Lieferant dabei "gedacht" hat) lässt sich das nicht eindeutig sagen. Was spricht dagegen, den Lieferanten einfach direkt zu fragen, warum er alle Signale in die Sensitivity List gepackt hat?
Ein starkes Indiz ist immer, wenn interne Signale Namen wie Signal1, Signal2, Signal3, etc. tragen.
Patrick schrieb: > Okay. Was genau wäre das Problem, wenn der Code nicht zu 100% durch > einen Menschen geschrieben wurde, sondern zumindest teilweise > automatisiert? Der Lieferant hat uns versichert, dass der Code nicht automatisch generiert wurde und alles wurde durch Menschen geschrieben. Deshalb möchten wir es überprüfen. Patrick schrieb: > Saubere Kommentare sowie eine durchgehend einheitliche Formatierung > zeugen von einem guten Stil. Sie machen den Code übersichtlicher und > "lesbarer" und sind daher ein Anhaltspunkt dafür, dass Eurer Lieferant > Euch als Kunden "respektiert" und Euch nicht einfach einen Haufen > Spaghetticode vor die Füße schmeißt. Da hast Du vollkommen Recht. Aber nur ein bisschen seltsam wie die Kommentare aufgebaut sind. :-) Patrick schrieb: > Das kommt darauf an, was erreicht werden soll. Ich persönlich bevorzuge > es, die Sensitivity-List komplett wegzulassen, aber ohne nähere Kenntnis > des Hintergrunds (was sich der Lieferant dabei "gedacht" hat) lässt sich > das nicht eindeutig sagen. > Was spricht dagegen, den Lieferanten einfach direkt zu fragen, warum er > alle Signale in die Sensitivity List gepackt hat? Super Tipp!
Hanel schrieb: > in einem getakteten Prozess befinden sich alle Signale auf der rechten > Seite (nach dem Zuweisungsoperator <=) in der Sensitivity-Liste. Ein > normaler VHDL-Entwickler würde das nie tun (oder ???), denn der Takt und > max. noch ein asynchrones Reset-Signal sollen sich in dieser Liste > befinden. Ich würde annehmen, daß so etwas eher ein Indiz für einen menschlichen Entwickler ist. Ein Tool sollte wissen, daß das unnötig ist.
Klaus schrieb: > Ein starkes Indiz ist immer, wenn interne Signale Namen wie Signal1, > Signal2, Signal3, etc. tragen. Danke für Deine Antwort, aber zum Glück sind die Signalnamen nicht wie beschrieben aufgebaut.
Ich verstehe aber noch immer nicht (würde es aber gerne verstehen), warum nicht handgeschriebener Code hier ein Problem ist.
Chi schrieb: > Ich verstehe aber noch immer nicht (würde es aber gerne verstehen), > warum nicht handgeschriebener Code hier ein Problem ist. Das wäre kein Problem, wenn der Lieferant uns nicht versichert hatte, den Code nicht generieren zu lassen. Und das ist das erste Projekt mit diesem Lieferanten. Und natürlich freuen wir uns, wenn der Code tatsächlich selbst geschrieben wurde. Das beweist die Glaubwürdigkeit des Lieferanten.
Einige editoren z.B. Emacs im VHDL-Mode verschönern den Code automatisch (Ausgewählte schlüsselwörter groß). Ebenso bieten diese template für entityt. processe etc an. Beispiel f. Emacs: entity clevererEditor is generic ( generic_oans : boolean := true); -- comment from template port ( clk : in std_logic; reste : in std_logic; -- reset data_in : in std_logic_vector(7 downto 0); data_out : out std_logic_vector(5 downto 0)); end clevererEditor; -- purpose: per template generiert -- type : sequential -- inputs : clk, reste, data_out -- outputs: data_in t_h: process (clk, reste) begin if reste = '0' then elsif clk'event and clk = '1' then end if; end process t_h; Die 4 kommentare vor dem process, wurden vom editor so eingefügt, während der template ausführung hat der anwender nur signalnamen und typen anzugeben. Das muss also kein Indiz für generierten code sein. ferner, was spricht dagegen einen selbstgeschriebenen Code-generator für langweilige tipparbeiten einzusetzen, ein bißchen perl und fertig is! Oder Copy und paste templates? MfG
<Das wäre kein Problem, wenn der Lieferant uns nicht versichert hatte, <den Code nicht generieren zu lassen. Und das ist das erste Projekt mit <diesem Lieferanten. Und natürlich freuen wir uns, wenn der Code <tatsächlich selbst geschrieben wurde. Das beweist die Glaubwürdigkeit <des Lieferanten. Cleverer wäre es, sich von Lieferanten versichern zu lassen, das der Code entsprechend Euren Vorgaben verifiziert wird und die Logs der Verfifikation zum Lieferbestandteil zu machen. Verifizierter/funktionsfähiger Code ist ein Qualitätsmerkmal, handgeschrieben oder generiert dagegen nicht! MfG
Hanel schrieb: > in einem getakteten Prozess befinden sich alle Signale auf der rechten > Seite (nach dem Zuweisungsoperator <=) in der Sensitivity-Liste. > Ein normaler VHDL-Entwickler würde das nie tun (oder ???), > denn der Takt und max. noch ein asynchrones Reset-Signal sollen sich > in dieser Liste befinden. Es soll sich da gar nichts befinden, sondern es muss sich das dort befinden, was für die Simulation einen Neuberechnung des Prozesses nötig macht. Hanel schrieb: > hat jemand von Euch schon mal VHDL Code automatisch z.B. mit HDL Coder > erzeugen lassen? Wenn du z.B. einen Top-Level-Schaltplan in VHDL übersetzen lässt, dann findest du in der Portliste z.B. sowas:
1 | ...
|
2 | busint(0) <= busext(0), |
3 | busint(1) <= busext(2), |
4 | busint(2) <= busext(2), |
5 | ...
|
6 | busint(30) <= busext(30), |
7 | busint(31) <= busext(31)); |
Handgeschriebener Code würde so aussehen:
1 | ...
|
2 | busint <= busext); |
Bei FSM-Tools, die eine FSM in VHDL übersetzen, kannst du solche "Verallgemeinerungen" evtl. auch sehen. Hanel schrieb: > Denn wir haben VHDL-Sourcecode von einer anderen Firma bekommen und > vermuten, dass diese nicht "selbst geschrieben" wurden. Aber: trotzdem muss ja jemand den Schaltplan und die FSM erst mal kapieren und zeichnen können. Und wie der von dort aus zum VHDL-Code kommt, ist erst mal egal. Das mit den überbestimmten Sensitivlisten wäre für mich aber definitiv ein Fehler!
Hanel schrieb: > ---------------------------- > > -- EIN LÄNGERER KOMMENTAR -- > > ---------------------------- Ich kopiere schon seit Jahren VHDL von einem Projekt zum anderen und habe an die 50 Standardkommentarblöcke drin. Das wäre jetzt kein Kriterium finde ich. Was augenscheinlich FÜR Automatismen spräche, währen druchnummerierte Signale und Deklarationen, sowie viele unnötige Signale mit Zwischenzuweisungen, die ein Modul mit dem nächsten verbinden.
>Ich kopiere schon seit Jahren VHDL von einem Projekt zum anderen
Das ist auch kein Qualitätsmerkmal.
Hast Du schon mal darüber nachgedacht, Komponenten zu verwenden, die
lediglich instanziiert werden müssen?
Stachele schrieb: > Hast Du schon mal darüber nachgedacht, Komponenten zu verwenden, die > lediglich instanziiert werden müssen? Dann müsste schon die erste Implementierung einer Komponente so ideal sein, dass sie fürderhin nicht mehr angefasst werden muss. Träumen ist sooooo schön...
Stachele schrieb: > Das ist auch kein Qualitätsmerkmal. > > > > Hast Du schon mal darüber nachgedacht, Komponenten zu verwenden, die > > lediglich instanziiert werden müssen? Es ging um die Kommentare! Diese geben eine formelle Struktur vor, die in allen VHDLs dieselbe ist. * Definitionen * Komponenen * Proceduren * Funktionserklärungen * Fallunterscheidungen * Flicks / temporäre Dinge -- Beginn -- * Eingänge Synchen * Komponenten Mappen (signalflow aehliche Anordnung der Komponenten) * Komonentenverbidungssignale * Operationen - statische skalieren - bedingte skalierung - verarbeitungen * Überwachungsfunktionen * Monitorfunktionen * Debug Interface * Ausgänge Synchen -- Ende --
Lothar Miller schrieb: > busint(0) <= busext(0), > > busint(1) <= busext(2), > > busint(2) <= busext(2), Das sieht aber sehr handgeschrieben aus, da falsch :-)
R. K. schrieb: > Lothar Miller schrieb: >> busint(0) <= busext(0), >> >> busint(1) <= busext(2), >> >> busint(2) <= busext(2), > > Das sieht aber sehr handgeschrieben aus, da falsch :-) Eine neue Art Demultiplexer oder eine Buserweiterung. B-]
R. K. schrieb: > Das sieht aber sehr handgeschrieben aus, da falsch :-) Hier wird einem echt jedes Bit im Bus umgedreht. Ich schwörs, das war tomatisch generierter Code: mit TOMATen auf den Augen generiert... ;-)
mal ne andere Frage: warum sollte "automatisch" generierter Code überhaupt Kommentare enthalten? außer viellleicht "generate with...at date..." cheers.
So sieht Spaghetti-Code aus, der automatisch generiert wurde: siehe Anhang
Thread beobachten
Seitenaufteilung abschaltenBitte 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.