Author Topic: BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.60.  (Read 56637 times)

0 Members and 1 Guest are viewing this topic.

Online BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #100 on: November 13, 2021, 07:56:17 am »


Please, just read the entire DDR3 datasheet and try things for yourself.
« Last Edit: November 13, 2021, 07:57:59 am by BrianHG »
 
The following users thanked this post: promach

Offline promach

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #101 on: November 23, 2021, 03:34:35 am »
Quote
You could say because of my mid FIFO, if it were a bit larger like 4 words enqueue, I have designed a hybrid half-rate controller with a full-rate controller's performance.  But with 2 words, I'm sort of stuck half way in-between where some situations are taken advantage of while others arent.

Which other situations are not taken advantage of ?


I understand that you are using synchronous FIFO in the above case of in-between commands. 
However, what about synchronizing asynchronous incoming multi-bits DQ signals from DRAM into FPGA ?
I suppose you would need an asynchronous FIFO ?
 

Online BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #102 on: November 23, 2021, 03:49:42 am »
For example, looking at my above screenshot, if my activate of bank 1 was done just before the last write of bank 0, the continuing write would not need that little blue gap where I wrote in red 'ongoing burst' as the continuing write now switching into bank 1 will have been fully activated.  We can extend this throughout while writing in bank 7 and next switching to a new bank 0, where if needed, while write bursting in bank 7, we can send a 'precharge' command, still continuing to write to bank 7, then the new activate bank 0 while still writing into 7, then seamlessly transition you write into the new activated bank 0 without any pause.  You can literally continuously read and write to DDR3 with strategic plan ahead precharge and activates making the ram access as continuous as static ram with the 1 caveat that every-time you switch between a read burst and write burst, there are a few dead 0 access clock cycles as the DDR3 needs time to transition from input to output.

During an unbroken burst, you send a command every 4 clocks to maintain optimum efficiency.  This means with a full rate controller, you can stuff 3 new commands in-between.  With a half-rate controller, your controller can only be fast enough to add 1 command in-between.  The other advantage of in-between commands is that you can activate and precharge unused banks in an effort to further manual refresh the DDR3 allowing the development of a controller which may almost never need waste any bus cycle time if you application processor is designed to access the DDR3 in a sequential burst manner.

When properly done, a smart controller and an application which can take advantage of bursting and knowledge of DDR3 banks can create a system with access close the the performance of high speed static ram.

This is why both my ram controller and Altera's as well have a parameter to set the address location of the 'BANK'-'ROW'-'COLUMN' order in the controller's addressing scheme.
« Last Edit: November 23, 2021, 03:53:56 am by BrianHG »
 
The following users thanked this post: promach

Online BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #103 on: November 23, 2021, 06:01:10 am »
You could say because of my mid FIFO, if it were a bit larger like 4 words enqueue, I have designed a hybrid half-I understand that you are using synchronous FIFO in the above case of in-between commands. 
However, what about synchronizing asynchronous incoming multi-bits DQ signals from DRAM into FPGA ?
I suppose you would need an asynchronous FIFO ?

Actually, for the DDR DQ, in my 400MHz command out section, I decode the instructions being sent out to detect when a read or write command is being sent.  That r/w decode will schedule my read data and write data FIFO serializers to send or capture / receive DDR data at the right time.  It is the job of my controller to make sure the write data is ready for the write by the time the write data needs to be sent.  For the read, well, if you miss it when the acknowledge / read data ready comes in, you missed it.
 

Online BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
 

Online BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #105 on: December 04, 2021, 09:49:35 am »
Next I will make my own sync generator and replace the DECA example junk.
Fix a bug where only the current display mode of 1080p@32bit color functions properly.
And remove the 1-line dualport buffer for a minimal sized dual-port ram.
 

Offline promach

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.50.
« Reply #106 on: December 12, 2021, 10:04:22 am »
Quote
I pipe enqueue multiple user request commands.  There are situations where a new bank may be activated while a previous write was just sent and a current burst is taking place.  This activate command is allowed immediately after the previous write command. 

Could the same bank interleave mechanism happen for write operations ?
And if yes, then I suppose there is no need for such pipe enqueue stuff ?




