Lab 4 Controller design completed, with simple test bench

[gitgnmn]

closes #30

• Design microprocessor AR 4003
• Test bench for microprocessor

Todos for TB

• [x] ADD
• [x] SUB
• [x] AND
• [x] OR
• [x] XOR
• [x] NOT
• [x] MOV
• [x] LDR
• [x] STR
• [x] LDI
• [x] BRZ
• [x] BRN
• [x] BRO
• [x] BRA

[gitgnmn]

79:e raden: "data" kommer från ROM eller hur? Men det finns ingen kod som laddar instruktioner från ROM:n till "data"

Det är väl ändå något som vi gör i labb 5 när vi kopplar ihop allt?

Se 89:e raden. Op-koden är 0110, " inst(8 downto 6) " blir aldrig 101.

"when '0110' " är för instruktionen MOV, decoding för NOT ska inte vara här

Hela det kodblocket var tänkt att vara för alla ALU operationer. Detta fungerade inte, och som du kan se i koden nu så har alla operationer ett eget kodblock anpassat till sig.

[rlindsberg]

[rlindsberg]

@gitgnmn Varför loopar "address"?

[rlindsberg]

Issue: PC ökar sitt värdet varje gång CLK togglar

[gitgnmn]

@gitgnmn Varför loopar "address"?

Det beror vilken version av koden du kör. Antingen är det för att rom_en aldrig går tillbaks till rom_en = '0' så den läser aldrig in nästa instruktion eller så är det för att tb inte tittar på program_countern när den avgör vilken instruktion den skickar in via data-porten.

[rlindsberg]

Jag kör nuvarande pushade versionen

[rlindsberg]

Problemet jag hittade nu är att trots att jag bara har ett test, ökar pc med 1 hela tiden.

[gitgnmn]

Problemet jag hittade nu är att trots att jag bara har ett test, ökar pc med 1 hela tiden.

Jo, jag är inte helt säker på hur vi ska lösa det. Men vi kanske kan lösa det likt sate funkar just nu. dvs, den sätter inte PC direkt utan next_pc = pc + 1 och sedan så har vi en process som väntar på att state ändras till state = 1 som ändrar pc = next_pc.

vad tror du om det?

[rlindsberg]

Problemet jag hittade nu är att trots att jag bara har ett test, ökar pc med 1 hela tiden.

Jo, jag är inte helt säker på hur vi ska lösa det. Men vi kanske kan lösa det likt sate funkar just nu. dvs, den sätter inte PC direkt utan next_pc = pc + 1 och sedan så har vi en process som väntar på att state ändras till state = 1 som ändrar pc = next_pc.

vad tror du om det?

Låter bra. Jag sätter igång nu.

[gitgnmn]

Problemet jag hittade nu är att trots att jag bara har ett test, ökar pc med 1 hela tiden.

Jo, jag är inte helt säker på hur vi ska lösa det. Men vi kanske kan lösa det likt sate funkar just nu. dvs, den sätter inte PC direkt utan next_pc = pc + 1 och sedan så har vi en process som väntar på att state ändras till state = 1 som ändrar pc = next_pc. vad tror du om det?

Låter bra. Jag sätter igång nu.

eller kanske den ska ändra pc på state = 1 då det verkar vara i state 3 pc ändras just nu.

[rlindsberg]

https://github.com/rlindsberg/1331IL-VHDL-Design/blob/92547cc88975bb0a6c35d30ad6be0ed729e1e123/labb4/1.2%20Controller/controller.vhd#L55-L86

Bugger är här: processen körs vid varje positiv CLK flank och instruktionen hinner inte ändras inom 500 ps och då körs

https://github.com/rlindsberg/1331IL-VHDL-Design/blob/92547cc88975bb0a6c35d30ad6be0ed729e1e123/labb4/1.2%20Controller/controller.vhd#L85

ännu en gång till, och en gång till...

[rlindsberg]

PC : process(clk) begin if rising_edge(clk) then program_counter <= next_pc; end if; end process;

