Zugriff auf gleiches Signal aus verschiedenen Prozessen?

[Steffen Hausinger (Gast)]

Hallo allerseits

in meiner Beschreibung taucht ein bidirektionaler Bus auf. Da dieser 
"sowieso" Tristate können muss - ist es ok, auf ihn aus mehreren 
Prozessen zuzugreifen?

entity Bar is
  Port (
    ...
    Selector : in integer;
    Address : inout STD_LOGIC_VECTOR(15 downto 0);
    ...
  );
end Bar;



architecture Behavioral of Bar is
  Foo_1 : process(Selector)
    if Selector = 1 then
      Address <= x"0123";
    else
      Address <= "ZZZZZZZZZZZZZZZZ";
    end if;
  end process;

  Foo_2 : process(Selector)
    if Selector = 2 then
      Address <= x"4567";
    else
      Address <= "ZZZZZZZZZZZZZZZZ";
    end if;
  end process;

  Foo_3 : process(Selector)
    if Selector = 3 then
      if Address = x"89AB" then
        ...
      end if;
    end if;
  end process;
end Behavioral;

Grüße
Steffen

[MXM (Gast)]

Hi,

ich bin mir zu 99% sicher, dass das nicht funktioniert.. kannst du ja 
mal ausprobieren..

aber mal eine Frage: welche Notwendigkeit besteht den dazu?
Wieso nicht einfach ein Prozess?
In beinem Beispiel würde auch ein "select with" reichen, da das Ganze 
kombinatorisch ist...

MXM

[Steffen Hausinger (Gast)]

MXM schrieb:
> ich bin mir zu 99% sicher, dass das nicht funktioniert.. kannst du ja
> mal ausprobieren..
Doch, es lässt sich synthetisieren. Nur lese ich hier im Forum, dass man 
das nicht machen sollte. Stattdessen soll man einen MUXer verwenden. Ich 
bin mir aber nicht sicher, ob das auch für Signale gilt, die als 
Tristate aus dem FPGA herausgeführt werden.


MXM schrieb:
> In beinem Beispiel würde auch ein "select with" reichen
Das Problem an dem Beispiel ist, dass es nur ein Beispiel ist...

[MXM (Gast)]

Beschreibe doch genau was du machen möchtest...

MXM

[Mathi (Gast)]

Wenn Du keine andere Beschreibungsform wählen möchtest, und Du 
sicherstellen kannst das immer nur ein Prozess auf das Signal treibt, 
kannst Du guarded Signalzuweisungen verwenden. Dazu musst Du ein Signal 
als "register" deklarieren und mit guarded Blöcken arbeiten.
Ein Beispiel dazu findest Du im IEEE 1076.6 in 6.1.3.6.

[Steffen Hausinger (Gast)]

Ich versuche, meine Beschreibung auf das Wesentliche zu konzentrieren:

Ich habe zwei getrennte Speicher, M1 und M2. Auf jeden der beiden möchte 
ich entweder lesend oder schreibend zugreifen. Da jeder Speicher eine 
unterschiedliche Ansteuerung benötigt (Timing, Signalleitungen), habe 
ich mir zwei Entities erzeugt - eine pro Speicher. Ich möchte auf gar 
keinen Fall nur eine einzige Entity mit nur einem einzigen Prozess 
verwenden, da der gesamte Speichercontroller noch deutlich mehr 
Funktionen beinhaltet und ich ansonsten den Überblick verlieren würde.

Beide Speicher sollen nun über ein gemeinsames Interface angesprochen 
werden. Es läuft also darauf hinaus, dass die Ausgangssignale beider 
Speicher zu einem einzelnen Ausgangssignal zusammengefasst werden 
müssen.


Geht das auf die von mir im Eingangsposting vorgeschlagene Weise? Oder 
muss ich explizit einen Multiplexer verwenden?

[Steffen Hausinger (Gast)]

@Mathi: Danke für den Hinweis! Ich bin noch nicht so lange mit VHDL 
zugange, das Kapitel muss ich mir erst genauer anschauen...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Steffen Hausinger schrieb:
> Ich bin noch nicht so lange mit VHDL zugange...
Dann lass die komplizierten Dinge einfach mal weg und mach es am Anfang 
einfach so, dass nicht aus mehreren Prozessen auf 1 Signal getrieben 
wird. Wenn du verstanden hast, was dahinter ist (ein Multiplexer 
nämlich) dann wird dir das auch gar nicht schwerfallen. Sowas lässt sich 
innerhalb eines FPGAs sowieso nicht realisieren:
>       Address <= "ZZZZZZZZZZZZZZZZ";
In einem FPGA gibt es nur '0' und '1'. Alles andere wird durch 
irgendwelche Logik, Latches oder Multiplexer ersetzt.

Der Codeauszug von ganz oben funktioniert solange der Synthesizer das 
Signal auflösen kann. Mit der expliziten Abfrage auf
if Selector = 1 then
:
if Selector = 2 then
:
if Selector = 3 then
:
werden übergreifend über die Prozesse Zugriffskonflikte ausgeschlossen. 
Weil ja der Selector immer nur 1 oder 2 oder 3 sein kann, kann auch auf 
Adresse jeweils nur 1 Prozess treiben.
Glück gehabt. Aber das nächste Mal fliegst du auf die Nase. 
Garantiert...

> Doch, es lässt sich synthetisieren.
Das ist neu hier...
Dass es sich simulieren lässt ist klar. Aber das mit der Synthese muß 
ich auch mal ausprobieren. Welchen Synthesizer verwendest du?

> Geht das auf die von mir im Eingangsposting vorgeschlagene Weise?
Offenbar schon...  :-/
> Oder muss ich explizit einen Multiplexer verwenden?
Das ist, was die Synthese sowieso daraus machen muss...  :-o

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> Aber das mit der Synthese muß ich auch mal ausprobieren.
Gesagt, getan:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity MultipleDrivers is
    Port ( selin   : in  STD_LOGIC_VECTOR  (1 downto 0);
           addrin  : in  STD_LOGIC_VECTOR  (3 downto 0);
           addrout : out  STD_LOGIC_VECTOR (3 downto 0));
end MultipleDrivers;

architecture Behavioral of MultipleDrivers is
begin
   process (selin, addrin) begin
      if (selin="00") then
         addrout <= "0001";
      else
         addrout <= "ZZZZ";
      end if;
   end process;

   process (selin, addrin) begin
      if (selin="01") then
         addrout <= "0001";
      else
         addrout <= "ZZZZ";
      end if;
   end process;

   process (selin, addrin) begin
      if (selin="10") then
         addrout <= "0001";
      else
         addrout <= "ZZZZ";
      end if;
   end process;

   process (selin, addrin) begin
      if (selin="11") then
         addrout <= addrin;
      else
         addrout <= "ZZZZ";
      end if;
   end process;
end Behavioral;

Wie berichtet: das geht.
Und wie erwartet: das gibt einen Multiplexer.
Dann wäre es aber auch sinnvoll, das auch gleich als Multiplexer zu 
beschreiben.

Denn solange alle Fälle von selin verwendet werden, ist kein 
Tristate-Buffer nötig. Wenn aber einer der 4 Fälle nicht verwendet wird, 
muß das Signal addrout hochohmig werden. Und das geht innerhalb des 
FPGAs nicht --> böses Erwachen...  :-o

[Harald F. (hfl)]

dem_vorredner_zustimm
aber_nochwas_dazu_sagen_will

Ich habe beste Erfahrungen mit der Anwendung des ASIC-Designsflows bei 
FPGA-Designs gemacht. Eine der Regeln lautet, tri-states ausschließlich 
in der obersten Ebene eines Designs zu verwenden. Und diese oberste 
Ebene darf lediglich Pins beinhalten, keine Logik. Daraus folgt, dass 
man in den unten liegenden Logikmodulen Datenmultiplexer verwendet, und 
zusätzlich ein Signal erzeugt, mit dem man in der obersten Eben den 
Tristate-Treiber einschaltet. Klingt kompliziert, ist aber ein Abbild 
der realien Implementierung im Silizium. So sieht die Hardware eines 
FPGAs nunmal aus. Da wird nicht von mehreren Logikelementen 0/1/z auf 
eine gemeinsame Leitung gegeben, die dann an einem Pin rauskommt.

[Steffen Hausinger (Gast)]

Ok, damit ist meine Frage geklärt. Ich habe gestern Abend noch auf 
Multiplexer umgebaut. Das hat gleichzeitig einige der vorher bestehenden 
Warnungen beseitigt.

Der Nachteil an der Variante mit dem Multiplexer ist, dass mein Modell 
schrecklich unübersichtlich ist. Denn abgesehen davon, dass VHDL für 
mein Empfinden sowieso ganz fürchterlich unstrukturiert ist 
(Hierarchie?), habe ich in diesem konkreten Fall nun auch noch mehrere 
Signale, die später zu einem Signal zusammengefasst werden. Und damit 
tolle Appendizes á la "_out_MUX1" usw.

In drei Monaten werde ich da nicht mehr durchblicken. Deshalb werde ich 
heute Abend wohl damit beginnen müssen, einen Signalplan zu zeichnen...


Danke für Eure Antworten!
Steffen

[Steffen Hausinger (Gast)]

Nachtrag zum Beispiel von lkmiller:

Bei mir ist es etwas unkritischer, da das bei Dir "addrout" genannte 
Signal nicht vom Typ "in" ist, sondern "inout". Und das auch auf 
TOP-Ebene. Insofern müssten bei mir nicht mal alle Fälle belegt sein.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Steffen Hausinger schrieb:
> Denn abgesehen davon, dass VHDL für mein Empfinden sowieso
> ganz fürchterlich unstrukturiert ist (Hierarchie?)
Das liegt nicht unbedingt an VHDL, sondern eher an der passenden 
Modularisierung eines Projekts.

> Deshalb werde ich heute Abend wohl damit beginnen müssen,
> einen Signalplan zu zeichnen...
Ich habe durchaus größere Projekte mit VHDL am laufen, und ich blicke da 
relativ schnell wieder durch. Es ist eben so, dass z.B. die Erzeugung 
von Select-Signalen für Untermodule nicht unbedingt in einem getrennten 
Modul gut aufgehoben ist. Manchmal wird die Sache wesentlich 
überschaubarer, wenn eine Ebene eingespart wird.
Und dann sollte beachtet werden, dass es neben der Prozess-Schreibweise 
die Möglichkeit von Concurrent-Zuweisungen gibt. Damit lassen sich 
solche Multiplexer oft in ein paar kurzen Zeilen schön übersichtlich 
abhandeln...

[Steffen Hausinger (Gast)]

Lothar Miller schrieb:
> Das liegt nicht unbedingt an VHDL, sondern eher an der passenden
>
> Modularisierung eines Projekts.

Natürlich. Es liegt auch daran, dass ich noch nicht sonderlich lange in 
VHDL unterwegs bin und alles noch ein wenig ungewohnt ist.

Aber wenn ich wie hier auf ein Signal nur in einem einzigen Prozess 
schreibend drauf zugreifen kann, dann schränkt mich das schon ein. Denn 
dann muss ich entweder meinen Prozess riesig werden lassen und die 
Kapselung geht verloren. Oder aber ich muss das Signal aus mehreren 
Einzelsignalen zusammensetzen und die Kapselung geht ebenfalls verloren.

Mir ist schon klar, warum das in VHDL nun einmal so sein muss. Aber 
hilfreich ist es eben trotzdem nicht.

Mit der Modularisierung sprichst Du gleich das nächste Thema an. Wenn 
mir eine Entity zu groß wird, möchte ich sie gerne aufteilen. Das kann 
ich aber nur "nach unten hin". So steht dann "Entity 1" ganz oben und 
gibt ihr Verarbeitungsergebnis an "Entity 2" weiter - die zwangsweise 
darunter steht. "Entity 2" wiederum muss muss am Ende das Ergebnis 
wieder nach oben, durch Entity 1 hindurch, dem "aufrufenden" (Wie nennt 
man das? "Speisenden"?) Prozess leiten.

[Mathi (Gast)]

Steffen Hausinger schrieb:
> Aber wenn ich wie hier auf ein Signal nur in einem einzigen Prozess
> schreibend drauf zugreifen kann, dann schränkt mich das schon ein.

Wie oben geschrieben, bietet VHDL die Möglichkeit über guarded commands 
aus mehreren Blöcken (Achtung: NICHT Prozesse) auf ein Signal 
zuzugreifen. Des weiteren bietet VHDL die Möglichkeit mittels shared 
variables aus mehreren Prozessen auf einen Wert zuzugreifen.
Beides sind Techniken die für die High-Level Modellierung verwendet 
werden, sich nicht unbegrenzt synthetisieren lassen und von Anfängern 
gemieden werden sollten.
Allerdings beschreiben die meisten Entwickler eher auf der Register 
Transfer Ebene. Und dort kommen dann z.B. Konstrukte für explizite 
Multiplexer zu Einsatz. Die Abstraktion nimmt ab und die Beschreibung 
ist näher an der Hardware. Dadurch hat man mehr Kontrolle aber auch 
nicht mehr so übersichtliche Beschreibungen wie auf einer höheren Ebene.

> Mit der Modularisierung sprichst Du gleich das nächste Thema an. Wenn
> mir eine Entity zu groß wird, möchte ich sie gerne aufteilen. Das kann
> ich aber nur "nach unten hin". So steht dann "Entity 1" ganz oben und
> gibt ihr Verarbeitungsergebnis an "Entity 2" weiter - die zwangsweise
> darunter steht. "Entity 2" wiederum muss muss am Ende das Ergebnis
> wieder nach oben, durch Entity 1 hindurch, dem "aufrufenden" (Wie nennt
> man das? "Speisenden"?) Prozess leiten.

Was spricht dagegen die Entities 1 und 2 nebeneinander zu setzen?

[Semprini (Gast)]

Das Ganze funktioniert in der Synthese und der Realität nur, wenn die 
Prozesse sich gegenseitig ZEITLICH ausschließen, weil die Bedingungen 
auf die sie reagieren, dies tun.

Das ist aber trotzdem eine konfuse Technik: Einfacher ist, es immer 
"ausgangsorientiert" zu programmieren und einen prozess einem Ausgang 
zuzuordnen und zwar genau einem.

[Duke Scarring (Gast)]

Steffen Hausinger schrieb:
> Mit der Modularisierung sprichst Du gleich das nächste Thema an. Wenn
> mir eine Entity zu groß wird, möchte ich sie gerne aufteilen. Das kann
> ich aber nur "nach unten hin". So steht dann "Entity 1" ganz oben und
> gibt ihr Verarbeitungsergebnis an "Entity 2" weiter - die zwangsweise
> darunter steht. "Entity 2" wiederum muss muss am Ende das Ergebnis
> wieder nach oben, durch Entity 1 hindurch, dem "aufrufenden" (Wie nennt
> man das? "Speisenden"?) Prozess leiten.

Dafür wurden die records erfunden :-)

Siehe [1] ab Folie 23.

Duke

[1] http://www.imd.uni-rostock.de/lehre/vlsi_i/vhdlf.ppt

[Steffen Hausinger (Gast)]

Mathi schrieb:
> Beides sind Techniken die für die High-Level Modellierung verwendet
>
> werden, sich nicht unbegrenzt synthetisieren lassen und von Anfängern
>
> gemieden werden sollten.

Das dachte ich mir schon fast bei Deinem Posting von gestern Abend. Ich 
habe mir schon einige Anfängerbücher angeschaut, aber von guarded 
signals habe ich noch nichts gelesen. Aber ich bin weiter an dem Thema 
dran!



Mathi schrieb:
> Was spricht dagegen die Entities 1 und 2 nebeneinander zu setzen?

Das ISO-OSI Modell. Ich fange mit dem höchsten Abstraktionsgrad an und 
arbeite mich immer tiefer. Eine Ebene hat dabei genau einen Eingang (die 
darüberliegende Ebene) und einen Ausgang (die darunterliegende). Ein 
Beispiel - Protokollschnittstelle:

Protokoll-Engine
      v
Ansteuerung SJA1000
      v
Datentransfer

Natürlich geht das funktional auch nebeneinander. Die "Sichtbarkeit" ist 
dann aber eine andere. Und das ist eben der Grund, weshalb sich VHDL für 
mich unstrukturiert anfühlt. (Ich wage ja nicht zu behaupten, dass VHDL 
AN SICH unstrukturiert sei ;-) )



Duke Scarring schrieb:
> Dafür wurden die records erfunden :-)

Records kenn ich natürlich. Aber das kaschiert mein Problem nur, es löst 
es nicht ;-)

[Jean (Gast)]

>habe mir schon einige Anfängerbücher angeschaut, aber von guarded
>signals habe ich noch nichts gelesen.

"The Designer's Guide To VHDL" von Ashenden widmet hierfür ein Kapitel.

Gruß,
Jean

[Matthias G. (mgottke)]

Nur mal kurz, wie schön übersichtlich Dein obiges Beispiel auch 
geschrieben werden kann. Ich finde das jedenfalls übersichtlich.
Man muss ja nicht gleich Tausend Signale generieren die ich mühselig 
wieder über einen Mux zusammen setze. Auch wenn das der Synthesizer bei 
anderer Beschreibung so macht.

Die Kunst bei VHDL-Designs ist es weg von der Hardwarebeschreibung hin 
zu einer Verhaltensbeschreibung zu kommen. Das erfordert aber Erfahrung, 
denn es schon wichtig zu verstehen was der Synthesizer daraus macht.

Nun aber zwei einfache Schreibweisen:

Foo : process(Selector)
begin
   case Selector is
      when 1 => Address <= x"0123";
      when 2 => Address <= x"4567";
      when 3 => Address <= x"89AB";
      when others => Address <= "ZZZZZZZZZZZZZZZZ";
   end case;
end process;

oder noch kürzer:

Address <= x"0123" when Selector = 1 else
           x"4567" when Selector = 2 else
           x"89AB" when Selector = 3 else
           "ZZZZZZZZZZZZZZZZ";

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Steffen Hausinger schrieb:
> Protokoll-Engine
>       v
> Ansteuerung SJA1000
>       v
> Datentransfer
Das ist dein Problem. Der Top-Level muß bei einem FPGA-Design fast 
zwingend irgendwelche Baustein-Pins bedienen. Und deshalb mußt du deine 
Signale quasi "von unten" wieder nach oben durchschleusen...

Richtiger wäre also:
Top-Level:   IO-Pins
               ^
Eins tiefer: Datentransfer
               ^
:            SJA1000
               ^
:            Protokoll
               ^
Zuunterst:   Steuerung

[Mathi (Gast)]

Steffen Hausinger schrieb:
> Protokoll-Engine
>       v
> Ansteuerung SJA1000
>       v
> Datentransfer

Alternativ kannst Du den Datenfluss modellieren:

+----------------+    +----------------+    +----------------+
|Protokoll-Engine| -> |    SJA1000     | -> |  Datentransfer |
+----------------+    +----------------+    +----------------+

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

>>> "The Designer's Guide To VHDL" von Ashenden widmet hierfür ein Kapitel.
DAS würde mir zu denken geben. Es zeugt von der Komplexität des 
Themas... :-/

[Harald F. (hfl)]

-> Steffen

Deine Sichtweise der Modularisierung ist doch ok. Zitat: "Das kann
ich aber nur "nach unten hin". So steht dann "Entity 1" ganz oben und
gibt ihr Verarbeitungsergebnis an "Entity 2" weiter - die zwangsweise
darunter steht. "Entity 2" wiederum muss muss am Ende das Ergebnis
wieder nach oben, durch Entity 1 hindurch, dem "aufrufenden" (Wie nennt
man das? "Speisenden"?) Prozess leiten."

Das gleiche macht man doch auch in Programmiersprachen. Wenn eine 
Funktion unübersichtlich groß geworden ist, lagert man Teile des 
Algorithmus sinnvoll in eigene Funktionen aus und ruft diese in der 
Hauptfunktion auf. Was ist daran unübersichtlich? Nichts, das ist schon 
richtig so. Es ist in VHDL etwas mehr Tipparbeit, aber das Prinzip ist 
das Gleiche.

Unabhängig davon kannst Du dur aber auch schon vorher, bevor es Dir zu 
groß geworden ist, eine feinere Zerlegung ausdenken und zunächst mal das 
Verdrahtungsgerüst schreiben. Das würde dann deinem Schaltplan 
entsprechen, zu dem ich dir, wie andere auch, ebenfalls nicht raten 
würde.

[Steffen Hausinger (Gast)]

Lothar Miller schrieb:
> Richtiger wäre also:
>
> Top-Level:   IO-Pins
>
>                ^
>
> Eins tiefer: Datentransfer
>
>                ^
>
> :            SJA1000
>
>                ^
>
> :            Protokoll
>
>                ^
>
> Zuunterst:   Steuerung

Dann wäre "Steuerung" ja in der untersten Entity! Gerade "Steuerung" ist 
aber das zentrale Modul im Design! D.h., alles, was "Steuerung" machen 
würde (Peripherie abfragen, andere Prozesse anstoßen etc.), müsste dann 
zuerst an die Entity "Datentransfer" gegeben werden, die es dann Stück 
für Stück weiter nach unten reicht! Sozusagen ein umgedrehtes ISO-OSI 
Modell.

Dann schon lieber so wie Mathi es schreibt. Da habe ich dann allerdings 
keine vorgegeben Struktur, weil ich auf jede Entity frei zugreifen kann. 
Das wäre ja der Vorteil einer Kapselung, nämlich dass ich immer nur die 
jeweilige Ebene sehen kann und deren Schnittstellen nach oben und unten.


Mir ist eins wichtig: Das ist von mir kein meckern! Ich will Euch nur 
begründen, warum ich (als Beginner) VHDL vergleichsweise schwierig zu 
strukturieren und wenig intuitiv finde.



Harald Flügel schrieb:
> Unabhängig davon kannst Du dur aber auch schon vorher, bevor es Dir zu
>
> groß geworden ist, eine feinere Zerlegung ausdenken und zunächst mal das
>
> Verdrahtungsgerüst schreiben.
Ja, darauf läuft es hinaus...


Harald Flügel schrieb:
> Das würde dann deinem Schaltplan
>
> entsprechen, zu dem ich dir, wie andere auch, ebenfalls nicht raten
>
> würde.
Ich nehme an, das "nicht" ist am Schluß zu viel?!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> Sozusagen ein umgedrehtes ISO-OSI Modell.
> Dann schon lieber so wie Mathi es schreibt.
Sieh dir das mal an:
Das ist eigentlich genau das selbe, nur nicht von "unten nach oben"...
;-)

> warum ich (als Beginner) VHDL vergleichsweise schwierig zu
> strukturieren und wenig intuitiv finde.
Das betrifft nicht vorrangig VHDL, sondern eher die Hardware-Denkweise. 
Es ist eigentlich schön einfach und komfortabel, wenn man weiß, dass 
alle Signale über den Port der Entity müssen (mal von irgendwelchen 
Einflüssen im Stile von globalen Variablen aus der Software-Ecke 
abgesehen). Ich weiß genau, da kommt "seitlich" nichts rein und es geht 
nichts raus.

Nur, wenn du vorher in C oder sonstwas programmiert hast, dann muss 
dir bewusst werden, dass die Strategie bei VHDL eine grundlegend andere 
ist.

BTW:
> Sozusagen ein umgedrehtes ISO-OSI Modell.
Dieses Modell ist in den seltensten Fällen durchgängig implementiert... 
:-/

[Harald F. (hfl)]

@ Steffen
hab ich ein "nicht" zuviel oder zuwenig?

=====8<-----
Das würde dann deinem Schaltplan entsprechen, zu dem ich dir, wie andere 
auch, ebenfalls nicht raten würde.
=====8<-----

Komischer Satz. Was ist sagen wollte ist: Ich würde keinen 
Schaltplan-Editor verwenden. Ich hatte mal einen, der die 
Verbindungsliste der Blöcke in Verilog für die Simulation und die 
Synthese ausgeben konnte. Das war ganz nett, aber auch nicht wirklich 
notwendig. Da gibt es andere Faktoren, die bestimmen, ob man ein Design 
ein Jahr später noch versteht. Relativ wichtig finde ich z.B. eine 
durchgängige Nomenklatur von Signalnamen und Modulen, ausgeschriebene 
Namen (und keine kryptischen Abkürzungen), und einige andere Regeln 
mehr. Wenn man das unternehmensweit oder wenigstens gruppenweit 
durchzieht, dann versteht man sogar Designs von Kollegen.

[berndl (Gast)]

Harald Flügel schrieb:
> Relativ wichtig finde ich z.B. eine
> durchgängige Nomenklatur von Signalnamen und Modulen, ausgeschriebene
> Namen (und keine kryptischen Abkürzungen), und einige andere Regeln
> mehr.

