Syntaxfehler bei Simulation, kein Syntaxfehler bei Synthese

[Thomas B. (thomas1)]

Mein Phänomen mit Xilinx ISE 12.2:
Wenn ich das Design Synthesiere, dann macht er das ohne Fehler oder 
Warnung. Wenn ich hingegen die Simulation starte, dann begegnet er mir 
mit folgenden Fehlermeldungen:

Line 67: Syntax error near "process".
Line 67: Expecting type  void for <receive_data>.
Line 70: Syntax error near "process".
Line 71: Syntax error near "begin".
Line 82: Syntax error near "process".
Line 82: Expecting type  void for <sync_sig>.
Line 89: Syntax error near "Behavioral".
Line 89: Expecting type  void for <behavioral>.

Eigenartig ist auch folgendes:
Wenn ich das Design speichere (ganz normal mit Ctrl+S) dann gibt er auch 
etliche ähnliche Fehler aus:

Line 67: Syntax error near "process".
Line 70: Syntax error near "process".
Line 71: Syntax error near "begin".
Line 82: Syntax error near "process".
Line 89: Syntax error near "Behavioral".

Kennt jemand solche "Sprünge" von ISE? Oder wo liegt mein Fehler?

Vielen Dank für die Hilfe

[ich (Gast)]

Line 67: end process receive_data;

schreib stattdessen nur "end process;"

das selbe in Line 82

[Thomas B. (thomas1)]

Das habe ich nun probiert. Beim Start der Simulation kommen etwas 
weniger Fehler:

Line 67: Syntax error near "process".
Line 71: Syntax error near "begin".
Line 82: Syntax error near "process".
Line 89: Syntax error near "Behavioral".
Line 89: Expecting type  void for <behavioral>.

Das sind immer noch 5 zuviel...
Und beim speichern:

Line 67: Syntax error near "process".
Line 71: Syntax error near "begin".
Line 82: Syntax error near "process".
Line 89: Syntax error near "Behavioral".

Ausserdem hat "end process proc_name" noch immer geklappt!
Woran könnte es sonst noch liegen?

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

> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> use IEEE.NUMERIC_STD.ALL;
Was ist denn hier in letzter Zeit los? Wo lernt man das?
Siehe den Beitrag "Re: Maximum suchen"

Wie auch immer: bei mir (ISE13.1 + ISIM) tritt keiner der Effekte auf.

Lass doch mal den Prozessbezeichner weg...
Oder mach mal ein neues Projekt und kopier den Text von hier da rein.

[me (Gast)]

Nur zur Info:
Habe deinen Code in ISE 10.1 ausprobiert - läuft ohne diese/deine 
Fehler!
Simulieren kann ich es aber nicht mangels Sim-Code.

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

me schrieb:
> Simulieren kann ich es aber nicht mangels Sim-Code.
Du kannst aber den Compiler des Simulators aufrufen, indem du direkt das 
SPI-Modul simulierst. Natürlich gibt es dann keine Stimuli und damit 
viele 'U's, aber der VHDL-Code muss wie gesagt durch den Compiler...

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

Thomas B. schrieb:
> Wenn ich hingegen die Simulation starte
Welcher Simulator?

[Thomas B. (thomas1)]

Ich benutze ISim Simulator.

Dann noch zu den Libraries:
Wenn ich die
    use IEEE.STD_LOGIC_ARITH.ALL;
    use IEEE.STD_LOGIC_UNSIGNED.ALL;
weglasse, dann kann ich nicht mehr einfach so einfach subtrahieren:
    bitcnt <= bitcnt - 1;

    Line 57: Found 0 definitions for operator "-".

Muss ich dann bitcnt noch in unsigned umwandeln?

Weil

conv_integer(bitcnt)

 nicht mehr funktioniert, verwende ich nun

Data_MOSI(to_integer(unsigned(bitcnt(3 downto 0)))) <= MOSI;

Ist das gut so?

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

Thomas B. schrieb:
> Wenn ich die
>     use IEEE.STD_LOGIC_ARITH.ALL;
>     use IEEE.STD_LOGIC_UNSIGNED.ALL;
> weglasse, dann kann ich nicht mehr einfach so einfach subtrahieren:
>     bitcnt <= bitcnt - 1;
Richtig.
Aber man rechnet auch nicht mit uneingeschränkten Vektoren. Du siehst 
einem std_logic Vektor einfach nicht an, ob er signed oder unsigned ist. 
Dieses Verhalten ist in der Lib "versteckt". Wenn du dein Modul (oder 
Ausschnitte davon) weitergibst, und der Kollege hat das eingebunden:
     use IEEE.STD_LOGIC_ARITH.ALL;
     use IEEE.STD_LOGIC_SIGNED.ALL;
Dann kann das böse ins Auge gehen... :-o

Thomas B. schrieb:
> Weil conv_integer(bitcnt) nicht mehr funktioniert...
> Ist das gut so?
Richtig, du kannst es aber abkürzen:
  to_integer(unsigned(bitcnt))

BTW: im allgemeinen ist ein Schieberegister für den SPI effizienter, 
denn SPI besteht ja eigentlich nur aus 2 gekoppelten Schieberegistern:
http://www.lothar-miller.de/s9y/categories/17-SPI
http://www.lothar-miller.de/s9y/categories/26-SPI-Slave
http://www.lothar-miller.de/s9y/categories/45-SPI-Master

[Thomas B. (thomas1)]

Lothar Miller:
> Richtig.
> Aber man rechnet auch nicht mit uneingeschränkten Vektoren. Du siehst
> einem std_logic Vektor einfach nicht an, ob er signed oder unsigned ist.

Dieser bitcnt soll einfach immer "untendurch" laufen, d.h. von 0 auf 15, 
14, 13, ..., 0, 15.

Wie muss ich das jetzt machen?
unsigned(bitcnt) <= unsigned(bitcnt) - 1;
Fehler!:
<unsigned> is not a signal.

Das kannst Du mir sicher noch verraten...

[Thomas B. (thomas1)]

Dann noch gerade eine Frage zu diesem SPI-HDL:

-- Parallel-Eingänge --> MISO
  process (SS, Din, SCLK)   
  begin
     if (SS='1') then
        dsr <= Din;
     elsif rising_edge(SCLK) then               -- mit der fallenden SCLK-Flanke 
        dsr <= dsr(dsr'left-1 downto 0) & MOSI; -- wird MOSI eingetaktet
     end if;
  end process;
  MISO <= dsr(dsr'left) when SS='0' else 'Z';   -- und MISO aktualisiert

Dieser Code kommt Lothar Miller sicher bekannt vor...

Ist das sauber, 3 verschiedene Signale in die Sensitivitylist zu packen?
Das Design ist ja dann nicht sauber synchron, ja?

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

Thomas B. schrieb:
> Das kannst Du mir sicher noch verraten...
Ich will mal nicht so sein...
Rechne einfach immer mit usigned oder integer:

  signal bitcnt: UNSIGNED(3 downto 0) := (others => '1');
  :
  bitcnt <= bitcnt - 1;
  :
  Data_MOSI(to_integer(bitcnt)) <= MOSI;

Du wirst die passenden Zeilen in deiner Beschreibung schon finden...

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

Thomas B. schrieb:
> Dieser Code kommt Lothar Miller sicher bekannt vor...
Jadastuter... ;-)

> Ist das sauber, 3 verschiedene Signale in die Sensitivitylist zu packen?
Das ist in diesem Fall nicht nur sauber, sondern zwingend nötig.
Denn hier nehme ich den SCLK zum takten und den SS als asynchronen 
Reset. Und im Resetzustand SS='1' kann sich Din direkt auf das 
Schieberegister dsr auswirken.
Für die Sensitivliste interessiert sich sowieso nur die Simulation. 
Die Synthese schert sich einen feuchten Kerricht da drum... :-o

> Das Design ist ja dann nicht sauber synchron, ja?
Das Design ist hier genauso sauber und synchron, wie der daran 
angeschlossene SPI-Master. Wenn der den Slave "überrennt", dann wird der 
nicht mehr funktionieren. Das wird er aber auch bei einem "total" 
synchronen Design nicht mehr (können)...