Electronics > FPGA

FPGA VGA Controller for 8-bit computer

<< < (607/630) > >>

BrianHG:
before sending out any Modelsim .zip, please delete TB_v15.code-workspace and delete the 'work' directory and delete modelsim.ini, and delete vlog.opt and delete vsim.wlf to flush everything blank.  You just want a clean tiny project.

And what you sent me, (though I did the deleting first) seems to run completely fine.

Do you have the project in a folder where modelsim has write privileges?
What about the C:\tmp folder for the DDR3 bank files?
(If it is the C:\tmp write privileges, then I know you never ran a single DDR3 testbench of mine.)

nockieboy:

--- Quote from: BrianHG on December 02, 2021, 10:35:15 am ---before sending out any Modelsim .zip, please delete TB_v15.code-workspace and delete the 'work' directory and delete modelsim.ini, and delete vlog.opt and delete vsim.wlf to flush everything blank.  You just want a clean tiny project.

And what you sent me, (though I did the deleting first) seems to run completely fine.

Do you have the project in a folder where modelsim has write privileges?
What about the C:\tmp folder for the DDR3 bank files?
(If it is the C:\tmp write privileges, then I know you never ran a single DDR3 testbench of mine.)
--- End quote ---

Yeah, sorry about that, the DDR3 testbench always ran fine on the old one - then I realised I'd forgotten to update tmp_model_dir value in ddr3.v (with a Windoze-compatible path) in the new TB. ::)

Got meetings now - might get a chance to review the simulation later this afternoon.

nockieboy:
Okay, this is interesting.  According to the test bench (see screenshot below), the TAP port doesn't go live with data for quite a while after reset, presumably because it's waiting for more data to hit the DDR3 control buffer before writing to the memory to reduce writing?

In any case, as you can see in the screenshot, the simulation is writing to memory address 0x00000002 with data 0xAA.   This should be interpreted as HW_Reg[2], but it looks like TAP_ADDR is wrong?  It's showing an address of 0x00000000, but that should be 0x00000002?  The data and write mask appear correct, however the HW_Regs are not updating correctly either.  Instead of them changing to "10 00 AA 00 55 00 xx xx xx xx xx xx xx xx xx xx", they change to "10 00 10 00 55 00 xx xx xx xx xx xx 00 xx xx xx".

Is this to do with the endian issue you've alluded to or some other problem?  Either way, TAP_ADDR is wrong and the wrong data is being written to the wrong HW_Reg.  All in all, not a good start for me! ;)

[attach=1]

BrianHG:
Why didn't you simplify your sim display to Z80 bus / HW_REGS only and click on the ' + ' on the HW_REGS, zoom out, so you can see what's going on like I did?

SEE:


Also, why do you have 16regs only, I said to use 64 so you can at least go above 1 single 128bit wide WDATA all at address 16'h0000.

And again, why did you choose such poor test write data which wouldn't give you a clue to the actual problem, why not try these Z80 writes (inside Z80_cmd_stimulus.txt) to see what is going on:

--- Code: ---@LOG_FILE Z80_cmd_stimulus_log.txt
@RESET

@CMD WM 0000 aa     Write to memory address
@CMD WM 0001 11     Write to memory address
@CMD WM 0002 22     Write to memory address
@CMD WM 0003 33     Write to memory address
@CMD WM 0004 44     Write to memory address
@CMD WM 0005 55     Write to memory address
@CMD WM 0006 66     Write to memory address
@CMD WM 0007 77     Write to memory address
@CMD WM 0010 10     Write to memory address
@CMD WM 0020 20     Write to memory address
@CMD WM 0030 30     Write to memory address
@CMD WM 0040 40     Write to memory address
@CMD WM 0050 50     Write to memory address
@CMD WM 1110 BB     Write to memory address
@CMD WM 2210 CC     Write to memory address
@CMD WM 3310 DD     Write to memory address

--- End code ---

Now do not look at this line, see if you can figure out the problem by yourself first:
for (i = 0; i < PORT_CACHE_BITS/8; i = i + 1) if (valid_wr && WMASK[i ^ ENDIAN]) HW_REGS[( ADDR_IN[HW_REGS_SIZE-1:0] | (i^(PORT_CACHE_BITS/8-1)) )] <= DATA_IN[i*8+:8] ;

Next, work out why the 'ENDIAN' only messes up then entire HW_REG system, why you need to get rid of it and why making new IO port with the same output reg renamed to 8bit and these new assigned output wires would help provide a better solution:

--- Code: ---)(

        input                               RESET,
        input                               CLK,
        input                               WE,
        input          [PORT_ADDR_SIZE-1:0] ADDR_IN,
        input         [PORT_CACHE_BITS-1:0] DATA_IN,
        input       [PORT_CACHE_BITS/8-1:0] WMASK,
        output  reg                 [  7:0] HW_REGS_8bit[0:(2**HW_REGS_SIZE-1)]
        output  wire                [ 15:0] HW_REGS_16bit[0:(2**HW_REGS_SIZE-1)]
        output  wire                [ 31:0] HW_REGS_32bit[0:(2**HW_REGS_SIZE-1)]

);

--- End code ---

You may also do the 'reset' values in the same way for defaults which are 8bit, 16bit, or 32bit.

(BTW: I do not have a "D:\tmp" drive.  Also, isn't there a way to define the tmp folrder in the code instead of modifying Micron's ddr3.v source code + make that folder in the same folder as the work directory...)

BrianHG:
 :phew:
Here is the GPU project with the final BrianHG_DDR3_Controller_v15 release.
Consider all the files updated, including the .sdc file.
Let me know if it works properly.

The new complete BrianHG_DDR3_Controller v1.50 here:
https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3606415/#msg3606415
And here:
https://github.com/BrianHGinc/BrianHG-DDR3-Controller

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version