Electronics > FPGA

BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.60.

<< < (74/75) > >>

Andrp19n:
I didn't want to change source files except for test purposes. If I define "Cyclone V" family, I get this error:

Error (12024): WYSIWYG primitive "lcell_inst" is not compatible with the current device family

Editing helped me to bypass PLL compilation error. Anyway, I discarded all changes in source files, thanks for help!

About debugging. The only way to check ddr3 functionality for now on my board is trying to read/write some data

BrianHG:
@Andrp19n.  Ok, try my updated PLL source file.

Just set your FPGA_FAMILY on pgk_lib.vhd, line 22 to:

     FPGA_FAMILY :string := "Arria V GZ";

If you now use an unknows FPGA_FAMILY string, my PLL will also stop the compiler and spit out an error message in the compiler message window.


Also, if you get another Quartus compiler error, please include a few additional lines prior to the error message in the error log.



--- Code: ---// Version 1.3, April 5, 2024
//   *** New, added Arria V GX, GT, SX, ST, GZ pll support to line 288 & selecting which PLL at line 335.
//       Also added a $stop & $error message if the FPGA_FAMILY is Unknown at line 310.


--- End code ---

According to the datasheet, the fastest Arria Vs should officially achieve an 800MHz DDR3 controller, meaning an official 1.6gtps data rate.

However, since I cannot compile for the Arria V, I cannot tune the .sdc file.  However, with the existing entries where I list the optimum -8,-7-,6 optimum cyclone devices, the Arria V -5,-4,-3 may be inferred.

I've downloaded the full paid Quartus to see if I can get the 1 month free full support.  If it works, I'll know if everything will simulate and tune the best .sdc as my DDR3 controller uses an FPGA centered IO timing system.  Meaning: all the IO ports were just need to have a best possible minimal pin-to-pin skew.  At power-up, my controller then measures the return-read data timing read from the DDR3 automatically adjusting to the IO pin delays and PCB trace lengths.

Andrp19n:
Hi! Thank you! Pll error compilation has now disappeared. But I still get this error

Error (10232): Verilog HDL error at BrianHG_DDR3_COMMANDER_v16.sv(1683): index 15 cannot fall outside the declared range [7:0] for vector "mask_in"

I have MT41K512M8 memory, which has 8bit DQ. So I set these parameters:
DDR3_WIDTH_DQ = 8
DDR3_WIDTH_DM = 1
DDR3_WIDTH_DQS = 1

When these parameters are set as for 16bit DQ, this error doesn't appear. Only these 3 parameters and "FPGA_FAMILY" are different from defaults. Did I miss something?

BrianHG:

--- Quote from: Andrp19n on April 05, 2024, 01:51:36 pm ---Hi! Thank you! Pll error compilation has now disappeared. But I still get this error

Error (10232): Verilog HDL error at BrianHG_DDR3_COMMANDER_v16.sv(1683): index 15 cannot fall outside the declared range [7:0] for vector "mask_in"

I have MT41K512M8 memory, which has 8bit DQ. So I set these parameters:
DDR3_WIDTH_DQ = 8
DDR3_WIDTH_DM = 1
DDR3_WIDTH_DQS = 1

When these parameters are set as for 16bit DQ, this error doesn't appear. Only these 3 parameters and "FPGA_FAMILY" are different from defaults. Did I miss something?

--- End quote ---

I just compiled a 8-bit DDR3 version of my Cyclone IV project and it went fine.

The 'BrianHG_DDR3_COMMANDER_v16.sv' module has a width limit on the multiport read & write data widths:


--- Code: ---parameter bit [8:0]  PORT_R_DATA_WIDTH [0:15] = '{  8, 64, 32, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64},
parameter bit [8:0]  PORT_W_DATA_WIDTH [0:15] = '{  8, 64, 32, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64},
                                                // Use 8,16,32,64,128, or 256 bits, maximum = 'PORT_CACHE_BITS'
                                                // As a precaution, this will prune/ignore unused data bits and write masks bits, however,
                                                // all the data ports will still be 'PORT_CACHE_BITS' bits and the write masks will be 'PORT_CACHE_WMASK' bits.
                                                // (a 'PORT_CACHE_BITS' bit wide data bus has 32 individual mask-able bytes (8 bit words))
                                                // For ports sizes below 'PORT_CACHE_BITS', the data is stored and received in Big Endian. 

--- End code ---

Basically, with a single 8bit DDR3 ram chip, you cannot go above 64bits for each read and write channel.
IE: Only 8,16,32,64 bits on each channel are valid.


As for your ram chip settings, for a 4gb DDR3 ram chip with 8 bits, you should have: (MT41K512M8 – 64 Meg x 8 x 8 banks)


--- Code: ---parameter int        DDR3_SIZE_GB            = 4,                // Use 0,1,2,4 or 8.  (0=512mb) Caution: Must be correct as ram chip size affects the tRFC REFRESH period.
parameter int        DDR3_WIDTH_DQ           = 8,                // Use 8 or 16.  The width of each DDR3 ram chip.

parameter int        DDR3_NUM_CHIPS          = 1,                // 1, 2, or 4 for the number of DDR3 RAM chips.
parameter int        DDR3_NUM_CK             = 1,                // Select the number of DDR3_CK & DDR3_CK# output pairs.
                                                                 // Optionally use 2 for 4 ram chips, if not 1 for each ram chip for best timing..
                                                                 // These are placed on a DDR DQ or DDR CK# IO output pins.

parameter int        DDR3_WIDTH_ADDR         = 16,               // Use for the number of bits to address each row.
parameter int        DDR3_WIDTH_BANK         = 3,                // Use for the number of bits to address each bank.
parameter int        DDR3_WIDTH_CAS          = 10,               // Use for the number of bits to address each column.

--- End code ---

Again, my 'commander' module is only a multi-channel front-end, it has no DDR3 or Altera specific code.
I've attached my 8bit DDR3 CycloneIV project.  It contains my full multiwindow graphics subsystem with a drawing and scrolling algorythm with RS232 debugger.  It appears to compile fine.

BrianHG:
@Andrp19n, in the VHDL file you send me, pkg_lib.vhd:

Lines 63,64:

--- Code: --- PORT_R_DATA_WIDTH: array_of_std_logic_vector(0 to 15)(8 downto 0) := ("010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000");
PORT_W_DATA_WIDTH: array_of_std_logic_vector(0 to 15)(8 downto 0) := ("010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000","010000000");

--- End code ---

You have the read and write ports bit width set to 128.  Like I said, with a single 8bit DDR3, the maximum you can use is 64, otherwise you will get a compiler error.

The max port width for 16bit DDR3 would be 128 and the max port width for a 32bit DDR3 controller would be 256.

Maybe changing the "binary" representation into an integer would help catch these bugs.  On a hunch, I double checked by counting the binary '0's in your code.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod