USI Freqently Asked Questions

HS USI: wo wird festgelegt, welche Daten über HS USI übertragen werden?
HS USI: unter welchem FIFO/FSP landen die HS Daten?
In der USI Spezifikation wird in 4.1. auf vereinheitlichte FSPs verwiesen. Existiert dazu eine Übersicht/Definition? Können Sie uns das Dokument "ACU-FSPs_mUSIC" zukommen lassen?
Gibt es eine aktuelle Liste der Descriptoren? Detail Descriptor: 0x2 oder 0x3?
Wo bzw. worüber werden den FSPs bzw FIFOs Klartextbezeichnungen zugewiesen?
HS USI: wo wird festgelegt, welche Daten über HS USI übertragen werden?

Die zu verschickenden HigHSpeed Daten werden direkt an das mUSIc_Shell Modul angeschlossen. Bzw. per HighSpeed empfangene Daten werden dort direkt ausgegeben. Daten die ein Modul via HighSpeed senden soll werden am Port „HighSpeed_In[31..0]“ und (sofern notwendig) „HS_Ext_Bits_In[1..0]“ der mUSIc_Shell übergeben. Ist der Parameter „gShellUse_HighSpeedPort_NewDataPulse“ = ‚0‘, werden die Ports „HighSpeed_In[31..0]“ und „HS_Ext_Bits_In[1..0]“ abhängig von der gewählten Baudrate (bei 20 MBaud sind das 6us) eingelesen und über den HighSpeed Kanal verschickt. Ist „gShellUse_HighSpeedPort_NewDataPulse“ = ‚1‘, muss am Port „HighSpeedPort_NewDataPulse“ eine steigende Flanke erkannt werden damit die Daten an den Ports „HighSpeed_In[31..0]“ und „HS_Ext_Bits_In[1..0]“ übernommen werden. Diese befinden sich dann in einem Latch und werden solange immer wieder via HigHSpeed verschickt, bis eine weitere steigende Flanke an „HighSpeedPort_NewDataPulse“ neue Daten signalisiert. Jedes mal wenn Daten via HighSpeed verschickt werden, signalisiert mUSIc_Shell dies am Port „HighSpeedPort_NewDataStrobe[1]“ durch einen kurzen Puls.

Umgekehrt werden an „HighSpeed_In[31..0]“ und „HS_Ext_Bits_In[1..0]“ empfangene HigHSpeed Daten ausgegeben. Jedes mal wenn ein vollständiger und gültiger HighSpeed Wert empfangen wurde signalisiert dies „HighSpeedPort_NewDataPulse[0]“ durch einen kurzen Puls.

HS USI: unter welchem FIFO/FSP landen die HS Daten?

Die Daten werden nicht in einem FSP vorgehalten, sondern modulintern direkt verarbeitet. Die Ports „HighSpeed_In[31..0]“ und „HS_Ext_Bits_In[1..0]“ bilden dabei ein Eingabelatch, die Ports „HighSpeed_Out[31..0]“ und „HS_Ext_Bits_Out[1..0]“ ein Ausgabelatch. Siehe vorherige Frage

Welche Standardkommandos gibt es? Gibt es eine Liste dazu?

Wir verwenden die folgenden Standard Kommandos:

NOP	0x0
Kommando_Einschalten	0x1
Kommando_Ausschalten	0x2
Kommando_Reset	0x3
Kommado_ReglerSperre	0x4

