Quadrature Decoder kann nicht synthetisiert werden

[Patrick B. (p51d)]

Hallo

Ich bin nun endlich einmal dazu gekommen, ein wenig mit meinem FPGA 
Board zu spielen. Nun möchte ich eine einfache Schaltung, die einen 
Rotary switch einliest und die Leds durchschaltet.

Nur leider habe ich einen Fehler beim synthetisieren (Simulation hat 
geklappt).

entity QuadratureDecoder is
    Port ( A : in  STD_LOGIC;
           B : in  STD_LOGIC;
           Sector : out  STD_LOGIC_VECTOR (7 downto 0));
end QuadratureDecoder;

architecture Behavioral of QuadratureDecoder is

signal count : std_logic_vector(2 downto 0) := "000";

begin

  process(A, B)
  begin
    if rising_edge(A) then
      if B = '0' then
        count <= std_logic_vector(unsigned(count) + 1);
      else
        count <= std_logic_vector(unsigned(count) - 1);
      end if;
    elsif falling_edge(A) then
      if B = '0' then
        count <= std_logic_vector(unsigned(count) - 1);
      else
        count <= std_logic_vector(unsigned(count) + 1);
      end if;
    elsif rising_edge(B) then
      if A = '0' then
        count <= std_logic_vector(unsigned(count) - 1);
      else
        count <= std_logic_vector(unsigned(count) + 1);
      end if;
    elsif falling_edge(B) then
      if A = '0' then
        count <= std_logic_vector(unsigned(count) + 1);
      else
        count <= std_logic_vector(unsigned(count) - 1);
      end if;
    end if;
  end process;

  with count select
    Sector <=   "00000001" when "000",
            "00000010" when "001",
            "00000100" when "010",
            "00001000" when "011",
            "00010000" when "100",
            "00100000" when "101",
            "01000000" when "110",
            "10000000" when "111",
            "XXXXXXXX" when others;

end Behavioral;

line 44: Signal count cannot be synthesized, bad synchronous description. The description style you are using to describe a synchronous element (register, memory, etc.) is not supported in the current software release.

Kann mir jemand weiterhelfen?

Nebenbei: Wie wird normalerweise ein flankengetriggertes Modul aufgebaut 
(mehrere Eingänge und unterschiedliche Flankten), oder soll dies über 
Pegel gelöst werden und einzig einen Clock verwenden?

Besten Dank,
Patrick

[Pongo unterwegs (Gast)]

Mach schnell die vielen konkurrierenden rising und falling Konstrukte 
weg, bevor Lothar das sieht und Dich zerfetzt!

[Patrick B. (p51d)]

Wie denn sonst (ist wie gesagt mein erstes VHDL Programm)? Jede 
Bedingung in einen eigenen Prozess?

[Pongo unterwegs (Gast)]

nein, liest erstmal was rising edge macht.

das brauchst du EINMAL, ein Prozess innen drin die typischen Abfragen 
nach Pegeln und nicht nach Flanken - siehe die einschlägigen 
Beispielprojekte

[Patrick B. (p51d)]

Ok, werds auf einen Master-Clk umschreiben.

[Christian R. (supachris)]

Ohje. Musst noch viel lernen. Aber lass dich nicht entmutigen, jeder 
fängt mal an.
Schau doch mal hier: 
http://www.mikrocontroller.net/articles/Drehgeber#Beispielcode_in_VHDL 
diese Lösung klappt bestens, selbst in gestörten Industrie-Umgebungen.

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

Patrick B. schrieb:
> (ist wie gesagt mein erstes VHDL Programm)
Warum heißt VHDL VHDL und nicht VHPL?

Zum Thema: was du beschreibst, sind "Dual-Clock-Flipflops" und so etwas 
gibt es nicht...

Pongo unterwegs schrieb:
> und Dich zerfetzt!
Tja, Pech, zu spät...

Als kleiner Denkanstoss mit Wiedererkennungswert:

http://www.lothar-miller.de/s9y/archives/53-Drehgeber,-Encoder,-Quadraturdecoder.html