Naja, viel wichtiger ist mir, dass in einer Komponente (also im File die 
'entity' und im drueber liegenden level die 'component' Deklaration 
hinter jedem Signal eine sinnvolle Beschreibung eben dieses steht.
Damit kannst du dich in NullKommaNix durch einen Design hangeln.

Getoppt wird das ganze noch durch ein Bildchen mit all den Komponenten 
in der richtigen Hierarchie. Das mit ein paar zusaetzlichen Kommentaren 
hilft enorm...

[Duke Scarring (Gast)]

berndl schrieb:
> Getoppt wird das ganze noch durch ein Bildchen mit all den Komponenten
> in der richtigen Hierarchie. Das mit ein paar zusaetzlichen Kommentaren
> hilft enorm...

Sowas male ich mir mit graphviz. Damit findet man sich in unbekannten 
Code schneller rein.

Duke

[Steffen Hausinger (Gast)]

Lothar Miller schrieb:
> Nur, wenn du vorher in C oder sonstwas programmiert hast, dann muss
>
> dir bewusst werden, dass die Strategie bei VHDL eine grundlegend andere
>
> ist.

Ja und genau da hakt es immer wieder. Alle Signale sind innerhalb einer 
Entity für alle sichtbar, es kann aber nur einer drauf schreiben, was 
häufig einen Handshake zur Folge hat. Und dementsprechend groß wird dann 
die Signalliste. Üblicherweise ist sowas schlecht. In VHDL aber 
offensichtlich nicht. Im Gegenteil, viele Signale zu haben, ist in 
Ordnung. Anstelle bspw. einen Bus bidirektional auszuführen, nimmt man 
einfach die doppelte Anzahl an Signalen und macht ihn unidirektional, 
für jede Richtung einen. In VHDL kein Problem. In C läuft der Stack 
über.


Harald Flügel schrieb:
> Was ist sagen wollte ist: Ich würde keinen
>
> Schaltplan-Editor verwenden.

Ach so! Keine Sorge, den Schaltplan-Editor habe ich schon nach einer 
Woche hinter mir gelassen. Die Signalverschaltung, die ich aufzeichnen 
möchte, soll in etwa so aussehen wie von Duke Scarring.


Harald Flügel schrieb:
> Relativ wichtig finde ich z.B. eine
>
> durchgängige Nomenklatur von Signalnamen und Modulen, ausgeschriebene
>
> Namen (und keine kryptischen Abkürzungen), und einige andere Regeln
>
> mehr.

;-)


Duke Scarring schrieb:
> Sowas male ich mir mit graphviz.

Das werde ich auch ausprobieren.


Meine ursprüngliche Frage ist geklärt und ich bedanke mich für Eure 
Tipps! Das schlechte Gefühl, meine Vorgehensweise wäre zu 
unübersichtlich und ich würde deshalb irgendetwas falsch machen, ist 
abgeflaut :-)

Grüße
Steffen

[Marcus H. (mharnisch)]

Steffen Hausinger schrieb:
> Ja und genau da hakt es immer wieder. Alle Signale sind innerhalb einer
> Entity für alle sichtbar, es kann aber nur einer drauf schreiben

Das mit dem Schreiben ist nicht generell der Fall. Du musst nur wissen 
was Du tust, wenn Du ein Signal von mehreren Quellen treibst, und 
natürlich, ob (und unter welchen Voraussetzungen) die Zielhardware 
derartige Signaltreiber unterstützt.

> Anstelle bspw. einen Bus bidirektional auszuführen, nimmt man
> einfach die doppelte Anzahl an Signalen und macht ihn unidirektional,
> für jede Richtung einen. In VHDL kein Problem.

Aber das macht man ja nicht aus Spaß an der Freude, sondern weil das 
eben die Hardware ist, die man beschreiben möchte. Ein Bus im 
klassischen Sinne (mehrere Treiber) ist eben was anderes als ein 
multiplexed Bus oder gar ein Network on Chip. In heutiger Hardware ist 
ersterer meist nicht der beste Weg.

Es gibt ein Seminar zum Thema Grundlagen des Digitaldesigns (frei 
übersetzt) von einer mir bekannten Firma, und auch ein "Pacemaker" 
genanntes VHDL Tutorial, das nach Registrierung frei erhältlich ist.

Entschuldigt bitte dieses hoffentlich vertretbare Maß an Eigenwerbung.

Gruß
Marcus

[SuperWilly (Gast)]

>Entschuldigt bitte dieses hoffentlich vertretbare Maß an Eigenwerbung.

Kann die Seminare dieser Firma nur wärmstens empfehlen. Echt Klasse !

VG,
SuperWilly