Quote
every-time you switch between a read burst and write burst, there are a few dead 0 access clock cycles as the DDR3 needs time to transition from input to output.

Why few dead 0 access clock cycles ?

 

Online BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.50.
« Reply #107 on: December 12, 2021, 10:24:49 am »
Quote
I pipe enqueue multiple user request commands.  There are situations where a new bank may be activated while a previous write was just sent and a current burst is taking place.  This activate command is allowed immediately after the previous write command. 

Could the same bank interleave mechanism happen for write operations ?
And if yes, then I suppose there is no need for such pipe enqueue stuff ?




Quote
every-time you switch between a read burst and write burst, there are a few dead 0 access clock cycles as the DDR3 needs time to transition from input to output.

Why few dead 0 access clock cycles ?
#1, Yes.  Opening and closing banks are separate of read and write data into any bank's activated row.  You may mess around with all other banks while you still are reading / writing on a different bank, or, at least give enough time for an ACT to become ready.
#2, Read the god damn DDR3 data sheet!  They have example illustrations on switching between read and write called read-to-write and write-to-read operations.  There are mandatory empty cycles as the DQ buffers and DQS switch direction and the DDR3 ram chip row amplifiers change drive current into the memory cap arrays.
 

Offline promach

  • Frequent Contributor
  • **
  • Posts: 875
  • Country: us
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.50.
« Reply #108 on: December 14, 2021, 05:07:53 pm »
Quote
During an unbroken burst, you send a command every 4 clocks to maintain optimum efficiency.  This means with a full rate controller, you can stuff 3 new commands in-between.  With a half-rate controller, your controller can only be fast enough to add 1 command in-between. 

I think the number of in-between commands shall not be limited by whether it is full-rate or half-rate controller.
Since it would only be using simple if-else clocked logic (inside fast clock domain, maybe 500MHz in your case), your controller should be able to achieve such goal without suffering from STA setup timing violation.

Please correct me if wrong.
 

Online BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.50.
« Reply #109 on: December 15, 2021, 03:21:04 am »
Quote
During an unbroken burst, you send a command every 4 clocks to maintain optimum efficiency.  This means with a full rate controller, you can stuff 3 new commands in-between.  With a half-rate controller, your controller can only be fast enough to add 1 command in-between. 

I think the number of in-between commands shall not be limited by whether it is full-rate or half-rate controller.
Since it would only be using simple if-else clocked logic (inside fast clock domain, maybe 500MHz in your case), your controller should be able to achieve such goal without suffering from STA setup timing violation.

Please correct me if wrong.
:-//  Ok, I have given you plenty enough already, just read my previous posts as the answer lies within.
Please stop asking for guidelines for altering your DDR3 controller here on my thread with my finished DDR3 controller.

    This thread is for those who have issues or need help implementing 'MY' controller in their designs, and, for those who wish to share their success stories & examples implementations using my DDR3 controller system.
« Last Edit: December 15, 2021, 11:36:53 am by BrianHG »
 
The following users thanked this post: voltsandjolts

Online BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #110 on: December 15, 2021, 05:15:31 am »
Hi Brian I'm back and I have made some changes.

SignalTap is very useful, thank you for mentioned it  :)

Tested with mowing video and the Rotate was now where real time ... right now I'm not interested in Rotate but 2 straight inputs
But for sure I would like to scale and rotate later

I have removed the flat cable and added in single wires (same length) so fit GPIO's
I have 2 HDMI inputs running 1920x1080@60 non sync in parallel from 2 BrighSign players

I place the 2 inputs side by side on the 4K buffer and can scroll to see the Left / Right transition and it pretty OK
I had some PSU issues and have spitted to more PSU's to avoid interference

I do have some noise here and there in the picture ... you can see in the black hole on the video
Not sure why, but I suspect the "wires" and potential wrong terminations


I would like to write to the DDR as 128 bit instead of 32 bit to lower the traffic to the DDR

Attached is the Quartus project

Link for video