[Bitflüsterer (Gast)]

Ich weiss nicht. Wie soll ich es sagen, ohne das Lothar Miller mir die 
Ohren abreisst - aber sagen will ich es doch:

Es ist richtig, dass die erhältlichen FPGAs keine Dual-Edge-Flip-Flops 
als Einheiten enthalten. Aber so etwas lässt sich in VHDL durchaus 
synthetisierbar beschreiben in dem man es mit zwei Flip-Flops - äh - 
sozusagen emuliert.

Mit den Suchbegriffen "Dual Edge FF VHLD" erhält man z.B. folgende 
interessante Links:

http://www.ralf-hildebrandt.de/publication/pdf_dff/pde_dff.pdf

und

http://asicdigitaldesign.wordpress.com/2007/07/31/the-double-edge-flip-flop/

(nebst weiteren)

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

Bitflüsterer schrieb:
> Dual-Edge-Flip-Flops
Naja, Dual-Edge ist nun nicht Dual-Clock. Ein FF mit 2 Takteingängen 
also.
Oder, wenn man sich den VHDL Code ganz oben ansieht, sogar 
Dual-Edge-Dual-Clock-FFs...

[Bitflüsterer (Gast)]

Lothar Miller schrieb:
> Bitflüsterer schrieb:
>> Dual-Edge-Flip-Flops
> Naja, Dual-Edge ist nun nicht Dual-Clock. Ein FF mit 2 /Takteingängen/
> also.
> Oder, wenn man sich den VHDL Code ganz oben ansieht, sogar
> Dual-Edge-Dual-Clock-FFs...

Richtig. Meine armen Ohren ...

[Bitflüsterer (Gast)]

... obowhl ... das sind dann eben zwei Dual-Edge-FFs. Habe noch 'ne 
Nase. :-)

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

Bitflüsterer schrieb:
> Habe noch 'ne Nase. :-)
Wenn unbedingt sein muss... ;-)

> das sind dann eben zwei Dual-Edge-FFs
Und wie verschaltest du die count FFs hier:

    if rising_edge(A) then
        count <= ...
    elsif falling_edge(A) then
        count <= ...
    elsif rising_edge(B) then
        count <= ...
    elsif falling_edge(B) then
        count <= ...

[Punkt Setzer (Gast)]

Bitflüsterer behauptetet:

>Es ist richtig, dass die erhältlichen FPGAs keine Dual-Edge-Flip-Flops
>als Einheiten enthalten.

Nein, das ist nicht richtig, zum Ansteuern von DDR-SDRAM gibbet es 
sowas, bspw im Spartan-6:

http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_1/spartan6_scm.pdf 
S.428

MfG,

[Patrick B. (p51d)]

Lothar Miller schrieb:
> Patrick B. schrieb:
>> (ist wie gesagt mein erstes VHDL Programm)
> Warum heißt VHDL VHDL und nicht VHPL?

Wie nennt man den das? Skript, File, Hardware...?

Nur so aus Neugierde: Wie werden bei einem MCU solche Peripherieteile 
realisiert? Wenn man es auf Flankengetriggert einstellt, wird das nur 
pseudomässig umgesetzt oder werden da wirkich die Flanken ausgewertet. 
Letzeres würde dann ja zu einer Asynchronität führen.

Habe mein Teil gestern noch auf ein ähnliches System (alles nür über 
einzelne Rising_edge und Falling_edge Funktionen) umgeschrieben, wie 
diese (habe ich vom Lothars Seite):

process (A,B) begin     
  if rising_edge(A) then        
  if (B='1') then p<=p+1; 
  else p<=p-1; end if;     
  end if;     
  if falling_edge(A) then        
    if (B='0') then p<=p+1; 
    else p<=p-1; end if;     
  end if;     
  if rising_edge(B) then        
    if (A='0') then p<=p+1; 
    else p<=p-1; end if;     
  end if;     
  if falling_edge(B) then        
    if (A='1') then p<=p+1; 
    else p<=p-1; end if;     
  end if;  
