Anfängerfrage zu ISE

Tu Dir einen Gefallen: Lerne VHDL oder Verilog und benutze nicht den 
Schaltplan/schematic-Editor. Das Ding ist so kaputt, da ist der Frust 
vorprogrammiert.

Rick

Hi Rick,

ich habe mein Teil jetzt am Laufen, warum weiß ich eigentlich auch nicht 
so genau.

Mit der These "Finger weg von schematic" hast Du sicher recht, weil 
bereits ein einfaches Design sehr schnell unübersichtlich wird, aber 
VHDL/VERILOG ist ein Thema für sich, aber da muss ich wohl durch mit 
meinen 58 Jahren Lebenserfahrung.

Vielen Dank für Deinen Beitrag,

Otto

>Das Ding ist so kaputt, da ist der Frust
>vorprogrammiert.

Eigentlich nicht. Einfache Sache lassen sich damit problemlos machen und 
es geht auf jeden Fall schneller, als mal eben VHDL zu lernen.

Jein. Ich wollte schematic nehmen um in einem Projekt etwas den 
Überblick zu behalten. Aber:

(1) Es ist sehr umständlich (fast unmöglich) wenn man generics verwenden 
will, um z.B. variable Busbreiten zu definieren.

(2) Wenn Signale hinzukommen/wegfallen, muss jedes mal ein neues Symbol 
erstellt und verkabelt werden.

(3) Symbole zu verschieben scheitert meistens an einem zu vollen Blatt 
(kann Signale nicht routen).

(4) Wenn man eng beieinander liegende Signale/Symbole selektieren will, 
geht das nicht.

(5) Ausführlich kommentieren geht auch nicht.

(6) Und bidirektionale Signale in Busse ein- und auszukoppeln habe ich 
auch nicht hinbekommen.

Sicher, für einfache Sachen mag es reichen, aber wer weiß schon auf 
Anhieb was mit einem FD4RE anzufangen.

Da mag ich lieber die folgende Beschreibung:

1

architecture bhv of data_register is

2

begin

3

process 

4

begin

5

  wait until rising_edge(clk); -- steht immer da, da alles synchron

6

7

  if (ce = '1') then

8

     Q <= D;

9

  end if;

10

11

  if (reset = '1') then -- reset hat Prioritaet

12

     Q <= (others => '0');

13

  end if;

14

15

end process;

16

end bhv;

Rick

Das spuckt der Editor aus? Das ist ja abartig!

pumpkin

@pumpkin:

Du hast da was missverstanden: Das gebe ich in den Editor ein.

Rick

Die Beschreibung ist aber auch nicht das, was man als sauber bezeichnet:

process (clk, reset)
begin

  if (reset = '0') then       -- HIER hat reset priorität (asynchron)
    Q <= (others => '0');
  elsif (clk'event and clk = '1') then
    if (ce = '1') then
      Q <= D;
    end if;
  end if;

end process;


Oder ist es mit Absicht nicht schön programmiert, weil es nur eine 
Verhaltensbeschreibung sein soll (bhv)?

Ok. Prinzipiell alles richtig, was ihr schreibt.
Aber 1) entfällt ein Schachtel-if mit dem wait until rising_edge(clk) 
und 2) lest selbst, was dir Profis zum asynchronen Reset schreiben:
http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?category=&iLanguageID=1&multPartNum=1&sTechX_ID=kc_priorities

Rick

Beim Thema (a)synchroner Reset gibts aber auch unter Experten geteilte 
Meinungen. Sehr interessant sind da zB. die Paper von Cliff Cummings von 
Sunburst Design:
http://www.sunburst-design.com/papers/CummingsSNUG2002SJ_Resets.pdf
http://www.sunburst-design.com/papers/CummingsSNUG2003Boston_Resets.pdf

Qunintessenz ist dabei, dass der Zeitpunkt, an dem der Reset wieder 
gelöst wird der kritische Punkt ist...

Auf http://www.sunburst-design.com/papers/ gibts auch noch weitere 
interessante Paper, zB auch zu asynchronen Fifos und Cross-Clock-Domain 
Designs. Sehr empfehlenswert.

@T.M.

Danke für die Hinweise/ Dokumentationen. Letztendlich, wird - wie auch 
hier[1] - aus einem asynchronen Reset ein synchroner Reset gemacht.

Was für den Anfänger nun übersichtlicher ist, ich weiß es auch nicht. 
Ich finde nur die vielen if/else/endif (reset, rising_edge) schwerer zu 
lesen.

Rick


[1] 
http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&multPartNum=1&sTechX_ID=kc_smart_reset&BV_SessionID=@@@@1399560539.1185777461@@@@&BV_EngineID=ccccaddlikhmkmdcefeceihdffhdfjf.0

@Rick
Das Lösen des Resets wird synchron gemacht, das Aktivieren bleibt 
asynchron. Die Vorschläge von Xilinx sind halt auf FPGAs zugeschnitten, 
da ist (a)synchroner Reset oft auch eine Frage des Ressourcenverbrauchs.