Electronics > FPGA

BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.50.

<< < (25/31) > >>

mfro:
doesn't work with BrianHG-DDR3-Controller_top.sv:


--- Code: ---Error (283001): Can't create Component Declaration or Verilog Instantiation File for entity "BrianHG_DDR3_CONTROLLER_top" which has two or more dimensional ports

--- End code ---

Thanks anyway.

The std_logic mapping also appears to be wrong (at least, it doesn't compile). The only mapping that works for me is indeed to std_logic_vector(0 to 0) as posted.

I'm on Quartus 20.1, btw.

vdp:

--- Quote from: BrianHG on September 09, 2021, 05:26:01 pm ---I though Gowin already came with a free DDR3/4 controller IP.  Not much need for mine like with Lattice and Altera who charge an arm and a leg to hook up DDR3 ram.

--- End quote ---

Edit: nevermind

BrianHG:
 :phew: Ok, here is the new 2 page block diagram 'BrianHG_GFX_VGA_Window_System.pdf' block diagram and 'BrianHG_GFX_VGA_Window_System.txt' documentation for developers.

-Up to 64 window layers, with alpha blend transparency from layer-to-layer.
-In system real-time video mode switching support.
-Supports 32/16a/16b/8/4/2/1 bpp windows.
-Supports accelerated Fonts/Tiles stored in dedicated M9K blockram with resolutions of 4/8/16/32 X 4/8/16/32 pixels.
-Supports up to 1k addressable tiles/characters with 32/16a/16b/8/4/2/1 bpp, with mirror and flip.
-Each window has a base address, X&Y screen position & H&V sizes up to 65kx65k pixels.
-Independent bpp depth for each window.
-Optional independent or shared 256 color 32 bit RGBA palettes for each window.
-In tile mode, each tile/character's output with 8 bpp and below can be individually assigned to different portions of the palette.
-Multilayer 8 bit alpha stencil translucency between layers with programmable global override.
-Quick layer swap-able registers.
-Hardware individual integer X&Y scaling where each window output can be scaled 1x through 16x.

     My new BrianHG_DDR3_CONTROLLER_v16 which now has the multi-window VGA system demo should be uploaded in a few days.

davemuscle:
Hi. I'm attempting to write an Avalon wrapper for your controller. During my memory test sim I encountered this error with a write/readback sequence:
(all addresses are byte-addressed)

* Write 'data1' to 0x0000, readback and check against 'data1' (PASS)
* Write 'data2' to 0x1000, readback and check against 'data2' (PASS)
* Write 'data3' to 0x0000, readback and check against 'data3' (PASS)
* Write 'data4' to 0x0000, readback and check against 'data4' (FAIL, data3 received)
The fourth read doesn't issue any command to the DDR3 model, it just returns dirty data from the cache. I would expect the fourth write with fresh data to signal to the cache it needs to perform another read.

Here's the failed write/read:
[attachimg=1]

Is this expected behavior?
Thanks.

BrianHG:

--- Quote from: davemuscle on March 20, 2022, 04:35:50 pm ---Hi. I'm attempting to write an Avalon wrapper for your controller. During my memory test sim I encountered this error with a write/readback sequence:
(all addresses are byte-addressed)

* Write 'data1' to 0x0000, readback and check against 'data1' (PASS)
* Write 'data2' to 0x1000, readback and check against 'data2' (PASS)
* Write 'data3' to 0x0000, readback and check against 'data3' (PASS)
* Write 'data4' to 0x0000, readback and check against 'data4' (FAIL, data3 received)
The fourth read doesn't issue any command to the DDR3 model, it just returns dirty data from the cache. I would expect the fourth write with fresh data to signal to the cache it needs to perform another read.

Here's the failed write/read:

--- End quote ---
If you are using the multiport module and the read and write channel are on the same CMD_xxx[ # ] bus, and smart cache is enabled, then you should receive the new data as long as there is 1 spare clock between the 2.  However, I will try to replicate the bug later tonight both with and without that 1 spare clock.  If you are using a separate CMD_xxx[ # ] as a write channel and another one for the read channel, then yes, it is possible to have stale data in the cache.

Writes to the DDR3 are held off until either a new write is sent outside the current cached address, or, the write cache timer has reached 0 due to no additional writes on that port.  The current 'PORT_W_CACHE_TOUT' parameter default is set to 255 CMD_CLKS. This allows the cache module to coalesce multiple writes within the same 16 bytes before sending a write command to the DDR3.  Otherwise, if you were to write, with a 8 bit data mode port, 16 consecutive bytes, every single byte write will send a DDR3 command wasting a huge setup and burst-8-cycle to the DDR3 which wouldn't be needed until the last of the 16 bytes has been received.  The smart cache feature means if you are reading from the same address as the current coalescing writes, you will read the new data even though it has yet to be send to the DDR3.

My bug may be because a write's smart caching takes 1 clock cycle to transfer it's new data to the read cache's buffer side, but you appear to have plenty of time in your sim.  Remember, the read cache is there to perform the same function as the write cache.

If you are using a single port directly controlling my 'PHY' module, then there is no caching and you should see the correct data in order or read and write.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

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