end process;

Gleicher Fehler wie mit if-elsif Konstrukt.

Sehe gerade überhaupt nicht, was so nicht laufen soll.

Besten Dank, Gruss

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

Patrick B. schrieb:
> Lothar Miller schrieb:
>> Patrick B. schrieb:
>>> (ist wie gesagt mein erstes VHDL Programm)
>> Warum heißt VHDL VHDL und nicht VHPL?
> Wie nennt man den das? Skript, File, Hardware...?
Hardware DESCRIPTION Language
Hardware BESCHREIBUNG ssprache
Ich habe also kein VHDL Programm, sondern eine VHDL Beschreibung. Ich 
habe auch nicht einen Prozessor mit VHDL programmiert (fällt dir was 
auf: womit werden Prozressoren i.A. programmiert?), sondern ich habe mit 
VHDL einen Prozessor beschrieben.

> Sehe gerade überhaupt nicht, was so nicht laufen soll.
Hast du mit aller Gewalt meinen Link und alle Posts ignoriert?
Es gibt nirgends auf der Welt solche Bautsteine, die du da beschreibst!

> Habe mein Teil gestern noch auf ein ähnliches System (alles nür über
> einzelne Rising_edge und Falling_edge Funktionen) umgeschrieben, wie
> diese (habe ich vom Lothars Seite):
Und was steht dort dann auch?

Leider taugt dieser Quadraturdecoder wegen der Flankenauswertungen 
nur für die Simulation. Denn in einem programmierbaren Baustein gibt 
es kein Flipflop, das zwei Takteingänge hat, die sowohl auf die 
steigende wie auch die fallende Flanke reagieren könnten.

Taugt nur für die Simulation bedeutet, dass du das zwar simulieren 
kannst, aber nicht auf irgendeine Hadware bekommst. Merke: bestenfalls 
5% von VHDL können tatsächlich auf Hardware abgebildet werden. Aber 100% 
können simuliert werden...

> Nur so aus Neugierde: Wie werden bei einem MCU solche Peripherieteile 
realisiert?
So, wie es auf meiner HP ein paar Zeilen weiter unten gemacht ist: mit 1 
einzigen Mastertakt. Der muss nur ausreichend schnell sein. Und auf 
diesen Takt werden die Eingangssignale einsynchonisiert...
Es wird niemals auf ein Eingangssignal, das evtl. auch noch prellen 
oder überschwingen kann, ein rising_edge() oder ein falling_edge() 
abgefragt. Eine Flankenerkennung macht man wieder mit dem "Mastertakt": 
erst einsynchonisieren und dann eine Flankenauswertung:
http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren
http://www.lothar-miller.de/s9y/categories/18-Flankenerkennung
Sieh dir diese beiden Links genau an. Damit kannst du 90% aller 
Anfängerfehler umgehen...

[Bitflüsterer (Gast)]

Lothar Miller schrieb:
> Bitflüsterer schrieb:
>> Habe noch 'ne Nase. :-)
> Wenn unbedingt sein muss... ;-)
>
>> das sind dann eben zwei Dual-Edge-FFs
> Und wie verschaltest du die count FFs hier:
>

>     if rising_edge(A) then
>         count <= ...
>     elsif falling_edge(A) then
>         count <= ...
>     elsif rising_edge(B) then
>         count <= ...
>     elsif falling_edge(B) then
>         count <= ...
>

Ich habe leider kein ISE hier und kann das nicht ausprobieren. Aber 
meine Idee dazu wäre, jeweils einen Abwärts- und einen Aufwärtszähler zu 
benutzen, deren Differenz am Ende gebildet wird. Auch würde am Ende 
keine Sequenz von ifs in der gezeigten Form dastehen. Eher zwei 
Prozesse.

Lothar, ich weiß, solche theoretischen Einwände sind schwer 
ernstzunehmen. Wenn Du sagen willst, das es überhaupt nicht geht, auch 
nicht emuliert und mit Gebeten zum Spaghettimonster, nehme ich das mal 
unter Vorbehalt so an.

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

