compiler fehler

[jason (Gast)]

hallo

ich bin gerade dabei eine vhd datei mit modelsim zu testen. jedoch weiß
ich nicht was dieser error bedeutet und komm nicht weiter.


** Error: I:/iounit.vhd(91): 'Others' is in unconstrained array
aggregate
** Error: I:/iounit.vhd(99): VHDL Compiler exiting

zeile 90-92:
elsif clock10_s'event and clock10_s = '1' then
      if counter_s = "111" and iobus_io /= (others => '1') then
        speicher_s <= iobus_io;

zeile 97-99:
  end process;

end rtl;

was mir auch noch unklar ist. wieso zeigt modelsim immer nur einen
error an obwohl es mehrere sind.

mfg

[jason (Gast)]

ich hätte da noch eine frage.

wenn ihr ein projekt machen wollte was mehrere funktionen hat, wie
überlegt ihr euch wie ihr das programmiert.

zeichnet ihr zuerst eine skizze wie man das aufbauen könnte mit zähler,
multiplexer usw. und dann macht ihr daraus einen vhdl code

oder

überlegt ihr euch wie es am einfachsten wäre zu programmieren und macht
daraus immer kleine prozesse.

[TobiFlex (Gast)]

Wenn iobus_io kein vector ist solltest Du
iobus_io /= '1'
schreiben.
Ansonsten ist Dein Codeauszug zu knapp um nähere Aussagen zu treffen.

Viele Grüße
TobiFlex

[jason (Gast)]

iobus ist ein vektor

hier ist mal der process wo die fehler sind

 process (clock10_s, reset_i)
  begin  -- process
    if reset_i = '0' then           -- asynchronous reset (active
low)
      speicher_s<= (others => '0');
    elsif clock10_s'event and clock10_s = '1' then
      if counter_s = "111" and iobus_io /= (others => '1') then
        speicher_s <= iobus_io;
        else
          buttons_o<= speicher_s;
      end if;
    end if;
  end process;

end rtl;

[TobiFlex (Gast)]

Ich kenn others nur im Zusammenhang mit Zuweisungen ( "<=" ) oder der
case Anweisung. Aber als Vergleich... Ich weiß nicht. Machs doch
einfach so:
... iobus_io /= H"FFFF" ...

[jason (Gast)]

others ist ja auch eine zuweisung
dem 8 bit breiten iobus wird eine 1 zugewiesen.
und dann wird die if anweisung geprüft

durch others wollte ich mir nur die acht '1' ersparen.

[ope (Gast)]

ich bin mir nicht sicher, aber an diesem Vergleich mit (others => '1')
könnte es durchaus liegen - unconstrained. Die Compiler sind entweder
nicht klever genug oder es gibt andere Gründe. Solche Konstrukte habe
ich bei mir ebenfalls, vergleiche aber immer gegen eine Konstante:

  process (clock10_s, reset_i)
    constant IOBUS_ONES 
      : std_logic_vector(iobis_io'range) := (others => '1');
  begin  -- process
    if reset_i = '0' then 
      speicher_s<= (others => '0');
    elsif clock10_s'event and clock10_s = '1' then  
      if counter_s = "111" and iobus_io /= IOBUS_ONES then
        speicher_s <= iobus_io;
      else
        buttons_o<= speicher_s;
      end if;
    end if; 
  end process;

BTW, sieht nach (x)emacs source aus ;-)

Viele Grüße
Olaf

[jason (Gast)]

hallo
du hast recht gehabt es lang an dem "others".
woher weißt du dass das emacs ist?

jetzt ist da noch mein zweites problem-

die vorgehensweise bei einem projekt wie macht ihr das

mfg

[ope (Gast)]

> woher weißt du dass das emacs ist?

Anhand der emacs/vhdl-mode typischen Kommentare ;-)

> die vorgehensweise bei einem projekt wie macht ihr das

