Aktuelles

[20.12.2016 Im CAN Interface Hassards auf Rx-Fehlern im Tx unterbunden]

[30.11.2016 Im Timer Compare Hassards am Ausgang bei der Erzeugung von Tonfrequenzen beseidigt]

Testprogramme mit Impusbreiten Modulation zur Helligkeits Steuerung einer LED und zur Tonfrequenz Erzeugung in einem Melodie Gong erstellt.

[01.11.2016 Fehler im IIC Interface beseitigt]

Durch den Fehler im IIC Slave konnte nur mit 400 kHz gearbeitet werden. Mit der Änderung arbeitet der Test in allen Varianten mit mehr als 1000kHz Datenrate. Auf dem SP601 konnten maximal 3000 kHz erreicht werden.

[29.08.2016 Fehler im Timer Compare beseitigt]

Durch Vergleich mit einem nicht synchronisiertem Register war die Funktion am Ausgang des Moduls instabil.

[19.07.2016 SPI Master und Slave auf 18 Bit Schieberegister umgestellt]

Das SPI-Interface ist jetzt kopatibel zu der Version aus Darmstadt mit den aktuellen Erweiiterungen aus Dresden. Zum Test wurde mit dem Pragramm aus Darmstadt ein Display OLED25664 angesteuert. SPI-Testprogramme wurden erstellt. Das Einschalt RESET wurde auf den Normwert von 20ms verlängert um damit direckt das OLED25664 Display beim Start rücksetzen zu können.

[27.05.2016 SpartanMC GCC 445 GIT Verzeichnisse im https://fusionforge.zih.tu-dresden.de/ angelegt]

[05.05.2016 Aktuelle SpartanMC Projecte von ss17 im GIT https://fusionforge.zih.tu-dresden.de/ angelegt]

[05.12.2015 Web-Seiten zum SpartanMC Project in HTML Konvertiert und auf http://wwwpub.zih.tu-dresden.de/~ss17/ verschoben.]

Die Seiten zum Projekt sind unter http://wwwpub.zih.tu-dresden.de/~ss17/forschung-spartanmc/www.mr.inf.tu-dresden.de/forschung/spartanmc/index.html und die Wiki Seiten unter http://wwwpub.zih.tu-dresden.de/~ss17/wiki/www.mr.inf.tu-dresden.de/wiki/tiki-index3f78.html zu erreichen.

[30.11.2015 SpartanMC GIT Verzeichnisse im https://fusionforge.zih.tu-dresden.de/ angelegt]

[03.08.2015 GIT Projekte und SpartanMC schoene master] CAN-Interface arbeitet alle Tests fehlerfrei ab.

Nach der Realisierung der Tests für den Empfang von Nachrichten im letzten Jahr durch Friedeman Wulff-Woesten wurden die Tests mit den gleichen *.case Dateien jetzt auch für das Senden realisiert. Dabei wurden noch Fehler bei der Bildung des Stuff Bits im CRC und andere Fehler gefunden. Bei der Ausführung der Tests mit 1000 kB/s wurde die Datenübertragung sehr unsicher, da nur über 7 Zeitquanten Synchronisiert werden musste. Daraufhin wurde der CAN-clk von 14MHz auf 28MHz erhöht wodurch nun 14 Zeitquanten zur Synchronisation bereitstehen. Im Ergebnis arbeitet jetzt auch die Datenübertragung mit 1000kB/s bei den Tests 4.1.case, 4.2.case und 5.case ohne Fehler. Bei der großen Anzahl der Testnachrichten in diesen Tests ist es vorher immer an unterschiedlichen Stellen zum Abbruch gekommen.

[30.04.2015 GIT Projekte schoene master] showmem und showregs wieder im VSIM nutzbar.

Im SIM Verzeichnis von Test1 auf dem memec_lc konnten die beiden Kommandos wieder erfolgreich in der Datei testbench.udo implementiert werden. Die Werteingaben können jetzt dezimal oder hexadezimal erfolgen. Hexadezimalen Werten muss bei der Eingabe ein 0x vorangestellt werden.

[17.03.2015 GIT Branch schoene master] DI Stoerimpulse im SFR verhindert.

Seit der Einführung des asynchronen Rücksetzens vom Interrupt Enable, kam es ab der 14er ISE Versionen zu einem ungewollten Rücksetzen der Interrupt Freigabe bei hohen Takt Frequenzen. Dieser Fehler wird jetzt verhindert und die Versionen funktionieren auch noch bei Frequenzen die größer sind als die maximale vom ISE ermittelte Takt Frequenz.

[10.03.2015 GIT Branch schoene master] ChipScope für SpartanMC

Nachdem schon Ende 2013 von Rico die Generierung von IP-Cores in das make System eingebaut wurde, gibt es jetzt auch einen IP-Core der im SpartanMC ifid.v eingebunden ist und mit einem Schalter "ChipScope" im jConfig aktiviert werden kann. Er verbessert das Debuggen von Programmen für den SpartanMC.

[19.02.2015 GIT Branch schoene master] Interrupcontroller intr_ctrlp bleibt nicht mehr hängen.

Änderungen

• Das Incremetieren der Anzahl der aktuell geschachtelten ISR Aufrufe erfolgt jetzt mit dem Signal run_intr

Auswirkungen
In der alten Variante wurde das Increment aus dem Prozessor Interruptsignal abgeleitet. Dabei sind gelegentlich beim Start einer ISR zwei Impulse entstanden. Mit der Verwendung des im SpartanMC Steuerwerk erzeugten Signals run_intr wurde dieser Fehler beseitigt.

[28.01.2015 GIT Branch schoene master] Verbesserung der Funktion für die Befehle SBITS und CBITS, Optimierung der Interruptbehandlung und Verbesserung der Interruptcontroller.

Änderungen

• Vermeidung von Hazards in der Logik der Befehle SBITS und CBITS.
• kürzere Interruptbehandlung.
• Synchronisation der Interruptsignale mit clk_peri in den Interruptcontrollern um Fehler bei der Bestimmung der Priorität zu verhindern.
• Im intr_ctrlp ist jetzt im Register INT_PRI in den Bits 10-8 die Anzahl der aktuell geschachtelten ISR Aufrufe und in den Bits 7-0 die Nummer des aktuellen Inerrupts mit der höchsten Priorität verfügbar.

Auswirkungen
Die Freigabe von Interrupts wird damit sicherer, der Fehler im ISE 14.7 wird aber nur verringert. Bei der maximalen Taktfrequenz für eine Konfiguration ist die Freigabe der Interrupts nicht immer wirksam obwohl die Übersetzung mit "All constraints were met:" beendet wurde.

[18.08.2014 GIT Branch schoene master] SpartanMC Core mit Einzelschritt oder Umschaltung zwischen 2 CLK-Frequenzen.

Änderungen
Bei einer Implementierung des SpartanMC mit 3 Port Register File stehen jetzt drei Signale zur Verfügung, mit denen der Systemtakt angehalten oder auf eine niedrigere Frequenz zur Laufzeit umgeschaltet werden kann. Damit ist es jetzt möglich die CPU anzuhalten, während eine spezielle IO-Komponente Daten im Speicher erzeugt. Es kann aber auch zur Laufzeit auf eine niedrigere Taktfrequenz umgeschaltet werden, um langsame Funktionseinheiten direkt ansprechen zu können. Die drei neuen Signale sind:

1. step_en_off Durch einen High-Impuls wird in den normalen Betriebsmode umgeschaltet.
2. step_en_on Durch einen High-Impuls wird in den STEP-Mode umgeschaltet.
3. step Mit jeder low-high Flanke an diesem Eingang wird ein Takt für den SpartanMC freigegeben.

Zum Test wurde step_en_off und step_en_on je mit einem high-aktiven Taster vom SP601 verbunden und an step wurde der Ausgang eines Timer Moduls gelegt, welcher eine Frequenz von 3,86MHz aus den 27MHz des SP601 erzeugt. Das Testprogramm wurde dann bei Druck auf den Taster für step_en_on mit 3,86MHz abgearbeitet und nach Druck auf den Taster für step_en_off mit der Systemtaktfrequenz von 62,5MHz.
Auswirkungen
In bestehenden Projekten kommt es wegen den 3 neuen Signalen zu Warnungen im jConfig. Die drei Signale sollten dann am besten mit GND verbunden werden.

[11.10.2013 GIT Branch schoene new_pipe] LCD-Ansteuerung ist jetzt wieder möglich.

Änderungen
Der in Assembler geschriebene Treiber zur Ansteuerung von LCD-Modulen wurde auf den GNU-Assembler umgestellt und unter spartanmc/lib_obj/src/peri/lcd.s für die Nutzung mit dem GCC bereitgestellt. Die bereitgestellten C-Funktionen werden in C durch #include <lcd.h> geladen. Die Verwendung ist in einem Testprogramm für die Förderband 3 Konfiguration hier zu finden. Weitere Informationen sind im Wiki unter LCD Assemblerprogramme für 2*16 Zeichen Displays zu finden.

[16.07.2013 GIT Branch schoene new_pipe] Realisierung einer neuen Pipeline, die nur noch mit clk1 arbeitet und damit deutlich schneller geworden ist.

Änderungen

• Entfernung des Phasensplitting und dafür Einbau eines zweiten Bypass bei konsequenter Nutzung des 3 Port Registerspeichers. Der Bypass 1 realisiert die Rückkopplung von WB zu IFID und der Bypass 2 (war schon Vorhanden) die Rückkopplung von WB zu EXMEM. Die Ausgaberegister aller Blockram Module sind jetzt Bestandteil des Pipeline Registers. Dadurch findet das lesen von I/O Registern und Speicherzellen jetzt erst im WB statt. Die Read-Select Signale werden daher in der neuen Hardware um einen Takt gegenüber den Write-Select Signalen verzögert. Dazu wurde in alle umgestellten Geräte der I/O-Decoder "spartanmc/hardware/common/src/reg_access_decoder.v" eingebaut.
• Im GCC sind keine Änderungen notwendig.
• Im SIM kann auch die bisherige Version weiter genutzt werden. Die Darstellung der zeitlichen Abläufe in den einzelnen Pipeline Stufen muss aber gelegentlich angepasst werden (Data READ erst im WB und damit LMD_IO MUX(Register) auch erst im WB).

Auswirkungen

• Ohne jegliche Veränderungen an den Timing Einstellungen in der Synthese wird jetzt bei Konfigurationen für den Spartan 3E eine maximale Systemtakt Frequenz von > 42 MHz ermittelt. (Bisher etwa 28 MHz).
• Der Systemtakt kann jetzt auch durch den Fx Ausgang eines DCM realisiert werden, wodurch die Frequenz des Quarz Generators mit Division und Multiplikation in weiten Bereichen variabel einstellbar wird.

[11.10.2012 - r2034] SpartanMC-SIM: Einbau des Delay-Slot

Änderungen

• Programme für die Hardware ab Version r1880 können jetzt auch im Simulator abgearbeitet werden.
• Programme die noch mit einer GCC Version vor r160 übersetzt wurden, arbeiten damit jetzt fehlerhaft!

[27.08.2012 - r1880] SpartanMC-Core: Einbau des Delay-Slot

Änderungen

• Die Befehle BEQZ, BNEZ, JR, JRS, RFE, JALR und JALRS haben jetzt eine Delay-Slot.
• Befehle im Delay-Slot nutzen noch das alte Registerfenster, und funktionieren damit so als ob sie noch vor dem Befehl stehen würden.
• Anpassung des GCC in der Version r160 ausgeführt. Die Hardware ab Version r1880 darf nur mit dem GCC ab Version r160 genutzt werden!

Auswirkungen

• Besseres Zeiverhalten bei den veränderten Befehlen.

[29.03.2012 - r1266] SpartanMC-Core: Verbessertes Timing

Änderungen

• getrennte Behandlung der Operandeadresse A für Read und Writeback.
• Änderungen in den Bildern ifid1.fig und exmem1.fig [r1283] eingetragen und die Bilder auf der Wiki Pipeline Seite ausgetauscht.

Auswirkungen

• Bei Optimierung auf z.B.: 30ns Systemtakt kommen jetzt auch Werte kleiner 30ns heraus.

[23.02.2012 - r1165] JConfig/Toolchain: Infrastruktur geändert

Änderungen

• JConfig erzeugt jetzt die Parameter der einzelnen Werkzeuge (Synthese, Mapping, PAR) selbst
• Prinzipiell werden jetzt andere Toolchains (Lattice/Altera) unterstützt (Wurden aber noch keine implementiert)

Auswirkungen

• Alle alten Projekte sind nunmehr ungültig.
• Beim öffnen alter Projekte mit JConfig erscheint eine Warnung mit Hinweisen zur Migration in das neue Format. Die Migration sollte problemlos verlaufen.
• Einzelne Synthese-Parameter können jetzt vom User eingestellt werden (z.B. Optimierungen, Mapping-Parameter)

[07.02.2012 - r1114] Firmware: Speicherinitialisierung mit Linker-Sections

Änderungen

• Initialisierung von DMA-BlockRAM-Inhalten geschieht jetzt durch Platzierung der entsprechenden Symbole in der dem DMA-Gerät zugeordneten Linker-Section
• Der Name der Section entspricht dem Namen der Komponente mit vorangestelltem dma_ (Beispiel: die Komponente usb11_0 wird über die Section dma_usb11_0 initialisiert)

Auswirkungen

• Bei bestehenden Projekten muss die Firmware im jConfig neu zugewiesen werden
• Programmspeicher und DMA-Inhalte kommen jetzt aus dem selben Firmware-Quellcode
• Keine Unterstützung mehr für DMA-Initialisierung über die alte LCC-Toolchain

[07.02.2012 - r1103] SpartanMC-Core: Verbessertes Timing

Änderungen

• Beseitigung eines Implementierungsfehlers im SpartanMC-Prozessorkern erlaubt jetzt das Verwenden von eingangsseitigen Constraints für den System-Clock-DCM und automatisch generierter Constraints für alle Taktsignale
• Setzen des Parameters THREE_PORT_REGISTER_FILE auf YES für den SpartanMC implementiert den Registerspeicher als Speicher mit drei Ports (mit 2 BlockRAMs) und erzielt so bessere Timing-Werte

Auswirkungen

• Automatisch generierte Constraints für alle Taktsignale sollten ein insgesamt stabileres System ergeben
• Variable CLOCK_FREQ_MHZ wurde durch SYSCLK_IN_FREQ_MHZ ersetzt und erfordert die Anpassung bestehender Projekte

[26.01.2012 - r1052] User-Clock-Generator: Änderung der Resetansteuerung

Änderungen

• User-Clock-Generator (Modul userclk) reagiert jetzt wahlweise auf high- oder low-aktives Resetsignal
• Neuer Parameter RESET_LEVEL
• Umbenennung des Reset-Ports in reset_i

Auswirkungen

• Bei bestehenden Systemkonfigurationen muss das Reset-Signal des User-Clock-Generators neu angeschlossen werden.

[24.01.2012 - r1027] Neue Peripherie: Heartbeat-Monitor

Ermöglicht das Überwachen des Systembetriebs und die Fehlerdiagnose bei nicht korrekt anlaufendem SpartanMC-System

[23.01.2012 - r1020] System-Clock-Generator: Änderung der Resetansteuerung

Änderungen

• System-Clock-Generator (Modul sysclk) reagiert jetzt wahlweise auf high- oder low-aktives Resetsignal
• Neuer Parameter RESET_LEVEL
• Umbenennung des Reset-Ports in reset

Auswirkungen

• Bei bestehenden Systemkonfigurationen muss das Reset-Signal des System-Clock-Generators neu angeschlossen werden.

---