[rlindsberg]

Compile error:

[rlindsberg]

Solved error.

[gitgnmn]

PC : process(clk) begin if rising_edge(clk) then program_counter <= next_pc; end if; end process;

ehm, du implementerar väl inte det där? det där är prceis problemet vi hade.

[rlindsberg]

PC : process(clk) begin if rising_edge(clk) then if state = '1' then program_counter <= next_pc; end if; end if; end process;

[rlindsberg]

Jag gjorde så. Men modelsim klagar på att "=" är ogiltigt

[gitgnmn]

PC : process(clk) begin if rising_edge(clk) then if state = '1' then program_counter <= next_pc; end if; end if; end process;

lägg det bara under state 1 i LOGIC

[rlindsberg]

OMG, du är så grym

[rlindsberg]

LÖST!

[gitgnmn]

waited almost 20 min for that commit and it still isn't perfect... jag borde ha gjort en ny branch...

[rlindsberg]

Fel med commits

[rlindsberg]

Kör: git reset 92547cc88975bb0a6c35d30ad6be0ed729e1e123 git pull origin flabb4

[rlindsberg]

Alltid git pull, git push när man jobbar på samman branch...

[gitgnmn]

Alltid git pull, git push när man jobbar på samman branch...

jo, men du commitade så ofta så jag hann knappt lösa skillnaderna innan de var nya skillnader att lösa. Ny temp branch skulle ha varit bättre i detta fall för min del.

[rlindsberg]

Tror att man ska kommita ofta så att vi jobbar på samma version

[rlindsberg]

vänta 5 min, jag fixar branchen..

[gitgnmn]

Tror att man ska kommita ofta så att vi jobbar på samma version

Om man måste jobba på samma branch, och samma fil framför allt, är inte högfrekventa comits bra. Då du kommer behöva merga på ett eller annat sätt och det vill du inte göra allt för ofta då det oftast tar tid och är jobbigt.

[gitgnmn]

Det bästa testet skulle vara om vi fick if rom_en then data <= rom(adress) end if; loopen att funka.

[rlindsberg]

Tror att man ska kommita ofta så att vi jobbar på samma version

Om man måste jobba på samma branch, och samma fil framför allt, är inte högfrekventa comits bra. Då du kommer behöva merga på ett eller annat sätt och det vill du inte göra allt för ofta då det oftast tar tid och är jobbigt.

Nej, om man alltid kör git pull förre commit, behöver man inte merga alls

[rlindsberg]

Kan du merga den här https://github.com/rlindsberg/1331IL-VHDL-Design/pull/44 ?

[gitgnmn]

Tror att man ska kommita ofta så att vi jobbar på samma version

Om man måste jobba på samma branch, och samma fil framför allt, är inte högfrekventa comits bra. Då du kommer behöva merga på ett eller annat sätt och det vill du inte göra allt för ofta då det oftast tar tid och är jobbigt.

Nej, om man alltid kör git pull förre commit, behöver man inte merga alls

Det var konstigt med tanke på att det var precis det jag gjorde och jag behövde merga varje gång. Dock gjorde jag inte det utan gjorde en reset till din senaste commit och sen väntade jag på att du skulle bli klar. Dock struntade jag i git reset sen och mergade istället.

[rlindsberg]

Tror att man ska kommita ofta så att vi jobbar på samma version

Om man måste jobba på samma branch, och samma fil framför allt, är inte högfrekventa comits bra. Då du kommer behöva merga på ett eller annat sätt och det vill du inte göra allt för ofta då det oftast tar tid och är jobbigt.

Nej, om man alltid kör git pull förre commit, behöver man inte merga alls

Det var konstigt med tanke på att det var precis det jag gjorde och jag behövde merga varje gång. Dock gjorde jag inte det utan gjorde en reset till din senaste commit och sen väntade jag på att du skulle bli klar. Dock struntade jag i git reset sen och mergade istället.

Aha, jag förstår. Beklagar för strul.

[rlindsberg]