Bitflüsterer schrieb:
> Aber meine Idee dazu wäre, jeweils einen Abwärts- und einen
> Aufwärtszähler zu benutzen, deren Differenz am Ende gebildet wird.
Das ergäbe einen recht glitchigen "Zählerstand", der zu nichts und 
niemandem synchron ist. Mir wäre nicht wohl dabei...

> Lothar, ich weiß, solche theoretischen Einwände sind schwer
> ernstzunehmen. Wenn Du sagen willst, das es überhaupt nicht geht, auch
> nicht emuliert und mit Gebeten zum Spaghettimonster, nehme ich das mal
> unter Vorbehalt so an.
Du wirst sicher auch in einem FPGA etwas hinbekommen, das irgendwie so 
oder so ähnlich etwas macht. Aber "funktioneren" würde ich das nicht 
nennen. Und die Not ist doch nicht groß, weil es ja Verfahren gibt, die 
100% zuverlässig arbeiten.

[berndl (Gast)]

Bitflüsterer schrieb:
> Lothar Miller schrieb:
>> Bitflüsterer schrieb:
>>> Habe noch 'ne Nase. :-)
>> Wenn unbedingt sein muss... ;-)
>>
>>> das sind dann eben zwei Dual-Edge-FFs
>> Und wie verschaltest du die count FFs hier:
>>>     if rising_edge(A) then
>>         count <= ...
>>     elsif falling_edge(A) then
>>         count <= ...
>>     elsif rising_edge(B) then
>>         count <= ...
>>     elsif falling_edge(B) then
>>         count <= ...
>>
> Ich habe leider kein ISE hier und kann das nicht ausprobieren. Aber
> meine Idee dazu wäre, jeweils einen Abwärts- und einen Aufwärtszähler zu
> benutzen, deren Differenz am Ende gebildet wird. Auch würde am Ende
> keine Sequenz von ifs in der gezeigten Form dastehen. Eher zwei
> Prozesse.
>
> Lothar, ich weiß, solche theoretischen Einwände sind schwer
> ernstzunehmen. Wenn Du sagen willst, das es überhaupt nicht geht, auch
> nicht emuliert und mit Gebeten zum Spaghettimonster, nehme ich das mal
> unter Vorbehalt so an.

aehm, wenn ich mal einfach so davon ausgehe, dass der Drehgeber mit 
seinen Flanken weit langsamer als der FPGA-Takt ist: Was ist denn so 
schwer daran, eine gescheite Flankenerkennung mit dem FPGA-Takt zu bauen 
und dieses +1 oder -1 dann entsprechend auszuwerten?
Damit waerst du innerhalb des FPGA voll synchron.

Bei deinem Vorschlag wuerdest du mit einem externen Pseudotakt Register 
setzen/veraendern. Diese Register musst du aber erstmal aufwendig in 
deine FPGA-Taktdomaene einsynchronisieren. Merkst was? Aus einem 
Pseudotakt machst du auf einmal eine Synchronisierung von z.B. 16 
Registerbits (count).

Welche der beiden Moeglichkeiten ist denn da einfacher? Vermutlich doch 
die, die nur mit einer Leitung am Eingang zu tun hat, oder? Oder willst 
du ernsthaft behaupten, du musst das Flankensignal auf die Nanosekunde 
genau abtasten?

[Patrick B. (p51d)]

Mhm, habe mich einmal an das Muster von Lothar gehalten...

entity Decoder is
    Port ( A : in  STD_LOGIC;
           B : in  STD_LOGIC;
           Clk : in  STD_LOGIC;
           Sector : out  STD_LOGIC_VECTOR (7 downto 0));
end Decoder;

architecture Behavioral of Decoder is

-- Zustandstypen und die Zustandsvariable
type states is (Z00, Z01, Z11, Z10);
signal state : states := Z00;

-- Zählervariable
signal count : std_logic_vector(2 downto 0) := "000";

