[Fehlersuche] Ansteuerung eines 1-Wire Sensors

[A. M. (am85)]

Hi

Ich will/muss einen 1-Wire Temperatursensor ansprechen und auslesen. Für 
die einzelnen Schritte, die dafür notwendig sind, habe ich mir zwei 
Zustandsautomaten geschrieben. Einen, der die groben Arbeitsschritte 
beschreibt und einen, der das Lesen und Schreiben auf dem Bus sowie die 
Einhaltung der Timings übernimmt. Der Code ist noch nicht ganz 
vollständig, sollte aber alles wesentliche vom Funktionsumfang her 
abdecken. Er wird zwar synthetisiert und auch das Bitfile wird erstellt, 
aber leider nur mit massig Warnings. Die will ich gerne loswerden, ich 
habe nur ein bisschen den Überblick verloren, weswegen ich mich freuen 
würde, wenn ihr einmal einen Blick auf mein Design werfen würdet. Für 
konstruktive Tipps aller Art bin ich sehr dankbar. Falls noch 
Informationen fehlen sollten, reiche ich die natürlich gerne nach.

Hier einmal die Warnings, die bei der Synthese ausgeworfen werden. Ich 
vermute, dass sich irgendwo eine Sackgasse entwickelt hat, ich sehe aber 
leider gerade nicht wo.

WARNING:Xst:646 - Signal <INPUT> is assigned but never used. This unconnected signal will be trimmed during the optimization process.
WARNING:Xst:737 - Found 4-bit latch for signal <BIT_SEND>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 5-bit latch for signal <BIT_READ>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 16-bit latch for signal <INPUT_BUFFER>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 8-bit latch for signal <FSM_F_ZUSTAND>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 8-bit latch for signal <OUTPUT_BUFFER>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 6-bit latch for signal <TRX_F_ZUSTAND>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 8-bit latch for signal <OUTPUT>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 3-bit latch for signal <PRESENCE_WAIT>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:1426 - The value init of the FF/Latch 0 hinder the constant cleaning in the block 0.
   You should achieve better results by setting this init to 0.
WARNING:Xst:1426 - The value init of the FF/Latch 0 hinder the constant cleaning in the block LPM_LATCH_29.
   You should achieve better results by setting this init to 0.

Schon einmal vielen Dank für jede Hilfe.
Schöne Grüße

[Duke Scarring (Gast)]

André M. schrieb:
> Für konstruktive Tipps aller Art bin ich sehr dankbar.
Wie sieht es mit einer Testbench und einer Simulation aus?
Erst wenn meine Designs im Simulator laufen (und die gewünschte Funktion 
zeigen) kommen sie auf die Hardware.

Duke

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

André M. schrieb:
> Ich vermute, dass sich irgendwo eine Sackgasse entwickelt hat
Jawoll, hier haben wir sie wieder, die kombinatorische Schleife in Form 
von Zählern:

   PRESENCE_WAIT <= PRESENCE_WAIT + 1;
    :
   BIT_READ <= BIT_READ + 1;
    :
   BIT_SEND <= BIT_SEND + 1;

http://www.lothar-miller.de/s9y/categories/36-Kombinatorische-Schleife

Und zur Verschärfung mal was neues:
ein kombinatorisches Schieberegister...  :-o

   INPUT_BUFFER <= DQ_SYNC & INPUT_BUFFER(15 downto 1);

Als Gedankenanregung: sowas gehört immer in den getakteten Teil einer 
FSM.

Duke Scarring schrieb:
> Wie sieht es mit einer Testbench und einer Simulation aus?
Blöd, dass sowas von der Simulation nicht sicher erkannt wird. 
"Irgendwie" kann das mit der passenden Sensitivliste nämlich sogar 
funktionieren...

[Duke Scarring (Gast)]

Lothar Miller schrieb:
> "Irgendwie" kann das mit der passenden Sensitivliste nämlich sogar
> funktionieren...
Ja, darauf bin ich auch schonmal reingefallen. Aber hier hatte ich mir 
den Code noch garnicht angeguckt.

Duke

[A. M. (am85)]

Danke schon einmal für eure schnellen Antworten.

Duke Scarring schrieb:
> André M. schrieb:
>> Für konstruktive Tipps aller Art bin ich sehr dankbar.
> Wie sieht es mit einer Testbench und einer Simulation aus?
> Erst wenn meine Designs im Simulator laufen (und die gewünschte Funktion
> zeigen) kommen sie auf die Hardware.
>
> Duke

Ich habe leider absolut keine Ahnung, wie ich dynamisches Zeitverhalten 
einer externen Quelle in eine statische Simulation bringen soll. Evtl. 
hätte eine Simulation schon deutlich gemacht, wo auf jeden Fall nach 
Fehlern zu suchen ist. Für mich war aber der Weg über das 
Synthesewerkzeug und dessen Auswertung naheliegender, da auch in der 
Simulation vieles nachhinten los gehen kann, wie Lothar auch schon 
angemerkt hat.

Lothar Miller schrieb:
> André M. schrieb:
>> Ich vermute, dass sich irgendwo eine Sackgasse entwickelt hat
> Jawoll, hier haben wir sie wieder, die kombinatorische Schleife in Form
> von Zählern:   PRESENCE_WAIT <= PRESENCE_WAIT + 1;
>     :
>    BIT_READ <= BIT_READ + 1;
>     :
>    BIT_SEND <= BIT_SEND + 1;
> http://www.lothar-miller.de/s9y/categories/36-Komb...

Ich habe mir deine beiden Artikel durchgelesen. Nun weiß ich aber noch 
nicht, wie ich die Lösung deiner Beispiele auf meinen Fall übertragen 
kann. Nehme ich jeweils ein zweites Signal, schreibe z.b. "NEXT_BIT_SEND 
<= BIT_SEND + 1" im kombinatorischen Prozess und im getakteten Prozess 
"BIT_SEND  <= NEXT_BIT_SEND", dann führt das im Wesentlich zu den selben 
Warnings.

Das kombinatorische Schieberegister liese sich wohl leicht beseitigen, 
indem die von dir zitierte Zeile "einfach" in einen getakteten Prozess 
wandert, oder?

Schöne Grüße

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

André M. schrieb:
> schreibe z.b. "NEXT_BIT_SEND <= BIT_SEND + 1" im kombinatorischen Prozess
> und im getakteten Prozess "BIT_SEND  <= NEXT_BIT_SEND", dann führt das im
> Wesentlich zu den selben Warnings.
Glaube ich nicht. Zeig mal den Code und die zugehörigen Warnungen...

BTW:

constant READ_SCRATCHPAD  : std_logic_vector(7 downto 0) := "10111110"; --BEh

Das könntest du intuitiver auch so schreiben:

constant READ_SCRATCHPAD  : std_logic_vector(7 downto 0) := 0x"BE";

[A. M. (am85)]

Lothar Miller schrieb:
> André M. schrieb:
>> schreibe z.b. "NEXT_BIT_SEND <= BIT_SEND + 1" im kombinatorischen Prozess
>> und im getakteten Prozess "BIT_SEND  <= NEXT_BIT_SEND", dann führt das im
>> Wesentlich zu den selben Warnings.
> Glaube ich nicht. Zeig mal den Code und die zugehörigen Warnungen...

WARNING:Xst:646 - Signal <SEND_8BIT> is assigned but never used. This unconnected signal will be trimmed during the optimization process.
WARNING:Xst:646 - Signal <INPUT> is assigned but never used. This unconnected signal will be trimmed during the optimization process.
WARNING:Xst:737 - Found 3-bit latch for signal <NEXT_PRE_WAIT>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 4-bit latch for signal <NEXT_BIT_SEND>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 5-bit latch for signal <NEXT_BIT_READ>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 16-bit latch for signal <INPUT_BUFFER>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 8-bit latch for signal <FSM_F_ZUSTAND>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 8-bit latch for signal <OUTPUT_BUFFER>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 6-bit latch for signal <TRX_F_ZUSTAND>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 8-bit latch for signal <OUTPUT>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:1426 - The value init of the FF/Latch 0 hinder the constant cleaning in the block 0.
   You should achieve better results by setting this init to 0.
WARNING:Xst:1426 - The value init of the FF/Latch 0 hinder the constant cleaning in the block LPM_LATCH_33.
   You should achieve better results by setting this init to 0.

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

André M. schrieb:
> Found ... latch for signal ...
Nun, das ist der Klassiker bei einem kombinatorischen Prozess, der keine 
Defaultzuweisungen hat. Sowas also:

TRX_FSM: process(TRX_ZUSTAND, READ_EN, WRITE_EN, ..., PRESENCE_WAIT)
begin
  MU_CLK_EN <= '0'; -- diese Signale haben noch eine Defaultzuweisung
  DQ        <= '1';
  IDLE_EN   <= '0';
  
  NEXT_PRE_WAIT <= PRESENCE_WAIT; -- für alle angemoserten Signale fehlt diese Defaultzuweisung... :-o

  case TRX_ZUSTAND is
    :

Dein Problem ist, dass du Ein-Prozess-Schreibweise (wo solche 
unvollständigen case- bzw. if- Pfade absolut ungestraft möglich sind) 
auf eine 2-Prozess-Schreibweise anwendest...
Lies dir das mal durch, und du wirst deine Probleme wieder finden:
http://www.lothar-miller.de/s9y/archives/43-Ein-oder-Zwei-Prozess-Schreibweise-fuer-FSM.html

[A. M. (am85)]

So, ich habe mittlerweile den Code um die nötigen Defaultzuweisungen 
ergänzt und u.a. auch die Schiebeoperationen in den getakteten Prozess 
der FSM gepackt und offensichtlich ist mein Synthesewerkzeug jetzt 
zufrieden. Noch ist das Design nicht fertig, aber die geposteten 
Probleme scheinen offensichtlich behoben zu sein. Ich melde mich noch 
mal, falls weitere Probleme auftauchen. Bis dahin aber erstmal vielen 
Dank für die Hilfe :-)