Not sure why, but Nockieboy also had some occasional missing pixels during block fills in his 8-bit GPU thread using my DDR3 V1.00.  If it is actually the same problem, when we updated to V1.50 on the 8-bit GPU thread, all empty pixel fills disappeared.  (Improved multiport design...)  Note that with 1.50, if you need to be backwards compatible to the old separate read and write ports, just hard wire the write enable on 2 separate ports and you will achieve the same function.  And, don't forget to ASSIGN '0' to all the unused inputs as shown in my new simplified block diagram.
 

Offline Wiljan

  • Regular Contributor
  • *
  • Posts: 225
  • Country: dk
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #111 on: December 15, 2021, 08:58:58 am »
Not sure why, but Nockieboy also had some occasional missing pixels during block fills in his 8-bit GPU thread using my DDR3 V1.00.  If it is actually the same problem, when we updated to V1.50 on the 8-bit GPU thread, all empty pixel fills disappeared.  (Improved multiport design...)  Note that with 1.50, if you need to be backwards compatible to the old separate read and write ports, just hard wire the write enable on 2 separate ports and you will achieve the same function.  And, don't forget to ASSIGN '0' to all the unused inputs as shown in my new simplified block diagram.

Thank you for letting me know, that similar issues has been observed.

The project I was working on was to determinate if a video clip played across 2 HDMI output on the same PC card actually was in sync.

The HDMI output it was processed through several video processors as 2 individual signal and ended up on a a huge LED wall (20m wide x 3 m height) working in 5 zones (processors).

So when I saw your DDR3 /  HDMI output and I already did have the 2 HDMI input board where I have used a scope to measure the 2 x V-Sync which was perfect in Sync, I got the idea to make the  HDMI splitter showing half of HDMI A and half of HDMI B on the same HDMI output.

Due to it was not perfect working in time, We ended up using 2 x Bacho multi-format converter HDMI to SDI (you can convert across all frame-rates / resolution) so it doe have a full frame of memory inside ,,, also here we saw the sync issue on fast horizontal moving content, we desired to record the 2x SDI on some broadcast recorders and try to analyze frame by frame, at the time we also added in external gen-lock for the 2 Barcho units... and the problem was gone.
This confirmed the video out of the PC was perfect in sync  :)

So right now the there are no need for the setup anymore. however I would like for my own exercise try the 1.5 when I get some time over Christmas.

If there still are noise I will also try to "loop" HDMI input to HDMI output via the FPGA to see if the noise goes away

But I'm aware that the wiring I  have are no good for a reliable solution, I did even think if it would be work to make a PCB shield fitting the DECA board with 2 HDMI input , on the other hand you can buy cheap 4x 2k input to 1x4k output splitt units and some of them have quite many features


 

Online BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #112 on: December 15, 2021, 09:37:02 am »
(you can convert across all frame-rates / resolution) so it doe have a full frame of memory inside ,,, also here we saw the sync issue on fast horizontal moving content, we desired to record the 2x SDI on some broadcast recorders and try to analyze frame by frame, at the time we also added in external gen-lock for the 2 Barcho units... and the problem was gone.

Ignoring the issue with your HDMI decoder wiring to the DECA, you could do the same on the DECA going from 2 in to 1 except you would have to most likely use lower quality bi-linear or small bi-cubic scaling if you are resizing the source images.  But I do know with code I've done in the past, with the know-how, you can easily do better picture enhancement/processing routines in the DECA than whatever may be available in the mixing consoles you are currently using.  (Except for true 1080i upsampled motion-adaptive de-interlacing unless you dedicate the entire DECA completely to that 1 task.)

Quote
This confirmed the video out of the PC was perfect in sync  :)

This depends on videocard type, drivers and settings/selected video modes, it is not guaranteed.
 

Offline Wiljan

  • Regular Contributor
  • *
  • Posts: 225
  • Country: dk
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #113 on: December 15, 2021, 09:55:36 am »

Quote
This confirmed the video out of the PC was perfect in sync  :)

This depends on videocard type, drivers and settings/selected video modes, it is not guaranteed.

Absolutely .. it's a AMD dual head, and it was here all the discussion started if the problem was on the PC side or on the Wall side (I was in charge for the PC side) and a 3. party on the Wall side

I have a big interest in video processing, been working with broadcast for 30+ years  :o
 