Ich kann da nur vom LA Projekt reden: Viele Entities schreiben, die
separat getestet werden. Was zusammengehört in Processe schreiben. Wenn
etwas innerhalb des Prozesses zu unübersichtlich wird, Funktionen und
Prozesse einführen (geht ja local). Packages sind auch ein Mittel, die
Übersichtlichkeit zu wahren, zB. für Types des Projektes wäre
offensichtlich. Die gleichen Paradigmen also, wie sind in den anderen
Hochsprachen auch zu finden sind. Da in VHDL aufgrund der Sprache eh
viel geschrieben werden muss, macht das nichts aus. Hier ist dann ein
guter Editor (Glückwunsch, Du hast imo eine gute Wahl getroffen) Gold
wert, der Instances, Components etc. per Knopfdruck einsetzten kann.
Lange/Aussagekräftige Bezeichner sind auch kein Problem, einmal
geschrieben und dann per Tab-Hangeln einfügen (im Emacs).

Ansonsten ein Blatt Papier - da schreibe ich auf, was es machen soll,
was es dazu braucht und ggf. ein Blockbild - dann geht's los.

Viele Grüße
Olaf

[ope (Gast)]

äähh: Funktionen und Prozesse einführen => sollte heissen: Funktionen
und Proceduren.

[jason (Gast)]

hallo

wie machst du das blockschaltbild? da habe ich so meine probleme.
später das zu programmieren ist glaube ich eh nicht so schwer, wenn man
das vom blockschaltbild ableitet.

ich will eine 6 stellige 7 segment anzeige steuern.

die funktionen sollen zb. eine uhr mit 24h betrieb, uhr mit 12h
betrieb, stoppuhr, countdown usw. sein die ich per tastendruck
umstellen kann.

wenn ich das blockschaltbild digitaltechnisch zeichnen würde, bräuchte
ich 6 zähler und codeumwandler für die jeweilige anzeige und den
frequenzteiler usw. und dann dementsprechend richtig verbinden.

wenn ich das aber programmiermäßig zeichnen würde dann würde das
blockschaltbild wieder ganz anders aussehen. da bräuchte ich für jede
funktion ein kästchen da jede funktion extra programmiert wird,  wo zb.
der überlauf stattfindet und in jeder funktion müßte ich die sechs
zähler neu definieren.
daraus werden ja dann fast 30 zähler

mfg

[ope (Gast)]

so tief gehe ich nicht in's Detail bei den Blockbildern. Die
Blockbilder bei mir orientieren sich mehr an den entities mit ihren
Funktionen und wie sie untereinander in Verbindung stehen; also keine
Detailarbeit, die dann anschliessend 1:1 in VHDl umgesetzt wird. zB: 6
stellige 7 segment anzeige => ein generic encoder mit 6 Instances,
braucht hex input, 7-segment output, enable (wegen Multiplex) ist ein
Block/Entity. Tasten benötigt eine Entprellroutine (gibt's im Netz
bzw. auch in der Codesammlung des Forums wenn ich mich recht erinnere)
und wird ein weiterer Block, der einen Zähler enthalten dürfte. Da hier
mehrere Zähler zusammenkommen schreit das nach einer generic
Implementierung mit up/down und generic bitwidth. Und so sammel ich,
was man so alles benötigt für die Realisierung. Im Grunde das Gleiche,
was Du bereits oben gemacht hast. Dabei wirst Du feststellen, dass Du
viel Schmierpapier verbrauchst, aber besser das, als etliche Source
Zeilen wieder zu löschen, die alle mal funktioniert haben, aber nicht
so recht in's Konzept plötzlich passen, weil ein Aspekt nicht so recht
betrachtet wurde ....

Sprich, nichts besonderes also.

Viele Grüße
Olaf

[ope (Gast)]

... Im Grunde eine Festlegung der Schnittstellen/Funktionen der
Entities, nicht deren Implentierung.