Tack!

[rlindsberg]

Kan du jobba med labb4 branch? Jag fortsätter här.

[rlindsberg]

Nu ska jag skapa en .do fil, så att man inte behöver lägga till waves, ställa om CLK och skriva "run 10 ns" varje gång

[rlindsberg]

Många fel uppstod i samband med din senaste commit

[rlindsberg]

[rlindsberg]

@gitgnmn Usage of automated test: Start simulation, load design. Enter "do ctl.do" in command line.

[rlindsberg]

  when 1 =>
    ROM_debug   <= '0'; -- active low
    ROM_en      <= ROM_debug; -- active low
    adr         <= std_logic_vector(to_unsigned(pc, address_size));

    assert ROM_debug = '0'
    report "ROM is not activated"
    severity warning;

Jag fick varning när jag körde tb. Dvs "ROM_debug <= '0' " funkar inte. @gitgnmn

[gitgnmn]

  when 1 =>
    ROM_debug   <= '0'; -- active low
    ROM_en      <= ROM_debug; -- active low
    adr         <= std_logic_vector(to_unsigned(pc, address_size));

    assert ROM_debug = '0'
    report "ROM is not activated"
    severity warning;

Jag fick varning när jag körde tb. Dvs "ROM_debug <= '0' " funkar inte. @gitgnmn

konstigt... jag tar en titt

[rlindsberg]

  when 1 =>
    ROM_debug   <= '0'; -- active low
    ROM_en      <= ROM_debug; -- active low
    adr         <= std_logic_vector(to_unsigned(pc, address_size));

    assert ROM_debug = '0'
    report "ROM is not activated"
    severity warning;

Jag fick varning när jag körde tb. Dvs "ROM_debug <= '0' " funkar inte. @gitgnmn

konstigt... jag tar en titt

Jag tror jag har löst det. Och samtidigt hittat en ny bugg. Får jag pusha min commit?

[gitgnmn]

  when 1 =>
    ROM_debug   <= '0'; -- active low
    ROM_en      <= ROM_debug; -- active low
    adr         <= std_logic_vector(to_unsigned(pc, address_size));

    assert ROM_debug = '0'
    report "ROM is not activated"
    severity warning;

Jag fick varning när jag körde tb. Dvs "ROM_debug <= '0' " funkar inte. @gitgnmn

konstigt... jag tar en titt

Jag tror jag har löst det. Och samtidigt hittat en ny bugg. Får jag pusha min commit?

Kör på!

[rlindsberg]

[rlindsberg]

@gitgnmn No warning at 7000 ps, but warning at 1500 ps

[gitgnmn]

spänningen är oliiidlig

[rlindsberg]

Nu ska jag snacka skit om VHDL...

Några upptäckter:

1. runt 500 ps, ROM_en ska vara 1, se den 63:e raden, men den förblir 0. Se vänstra fönstret.

2. runt 7000 ps, ROM_debug ska vara 0, men förblir U.

[rlindsberg]

Sen fortsatte jag att stega, och efter processen är klar, tilldelas ROM_en och ROM_debug det nya värdet, dvs man inte kommer åt det nya värdet på en gång, utan måste vänta ytterligare en klockcykel.

T.ex om vi kör följande kod, kommer det skriva ut neeeeeej

    ROM_debug   <= '0'; -- active low
    if ROM_debug = 'U' then
        neeeeeej
    elsif ROM_debug = '0' then
        yeahhhhh
    end if;

[rlindsberg]

@gitgnmn Code changes: https://github.com/rlindsberg/1331IL-VHDL-Design/commit/8f1e10c9b90332dab6acb21f7c997daec983442c

Test 1 should success at 1000 ps, 7000 ps and 1300 ps. Test 2 should success at 2500 ps, 8500 ps, 14500 ps.

[rlindsberg]

@gitgnmn Code changes: https://github.com/rlindsberg/1331IL-VHDL-Design/commit/be5a83d34acabedf1f85e3046807c6aaf353faca