bachelor/notes/memory-organization-2

beim Durchschauen der Implementierung bin ich (soweit ich das sehe) teilweise zu anderen Ergebnissen gekommen, vornehmlich was die Adressbreiten angeht (ich beziehe mich auf die Werte der Beispielimplementierung aus dem geteilten Repository). Die Zusammenfassung finden Sie im Folgenden (mein Ziel war es auch eine Übersicht der Implementierungsfiles zu erstellen, d.h. was wo zu finden ist, die Ihnen bereits bekannt sein dürfte, der Vollständigkeit halber habe ich jedoch nun alles beigefügt):

###MEMORY STRUCTURE MIRIV###
- top.vhd contains:
  (1) pll
  (2) core
      interface of core to memory:
      - Instructions: mem_i_in (MEM->CORE) / mem_i_out (CORE->MEM)
      - Data: mem_d_in (MEM->CORE) / mem_d_out (CORE->MEM)
  (3) devices
- core.vhd contains:
  (1) pipeline
  (2) dcache
- devices.vhd contains:
  (1) delay unit for imem
  (2) delay unit for dmem
  (3) serial port wrapper (memory-mapped addresses "as part" of dmem)
  (4) counter (memory-mapped address "as part" of dmem)
  (5) memory (separate dmem/imem ports)
  (6) multiplexer (separating/forwarding dmem address into "actual dmem", counter, uart)
- memory.vhd contains:
  (1) jtag_mem
  (2) jtag multiplexer
  (3) imem
  (4) dmem

==CORE/PIPELINE PERSPECTIVE==
- ADDR_WIDTH (mem_pkg): 14 (pipeline works with byte-addresses) => 2^14Byte (16KB) for dmem; 2^14Byte (16KB) for imem
For accessing the dmem, inside the pipeline byte-addressing is used, where theoretically an address width of 32 could be covered. However, in the memu the last two bits are cut off and (ADDR_WIDTH+1 downto 2) are passed to the devices as a 14-bit wide address (with word granularity). The upper two bits of this address distinguish between "actual dmem", uart and the counter.

==JTAG PERSPECTIVE==
- RAM_SIZE_LD (generic of memory, set in devices; word-addressed): 12 => 2^12 words (16KB) for dmem; 2^12 words (16KB) for imem
jtag views CTRL (for triggering reset), IMEM, DMEM in a combined address space with
00_(RAM_SIZE_LD-1 downto 0) => DMEM (word-addressed)
01_(RAM_SIZE_LD-1 downto 0) => IMEM (word-addressed)
###MEMORY STRUCTURE MIRIV###

Das heißt, ich komme hier jeweils auf eine Adressbreite (Wortgranularität) von 12bit jeweils für:
- DMEM (bezogen auf jtag im bootloader memory.vhd: 0x0000 bis 0x0FFF)
- IMEM (bezogen auf jtag im bootloader memory.vhd: 0x1000 bis 0x1FFF)
(Die in bootloader.tcl angegebene Basisadresse 0x400 ist meiner Ansicht nach etwas irreführend, da die ankommende Basisadresse meiner Analyse nach tatsächlich 0x1000 ist, wenn der IMEM gefüllt wird.)

Daraus würde ich den Schluss ziehen, dass der Stack mit der Initialisierung mit 0x1000 (Bytegranularität) nicht am "oberen Ende" des DMEM beginnt (ich habe dazu ein Testprogramm mit Ihnen über owncloud geteilt, das diese These zu bestätigen scheint).

Hinsichtlich der Adresse der Textsection (die im Endeffekt ein Artefakt aus der MIPS-Zeit ist bzw. von dort übernommen wurde) wäre meine Erklärung wie folgt: Grundsätzlich muss zwischen den Instruktionen (die nach *.imem.mif gehören, d.h. das Initialisierungsfile für den Instruction Memory) und Daten (die nach *.dmem.mif gehören) getrennt werden (soweit ist das vermutlich bekannt). Daher sollte die Textsection an einer bekannten Adresse platziert werden, getrennt von den Daten gehalten werden und so arrangiert sein, dass es möglich ist die erste Instruktion an (IMEM-)Adresse 0x0...0 zu verlegen. Die Auftrennung erfolgt dann mittels 'objcopy' im Makefile (nach *.imem.hex und *.dmem.hex), danach werden beim Umwandeln von *.hex nach *.mif (in hex2mif.pl) die obersten beiden bits entfernt, so dass die Daten an der niedrigsten Adresse im IMEM und DMEM landen.