ARM softcore cortex M0 : MULS Problem mit gcc

[student (Gast)]

Hallo,

ich simuliere hier gerade den cortex M0 Softcore als Uni-edition und 
sehe da ein Problem mit dem MULS Befehl bei mir.

In Abhängigkeit von den Operanden wird diese mal korrekt ausgeführt, mal 
fängt der cm0 core beim MULS Befehl an, einfach den memory 
durchzuscannen (immer mit dem Faktor 2 steigend bei der HADDR).

Da er dann irgendwann in einen Bereich kommt, wo niemand mehr zuständig 
ist für die Erzeugung des entsprechenden HREADY Signals, wartet er dann 
irgendwann unendlich auf dieses Signal.

Habt ihr so etwas schon einmal gehabt ? Wenn ja wie habt ihr das gelöst?

Workaround wäre ja einfach ein dummy HREADY für jetzt nicht belegte 
Bereiche zu erzeugen (nach einer gewissen Zeit), ist aber sicherlich 
nicht die Lösung dafür oder ?

Gruß

[Jim M. (turboj)]

student schrieb:
> In Abhängigkeit von den Operanden wird diese mal korrekt ausgeführt, mal
> fängt der cm0 core beim MULS Befehl an, einfach den memory
> durchzuscannen (immer mit dem Faktor 2 steigend bei der HADDR).

Implementiere mal einen Hardfault_Handler(). MULS ist nur für R0-R7 
spezifiziert, alles andere gibt einen Fault.

Eigentlich müsste er in den Lockup gehen, wenn HardFault nicht tut / 
implementiert ist. Vielleicht tut das einfach nur nicht.

Die 16-Bit Fetch klingen etwas nach Instruktion Fetch, aber eigentlich 
sollten die 32-bittig gepipelined sein.

student schrieb:
> Da er dann irgendwann in einen Bereich kommt, wo niemand mehr zuständig
> ist für die Erzeugung des entsprechenden HREADY Signals, wartet er dann
> irgendwann unendlich auf dieses Signal.

Das ist IMHO ein Fehler, den man im Design abfangen sollte. Bei Buffer 
Overflows kommen schon mal Zugriffe auf zufällige Adressen vor - dann 
sollte der sich nicht aufhängen.

[student (Gast)]

Hallo Jim,

danke für Deine Hilfe.
Habe meinen Fehler in der Simu gefunden.

Die Studenten-Version des CM0 hat nur die small Mult unit (also 
sequentiell) drin. Während der Multiplikation zeigt er die 
Zwischenergebnisse auf dem HADDR (was ich als scannen des Speichers 
falsch interpretiert habe), markiert aber korrekt den AHB via HTRANS als 
IDLE.

Das habe ich nicht beachtet. Der CM0 schaut trotzdem auf HREADY ob nicht 
eine Komponente in verzögern will.

Da bei meiner Simu keine Komponente dieses tun soll/möchte,  muss ich 
nur ein dummy HREADY für den Fall von HTRANS=idle erzeugen.

Jetzt muss ich mir nur noch nach eine elegante kleine Lösung für den 
Fall eines echten Buffer Overflows einfallen lassen.

Gruß