Die Kommandos haben 4 Bit Datenbreite. Kommando_Einschalten darf nur ausgeführt werden, wenn das Gerät fehlerfrei ist. Kommando_Ausschalten muss in allen Zuständen durchführbar sein. Dies dann, wenn z.B. zum Einschalten eine Statemachine abläuft. Diese muss durch das Kommando unterbrechbar sein. Kommando_Reset muss zu jedem Zeitpunkt durchführbar sein. Kommado_ReglerSperre ist nur durchführbar, wenn das Gerät eingeschaltet und der Regler freigegeben ist. Andernfalls ergibt dieses Kommando keinen Sinn. Allgemein ist es so zu realisieren, dass das Gerät prinzipiell nur auf Änderungen der Kommandos reagiert. Wird z.B. das Kommando_Reset mehrfach abgesetzt ist dazwischen immer ein Dummy_NOP nötig, damit die Änderung erkannt werden kann. Auch die Kommandos Ein/Aus sollen nicht dauerhaft anstehen sondern nach kurzer Zeit von NOP abgelöst werden. Dies aus folgendem Grund: steht das Gerät auf Remote und wird per Kommando eigeschaltet, nun schaltet jemand vor Ort auf Lokalbetrieb um und schaltet dann das Gerät aus und wieder zurück auf Remote, würde evtl. das Remotekommando als Änderung erkannt und das Gerät wieder einschalten. Dies darf nicht passieren. Die von der MFU ausgegeben Kommandos werden nach ca. 100uSekunden gelöscht.

In der USI Spezifikation wird in 4.1. auf vereinheitlichte FSPs verwiesen. Existiert dazu eine Übersicht/Definition?

Hier finden Sie das Dokument „ACU-FSP_mUSIc_TFT“. Darin sind (hoffentlich) alle FSP beschrieben und wie wir diese in den Modulen einsetzen. FSP-Muss sind FSP000, FSP004 und FSP012, alle weiteren sind bei Bedarf zu implementieren. Ab FSP060 finden sich die modulspezifischen FSPs.

Gibt es eine aktuelle Liste der Descriptoren? Detail Descriptor: 0x2 oder 0x3?

Im Dokument " UnderstandingUSI " findet sich im Kapitel 6.5.2 ein Hinweis darauf wie der Descriptor 2 aufgebaut ist. Für den Entwickler und Nutzer von mUSIc ist das Füllen der Descriptoren denkbar einfach. Am Modul FSP_MDS werden die Moduldescriptoreinträge an die Eingangsports angeschlossen (Seriennummer, HW Release, FW Release und deren Datum) bzw. in die Parameterliste eingetragen (ModulClass, SubClass; VendorID, ProductID, sDescription). MaxPower ist obsolet und stammt noch aus der Zeit als es noch Power-Over-USI gab. Ist aber technisch nicht realisiert worden. Jedes Modul muss nun selbst mit Spannung versorgt werden und wird dies nicht wie geplant alternativ über USI. MaxSpeed verbleibt i.d.R. auf '1', dann unterstützt das Modul bis 20 MBaud.

An den ‚FIFOStartpointRAM‘ Ports muss ein DualPort RAM mit 256 x 32 Bit über die mUSIc_Shell ansprechbar sein. Wie das bei Lattice eingebunden wird weiß ich nicht. Ich hoffe das Lattice auch DualPort RAM unterstützt, bei XILINX war dies problemlos realisierbar. mUSIc_Shell führt nach dem Reset eine automatischen FSP Suchlauf durch. Dabei werden alle FSP eingesprochen, deren Tiefe, Nummer und Attribute gelesen und in diesem RAM gesichert. Dies bildet die Datenbank für die FSP-Descriptoren 2 die durch die MDS an den host kommuniziert werden. Dadurch müssen Sie sich um die FSPDescriptoren nicht kümmern. Auch der End-Descriptor wird automatisch gebildet. Kurz: FSP_MDS mit Infos füttern, DualPortRAM in mUSIc_Core, innerhalb von mUSIc_Shell anbinden. Das war’s für die Descriptoren. Alles andere übernimmt das FPGA.

Wo bzw. worüber werden den FSPs bzw FIFOs Klartextbezeichnungen zugewiesen?

Wir nutzen ein grafisches Blockdiagram zum verdrahten aller Instanzen in Form von Symbolen innerhalb eines Projekts. Da gibt es Parameterblöcke in den sich die Klartextbezeichnungen eintragen lassen (also quasi die Top Level Entity). Die Texte sind aber nur rein informativ und haben keinerlei Einfluss auf den FSP und dessen Funktion. Sie dienen nur dazu damit man versteht wofür ein FSP gedacht ist.

-- DerekSchupp - 2017-08-11