Electronics > FPGA

FPGA VGA Controller for 8-bit computer

<< < (608/631) > >>

BrianHG:
Well nockieboy, is my final release DDR3 v1.5 working fine?
Did you tune the Z80 read cache / WAIT output timing?
Did you solve the new HW_REGS code issue?

nockieboy:
Had a busy weekend, unfortunately.  Have just had time to compile the new project and quickly try it out with the BBCBASIC tests - getting no artefacts in the graphics so far. :-+


--- Quote from: BrianHG on December 06, 2021, 09:59:57 am ---Did you tune the Z80 read cache / WAIT output timing?
Did you solve the new HW_REGS code issue?
--- End quote ---

Nope.  Will maybe get some time later this week, depends how things go.  ::)

nockieboy:

--- Quote from: BrianHG on December 06, 2021, 09:59:57 am ---Did you tune the Z80 read cache / WAIT output timing?
--- End quote ---

From what I can tell from SignalTap, it looks like the default settings are working fine.  Not seeing any unnecessary WAITs being inserted when a cache-hit is achieved and no bad reads as a result of a cache miss and no WAIT.

nockieboy:

--- Quote from: BrianHG on December 06, 2021, 09:59:57 am ---Did you solve the new HW_REGS code issue?
--- End quote ---

Looks like it was writing each 16-bit value to the wrong address - i.e. for the first write (0xAA), it should have been writing to address 0, it was writing to 15-(the required address).  I don't know why it would do that and I'm struggling to get my head around what's going on with [i^ENDIAN] and OR-ing values together etc. :o


--- Quote from: BrianHG on December 02, 2021, 08:48:40 pm ---(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...)
--- End quote ---

Fixed this - although it still required an alteration to Micron's ddr3.v source code.  Changed the path from "D:\tmp" to just ".\tmp" - it now uses a folder called 'tmp' in the project directory.  Can find no reference to a command that allows me to change the tmp directory path outside of the source code, and frankly don't have the time to hunt it down when I have a working solution that (hopefully) won't cause issues at anyone else's end either.

Am I going along the right path with the changes I've made in the attached files?  Haven't sorted out the resets for the 16 and 32-bit regs, plus it all seems a bit wasteful in terms of gates duplicating all that data, but I'm sure there's probably a much simpler way of doing it all that you've got.

BrianHG:

--- Quote from: nockieboy on December 09, 2021, 10:51:04 am ---
--- Quote from: BrianHG on December 06, 2021, 09:59:57 am ---Did you solve the new HW_REGS code issue?
--- End quote ---

Looks like it was writing each 16-bit value to the wrong address - i.e. for the first write (0xAA), it should have been writing to address 0, it was writing to 15-(the required address).  I don't know why it would do that and I'm struggling to get my head around what's going on with [i^ENDIAN] and OR-ing values together etc. :o


--- Quote from: BrianHG on December 02, 2021, 08:48:40 pm ---(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...)
--- End quote ---

Fixed this - although it still required an alteration to Micron's ddr3.v source code.  Changed the path from "D:\tmp" to just ".\tmp" - it now uses a folder called 'tmp' in the project directory.  Can find no reference to a command that allows me to change the tmp directory path outside of the source code, and frankly don't have the time to hunt it down when I have a working solution that (hopefully) won't cause issues at anyone else's end either.

Am I going along the right path with the changes I've made in the attached files?  Haven't sorted out the resets for the 16 and 32-bit regs, plus it all seems a bit wasteful in terms of gates duplicating all that data, but I'm sure there's probably a much simpler way of doing it all that you've got.

--- End quote ---


--- Quote from: BrianHG on December 02, 2021, 08:48:40 pm ---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 ---

--- End quote ---

I said assigned wires, not new regs.

IE:
for loop
assign HW_REGS_16bit[ i ] = {HW_REGS_8bit[ i+0 ],HW_REGS_8bit[ i+1 ]};

similar for the 32bit assigns.

Swap the +0 and +1 depending on the endian setting.

Unused regs are "PRUNED" from the design automatically, otherwise, your original 160kbits of regs would excede the DECA's available 50kbit logic cells.

I have a feeling you will soon need to look at my tiny code in the 2 point size.
It is kind of obvious if the address you are writing to is going into the wrong memory location that you need to correct the write address.  Well, at least you have seen that much with my chosen test 'write data'.  Look at the pattern of where each write goes to into the HW_REGS regardless of the data which is being written.  Look at the write address in the SIM and where the write data ends up.  Maybe this hint will help.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

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