Online BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.50.
« Reply #114 on: December 31, 2021, 07:51:00 pm »
Ok, the my BrianHG_GFX_VGA_Window_System is 90% functional.  Only the final layer alpha channel mixer is missing as I am now just averaging windows for testing, but they are all there with all their features.

I paused here because the ravage DDR3 memory access done by the BrianHG_GFX_VGA_Window_System with multiple windows simultaneously open, each deliberately configured with an odd number of row pixels and to eat up over 90% of the available bandwidth causes that one DDR3 read port in use by the graphics system to randomly freeze.  It's time to look at debugging my multiport section of my controller before I finish my last alpha-blend window layer mixing module of my window system.

A version 1.6 will soon be coming where I fix this DDR3 frozen read bug.
(Narrowed it down to using the multiport in Quarter-rate, the higher speed Half-Rate mode works fine.  It seems to be a congestion issue.)
« Last Edit: December 31, 2021, 10:04:02 pm by BrianHG »
 

Offline mfro

  • Regular Contributor
  • *
  • Posts: 208
  • Country: de
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.50.
« Reply #115 on: January 09, 2022, 02:52:14 pm »
Wanted to get serious with the BrianHG_DDR3_CONTROLLER after just playing (impressed  :-+) with it. Tried to replace a UniPHY DDR3 controller in one of my existing designs with it today, but failed miserably.

I'm a VHDL guy and it seems interfacing SystemVerilog designs with VHDL isn't really fully supported in Quartus. I implemented a VHDL component representing the BrianHG_DDR3_CONTROLLER_top module on the VHDL side that has the SystemVerilog parameters as VHDL generics but wasn't successful. It appears that it is not possible to map SystemVerilog parameters of any other types than plain integers or bit vectors.
E.g I was expecting that it should be possible to map a SystemVerilog bit parameter (as BHG_OPTIMIZE_SPEED) into a VHDL BIT generic, but all I get is
Code: [Select]
Error (10258): Verilog HDL error at BrianHG_DDR3_CONTROLLER_top.sv(116): unsupported type for Verilog parameter BHG_OPTIMIZE_SPEED
Tried to use an integer generic in the VHDL component instead. This was accepted on the VHDL side, but then failed on the SystemVerilog side as an invalid type.

Apparently, it is not possible to pass the SystemVerilog parameters as VHDL generics, so one either needs to do the parametrization on the SystemVerilog side or modify the interface.

Anybody more successful than myself in interfacing to VHDL?
Beethoven wrote his first symphony in C.
 

Online BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.50.
« Reply #116 on: January 09, 2022, 04:12:01 pm »
In SystemVerilog, when I say'

parameter bit [x:y] OPTIMIZE_SPEED = z
Note that the 'bit [x:y]' usually can be omitted and changed into an 'int' and the code should still function.
However, I have seen such parameters passed through VHDL as some VHDL of verilog do pass parameters.  Note that the 'bit [x:y]' parameter is similar to a limited logic/register with a limited bit range.  It the [x:y] is missing, it just means a single wire.

This is not my area of expertise.  Note that the Intel FPGA forum may have engineers who may have an answer for you.

If you are out of luck, one workaround which means not modifying my code may be adding a dummy 'mfro' BrianHG_DDR3_CONTROLLER_top_pre-vhdl.sv dummy box module and stuff all your parameters there while your  BrianHG_DDR3_CONTROLLER_top.vhd calls that dummy box.

Also verify Altera's 'Compiler Settings' / 'VHDL Input' and try using the 'VHDL 2008' settings instead of the default 'VHDL 1993'.

IE: When I use that 'bit ***', Instead of declaring the default parameter as 'constant integers', I am declaring them as 'constant standard logic' with so many bits.  This way, I plug them directly into my code and System Verilog will understand that I am passing for example an 16/10/8 bit constants or a 1 bit constant logic wires limiting the user from inputting defaults outside my allotted scope/field/range.  There has got to be a way within VHDL to pass the same logic arguments.
« Last Edit: January 09, 2022, 05:12:50 pm by BrianHG »
 

