openrisc / mor1kx Goto Github PK

I have converted to or1k-tests to use inline calls to mtspr() and mfspr(). This causes failures in the following cases in or1k-mmu.

See: openrisc/or1k-tests@32f0ba2

static int itlb_match_test (int way, int set)
{
...

  // Flush these areas incase cache doesn't write them through immediately
  mtspr(OR1K_SPR_DCACHE_DCBFR_ADDR, ta - 8);
  mtspr(OR1K_SPR_DCACHE_DCBFR_ADDR, ta);
(CASE 1 - assembly stores ta to stack at this time)

  mtspr(OR1K_SPR_DCACHE_DCBFR_ADDR, ta + PAGE_SIZE - 8);
  mtspr(OR1K_SPR_DCACHE_DCBFR_ADDR, ta + PAGE_SIZE);

  /* Shifting one in ITLBMR */
  add = (PAGE_SIZE*itlb_sets);
  // Space we'll access and expect the MMU to translate our requests
  ea = add + (set*PAGE_SIZE);

  /* Enable IMMU */
  immu_enable ();

  while (add != 0x00000000) {
(CASE 2)
    mtspr (OR1K_SPR_IMMU_ITLBW_MR_ADDR(way, set), ea | OR1K_SPR_IMMU_ITLBW_MR_V_MASK);
    mtspr (OR1K_SPR_IMMU_ITLBW_TR_ADDR(way, set), ta | ITLB_PR_NOLIMIT);

Case 1 - this happens when 1 nop after mtspr.

The first case is where we have mtspr following by a l.sw, this causes an invalidate to be sent to the dcache. At the same time as the write operation. The write fails.

Case 2 - this happens with 0 nop after mtspr.

The mtspr followed by mtspr causes the second write to OR1K_SPR_IMMU_ITLBW_TR_ADDR to be lost.

Workaround

Adding 2 l.nops after mtspr fixes the issue. Below in case 1 the l.sw came before the l.nop due to some optimizations from gcc, to fix it the asm for l.mtspr contains the nop inline i.e. l.mtspr %0, %1, 0; l.nop; l.nop. But the below is without the fix exposing the CPU issue, but it should still work.

Trace case1 - dcache spr mix with l.sw fails

    2ff8:       9e b9 20 00     l.addi r21,r25,8192
    2ffc:       aa 20 18 02     l.ori r17,r0,0x1802
    3000:       c0 11 d8 00     l.mtspr r17,r27,0x0  <--- mtspr(OR1K_SPR_DCACHE_DCBFR_ADDR, ta - 8);
    3004:       15 00 00 00     l.nop 0x0
    3008:       c0 11 c8 00     l.mtspr r17,r25,0x0   <--- mtspr(OR1K_SPR_DCACHE_DCBFR_ADDR, ta);
    300c:       d4 01 c8 24     l.sw 36(r1),r25          <--- This store fails to go to dcache (save ta)
    3010:       15 00 00 00     l.nop 0x0
    3014:       c0 11 b8 00     l.mtspr r17,r23,0x0
    3018:       15 00 00 00     l.nop 0x0
    301c:       c0 11 a8 00     l.mtspr r17,r21,0x0
    3020:       15 00 00 00     l.nop 0x0
    3024:       18 80 00 00     l.movhi r4,0x0

Trace case2 - immu spr fails

When we have a l.mtspr writing to the IMMU followed by another l.mtspr writing to the IMMU the second spr write may fail.

    24e0:       aa 94 08 00     l.ori r20,r20,0x800
    24e4:       aa 52 08 00     l.ori r18,r18,0x800
    24e8:       aa 10 03 c0     l.ori r16,r16,0x3c0
    24ec:       9f 51 ff ff     l.addi r26,r17,-1
    24f0:       aa 3e 00 01     l.ori r17,r30,0x1
    24f4:       c0 14 88 00     l.mtspr r20,r17,0x0  <--- This write to IMMUMR goes through
    24f8:       c0 12 80 00     l.mtspr r18,r16,0x0  <--- This write to IMMUTR never happens
    24fc:       d4 02 00 44     l.sw 68(r2),r0
    2500:       d4 02 00 48     l.sw 72(r2),r0
    2504:       d4 02 00 1c     l.sw 28(r2),r0

The PCU will at most increment the counters by one in a cycle. If there is more than one event enabled for a register, they are not counted. The workaround is to enable at most one event class per counter.

Following the spec, SWA instruction should store a value to the specified address only when the atomic-reserve is set.
If atomic-reserve is not set, SWA should not do any store.
SWA with misaligned address should not assert any exception if atomic-reserve is not set.
It seems mor1kx asserts exception in the above case.

following insn streams will reproduce

18000000 //l.movhi r0,0x0000   
a8200001 // l.ori   r1,r0,0x0001  
c0000811 // l.mtspr r0,r1,0x0011    
c1400000 // l.mtspr r0,r0,0x5000 
18000000 // l.movhi r0,0x0000
a8200001 // l.ori r1,r0,0x0001
18a0dead // l.movhi r5,0xdead
a8a5beef // l.ori r5,r5,0xbeef
cc802801 // l.swa 0x2001(r0),r5

following should solve this issue
in mor1kx_lsu_cappuccino.v
change assign except_align

assign except_align = ctrl_op_lsu & align_err & !(ctrl_op_lsu_store_i & ctrl_op_lsu_atomic_i & !atomic_reserve);

Hey,

it would be nice to have those in mor1kx. I think the TLB should set them itself when a page is read from and/or written to. I already saw, that the TLBs don't change the entries by themselves, so that some work is needed to enable updating the entries similar as with the caches.

Best,
Stefan

The librecores CI has been failing for some time, we now have setup github actions. Should we remove librecores CI?

https://ci.librecores.org/job/Projects/job/OpenRISC/job/mor1kx/job/master/

When mor1kx receives 'jalr to link register (r9)'
illegal instruction exception should be asserted as in or1ksim, but it doesn't

You can reproduce by inserting 'insn: 0x48004800'

in mor1kx_decode.v, changing as below should fix this.

always @*
 case (opc_insn)
  `OR1K_OPCODE_JALR:
   if (decode_insn_i[`OR1K_RB_SELECT] == 9)
    decode_except_illegal_o = 1'b1;

Found when building de0_nano-multicore. The design no longer fits on the de0_nano cyclone IV. It used to be 18210 logic cells no it has increased to 46111 logic cells.

BEFORE

$ fusesoc build ::de0_nano-multicore:1.0

...
INFO: Preparing ::mor1kx:5.0-r2
...


Info (21057): Implemented 19257 device resources after synthesis - the final resource count might be different
    Info (21058): Implemented 7 input pins
    Info (21059): Implemented 26 output pins
    Info (21060): Implemented 24 bidirectional pins
    Info (21061): Implemented 18210 logic cells
    Info (21064): Implemented 976 RAM segments
    Info (21065): Implemented 1 PLLs
    Info (21062): Implemented 12 DSP elements

NOW

Info (21057): Implemented 46990 device resources after synthesis - the final resource count might be different
    Info (21058): Implemented 7 input pins
    Info (21059): Implemented 26 output pins
    Info (21060): Implemented 24 bidirectional pins
    Info (21061): Implemented 46111 logic cells
    Info (21064): Implemented 808 RAM segments
    Info (21065): Implemented 1 PLLs
    Info (21062): Implemented 12 DSP elements

As in spec,
EEAR register should save the instruction fetch VA when illegal instruction exception.

We should change code in mor1kx_ctrl_cappuccino.v as follow.

    always @(posedge clk `OR_ASYNC_RST)
     if (rst)
       spr_eear <= {OPTION_OPERAND_WIDTH{1'b0}};
     else if (/*padv_ctrl & exception*/ exception_re)
       begin
	  if (except_ibus_err_i | except_itlb_miss_i | except_ipagefault_i | except_illegal_i)
	    spr_eear <= pc_ctrl_i;
	  else if (except_dbus_i | except_dtlb_miss_i | except_dpagefault_i | except_align_i)
	    spr_eear <= ctrl_lsu_adr_i;
       end 

When running the or1k-tests with ESPRESSO pipeline I am seeing many tests fail.

< shorne@lianli ~/work/openrisc/or1k-tests/native > ./runtests.sh 
Running or1k-alignillegalinsn                               TIME OUT
Running or1k-backtoback_jmp                                 TIME OUT
Running or1k-basic                                          TIME OUT
Running or1k-cmov                                           PASS
Running or1k-cy                                             PASS
Running or1k-dsx                                            TIME OUT
Running or1k-dsxinsn                                        TIME OUT
Running or1k-ext                                            PASS
Running or1k-ffl1                                           TIME OUT
Running or1k-icache                                         TIME OUT
Running or1k-illegalinsn                                    TIME OUT
Running or1k-illegalinsndelayslot                           TIME OUT
Running or1k-insnfetchalign                                 TIME OUT
Running or1k-insnfetcherror                                 TIME OUT
Running or1k-intloop                                        TIME OUT
Running or1k-intmulticycle                                  TIME OUT
Running or1k-intsyscall                                     TIME OUT
Running or1k-inttickloop                                    TIME OUT
Running or1k-jmp                                            FAIL
Running or1k-jr                                             FAIL
Running or1k-lsu                                            TIME OUT
Running or1k-lsualign                                       TIME OUT
Running or1k-lsualigndelayslot                              TIME OUT
Running or1k-lsuerror                                       TIME OUT
Running or1k-lsuerrordelayslot                              TIME OUT
Running or1k-lwjr                                           TIME OUT
Running or1k-msync                                          TIME OUT
Running or1k-mul-basic                                      FAIL
Running or1k-ov                                             FAIL
Running or1k-regjmp                                         FAIL
Running or1k-rfe                                            TIME OUT
Running or1k-sf                                             PASS
Running or1k-sfbf                                           TIME OUT
Running or1k-shiftopts                                      PASS
Running or1k-shortbranch                                    FAIL
Running or1k-shortjump                                      FAIL
Running or1k-systemcall                                     TIME OUT
Running or1k-tickloop                                       TIME OUT
Running or1k-tickrfforward                                  TIME OUT
Running or1k-ticksyscall                                    TIME OUT
Running or1k-timer                                          TIME OUT
Running or1k-trap                                           TIME OUT
Running or1k-trapdelayslot                                  TIME OUT
Results                                                     Total:  43  FAIL:  38

As per the comment in the THREESTAGE multiplier it doesn't support overflow detection. This causes the compliance tests in or1k-tests to fail.

See:
https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx_execute_alu.v#L258

Hi, everyone.

I tried to run dhrystone on mor1kx cpu using iverilog sim with fusesoc and failed.
Then I implemented my own branch predictor and tried it, test passed.
Take a look at attached files:

• dhrystone_simple.txt is insn trace with default branch predictor

dhrystone_simple.txt

• dhrystone_sat_cnt.txt is trace with new predictor

dhrystone_sat_cnt.txt
The odd thing to me is flag being in "x" state, but I haven't investigated it yet.

Bin and disasm are also attached. Rename dhrystone_10.zip to dhrystone, it's not archive but executable.
dhrystone_10_disasm.txt
dhrystone_10.zip

If there is a bus error during an IC refill, the fetch unit will be hanging forever waiting for an ack that won't come

In mor1kx_cache_lru.v, lru_post is calculated as AND of rows

for (i = 0;i < NUMWAYS; i = i + 1) begin 
        lru_post[i] = &expand[i];      
end

Due to this, access and lru_post value are not the same.

This can be corrected by computing lru_post as the product of columns

 for (i = 0; i < NUMWAYS; i = i + 1) begin
        lru_post[i]=1;
        for (j=0;j<NUMWAYS;j=j+1)
          lru_post[i]= lru_post[i]*expand[j][i];
      end

Another bug detected, during formal verification. With the following code, the tool detects error.

for (i = 0; i<NUMWAYS; i = i + 1) begin    
    if (access[i]) begin            
     for (j = 0; j < NUMWAYS; j = j + 1) begin         
         if (i != j) begin                 
         expand[i][j] = 1'b0;              
         end           
    end            
   for (j = 0; j < NUMWAYS; j = j + 1) begin      
         if (i != j) begin           
       expand[j][i] = 1'b1;           
        end        
   end      
  end     
end

Here, the third row of the expand matrix is of 3 bits instead of 4.

This can be corrected by precomputing the row exchange index.

 for (j=0;j<NUMWAYS;j=j+1) begin
       if (access[j])
         i=j;
 end
for (j = 0; j <NUMWAYS; j = j + 1) begin         
      if (i != j) begin                 
         expand[i][j] = 1'b0;              
       end           
end            
for (j = 0; j < NUMWAYS; j = j + 1) begin      
         if (i != j) begin           
              expand[j][i] = 1'b1;           
        end        
end  

This issue will be in direction of setting up demo CI flow for mor1kx in Librecores-CI. Initially, Jenkinsfine can be created which uses the same flow as in Travis CI in mor1kx and later it can be extended to include :

• Yosys synthesis which is required for monitoring resource usages.
• OpenOCD/GDB for CPU pipeline debugging

CC @oleg-nenashev, @stffrdhrn

@lifeasageek

mor1kx adder mistakenly set 'adder_carryout' when subtract.
You can reproduce the case with below instructions.

18000000 l.movhi r0,0x0000       r0         = 00000000  flag: x
a8200001 l.ori   r1,r0,0x0001    r1         = 00000001  flag: x
c0000811 l.mtspr r0,r1,0x0011    SPR[0011]  = 00000001  flag: x
a8800004 l.ori   r4,r4,0x0004    r4         = 00000000  flag: 0
a8600003 l.ori   r3,r0,0x0002    r3         = 00000000  flag: 0
e0441802 l.sub   r2,r4,r3        r2         = 00000000  flag: 0

My solution is,
in mor1kx_execute_alu.v
change

  wire [OPTION_OPERAND_WIDTH-1:0] b_neg;
  wire [OPTION_OPERAND_WIDTH-1:0] b_mux;

  assign b_neg = ~b;
  assign b_mux = adder_do_sub_i ? b_neg : b;

to

  wire [OPTION_OPERAND_WIDTH:0] b_neg;
  wire [OPTION_OPERAND_WIDTH:0] b_mux;

  assign b_neg = ~{{1{1'b0}}, b};
  assign b_mux = adder_do_sub_i ? b_neg : {{1{1'b0}}, b};

As reported in this thread https://lists.librecores.org/pipermail/openrisc/2016-June/000028.html , there seem to be an issue with single-stepping. Not confirmed that there is a problem or that the problem is in mor1kx, but I'm filing the bug here so that it's not forgotten

@Nancy-Chauhan is working on enabling LibreCores CI runs for this repository (e.g. see #84 and #85 ). In order to make it a part of the pull request builder, we need @librecores-ci-bot to be added to the repository with WRITE permissions so that it can post build results.

@stffrdhrn would it be possible to do so?

CI for Yosys synthesis can be impelemented to get the resource usage. It can be further extended to support pnr i.e place and route

After LWA instruction, if a snoop_en_i signal and snoop to same address are inserted at some specific time, the reservation does not get cancelled.
According to OpenRISC isa, they said snooping hit should break the reservation.
Isn't it bug?

Here's waveform

When I input multiply, mtspr, multiply instructions sequentially, like this,

  b08e1111	l.muli	r4, r14, 0x1111
  c011f416	l.mtspr	r17, r30, 0xf416
  b2160001	l.muli	r16, r22, 0x0001

value in r30 is written to r22 due to the mtspr.
and next l.muli instruction uses r22's value in multiplication.

However, next l.muli instruction mistakenly brings old value of r22 because the write back of first l.muli instruction occupies register write port when mtspr should write.
Register read-write bypass can fix this situation but I saw ENABLE_BYPASS parameters in mor1kx_rf_cappuccino.v is set to 0.
Are there any reason for it?

The full input instructions are as follow.

  18000000	l.movhi	r0, 0x0000
  a8200001	l.ori	r1, r0, 0x0001
  c0000811	l.mtspr	r0, r1, 0x0811
  abc00000      l.ori   r30, r0, 0x0000
  aac00000      l.ori   r22, r0, 0x0000
  a8800000      l.ori   r4, r0, 0x0000
  a9c00000      l.ori   r14, r0, 0x0000
  aa200000      l.ori   r17, r0, 0x0000
  aa000000      l.ori   r16, r0, 0x0000
  afde0001      l.ori   r30, r30, 0x0001
  aed60002	l.xori	r22, r22, 0x0002
  b08e1111	l.muli	r4, r14, 0x1111
  c011f416	l.mtspr	r17, r30, 0xf416
  b2160001	l.muli	r16, r22, 0x0001
  15000000	l.nop	0x0
  15000000	l.nop	0x0

Hi,

When I was trying to simulate mor1kx with modelsim, the execution flow always somehow "halted" after around 4700 instructions executed if I enabled DCache and ICache in mor1kx.v. The cache works for around 2000 instructions but halted after that. I haven't made any modification to anything else except mor1kx.v. Do I need to make any configuration to make it work properly or it should not be enabled.

Thanks.

Properties that failed:

1. The direction of the write enable shouldn't change within a series of strobe/requests.
2. Within any given bus cycle, the direction may only change when there are no further outstanding requests

Solver picks up a case where the write enable changes due to atomic signal transition.

Code:
https://github.com/openrisc/mor1kx/blob/master/bench/formal/fwb_master.v#L173#L186

Trace showing failure:

When flag is not set, instruction after l.bf instruction is not a delay slot instruction.
However, if exception occurs right after l.bf instruction with flag unset, DSX bit (delay slot exception) of SR is set.

I think it should not be set because it is not a delay slot instruction.

It needs lot more modification of the codes.

When running or1k-tests.

Running or1k-alignillegalinsn PASS
Running or1k-backtoback_jmp PASS
Running or1k-basic PASS
Running or1k-cmov PASS
Running or1k-cy FAIL
Running or1k-dsx TIME OUT
Running or1k-dsxinsn PASS
Running or1k-ext PASS
Running or1k-ffl1 PASS
Running or1k-icache PASS
Running or1k-illegalinsn PASS
Running or1k-illegalinsndelayslot FAIL
Running or1k-insnfetchalign PASS
Running or1k-insnfetcherror TIME OUT
Running or1k-intloop PASS
Running or1k-intmulticycle PASS
Running or1k-intsyscall PASS
Running or1k-inttickloop PASS
Running or1k-jmp PASS
Running or1k-jr PASS
Running or1k-lsu TIME OUT
Running or1k-lsualign PASS
Running or1k-lsualigndelayslot PASS
Running or1k-lsuerror PASS
Running or1k-lsuerrordelayslot PASS
Running or1k-lwjr PASS
Running or1k-msync TIME OUT
Running or1k-mul-basic PASS
Running or1k-ov FAIL
Running or1k-regjmp PASS
Running or1k-rfe TIME OUT
Running or1k-sf PASS
Running or1k-sfbf TIME OUT
Running or1k-shiftopts PASS
Running or1k-shortbranch PASS
Running or1k-shortjump FAIL
Running or1k-systemcall PASS
Running or1k-tickloop PASS
Running or1k-tickrfforward TIME OUT
Running or1k-ticksyscall PASS
Running or1k-timer PASS
Running or1k-trap TIME OUT
Running or1k-trapdelayslot TIME OUT

@lifeasageek

l.fl1 instruction is not decoded correctly.
Any l.fl1 instruction can reproduce the error.

We can solve this with following change in mor1kx_decode.v

  assign decode_op_ffl1_o = opc_insn == `OR1K_OPCODE_ALU &&
                        (decode_insn_i[9:8] == 2'b00 || decode_insn_i[9:8] == 2'b01) &&
                        opc_alu == `OR1K_ALU_OPC_FFL1;

When clearing SR_SPR[SR_SPR_IEE] within an ISR (using or1k_interrupts_disable() from or1k-support.h), the global irq disable (which this bit represents) seems to be overwritten by the restoring from spr_sr[14:0] <= spr_esr[14:0] in mor1kx_ctrl_cappuccino.v when leaving the ISR. So the IRQs are effectively not disabled.

My workaround for now is just not to restore sr_spr[SR_SPR_IEE] from spr_esr but I am relatively new to OpenRISC and may not see all implications this includes.
Also I believe now it is not possible to do any manipulations of the SR within an ISR that are not overwritten when leaving the ISR?

Best regards,
wwwweb

in the code mor1kx_excute_alu.v

    // One signed overflow detection for all multiplication implmentations
    assign mul_signed_overflow = (FEATURE_MULTIPLIER=="NONE") || (FEATURE_MULTIPLIER=="PIPELINED") ? 1'b0 :
    // Same signs, check for negative result
    // (should be positive)
    ((a[OPTION_OPERAND_WIDTH-1] == b[OPTION_OPERAND_WIDTH-1]) && mul_result[OPTION_OPERAND_WIDTH-1]) ||
    // Differring signs, check for positive result
    // (should be negative)
    ((a[OPTION_OPERAND_WIDTH-1] ^ b[OPTION_OPERAND_WIDTH-1]) && !mul_result[OPTION_OPERAND_WIDTH-1]);

multiplying negative value with 0 will mistakenly assert the overflow.
Also, other cases such as '0x4 * 0x5fffffff' will not detect the overflow.

In the case of SERIAL multiplier, we can fix it by changing

assign mul_signed_overflow = (mul_prod_r[(OPTION_OPERAND_WIDTH*2)-1:OPTION_OPERAND_WIDTH] == 32'h0 || mul_prod_r[(OPTION_OPERAND_WIDTH*2)-1:OPTION_OPERAND_WIDTH] == 32'hffffffff) ? 0:1;

Property: No two spr groups can acknowledge at the same time.

Assertion:

https://github.com/openrisc/mor1kx/blob/master/bench/formal/fspr_master.v#L66#L70

always @(posedge clk)
      if (f_past_valid)
         assert ($onehot0({spr_bus_ack_dc_i, spr_bus_ack_ic_i,
                 spr_bus_ack_dmmu_i, spr_bus_ack_immu_i}));

Back-to-back spr requests may delay the fall of spr acknowledgment. Meanwhile, a new spr request would have been acknowledged. Here, we can see spr_bus_ack_ic_i and spr_bus_ack_dc_i signals are high at the same time.

Trace:

This issue is in direction of Setting up Demo CI Flow for mor1kx Project. Currently mor1kx constantly evolving code is verified by Travis Continous Integration. One of the first aim of GSoC 2019 project is to use Librecores CI for Continous Integration of mor1kx. Librecores CI is an approach/service to provide continuous integration to hardware projects hosted on Librecores to improve user experience and reliability.

Goal : This will create shared tooling of Librecores CI image with mor1kx project
Implementation : With reference to issue librecores/docker-images#10 , it will be possible to replace custom dockerfile image used in mor1kx project https://github.com/openrisc/mor1kx/tree/master/.travis with Librecores CI image . Further Jenkinsfile can be created for refactoring of existing travis CI

Project Link: https://github.com/librecores/librecores-ci/

CC @oleg-nenashev @wallento @stffrdhrn
Link to doc proposal

https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx_lsu_cappuccino.v#L524

always @(posedge clk)
     if (rst | pipeline_flush_i)
       atomic_reserve <= 0;
     else if (ctrl_op_lsu_store_i & ctrl_op_lsu_atomic_i & write_done ||
          !ctrl_op_lsu_atomic_i & store_buffer_write &
          (store_buffer_wadr == atomic_addr) ||
          (snoop_valid & (snoop_adr_i == atomic_addr)))
       atomic_reserve <= 0;

(rst | pipeline_flush_i) seems a bit dodgy if the timing tools were to analyse the net as an asyncronous reset (in other parts of the code) and synchronous here. Maybe it's ok (who knows with fpga design tools!), though pipeline_flush_i could migrate, I think, to the first if condition and possibly a OR_ASYNC_RST added to the always @ trigger.

Hi,

with this commit it was introduced that the DC refill aborts on snoop hits: 87283e9

The issue is that the wishbone spec does not allow to just abort a transaction and I had a chain of events to led to a crash eventually.

@skristiansson fortunately documented the change very well, thanks!

I am wondering if a solution based on the outline in the commit or a solution where the bus itnerface unit completes a burst after two words and then withdraws the data is better.

What do you think?

Cheers,
Stefan

@lifeasageek
l.sfgtu rA,rB should set flag when rA > rB
But it doesn't.

reproduce:

18000000 l.movhi r0,0x0000    
a8200001 l.ori   r1,r0,0x0001   
c0000811 l.mtspr r0,r1,0x0011 
a8800004 l.ori   r4,r4,0x0004   
a8600003 l.ori   r3,r0,0x0002   
e4441800 l.sfgtu r4,r3

My solution (in mor1kx_execute_alu.v)

assign a_ltu_b = adder_carry_out;

Hello, I want to put mor1kx into my Xilinx Xc7k325t-2 FPGA for hardware simulation. Have you tested the max operating frequency that mor1kx can achieve on Xilinx 7 series FPGA?

Thanks!

When using edge triggered IRQs, the (rising) edge seems to be detected using the PICSR itself and the incoming IRQLINE (!spr_picsr[irqline] & irq_unmasked[irqline] in mor1kx-pic.v). When resetting the according IRQ bit in PICSR with the IRQLINE still high (no new edge but still high level), the IRQ is triggered in the next cycle again, so this just works like a level triggered IRQ.

From my opinion there needs to be an additional register stage for edge detection which only generates a 1 cycle set. Using this, I think the logic that "CLEAR" is served before "SET" is not sufficient, as I would expect that when an edge occurs in the instant I clear the IRQ (usually within the ISR), the IRQ bit stays active and another IRQ is triggered.

Best regards,
wwwweb

** Conditional Loading without a reset**
In mor1kx_lsu_cappuccino there is a reset missing, when FEATURE_STORE_BUFFER==NONE.

The register store_buffer_full_r does not have a reset, and it is conditionally loaded, but the condition cannot be met unless the regiser contains a valid value.

reg store_buffer_full_r; always @(posedge clk) if (store_buffer_write) store_buffer_full_r <= 1; else if (write_done) store_buffer_full_r <= 0;

In simulation, store_buffer_full_r is initialised to 1'bx and as a result store_buffer_full is 1'bx, and this prevents writes from completing, and as a result simulation hangs.

There other registers in the design which have a similar conditional loading feature and no reset. They do not cause SIM to hang, but it is not clear if they are safe.

Mixed Sync and Async Resets
The majority of the registers in mor1kx which have a reset use the `OR_ASYNC_RST macro to give the option of the reset being asynchronous, but some registers, such as the "state" register in mor1kx_lsu_cappuccino treat the reset as unconditionally synchronous. This means someone who wants to use asynchronous resets my not achieve a clean reset unless they start the clock whilst the reset is active.

Hi,

I'm a newbie in Verilog coding, so most probably this is the cause of my problem, but, working on a university project that include the mor1kx module (https://github.com/mit-ll/CEP), I'm not able to run a complete simulation of the architecture because it stops at line 144 of the mor1k_monitor file.
So I'd like to ask what is that execute_insnvariable that bring my simulation to finish and, if it is possible to know, why it has that value.
Thank you in advance to all those who can help me,

Lorenzo

In the control module, signal spr_access is driven by the spr_group which is dependent on the address computed in the execution stage i.e., ctrl_alu_result_i. When we don’t have spr instructions but the last five bits of address ctrl_alu_result_i match to any of SPR groups then spr_access will get updated. Due to which spr_access_valid and spr_ack are driven when there are no mtspr/mfspr opcode signals.

Assertion:

always @(posedge clk)
   if ($onehot(spr_access) && !$past(rst) && f_past_valid)
      assert (ctrl_op_mtspr_i | ctrl_op_mfspr_i);

Trace:

Hi, I have a problem when I am using mor1kx.

My env:

• mor1kx espresso
• ibus type => CLASSIC
• enable debug_unit

I use openocd,jtag_vpi and gdb to debug the system, after I uploaded the elf program and let it start to run, the PC was jump to 0x4.

I think it might be a bug when du stop the cpu, and at the same time, CPU is in branch or delay slot.

And I think after a du_restart issued, CPU might need to wait until something is finished.

Let me explain it, It is a little bit complicated, so pls correct me if...

1. In the beginning, CPU is running normally.
2. When CPU is just execute an branch inst. with a delay slot (ctrl_branch_occur is HIGH), CPU is stalled by external signal (du_stall by debug_unit by gdb)
3. Then execute_delay_slot and ctrl_branch_occur_o become always HIGH until the du_stall_i is de-asserted.

1. After gdb upload everything, it send a du_restart_o pulse to let CPU jump to 0x100
2. Then I think because ctrl_branch_occur_o is HIGH, so CPU believe it is in branching, but actually the first two instructions are two l.nop.
3. PC jump to 0x4, then everything messed up. -_-

Another clue is if I modify

diff mor1kx_bus_if_wb32.v
@@ 179
     assign wbm_stb_o = cpu_req_i & !cycle_end;
-    assign wbm_cyc_o = cpu_req_i;
+    assign wbm_cyc_o = cpu_req_i & !cycle_end;

It seems that it is fixed, I am really not sure about this!

Thanks!

SPR read and write requests are mutually exclusive. Both spr_read_access and spr_write_acess can’t be high at the same time. When the Debug unit is enabled, this property fails.

Assertion (Check applied to mor1kx_ctrl_cappuccino.v)

always @*
   assert ($onehot0 ({spr_read_access, spr_write_access}));

Trace:

In the fusesoc-cores project we have mor1kx version v5.0*

We should be synced with @olofk and making tags.

I am not sure if this is a problem with mor1kx or the or1k-support library.

When enabling 2 IRQs (i.e. IRQ1 and IRQ2), registering an ISR for each (i.e. ISR1 and ISR2) and then triggering both IRQs at the same time (i.e. PICSR becomes 0x00000006), the program "hangs up" after serving ISR1.

When using LEVEL triggered IRQs, ISR1 is repeated until the trigger condition is negative, then the program hangs.

When using LATCHED_LEVEL triggered IRQs and asserting the trigger only for one clock cycle, ISR1 is executed one time and then the program hangs. With the same setting, when doing or1k_interrupts_disable() at the beginning of ISR1 and or1k_interrupts_enable() at its end, the program enters ISR2 after serving ISR1 and hangs up.

I am using mor1kx_cappuccino. When triggering the IRQs one after the other (so there is only one IRQ active at a time), both ISRs work and return correctly.

"hangs up" does not mean that it really hangs in the meaning that no instructions are processed anymore but at least it does not return to the correct point in the main program and so it does not continue in my case. It also seems that mor1kx_ctrl_cappuccino is trying to recover from some state repeatedly.

Best regards,
wwwweb

Icache updates the LRU access variable only if cache hits occur in the read state. There may be cache hits that occur in the state refill or invalidate. CPU gets back its requested data for these hits but the access information for such hits fails to update the LRU algorithm.

Case 1: Cache hit in refill state

Case 2: Cache hit in invalidate state

Tested with de0_nano 1.1, but pointed it to mor1kx master.

It fails with the following error.

Info (12128): Elaborating entity "mor1kx_rf_cappuccino" for hierarchy "de0_nano_core:core|mor1kx:mor1kx0|mor1kx_cpu:mor1kx_cpu|mor1kx_cpu_cappuccino:cappuccino.mor1kx_cpu|mor1kx_rf_cappuccino:mor1kx_rf_cappuccino"
Error (10198): Verilog HDL error at mor1kx_rf_cappuccino.v(275): part-select direction is opposite from prefix index direction File: /home/shorne/work/openrisc/fuse-builds/de0_nano_1.1/src/mor1kx_5.0-r3/rtl/verilog/mor1kx_rf_cappuccino.v Line: 275
Info (10499): HDL info at mor1kx_rf_cappuccino.v(275): see declaration for object "wb_rfd_adr_expand"
Error (12152): Can't elaborate user hierarchy "de0_nano_core:core|mor1kx:mor1kx0|mor1kx_cpu:mor1kx_cpu|mor1kx_cpu_cappuccino:cappuccino.mor1kx_cpu|mor1kx_rf_cappuccino:mor1kx_rf_cappuccino" File: /home/shorne/work/openrisc/fuse-builds/de0_nano_1.1/src/mor1kx_5.0-r3/rtl/verilog/mor1kx_cpu_cappuccino.v Line: 1131
Info (144001): Generated suppressed messages file /home/shorne/work/openrisc/fuse-builds/de0_nano_1.1/synth-quartus/de0_nano_1_1.map.smsg
Error: Quartus II 64-Bit Analysis & Synthesis was unsuccessful. 2 errors, 68 warnings
    Error: Peak virtual memory: 1283 megabytes
    Error: Processing ended: Wed Jan  9 22:33:16 2019
    Error: Elapsed time: 00:01:45
    Error: Total CPU time (on all processors): 00:00:20

This issue is applicable to the mor1kx_icache module. After resetting, the state moves to IDLE but spr_bus_ack_o can be high if spr strobe/write signals stays high during reset. This is possible as spr stb/we signals are not reset in the ctrl module.

Assertion Failed:

          always @(posedge clk)
               if ($past(rst) && f_past_valid)
                  assert (!spr_bus_ack_ic_i);

Trace showing issue:

Hi, when I try to compile the mor1x code by iverilog.

The iverilog show this

mor1kx/rtl/verilog/mor1kx_bus_if_avalon.v:17: syntax error
I give up.

I think if you just remove [3:0] from the code in that line, there will be fine.

In our or1k-tests suite the itlb_permission_test fails when the DMMU is disabled. This is reproduced in the github actions CI test suite (will commit soon).

The test case set's up some code and jumps to it expecting to generate page fault. But this may be wrong, there should be no page fault in supervisor mode.

Next in user more it tries to access the same code and expects a page fault again. There are several issues around page faults pointed out in the dtlb_permission_test too.

-------------------------------------------
itlb_permission_test set = 12
check 1 - page fault exec supervisor
report(0x0000053b);
report(0x00fae1ed);
exit(0x00000001);

Expected

-------------------------------------------
itlb_permission_test set = 12
check 1 - page fault exec supervisor
report(0x001f7357);
report(0x00418000);
check 2 - page fault exec user
-------------------------------------------
itlb_permission_test set = 13
check 1 - page fault exec supervisor
report(0x001f7357);
report(0x0041a000);
check 2 - page fault exec user
-------------------------------------------
...

Hi,

I have a problem using the debug unit in combination with the mor1kx espresso (GDB <-> OpenOCD <-> debug unit). When i read the registers they appear to be all 0 (i checked, their not). For some reason it appears the desired value is read to late and the date returned (in simulation) is all X.

Thanks!

I´m wondering if GLIP usage with FX3 backend and GDB debugging is supported anyhow ?
Or is a colaboration of JTAG and FX3 backend possible ?

@lifeasageek

When reading or writing shadow gprs through mfspr (mtspr),
it seems mor1kx_rf_cappuccino doesn't offset the register address.
(As the spec, SPR[1024+x] points to GPR_'x')

You can reproduce error through below instructions

18000000 l.movhi r0,0            
a8200001 l.ori   r1,r0,0x1       
c0000811 l.mtspr r0,r1,0x11      
15000000 l.nop   0               
c0010c0e l.mtspr r1,r1,0x40e 

Changing the code in mor1kx_rf_cappuccino.v as follow should solve this issue.

  assign rf_wradr = wb_rf_wb_i ? wb_rfd_adr_expand : (spr_bus_addr_i[RF_ADDR_WIDTH-1:0] - `RF_ADDR_WIDTH-1'h400);

https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx_dcache.v#L243

wire [TAG_WIDTH-1:0] check_way_tag [OPTION_DCACHE_WAYS-1:0];
...
assign check_way_tag[i] = tag_way_out[i][TAGMEM_WAY_WIDTH-1:0];

Though won't affect the design functionality, I suspect the assignment should read

assign check_way_tag[i] = tag_way_out[i][TAG_WIDTH-1:0];