Nexys 4 DDR - accelerometer/Beschleunigungssensor

[Karlsson (Gast)]

Hallo zusammen,

ich möchte auf meinem Nexys 4 DDR gerne den on-board 
Beschleunigungssensor nutzen. Dieser kommuniziert über eine 
SPI-Schnittstelle mit dem FPGA.

Nach einigen Versuchen habe ich in der Simulation nun diese Waveforms 
erhalten (siehe Anhang).

Zu den Waveforms:
Der Sensor soll als erstes eingeschaltet werden, daher ein Write-Befehl 
("00001010") für das Power-Register ("00101101") mit den Daten "0000
0010". Hier nach sollte der Sensor anfangen die Beschleunigungen zu 
messen.
Als nächste möchte ich dann das Register mit den X-Beschleunigungen 
auslesen. Dazu ein Read-Befehl ("00001011") für das Register "00001000". 
Schließlich warte ich nur noch auf die Daten, die über den MISO-Kanal 
reinkommen. Diese Bits sollen dann in ein Register geschoben werden und 
über die LEDs auf dem Board ausgegeben werden.
In der Testbench habe ich dazu einfach ein paar Bits auf MISO gelegt und 
geschaut, ob die Bits auch im Vektor der LEDs auftauchen.
Den SCLK-Takt habe ich auf 1MHz gesetzt (in den Waveforms ist es der 
Übersichtlichkeit halber ein anderer (25MHz)).
Das CS-Signal (Chipselect) passt meines Erachtens auch zur Übertragung.

Mache ich irgendwas grundlegend falsch (ist meine erste 
SPI-Schnittstelle)? Falls noch weitere Informationen gebraucht werden, 
einfach kurz schreiben.

Hier noch der Link zu Datenblatt des Sensors:
https://www.analog.com/media/en/technical-documentation/data-sheets/ADXL362.pdf
Und der zu dem Datenblatt des Nexys:
https://reference.digilentinc.com/_media/nexys4-ddr:nexys4ddr_rm.pdf

Bin für jede Anmerkung dankbar!
Euer Karlsson

[Karlsson (Gast)]

Achso und auf dem Board leuchten bei Bewegung KEINE LEDs.

[Burkhard K. (buks)]

Fragen:
* wieso bleibt in Deiner Simulation der System-Takt (clk) bei ca. 1800 
ns stehen???
* Verdächtige Meldungen/Warnungen bei der Synthese?
* Du hast den Beispielcode von Digilent für das Auslesen des AXL in der 
Nexys4-DDR Demo gefunden?

Karlsson schrieb:
> Achso und auf dem Board leuchten bei Bewegung KEINE LEDs.

Oder sie leuchten so kurz auf, dass Du es nicht siehst? Grundsätzlich 
kann alles mögliche passieren - oder eben auch nicht, ob Dein 
Peripheriegerät mit Dir kommuniziert oder nicht, kannst Du sehen, wenn 
Du die SPI-Signale auf einen Pmod nach außen führst und mit einem 
Logic-Analyzer (zur Not mit einem Oszi) anschaust. Ob Deine Prosa 
Beschreibung sich mit dem Synthese-Ergebnis deckt, lässt sich nur anhand 
des Source-Codes überprüfen.

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

Karlsson schrieb:
> Nach einigen Versuchen habe ich in der Simulation nun diese Waveforms
> erhalten (siehe Anhang).
Irgendwie passt das ja nicht so richtig zu dem Timing, das im Datenblatt 
des Sensors gefordert wird. Im Datenblatt sind MOSI und MISO bei der 
steigenden SCLK-Flanke stabil. Bei deiner Waveform ändern sie sich genau 
da, obwohl tsu und thd eigentlich jeweils mindestens 20ns sein müssen. 
Du hast also schon mal die falsche Phase.

Warum hält die Simulation mitten in der Übertragung an?

Karlsson schrieb:
> Achso und auf dem Board leuchten bei Bewegung KEINE LEDs.
Du wirst da sowieso mit einem LogicAnalyzer oder einem Speicheroszi ran 
müssen, um zu kontrollieren, ob die Realität das macht, was die 
Simulation verspricht.

Karlsson schrieb:
> in den Waveforms ist es der Übersichtlichkeit halber ein anderer
Warum? Die Waveform kann man doch beliebig zoomen und den FPGA Takt 
ausblenden, wenn der grüne Balken stört...

------------------------------------------------------------------------ 
--

EDIT: Eine Anmerkung zum Screenshot vom Datenblatt findet sich dort im 
Beitrag "Re: Nexys 4 DDR - accelerometer/Beschleunigungssensor"

[Jürgen S. (engineer)]

Versuche mal, ein SPI-Slave Modell dranzuhängen und zu schauen, ob das 
überhaupt stimmig ist. Dann wäre mal die Antwort des realen Slaves 
aufzuzeichnen. (OSCI)

[Gustl B. (-gb-)]

Been there, done that.

https://gus.tl/fpga

https://gus.tl/fpga/nexys4_accel_sim.zip

Da ist eine Beschreibung samt Testbench. Oder auch im Anhang.

[Karlsson A. (karlsson)]

> Irgendwie passt das ja nicht so richtig zu dem Timing, das im Datenblatt
> des Sensors gefordert wird. Im Datenblatt sind MOSI und MISO bei der
> steigenden SCLK-Flanke stabil. Bei deiner Waveform ändern sie sich genau
> da, obwohl tsu und thd eigentlich jeweils mindestens 20ns sein müssen.
> Du hast also schon mal die falsche Phase.
Ohja, stimmt! Habe ich nun geändert (siehe Anhang).

> Warum hält die Simulation mitten in der Übertragung an?
Wollte ja nur sehen, ob die Bits überhaupt reingeshifted werden. Habe 
ich jetzt aber auch mal angepasst.

> Du wirst da soweiso mit einem LogicAnalyzer oder einem Speicheroszi ran
> müssen, um zu kontrollieren, ob die Realität das macht, was die
> Simulation verspricht.
Ich habe leider weder einen LogicAnalyzer noch ein Oszi...
Ich habe jetzt ein weiteres Register eingebaut, welches sich zweimal die 
Sekunde updatet (das sollte man ja mit dem Auge sehen können).

> Warum? Die Waveform kann man doch beliebig zoomen und den FPGA Takt
> ausblenden, wenn der grüne Balken sört...
Ja, stimmt schon.

Es funktioniert immer noch nicht. Meine Vermutung ist gerade, dass ich 
t_CSH nicht einhalte (siehe Datenblatt). Bin noch am tüfteln, wie ich 
das umsetze...
Oder kann ich nach dem PowerOn einfach direkt den read-Befehl 
nachschicken, ohne vorher CS noch einmal auf high zu setzen?

Schon mal vielen Dank!

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

Karlsson A. schrieb:
> ohne vorher CS noch einmal auf high zu setzen?
Nein. SS# ist für die Kommunikation zwingend notwendig. Jeder Transfer 
wird mit SS# umrahmt. SS# zeigt an, wann eine Übertragung beginnt und 
wann die Daten übernommen werden können.
> ohne vorher CS noch einmal auf high zu setzen?
Mach es einfach so wie im Datenblatt beschrieben. Dort steht, man müsse 
SS# zwichen zwei Übertragungen für mindestens 20ns auf high setzen.

> Ich habe leider weder einen LogicAnalyzer noch ein Oszi...
Im Prinzip braucht man eigentlich beides: das Oszi zum Bewerten der 
Signalqualität (Potentiale, Flanken, Überschwinger, Spikes, ...) und den 
LA zum Analysieren des Protokolls.
Wenn du kein Oszi hast, dann kannst du mit kurzen Leitungen und 
technisch gutem Aufbau vermutlich die Signalqualität ausreichend gut 
hinbekommen. Ob die Pegel passen, solltest du allerdings trotzdem mal 
statisch mit dem Multimeter nachmessen.
Und dann kauf dir bei Ebay so einen 8-Kanal-LA für 10€. Ohne Oszi und 
ohne LA ist die Inbetriebnahme einer seriellen Schnitte so ähnlich wie 
Autofahren nach Gehör: kann mit viel Glück gutgehen...

> Es funktioniert immer noch nicht
Was denn? Was erwartest du und was tut sich stattdessen?

Und im Zweifelsfall musst du eben "Divide et impera!" anwenden und 
zuerst mal sicherstellen, dass aus deinem FPGA überhaupt was rauskommt 
und reingeht:
was passiert denn, wenn du den ADXL abklemmst, und du dann MISO dauernd 
auf High oder Low klemmst?
Und was passiert, wenn du ohne ADXL den MOSI auf MISO brückst und dann 
z.B. 0x55 0xaa 0x5a sendest? Bekommst du eines der drei Bytes wieder 
"zurück"?

> Es funktioniert immer noch nicht
Ich kann leider mangels deinem Code nicht beurteilen, was da passieren 
könnte/würde/sollte...

[Karlsson A. (karlsson)]

Ok, ich werde mir dann doch mal einen LA anschaffen.

Vielen Dank! :D

[Gustl B. (-gb-)]

Karlsson A. schrieb:
> Ok, ich werde mir dann doch mal einen LA anschaffen.

Nein, den brauchst du dazu nicht. Die Simulation reicht. Aber noch 
wichtiger ist es das Datenblatt 
https://www.analog.com/media/en/technical-documentation/data-sheets/ADXL362.pdf 
zu lesen.

Wenn ich deinen Screenshot der Simulation sehe dann sendest du die 
falsche Instruktion. Die sollte immer mit 00001 beginnen, bei dir sind 
es aber 5 mal die Null. Auf weitere Fehler habe ich nicht geguckt.

Lothar M. schrieb:
> Wenn du kein Oszi hast, dann kannst du mit kurzen Leitungen und
> technisch gutem Aufbau vermutlich die Signalqualität ausreichend gut
> hinbekommen. Ob die Pegel passen, solltest du allerdings trotzdem mal
> statisch mit dem Multimeter nachmessen.

Ähm ... das ist ein fertiges FPGA Board auf dem der Sensor verbaut ist. 
Da hat der Fragende hier nix selber gelötet. Es interessiert also nur 
das Timing und das was da gesendet wird, das kann er simulieren.

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

Gustl B. schrieb:
> Ähm ... das ist ein fertiges FPGA Board auf dem der Sensor verbaut ist.
Ja, da muss er die Signalintegrität tatsächlich nicht prüfen. Das haben 
schon andere gemacht. Trotzdem ist so ein LA in der Schublade 
langfristig recht nützlich.

> Es interessiert also nur das Timing und das was da gesendet wird, das
> kann er simulieren.
Wenn das Design hübsch synchron aufgebaut ist. Denn wir sehen ja nicht, 
ob da irgendwelche Tricks drin sind, deren Seitenwirkungen eine 
funktionale Simulation nicht zeigt.

> Aber noch wichtiger ist es das Datenblatt zu lesen.
Und es zu verstehen und es anzuwenden, denn natürlich muss dann auch der 
Rest der Simulation erst mal zum Datenblatt passen. Und demzufolge auch 
der MISO nicht bei der fallenden Flanke, sondern bei der steigenden SCLK 
Flanke eingelesen werden. Denn dieser Baustein speichert Daten bei der 
steigenden Flanke.

> Aber noch wichtiger ist es das Datenblatt zu lesen.
Zum Thema "Datenblatt lesen und verstehen": wenn man das DB verstanden 
hat, findet man dann auch leichter die Fehler, die darin versteckt sind 
(siehe angehängter Screenshot)... ;-)

[Karlsson A. (karlsson)]

> Nein, den brauchst du dazu nicht. Die Simulation reicht. Aber noch
> wichtiger ist es das Datenblatt
> https://www.analog.com/media/en/technical-documentation/data-sheets/ADXL362.pdf
> zu lesen.
Ok, hatte ich eigentlich auch gedacht.


> Wenn ich deinen Screenshot der Simulation sehe dann sendest du die
> falsche Instruktion. Die sollte immer mit 00001 beginnen, bei dir sind
> es aber 5 mal die Null. Auf weitere Fehler habe ich nicht geguckt.
Ohh upps... danke :D

Ich hab mir deinen Code auch mal angesehen. Du zählst ja scheinbar die 
Flanken und sendest entsprechend die Bits raus, oder?

[-gb- (Gast)]

Ja. Mein Code ist nicht besonders toll oder so, aber das Prinzip ist für 
Bausteine mit SPI sehr einfach.

Man nimmt einen Zähler. Das/eines der untersten Bits wird die SPI Clock. 
Und in Abhängigkeit der höheren Bits werden Daten raus gegeben oder 
eingelesen.

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

Karlsson A. schrieb:
> Du zählst ja scheinbar die Flanken und sendest entsprechend die Bits
> raus, oder?
Richtig, da wird beim Ausgeben und beim Einlesen jeweils ein Multiplexer 
verwendet.
Ich mache das nur bei CPLDs, weil die gewaltige Produktterme haben, die 
einen Multiplexer leicht machen. In FPGAs nehme ich normalerweise 
Schieberegister, weil dort die Flipflops recht effizient verbunden 
werden können:
http://www.lothar-miller.de/s9y/categories/45-SPI-Master