-- Variablen zum Eintakten
signal DecoderInputUnstable : std_logic_vector(1 downto 0);
signal DecoderInputStable : std_logic_vector(1 downto 0);

begin
  -- Einsynchronisieren der asynchronen Eingangssignale
  process begin
    DecoderInputUnstable <= (B, A);                      -- Zusammenfassen der Signale
    DecoderInputStable <= DecoderInputUnstable;              -- 2. Stufe
  end process;


  -- Decoder
  process(Clk)
  variable Up, Down : std_logic := '0';                    -- Lokale Variable
  begin
    if rising_edge(Clk) then
      Up := '0';
      Down := '0';
    
      -- Zustäde
      case state is
        when Z00 => if DecoderInputStable = "01" then
                  state <= Z01;
                  Up := '1';
                elsif DecoderInputStable = "10" then
                  state <= Z10;
                  Down := '1';
                end if;
        when Z01 => if DecoderInputStable = "11" then
                  state <= Z11;
                  Up := '1';
                elsif DecoderInputStable = "00" then
                  state <= Z00;
                  Down := '1';
                end if;
        when Z11 => if DecoderInputStable = "10" then
                  state <= Z10;
                  Up := '1';
                elsif DecoderInputStable = "01" then
                  state <= Z01;
                  Down := '1';
                end if;
        when Z10 => if DecoderInputStable = "00" then
                  state <= Z00;
                  Up := '1';
                elsif DecoderInputStable = "11" then
                  state <= Z11;
                  Down := '1';
                end if;
      end case;
      
      -- Zählen
      if Up = '1' then
        count <= std_logic_vector(unsigned(count) + 1);
      end if;      
      if Down = '1' then
        count <= std_logic_vector(unsigned(count) - 1);
      end if;
    end if;
  end process;

  -- Variable ausgeben
  with count select
    Sector <=   "00000001" when "000",
            "00000010" when "001",
            "00000100" when "010",
            "00001000" when "011",
            "00010000" when "100",
            "00100000" when "101",
            "01000000" when "110",
            "10000000" when "111",
            "XXXXXXXX" when others;

Beim simulieren habe ich aber keine Signale mehr. Sobald ich den Prozess 
mit dem clk und den Teil mit dem Einsynchronisieren auskommentiere, dann 
sehe ich zumindest wieder Pegel.

Mhm, das ganze ist irgendwie eine eigene Welt. Habe mitlerweile viel 
Erfahrung mit MCUs (8Bit, DSP, 16Bit, 32Bit, ARM), aber hier habe ich 
das Gefühl, als hätte ich nicht den Hauch einer Ahnung.

@Lothar
Sorry, hab wohl nicht alles gelesen. Aber ist eine interessante Seite, 
die ich gerne mal durchlese.

MFG

[Fpgakuechle K. (Gast)]

Patrick B. schrieb:
> Mhm, das ganze ist irgendwie eine eigene Welt. Habe mitlerweile viel
> Erfahrung mit MCUs (8Bit, DSP, 16Bit, 32Bit, ARM), aber hier habe ich
> das Gefühl, als hätte ich nicht den Hauch einer Ahnung.

Ja MCU in C-Programmieren ist keine Grundlage für FPGA-Entwicklung.
Was du brauchst ist ein Grundverständniss in digitaler 
Schaltungstechnik.

MfG,

[Duke Scarring (Gast)]

Patrick B. schrieb:
> eim simulieren habe ich aber keine Signale mehr.
Häng doch mal den Code und die Testbench hier ran. Dann kann man es 
selber simulieren und nachvollziehen.

Duke

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

Patrick B. schrieb:
> -- Einsynchronisieren der asynchronen Eingangssignale
>   process begin
>     DecoderInputUnstable <= (B, A);
>     DecoderInputStable <= DecoderInputUnstable;
>   end process;
Da wird nichts einsynchronisiert, weil kein Takt (=Flipflop) beteiligt 
ist. Eigentlich muss der Simulator hier rummeckern, weil nichts in der 
Sensitivliste  steht und auch kein wait im Prozess vorkommt.