Online BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.50.
« Reply #117 on: January 09, 2022, 05:44:34 pm »
@mfro, one thing you can try is to Quartus to 'generate' a verilog instantiation template file for my project.  The new .v generated by quartus re-write the parameters in the older style calling my SystemVerilog module.  Maybe it will be easier to call that new .v from VHDL instead of my direct SystemVerilog.

Though, once you see how Quartus rewrote the parameters, maybe that will give you a clue on how to directly feed my module in VHDL.

Also, do not forget the reverse route.  Just make my wire my top design to the FPGA as I have in the examples, and within that, initiate the rest of your VHDL project inside the FPGA top.sv with all the CDM_xxx and other FPGA IO ports wired to your VHDL instantiation in the top.sv.
« Last Edit: January 09, 2022, 05:49:27 pm by BrianHG »
 

Offline mfro

  • Regular Contributor
  • *
  • Posts: 208
  • Country: de
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.50.
« Reply #118 on: January 09, 2022, 06:40:34 pm »
Thanks, Brian. Got it to work, eventually (I now have a compiler crash, but that's another story). At least it passes the stage where it maps the parameters.

It appears the SystemVerilog single bit parameters don't map to std_logic or bit in VHDL generics, but to a std_logic_vector(0 to 0) instead (studied the relevant chapter in the Quartus manual that doesn't really tell you much what maps to what, but the fact that it states the parameters are internally passed as strings inspired me to try a single bit vector instead.
Beethoven wrote his first symphony in C.
 
The following users thanked this post: BrianHG

Online BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.50.
« Reply #119 on: January 10, 2022, 03:55:28 pm »
@mfro, one thing you can try is to Quartus to 'generate' a verilog instantiation template file for my project.  The new .v generated by quartus re-write the parameters in the older style calling my SystemVerilog module.  Maybe it will be easier to call that new .v from VHDL instead of my direct SystemVerilog.

Doing a generate VHDL instantiation creates this file on one of my new projects: GPU_DECA_DDR3_top.cmp

Code: [Select]
-- Copyright (C) 2020  Intel Corporation. All rights reserved.
-- Your use of Intel Corporation's design tools, logic functions
-- and other software and tools, and any partner logic
-- functions, and any output files from any of the foregoing
-- (including device programming or simulation files), and any
-- associated documentation or information are expressly subject
-- to the terms and conditions of the Intel Program License
-- Subscription Agreement, the Intel Quartus Prime License Agreement,
-- the Intel FPGA IP License Agreement, or other applicable license
-- agreement, including, without limitation, that your use is for
-- the sole purpose of programming logic devices manufactured by
-- Intel and sold by Intel or its authorized distributors.  Please
-- refer to the applicable agreement for further details, at
-- https://fpgasoftware.intel.com/eula.


-- Generated by Quartus Prime Version 20.1 (Build Build 720 11/11/2020)
-- Created on Sun Jan 09 12:32:21 2022

COMPONENT GPU_DECA_DDR3_top
GENERIC ( GPU_MEM : INTEGER := 524288; ENDIAN : STRING := "Little"; PDI_LAYERS : STD_LOGIC_VECTOR(3 DOWNTO 0) := b"0001"; SDI_LAYERS : STD_LOGIC_VECTOR(3 DOWNTO 0) := b"0100";
ENABLE_TILE_MODE : STRING := "A(1,0,0,0,0,0,0,0)"; SKIP_TILE_DELAY : std_logic := '0'; ENABLE_PALETTE : STRING := "A(1,1,1,1,1,1,1,1)"; SKIP_PALETTE_DELAY : std_logic := '0';
HWREG_BASE_ADDRESS : INTEGER := 256; HWREG_BASE_ADDR_LSWAP : INTEGER := 240; PAL_BASE_ADDR : INTEGER := 4096; TILE_BYTES : INTEGER := 65536;
TILE_BASE_ADDR : INTEGER := 16384; FPGA_VENDOR : STRING := "Altera"; FPGA_FAMILY : STRING := "MAX 10"; BHG_OPTIMIZE_SPEED : std_logic := '1';
BHG_EXTRA_SPEED : std_logic := '1'; CLK_KHZ_IN : INTEGER := 50000; CLK_IN_MULT : INTEGER := 24; CLK_IN_DIV : INTEGER := 4;
DDR_TRICK_MTPS_CAP : INTEGER := 600; INTERFACE_SPEED : STRING := "Half"; DDR3_CK_MHZ : INTEGER := 300; DDR3_SPEED_GRADE : STRING := "-15E";
DDR3_SIZE_GB : INTEGER := 4; DDR3_WIDTH_DQ : INTEGER := 16; DDR3_NUM_CHIPS : INTEGER := 1; DDR3_NUM_CK : INTEGER := 1;
DDR3_WIDTH_ADDR : INTEGER := 15; DDR3_WIDTH_BANK : INTEGER := 3; DDR3_WIDTH_CAS : INTEGER := 10; DDR3_WIDTH_DM : INTEGER := 2;
DDR3_WIDTH_DQS : INTEGER := 2; DDR3_RWDQ_BITS : INTEGER := 128; DDR3_ODT_RTT : INTEGER := 40; DDR3_RZQ : INTEGER := 40;
DDR3_TEMP : INTEGER := 85; DDR3_WDQ_PHASE : INTEGER := 270; DDR3_RDQ_PHASE : INTEGER := 0; DDR3_MAX_REF_QUEUE : STD_LOGIC_VECTOR(3 DOWNTO 0) := b"1000";
IDLE_TIME_uSx10 : STD_LOGIC_VECTOR(6 DOWNTO 0) := b"0001010"; SKIP_PUP_TIMER : std_logic := '0'; BANK_ROW_ORDER : STRING := "ROW_BANK_COL"; PORT_ADDR_SIZE : INTEGER := 30;
PORT_TOTAL : INTEGER := 5; PORT_MLAYER_WIDTH : STRING := "A(2,2,2,2)"; PORT_VECTOR_SIZE : INTEGER := 16; READ_ID_SIZE : INTEGER := 4;
DDR3_VECTOR_SIZE : INTEGER := 5; PORT_CACHE_BITS : INTEGER := 128; CACHE_ADDR_WIDTH : INTEGER := 4; BYTE_INDEX_BITS : INTEGER := 11;
PORT_TOGGLE_INPUT : STRING := "A(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)"; PORT_R_DATA_WIDTH : STRING := "A(000001000,000001000,000010000,000010000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000)"; PORT_W_DATA_WIDTH : STRING := "A(000001000,000001000,000010000,000010000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000)"; PORT_PRIORITY : STRING := "A(11,10,00,00,10,00,00,00,00,00,00,00,00,00,00,00)";
PORT_READ_STACK : STRING := "A(16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16)"; PORT_W_CACHE_TOUT : STRING := "A(100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000)"; PORT_CACHE_SMART : STRING := "A(1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)"; PORT_DREG_READ : STRING := "A(1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)";
PORT_MAX_BURST : STRING := "A(100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000)"; SMART_BANK : std_logic := '0' );
PORT
(
ADC_CLK_10 : IN STD_LOGIC;
MAX10_CLK1_50 : IN STD_LOGIC;
MAX10_CLK2_50 : IN STD_LOGIC;
KEY : IN STD_LOGIC_VECTOR(1 DOWNTO 0);
LED : OUT STD_LOGIC_VECTOR(7 DOWNTO 0);
CAP_SENSE_I2C_SCL : INOUT STD_LOGIC;
CAP_SENSE_I2C_SDA : INOUT STD_LOGIC;
AUDIO_BCLK : INOUT STD_LOGIC;
AUDIO_DIN_MFP1 : OUT STD_LOGIC;
AUDIO_DOUT_MFP2 : IN STD_LOGIC;
AUDIO_GPIO_MFP5 : INOUT STD_LOGIC;
AUDIO_MCLK : OUT STD_LOGIC;
AUDIO_MISO_MFP4 : IN STD_LOGIC;
AUDIO_RESET_n : INOUT STD_LOGIC;
AUDIO_SCL_SS_n : OUT STD_LOGIC;
AUDIO_SCLK_MFP3 : OUT STD_LOGIC;
AUDIO_SDA_MOSI : INOUT STD_LOGIC;
AUDIO_SPI_SELECT : OUT STD_LOGIC;
AUDIO_WCLK : INOUT STD_LOGIC;
FLASH_DATA : INOUT STD_LOGIC_VECTOR(3 DOWNTO 0);
FLASH_DCLK : OUT STD_LOGIC;
FLASH_NCSO : OUT STD_LOGIC;
FLASH_RESET_n : OUT STD_LOGIC;
G_SENSOR_CS_n : OUT STD_LOGIC;
G_SENSOR_INT1 : IN STD_LOGIC;
G_SENSOR_INT2 : IN STD_LOGIC;
G_SENSOR_SCLK : INOUT STD_LOGIC;
G_SENSOR_SDI : INOUT STD_LOGIC;
G_SENSOR_SDO : INOUT STD_LOGIC;
HDMI_I2C_SCL : INOUT STD_LOGIC;
HDMI_I2C_SDA : INOUT STD_LOGIC;
HDMI_I2S : INOUT STD_LOGIC_VECTOR(3 DOWNTO 0);
HDMI_LRCLK : INOUT STD_LOGIC;
HDMI_MCLK : INOUT STD_LOGIC;
HDMI_SCLK : INOUT STD_LOGIC;
HDMI_TX_CLK : OUT STD_LOGIC;
HDMI_TX_D : OUT STD_LOGIC_VECTOR(23 DOWNTO 0);
HDMI_TX_DE : OUT STD_LOGIC;
HDMI_TX_HS : OUT STD_LOGIC;
HDMI_TX_INT : IN STD_LOGIC;
HDMI_TX_VS : OUT STD_LOGIC;
LIGHT_I2C_SCL : OUT STD_LOGIC;
LIGHT_I2C_SDA : INOUT STD_LOGIC;
LIGHT_INT : INOUT STD_LOGIC;
MIPI_CORE_EN : OUT STD_LOGIC;
MIPI_I2C_SCL : OUT STD_LOGIC;
MIPI_I2C_SDA : INOUT STD_LOGIC;
MIPI_LP_MC_n : IN STD_LOGIC;
MIPI_LP_MC_p : IN STD_LOGIC;
MIPI_LP_MD_n : IN STD_LOGIC_VECTOR(3 DOWNTO 0);
MIPI_LP_MD_p : IN STD_LOGIC_VECTOR(3 DOWNTO 0);
MIPI_MC_p : IN STD_LOGIC;
MIPI_MCLK : OUT STD_LOGIC;
MIPI_MD_p : IN STD_LOGIC_VECTOR(3 DOWNTO 0);
MIPI_RESET_n : OUT STD_LOGIC;
MIPI_WP : OUT STD_LOGIC;
NET_COL : IN STD_LOGIC;
NET_CRS : IN STD_LOGIC;
NET_MDC : OUT STD_LOGIC;
NET_MDIO : INOUT STD_LOGIC;
NET_PCF_EN : OUT STD_LOGIC;
NET_RESET_n : OUT STD_LOGIC;
NET_RX_CLK : IN STD_LOGIC;
NET_RX_DV : IN STD_LOGIC;
NET_RX_ER : IN STD_LOGIC;
NET_RXD : IN STD_LOGIC_VECTOR(3 DOWNTO 0);
NET_TX_CLK : IN STD_LOGIC;
NET_TX_EN : OUT STD_LOGIC;
NET_TXD : OUT STD_LOGIC_VECTOR(3 DOWNTO 0);
PMONITOR_ALERT : IN STD_LOGIC;
PMONITOR_I2C_SCL : OUT STD_LOGIC;
PMONITOR_I2C_SDA : INOUT STD_LOGIC;
RH_TEMP_DRDY_n : IN STD_LOGIC;
RH_TEMP_I2C_SCL : OUT STD_LOGIC;
RH_TEMP_I2C_SDA : INOUT STD_LOGIC;
SD_CLK : OUT STD_LOGIC;
SD_CMD : INOUT STD_LOGIC;
SD_CMD_DIR : OUT STD_LOGIC;
SD_D0_DIR : OUT STD_LOGIC;
SD_D123_DIR : INOUT STD_LOGIC;
SD_DAT : INOUT STD_LOGIC_VECTOR(3 DOWNTO 0);
SD_FB_CLK : IN STD_LOGIC;
SD_SEL : OUT STD_LOGIC;
SW : IN STD_LOGIC_VECTOR(1 DOWNTO 0);
TEMP_CS_n : OUT STD_LOGIC;
TEMP_SC : OUT STD_LOGIC;
TEMP_SIO : INOUT STD_LOGIC;
USB_CLKIN : IN STD_LOGIC;
USB_CS : OUT STD_LOGIC;
USB_DATA : INOUT STD_LOGIC_VECTOR(7 DOWNTO 0);
USB_DIR : IN STD_LOGIC;
USB_FAULT_n : IN STD_LOGIC;
USB_NXT : IN STD_LOGIC;
USB_RESET_n : OUT STD_LOGIC;
USB_STP : OUT STD_LOGIC;
BBB_PWR_BUT : IN STD_LOGIC;
BBB_SYS_RESET_n : IN STD_LOGIC;
GPIO0_D : INOUT STD_LOGIC_VECTOR(43 DOWNTO 0);
GPIO1_D : INOUT STD_LOGIC_VECTOR(22 DOWNTO 0);
DDR3_RESET_n : OUT STD_LOGIC;
DDR3_CK_p : OUT STD_LOGIC_VECTOR(DDR3_NUM_CK-1 DOWNTO 0);
DDR3_CK_n : OUT STD_LOGIC_VECTOR(DDR3_NUM_CK-1 DOWNTO 0);
DDR3_CKE : OUT STD_LOGIC;
DDR3_CS_n : OUT STD_LOGIC;
DDR3_RAS_n : OUT STD_LOGIC;
DDR3_CAS_n : OUT STD_LOGIC;
DDR3_WE_n : OUT STD_LOGIC;
DDR3_ODT : OUT STD_LOGIC;
DDR3_A : OUT STD_LOGIC_VECTOR(DDR3_WIDTH_ADDR-1 DOWNTO 0);
DDR3_BA : OUT STD_LOGIC_VECTOR(DDR3_WIDTH_BANK-1 DOWNTO 0);
DDR3_DM : OUT STD_LOGIC_VECTOR(DDR3_WIDTH_DM-1 DOWNTO 0);
DDR3_DQ : INOUT STD_LOGIC_VECTOR(DDR3_WIDTH_DQ-1 DOWNTO 0);
DDR3_DQS_p : INOUT STD_LOGIC_VECTOR(DDR3_WIDTH_DQS-1 DOWNTO 0);
DDR3_DQS_n : INOUT STD_LOGIC_VECTOR(DDR3_WIDTH_DQS-1 DOWNTO 0)
);
END COMPONENT;


It looks like Quartus knows about using the 'STD_LOGIC_VECTOR(0 DOWNTO 0) := ...
If fact, I'm assuming Quartus just made a VHDL compliant code to call my project...

In fact, they have it even simpler at:  BHG_EXTRA_SPEED : std_logic := '1';
« Last Edit: January 10, 2022, 04:47:37 pm by BrianHG »
 

Offline mfro

  • Regular Contributor
  • *
  • Posts: 208
  • Country: de
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.50.
« Reply #120 on: January 10, 2022, 07:00:28 pm »
doesn't work with BrianHG-DDR3-Controller_top.sv:

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

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.
Beethoven wrote his first symphony in C.
 
The following users thanked this post: BrianHG

Online vdp

  • Newbie
  • Posts: 1
  • Country: bg
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #121 on: January 17, 2022, 08:13:51 am »
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.

Edit: nevermind
« Last Edit: January 29, 2022, 07:22:36 am by vdp »
 

Online BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.50.
« Reply #122 on: January 28, 2022, 01:00:33 pm »
 :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.
« Last Edit: January 28, 2022, 01:42:22 pm by BrianHG »
 
The following users thanked this post: nockieboy

Offline davemuscle

  • Newbie
  • Posts: 9
  • Country: us
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.50.
« Reply #123 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:


Is this expected behavior?
Thanks.
 

Online BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7661
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.50.
« Reply #124 on: March 20, 2022, 05:24:34 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:
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.
« Last Edit: March 20, 2022, 05:35:11 pm by BrianHG »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf