core.vhd

  • Servas Leute!


    Meine Grp-Members haben mich leider alle verlassen, jetzt versuch ich lvl2 selbst zu schreiben, bin aber knapp vorm scheitern. Ins Lab komm ich leider auch net vll liest hier ja jemand ich hab ne Frage. Man soll ja im core die serial_port vom 3er Bsp einbinden. Können wir da serial_port.vhd einfach reinkopieren? aber da brauchen wir ja auch alle pkgs wie math, sync, fifo etc?!


    Nur die ganzen Ein/Ausgänge passen ja garnet mit dem unsrem Serial Port zusammen, muss ich das so übernehmen oder muss ich irgendwas noch anpassen?! Steh leicht auf da Leitung...


    Zweite Frage, is das vom aufbau her richtig? so guckt meine ctrl.vhd aus :)

    PHP
    1. blub: process(jump, exc_load, exc_store)
    2. begin
    3. flush = 0
    4. if jump = '1' then
    5. flush = 1
    6. end if;
    7. if exc_load = '1' or exc_store = '1' then
    8. flush = 1
    9. end if;
    10. end process;


    mehr is da nicht...
    lg

  • Meine Grp-Members haben mich leider alle verlassen, jetzt versuch ich lvl2 selbst zu schreiben, bin aber knapp vorm scheitern. Ins Lab komm ich leider auch net vll liest hier ja jemand ich hab ne Frage. Man soll ja im core die serial_port vom 3er Bsp einbinden. Können wir da serial_port.vhd einfach reinkopieren? aber da brauchen wir ja auch alle pkgs wie math, sync, fifo etc?!

    Ja, einfach alles dorthin kopieren wo es passt. Der UART wird nur beim Synthetisieren gebraucht, die automatische Testbench verwendet eine eigene Implementierung.


    Nur die ganzen Ein/Ausgänge passen ja garnet mit dem unsrem Serial Port zusammen, muss ich das so übernehmen oder muss ich irgendwas noch anpassen?! Steh leicht auf da Leitung...

    Der im serial_port_wrapper instanziierte serial_port sollte kompatibel zu dem in der vorigen Übung geschriebenen sein. Es gab als die Angabe für die Levels 2 und 3 fixiert wurde auch ein kleines Update der zur Verfügung gestellten Templates. Die alte Version von core.vhd hat eine anderen UART ("sc_uart") verwendet, die neue verwendet den serial_port_wrapper.


    Zweite Frage, is das vom aufbau her richtig? so guckt meine ctrl.vhd aus :)

    PHP
    1. blub: process(jump, exc_load, exc_store)
    2. begin
    3. flush = 0
    4. if jump = '1' then
    5. flush = 1
    6. end if;
    7. if exc_load = '1' or exc_store = '1' then
    8. flush = 1
    9. end if;
    10. end process;


    mehr is da nicht...

    Das Flushen beim Branch kann stimmen, es hängt aber davon mit welchen Pipeline-Stufen das flush-Signal verbunden ist. Die Exception-Behandlung stimmt sicher nicht, da ist schon etwas mehr dahinter (z.B. werden andere Pipeline-Stufen als beim Branch geflusht).

    Why bother spending time reading up on things? Everybody's an authority, in a free land.

  • Danke vielmals, hatte noch die alte core.vhd hier :)


    Jetzt hab ich noch so eine sau dämliche Frage sicherlich :p Bis jetzt hab ich in meinen Testbenches immer selbst alle Signale angelegt, aber jetzt sollen wir ja ein Programm durch die Pipe laufen lassen, also ich hab jetzt auch schon mit dem Makefile ein mif-File erstellt, das is ja eigentlich nur beim synthetisieren interessant, zum testen brauchen wir ja aus dem mif ein hex-file für Modelsim was ich schon herausgefunden habe.


    Gut nur wie spiel ich das ein in die TB oder ins Modelsim? Jaja hätte wir schon bei lvl1 machen müssen, aber das habe ich nicht abgegeben :p Außerdem glaub ich sollte man das auch für den Test wissen...


    lg gibt auch nen keks :)

  • Jetzt hab ich noch so eine sau dämliche Frage sicherlich :p Bis jetzt hab ich in meinen Testbenches immer selbst alle Signale angelegt, aber jetzt sollen wir ja ein Programm durch die Pipe laufen lassen, also ich hab jetzt auch schon mit dem Makefile ein mif-File erstellt, das is ja eigentlich nur beim synthetisieren interessant, zum testen brauchen wir ja aus dem mif ein hex-file für Modelsim was ich schon herausgefunden habe.

    Ein hex-File ist nicht notwendig. imem_altera und ocram_altera lesen das mif-File und können auch simuliert werden. Sollte aus irgendeinem Grund doch ein hex-File gebraucht werden, kann man das mit dem Makefile erstellen (die mif-Files werden aus hex-Files erzeugt).


    Gut nur wie spiel ich das ein in die TB oder ins Modelsim? Jaja hätte wir schon bei lvl1 machen müssen, aber das habe ich nicht abgegeben :p

    imem_altera und ocram_altera lesen die Dateien imem.mif bzw. dmem.mif ein. Einfach dort hin spielen wo sie gefunden werden und simulieren. Zur Not kann man auch das mif-File direkt in imem_altera.vhd bzw. ocram_altera.vhd angeben, das kann aber Probleme mit der automatischen Testbench geben.

    Why bother spending time reading up on things? Everybody's an authority, in a free land.

  • Hm das versteh geht mir nicht ganz ein, das makefile generiert uns doch sowas wie arith.mif, fwd.mif etc...muss ich die umbenennen?

    Die mif-Dateien für die in Assembler geschriebenen Testfälle entsprechen dem Instruction-Memory, und müssen also ins passende Verzeichnis kopiert und in imem.mif umbenannt werden. Die in C geschriebenen Testfälle erzeugen zwei Dateien, foo.imem.mif und foo.dmem.mif. Auch die müssen kopiert und in imem.mif/dmem.mif umbenannt werden.

    Why bother spending time reading up on things? Everybody's an authority, in a free land.

  • Danke für deine Hilfe!


    Ich habs leider nicht geschaft, häng an irgendeinem beschissenem Fehler, allein is sehr zach. Eventuell kann ja jemand nach der Deadline sein exec, fwd und ctrl online stellen, damit ich zumindest seh wo ich falsch gedacht habe :(


    lg sense


    *kekse verteilt*