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?
Welche Standardkommandos gibt es? Gibt es eine Liste dazu?
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?
Wie ist die Verteilung der Interlockbits bei GSI Standardgeräten mit IFK?
Wie funktioniert die Interlockerfassung im FPGA?
Wie funktioniert die Kommando-Kommunikation?
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.

USIFaq_mUSIcShell.jpg

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.

USIFaq_MDS.jpg

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.

USIFaq_BDF.jpg

Wie ist die Verteilung der Interlockbits bei GSI Standardgeräten mit IFK?

Interlockbits3[15..0], Interlockbits2[15..0], Interlockbits1[15..0]

Bit
ArtName Überwachung
Standardtexte
Interlockbits1
[0] 0 Analog elektrisch um00 Komparator negative Spannung Mittelwert I Neg average >
1 um01 Komparator negative Spannung I Neg >
2 um02 Komparator positive Spannung Mittelwert I Pos average >
3 um03 Komparator positive Spannung I Pos >
4 Digital elektrisch um04 DCCT Fehler DCCT Error
5 -
6 -
7 -
0 Analog elektrisch um00 Lastspannung (p) U Load Pos
1 um01 Lastspannung (n) U Load Neg
2 um02 Primärspannung (p) I Primary Pos
3 um03 Primärspannung (n)ungenutzt -
4 um04 Zwischenkreis (p) Ud Pos
5 um05 Zwischenkreis (n) ungenutzt -
6 um06 Erdschluss (p) I Earth
[15] 7 um07 Erdschluss (n)ungenutzt
-
Interlockbits2
[0] 8 um08 Schwingungsüberwachung (p) Anti Oscillation
9 Digital optisch um09 IGBT1 IGBT V1
10 um10 IGBT2
IGBT V2
11 um11 IGBT3
IGBT V3
12 um12 IGBT4
IGBT V4
13 um13 IGBT5
IGBT V5
14 um14 IGBT6
IGBT V6
15 um15 - UNUSED
16 um16 - UNUSED
17 um17 Quench Detection Quench Detection
18 Digital elektrisch um18 Hauptschütz
Main contactor
19 um19 Sicherheits-Aus Fast Off
20 um20 Wasser Netzgerät Cooling H2O PSE
21 um21 Versorgungsspannung
Main Voltage
22 um22 Sicherungen
Fuses
[15] 23 um23 Temperatur Netzteil (Kühlbank)
PSU Temperature
Interlockbits3
[0] 24 um24 Wasser Magnet Magnet H2O
25 um25 Temperatur Magnet Magnet Temperature
26 um26 Temperatur Transformator Transformer Temperature
27 um27 Wasser Netzteil (Kühlbank)
PSU H2O
28 Wasserdurchflusskontrolle um28 Wasserdurchflussüberwachung1 WaterFlow01
29 um29 Wasserdurchflussüberwachung2
WaterFlow02
30 USI HighSpeed um30 USI HighSpeed Abbruch USI Highspeed
31 um31 - UNUSED
- - - -
- - - -
- - - -
- - - -
- - - -
- - - -
- - - -
[15] - - - -

Wie funktioniert die Interlockerfassung im FPGA?

In der Regel werden Interlocks immer per Hardware auf dem entsprechenden Modul erfasst. Diese Hardwareerfassung soll die Reißleine betätigen. Die zusätzliche Erfassung der Interlocks im FPGA dient dazu Interlockinformationen an die MFU senden zu können. Dabei ist es möglich die FPGA interne Interlockerfassung durch den Nutzer zu beeinflussen. Jedes von der Hardware kommenden Interlocks wird über einen zugehörigen Schalter (MskP: capture pending interlock) als aktuell anstehendes Interlock und parallel dazu über ein Latch und einen weiteren Schalter (MskM: memorize pending interlock) als gespeichertes Interlock an die MFU übertragen. Abhängig von den Schalterstellungen ist es möglich diese Informationen für die MFU ein- oder auszumaskieren.

Wichtig hierbei ist, dass die gespeicherten Interlocks diejenigen sind, die über das FPGA ebenfalls die Reißleine bedienen. Wird also bei einem Interlock die Speicherfunktion maskiert, wird dieses Interlock nicht die Summenreißleine bedienen.

