jtframe_ioctl_dump introduces a FF byte in region changes (sidi)

[jotego]

At least in SiDi, SD dumps appear with a wrong byte at region transitions. This can be seen on JTVIGIL commit f6e38d9 at bytes 0x1000 and 0x1800 which are dumped as 0xFF but they should not be that. The value expected at 0x1800 is the default value visible on screen via debug_view so it is easy to test.

Simulating the dump process with jtsim -q -video 3 -d JTFRAME_SIM_IODUMP=2 -w -d VERILATOR_KEEP_SDRAM does not seem to reproduce the problem. Although it shows a glitch in the part_addr signal:

Changing the logic and registering part_addr to prevent the glitch did not fix the problem. So it must be something else. I think this needs to be measured via JTAG to see where the problem is coming from.

Try to focus at the transition for bit sel[2] of jtframe_ioctl_dump (instantiated in jtvigil_game_sdram). It only dumps four bytes after it and the first one, which should be coming via the ioctl_aux input, is wrong.

[rp-jt]

In the module jtframe_ioctl_dump.v, I've tried applying these changes:

reg  [ 5:0] sel;
 wire [23:0] part_addr;
-reg  [23:0] offset;
+reg  [23:0] offset, part_addr_l;
+reg addr_l=0, addr_ll=0;
 
-assign part_addr = ioctl_addr - offset;
+assign part_addr = addr_l != addr_ll ? ioctl_addr - offset : part_addr_l;
 
 assign addr0_mx = sel[0] ? ioctl_addr[(AW0!=0?AW0-1:0):(AW0!=0?DW0>>4:0)] : addr0;
 assign addr1_mx = sel[1] ?  part_addr[(AW1!=0?AW1-1:0):(AW1!=0?DW1>>4:0)] : addr1;
@@ -128,6 +129,8 @@ assign din5_mx = ioctl_ram ? {DW5==16?2:1{ioctl_dout}} : din5;
 always @(posedge clk) begin
     sel    <= 0;
     offset <= 0;
+    {addr_l, addr_ll} <= {ioctl_addr[0],addr_l};
+    part_addr_l <= part_addr;
     if( ioctl_ram ) begin
         if     ( ioctl_addr < OS1 && AW0!=0) begin sel[0] <= 1; offset <= 0; end
         else if( ioctl_addr < OS2 && AW1!=0) begin sel[1] <= 1; offset <= OS1[23:0]; end

After using this compilation, the dumped value 0xFF persists in SiDi. However, it doesn't appear in Mister, at least in this compilation (need to check previous versions to see if the error is reproduced in Mister)

[rp-jt]

Independently from whether changes in the last comment were used or not, the wrong 0xFF value appears in dumps from both SiDi and SiDi128 but not from Mister

[gyurco]

Seems it's an issue in the firmware, which corrupts every 2048th byte.

[gyurco]

Uploaded a one-line fix directly to master, hope it won't cause any disturbance.

[jotego]

Thank you!
Is there a MiST firmware update needed too, or is it enough with the patch in the verilog module?

[gyurco]

Fortunately it works without a firmware change.

[jotego]

Thanks a lot for fixing this. @jtmiki