Das Zusammenspiel zwischen den aktuell anstehenden und den maskierten Interlocks in Bezug auf deren Konfiguration findet sich tabellarisch in MFUSoftwareChangeLog. Siehe dort MFU Nios Software Version 007.00003.

Interlockfunktion.jpg

Wie funktioniert die Kommando-Kommunikation?

Betrachtung aus Sicht der MFU.
Das Signal „Kommando Eingabe“ kommt entweder über die Backplane oder USB.
Das Signal „Kommando Ausgabe“ ist an folgende Bedingungen geknüpft:

Status Bedingung(en) Kommando Eingabe Kommando Ausgabe Bemerkung
X cCMDSwitchUnitOff cCMDSwitchUnitOff steht über allem
X Kommando Eingabe <> cCMDSwitchUnitOff cCMDResetUnit cCMDResetUnit Wird keine Kommando cCMDSwitchUnitOff ausgeführt, steht cCMDResetUnit über allem
cSTATUSSetDefaults X cCMDNoAction
cSTATUSResetInterlocks
cSTATUSUnitOff - alle Reißleinen OK
- keine Interlocks anstehend (CPU)
- Parameter gültig (CPU)
- Module verifiziert (CPU)
- es wird kein Resetkommando ausgeführt*)
cCMDSwitchUnitOn ggf. cCMDSwitchUnitOn sofern alle Bedingungen erfüllt sind, sonst wird Kommandoeingabe ignoriert
cCMDResetUnit cCMDResetUnit wird immer ausgeführt
cSTATUSLoadingBank X anstehendes Kommando Ausgabe des Kommandos ändert sich in diesem Status nicht
cSTATUSSwitchingUnitOn X cCMDNoAction
cSTATUSUnitOn cCMDSwitchUnitOn
cCMDSwitchUnitOff
cCMDResetUnit 
sExecuteCommand Abhängig von Kommando Eingabe wird sExecuteCommand zu einer der Kommando Eingaben
cSTATUSControllerEnabled - Parameter Prüfsumme
- Reglerfreigabe (siehe Bemerkungen)
- keine Interlocks anstehend (CPU)
- Parameter gültig (CPU)
- Module verifiziert (CPU)
- Bootsequenz komplett (CPU)
cCMDSwitchUnitOn
cCMDSwitchUnitOff
cCMDResetUnit
cCMDControllerLocked
sExecuteCommand Sofern alle Bedingungen erfüllt sind wird abhängig von Kommando Eingabe sExecuteCommand zu einer der Kommando Eingaben EIN/AUS/RESET. Andernfalls wird sExecuteCommand = cCMDControllerLocked
cSTATUSControllerDisabled - Parameter Prüfsumme
- Reglerfreigabe (siehe Bemerkungen)
- keine Interlocks anstehend (CPU)
- Parameter gültig (CPU)
- Module verifiziert (CPU)
- Bootsequenz komplett (CPU)
STATUSSwitchingUnitOff X anstehendes Kommando
cSTATUSControllerDisabledbySoftware cCMDSwitchUnitOn
cCMDSwitchUnitOff
cCMDResetUnit
cCMDControllerLocked
ExecuteCommand Ist Reglerfreigabe = 1 wird abhängig von Kommando Eingabe sExecuteCommand zu einer der Kommando Eingaben EIN/AUS/RESET. Andernfalls wird sExecuteCommand = cCMDControllerLocked
cSTATUSControllerDisabledExternal cCMDSwitchUnitOn
cCMDSwitchUnitOff
cCMDResetUnit
ExecuteCommand Abhängig von Kommando Eingabe wird sExecuteCommand zu einer der Kommando Eingaben
*) die Ausführung des Resetkommandos wird bei drücken der RESET Taste gestartet und dauert „gResetTripLinesExtensionIn_mSeconds“
Alle übrigen Kommandos werden mit „gCommandExtensionIn_uSeconds“ ausgegeben. Danach wechselt das Kommando automatisch zurück auf ‚cCMDNoAction‘.

-- DerekSchupp - 2017-08-11
Topic revision: r9 - 2018-11-23, DerekSchupp
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding GSI Wiki? Send feedback
Imprint (in German)
Privacy Policy (in German)