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

0 Members and 1 Guest are viewing this topic.

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #25 on: August 16, 2021, 06:49:02 pm »
 >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D
 >:D   400MHz/800MTPS, Zero timing violations with 85C model   >:D
 >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D  >:D



V1.00 coming...
Just cleaning up and increasing the clearance by a bit more...
« Last Edit: August 16, 2021, 09:30:45 pm by BrianHG »
 

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #26 on: August 16, 2021, 10:09:38 pm »
Huge clearance boost, latest V1.00 build @ 400MHz...



Just compile testing a few different configuration, then some documenting the changes and the full V1.00 should be released tonight.

If it weren't for CLK[2] having that clock restriction to 405.19MHz (read data in clock) instead of the 450.05MHz restrictions on CLK[0] and CLK[1] (data out clocks),  I could have made a 450MHz controller with no timing violations at 85C.  However, make no mistake that this controller does run at 450MHz error free and can even be overclocked to 500MHz  (PLL Maxes out at 475MHz according to data sheet).  The minimum period restrictions are only the limitations of the DDR IO PIN buffer itself and it's required data hold time.

At 450MHz & 500MHz, my tuneable read data clock's has 5 out of 8 error free tuning positions.  At 400MHz, it is 6 out of 8 while at 300MHz, it is 7 out of 8.  Note that 8=theoretical perfect all 180 degree error free positions, nearly impossible unless I begin to use individual DQ PIN deskew-tuning calibration with picosecond alignment.  (Each tuning step is 22.5 degrees.)
« Last Edit: August 16, 2021, 10:53:53 pm by BrianHG »
 

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #27 on: August 17, 2021, 12:41:07 am »
Slowest fabric -8 build using the device 10M50DAF484C8GES set to 300MHz.



Note that the DECA eval board uses the fastest -6 Max10 fabric.
Note that Altera doesn't support DDR3 on -8 Max10/Cyclone V FPGA as the DDR buffer transceivers max out at 550MTPS instead of the required 600MTPS.  Though, my source code has the 'DDR_TRICK_MTPS_CAP' parameter function to allow you to get around this (used to break Quartus' 600MTPS limiter on my 800MTPS builds), otherwise, you could not do a full compile.  (The fitter and timing analyzer still performs the rest of their function properly recognizing the requested true 300MHz core frequency.)

Yes, you can now have a DDR3 controller on any slowest -8 Cyclone III / IV / V / Max10.
« Last Edit: August 17, 2021, 12:46:31 am by BrianHG »
 

Online Daixiwen

  • Frequent Contributor
  • **
  • Posts: 351
  • Country: no
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #28 on: August 17, 2021, 06:22:07 am »
That's really impressive for Cyclone devices.  :-+
 
The following users thanked this post: BrianHG

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #29 on: August 17, 2021, 07:08:55 am »
That's really impressive for Cyclone devices.  :-+
LOL, Cyclone III/IV has the fastest fabric in the series and can outperform Max10 & Cyclone V.  IE, it should compile with better FMAX than what I have accomplished here, though it's only about 10% faster.

It's been hell.
I've started our around 2 months ago with something which only occasionally worked after each build, even when under clocking the DDR3 at 250MHz.

Then, the 300MHz got a little more stable, but 350MHz was a fluke and I got to see 400MHz initialize once as well as a 450MHz fluke with horrible FMAX report and no other code in the FPGA like the graphics geometry engine and video output.  Once I begun with the 1080p output, it took a few weeks to stabilize the 300MHz, but adding the ellipse geometry unit killed that.  500Mhz was a fable dream.

Finally, 300MHz was stable and 350 not too reliable while 400 was dead until last week.  Some concentration and fine tuning, now 400MHz is a breeze and 300MHz is a given.  Even 500MHz surprisingly worked first shot, though, right now, 450MHz has a weird addressing bug, but it's not with the DDR3 controller, but in the extended 16 read/write channel multiport front end.

I'm almost done with some final tests and tweaks, I should have a rev 1.00 out in a day where it's only limiting factor is the top FMAX speed of the 16 channel multi-port module.  It looks like the best solution here will be to make an alternate fast strip-down version with 2 read, 2 write port designed for speed and pyramid style stacking support so you can have as many ports as you like, though ports deep in the pyramid will have an extended sequential pipe delay.  Stack it the way you like and you can have at least 1 read & write port right next to the DDR ram controller with a single pipe stage.
« Last Edit: August 17, 2021, 11:08:20 am by BrianHG »
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #30 on: August 17, 2021, 11:28:33 am »
Thumbs up BrianHG :-+ Github is waiting for your rev 1.0 >:D
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 
The following users thanked this post: BrianHG

Offline nockieboy

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #31 on: August 17, 2021, 11:55:08 am »
Latest version of the project tested and working fine on the DECA at 500MHz!!!!!  :wtf:

https://youtu.be/a1k106CNylI
« Last Edit: August 17, 2021, 04:58:21 pm by nockieboy »
 
The following users thanked this post: BrianHG

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #32 on: August 19, 2021, 09:10:51 am »
V1.00 update.

Just cleaned up a bunch of stuff and also got rid of all multicycle paths in the .sdc as they are no longer needed.

400 MHz with 100% timing in the black is easy to achieve, though sometimes you may need to change compile settings or change the compiler beginning 'SEED' number as it is still a stretch for Cyclone/MAX10 devices.  300MHz is a given...  Though overclocking to 450/500Mhz functions with a -6 MAX10, it is not something I'm officially supporting.

I have some documenting to do and a compile test for a Cyclone IV to verify that we reach the same FMAX range.  Then I will upload V1.00.
« Last Edit: August 19, 2021, 09:15:51 am by BrianHG »
 

Offline dmendesf

  • Frequent Contributor
  • **
  • Posts: 316
  • Country: br
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #33 on: August 22, 2021, 01:05:10 am »
Tried the 500MHz version in my DECA10 and it worked flawlessy. Looking formward for the 1.0 release. I plan to make a VHDL wrapper for it. Congratulations!
 
The following users thanked this post: BrianHG

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #34 on: August 22, 2021, 10:54:38 am »
V1.00 update:

One last thing to do.  I just need to do a Cyclone IV E build test tonight to make absolutely sure we reach FMAX with that series as well, then .zip everything and I'll be ready to upload everything.

IE: I need to re-assign a bunch of IOs from my Ellipse DECA demo switched to a Cyclone IV FPGA following Altera's recommended connections for external DDR memory, then compile...

I will also be doing the same for Cyclone V as that FPGA seems to be slower/lower power (yet higher density and designed for DDR3) than the Cyclone IV.
« Last Edit: August 22, 2021, 11:02:18 am by BrianHG »
 
The following users thanked this post: dmendesf

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #35 on: August 23, 2021, 03:42:38 am »
Ok, Cyclone III and Cyclone IV compiles and reached a true 400MHz FMAX.

But for some FN reason, Cyclone V's PLL isn't compatible with Cyclone III/IV/10 LP/Max 10/Arria II.

Yes, there is a different PLL megafunction dedicated just for the Cyclone V.  If I use the normal 'altpll', it wont support phase stepping on a Cyclone V.  So, I need to use Cyclone V's 'altera_pll' function which uses a shit load of strings to define it's settings and yet still has the same identical phase step tuning function as the 'altpll' other than it has many more clock outputs.  Something which I might not be able to handle with my current parameters auto-pll generator system.

Altera drives me nuts.  Max 10 will simulate and compile correctly using the old 'altddio_bidir', but will not output anything unless you use the new 'altera_gpio_lite'.  Cyclone V needs the new PLL, and at least wont compile, but uses the old 'altddio_bidir', but the Max 10 uses the old PLL but new IO scheme...

Once I get the Cyclone V pll working and test the FMAX, I'll upload V1.00.
 

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #36 on: August 24, 2021, 12:50:18 am »
V1.00 update:
Arrrrgggg, this Cyclone V -6 is a piece of crap.

Ok, I can reach 400MHz & 200MHz for the controller clocks at 0C, after an 11 minute compile, and after I falsely set the read clock phase offset to 1ps so that it would not remove that tune-able clock and merge it with my DDR_CK clock 0. (Yes, that BS is a thing...) But somehow, my multiport interface module's FMAX is 41MHz?

WTF? 41MHz?

Even the Cyclone III achieved 115MHz for this clock while CIV got 118MHz and Max10 got 114MHz.
How can the next generation of Cyclone devices drop so terribly in performance, yet they improved the IO speed compared to the Max10's 450MHz and CIII/CIV's 500MHz limit.  And yet, these guys compile in 4-5 minutes.  And only 3.5 minutes for the CycloneIII only using 1 CPU core with the old Quartus 13.0sp1.

It's 11 minutes a shot for the Cyclone V compiles.  I though I would just have to add and adapt it's PLL function.  Not investigate how the hell Quartus's fitter decides to optimize my core into a snail of a design.
« Last Edit: August 24, 2021, 04:29:17 pm by BrianHG »
 

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #37 on: August 25, 2021, 06:38:12 am »
V1.00 update.

Ok, I got a Cyclone-V-6 to run at 300MHz, just barely with advanced smart banking feature in the multiport module disabled.  (The stand alone DDR3_PHY ram controller can still run at 400/200MHz and it's smart bank management is always enabled.  It's been designed to run at speed on the most pathetically slow FPGA s ever...)

I'll stick V1.00 here, document the updates and upload 1.00.

My DDR3 PHY stand-alone controller can do over 300MHz easy on the C-V -6, it's just the multiport hub which has a devastating FMAX of 50% speed.  I'm also going to upload it to Intel's support with the C-IV-6 versions and ask why there is such a huge speed difference.

Setting up it's PLL was a nightmare with built in system bugs, parameters as fancy non-standard string types & the compiler simplifying out some crucial clocks which I needed to invent multiple work arounds.

V1.00 coming tonight...
« Last Edit: August 25, 2021, 07:29:42 am by BrianHG »
 

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #38 on: August 26, 2021, 02:28:54 am »
I don't know WTF is going on with this Cyclone V build, but, I have this once build where the 85C model has an FMAX of 204.33MHz and the 0C model has an FMAX of 203.29 MHz.   Yes.  You read right.  The colder model is 'SLOWER' than the hot model.  WTF?

Ok, need to do a bunch of builds...
 

Offline SpacedCowboy

  • Frequent Contributor
  • **
  • Posts: 292
  • Country: gb
  • Aging physicist
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #39 on: August 27, 2021, 03:56:57 am »
So, reporting back somewhat later than I expected, I have the bouncing ellipses running on the screen at 1080p, and it's FREAKING AWESOME  :clap:

Regarding the blue eye-destroyers, LEDs 3 through 7 are lit :)
 
The following users thanked this post: BrianHG

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #40 on: August 27, 2021, 07:44:10 am »
V1.00 FMAX results:

Files,  Description:

300MHz, Hypothetical Cyclone III-8 DDR3 System scrolling ellipse build to verify FMAX.
(Uses Quartus 13.0sp1)


400MHz, Hypothetical Cyclone III-6 DDR3 System scrolling ellipse build to verify FMAX.
(Uses Quartus 13.0sp1)



300MHz, Hypothetical Cyclone IV-8 DDR3 System scrolling ellipse build to verify FMAX.


400MHz, Hypothetical Cyclone IV-6 DDR3 System scrolling ellipse build to verify FMAX.



300MHz, functional DDR3 System scrolling ellipse with optional RS232 debug port demo for Arrow DECA eval board, but compiled for a -8.


400MHz, functional DDR3 System scrolling ellipse with optional RS232 debug port demo for Arrow DECA eval board.




400MHz, Hypothetical Cyclone V-6 DDR3 System scrolling ellipse build to verify FMAX.
( :-- FMAX FAILED  :-- )  Take a look at the multiport clock.


300MHz, Hypothetical Cyclone V-6 DDR3 System scrolling ellipse build to verify FMAX.
(PASSED, but with I had to disable some smart multiport features and this is a CV-6 :--)


300MHz, Hypothetical Cyclone V-7 DDR3 PHY Only controller with RS232 debug port build to verify FMAX.
(300MHz only, no multiport )  A CV-7  :--, not even a -8.  Compiling for a -8 leaves 4 clock domain crossing nets in the red even though the rest of the design including IO ports easily pass.


375MHz, Hypothetical Cyclone V-6 DDR3 PHY Only controller with RS232 debug port build to verify FMAX.
(375MHz only, no multiport  :-- ) Compiling for 400MHz reveals ~8 clock domain crossing nets in the red even though the rest of the design including IO ports easily pass.  In fact, this FPGA should have reached 500MHz.



I will be sending my code to Intel to see why their Cyclone V only gets 60% speed on my multiport commander module.  Maybe there is something in the compiler setting to help as the FPGA fabric of Cyclone V is radically different compared to all other Cyclone & MAX FPGAs.


Clocks [ 0 ],[ 1 ],[ 2 ] are the 400MHz DDR_CK, Write clock, read clock.
Clock  [ 3 ] is the DDR_CLK_50 200 MHz half speed clock, the interface speed of the Brian_DDR3_PHY_SEQ.
Clock  [ 4 ] is the DDR_CLK_25 100MHz quarter speed clock, currently set for the multiport COMMANDER module.
« Last Edit: September 03, 2021, 08:10:03 am by BrianHG »
 

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #41 on: August 27, 2021, 07:55:07 am »
BrianHD_DDR3 V1.00 system FPGA utilization reports:

300MHz_PHY_only.png - DDR3 controller with 1 read & write port to an 8 bit device build.


300MHz-8_ellipse.png - DDR3 controller random ellipse project with 4 ports, 128 bit access, 300MHz Max10-8.


300MHz_ellipse.png - DDR3 controller random ellipse project with 4 ports, 128 bit access, 300MHz Max10-6.


400MHz_ellipse.png - DDR3 controller random ellipse project with 4 ports, 128 bit access, 400MHz Max10-6.


450MHz_ellipse.png - DDR3 controller random ellipse project with 4 ports, 128 bit access, 450MHz Max10-6.


500MHz_ellipse.png - DDR3 controller random ellipse project with 4 ports, 128 bit access, 500MHz Max10-6.



I've included a few builds.  You will notice that the LC/LUT increases with frequency.  This is most likely the compiler adding duplicate parallel logic cells to improve FMAX timing.


I highlighted the 'BrianHG_PHY_SEQ' module which tells you the full LC/LUT count is you were to build a stand-alone 1 read/write port DDR3 controller.

The COMMANDER module is the multiport handler configured with 2 read and 2 write ports in the ellipse demo.
« Last Edit: August 27, 2021, 07:53:50 pm by BrianHG »
 

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #42 on: August 27, 2021, 08:35:35 am »
******************************************
******** Finally, V1.00 release here: ***********
******************************************
https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/

Things to do:

a)  I will be contacting Intel's technical support about Cyclone V's poor 60% speed FMAX performance for my 1 multiport section in my design as seen in the above screenshots with the red arrow.  I'll see if something can be done.

b)  As described in my v0.95 notes, I will look into designing my simpler pyramid stack-able 2:1 multiport module aimed to achieve an FMAX of at least 200MHz allowing multiport running at Half rate interface controller speed, but with a loss of a few smart advanced features.

c)  I will download and install the latest Lattice Diamond and see if I can adapt and get my controller to compile and simulate there.  The LFE5U-45F/LFE5U-85F at 45kgate & 85kgate are just such a price bargain at 16$ and 36$ each respectively and if my DDR3 controller runs fast there, it is the next route to take.
« Last Edit: August 28, 2021, 11:29:15 pm by BrianHG »
 
The following users thanked this post: nockieboy, SpacedCowboy

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #43 on: August 28, 2021, 09:21:17 pm »
OMG, learning how to use Github with it's esoteric project generation and file entry is not treating me well.  I'm wondering if it is worth the hassle.
 

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #44 on: August 29, 2021, 01:46:00 am »
Arrrg, is Github a place to share some projects / source code, or, is it a place where you have to learn a bunch of their own esoteric terms and learn an entire new mix of text and web-page click OS just to post some .zop or source code.  And, I don't see any official support for HDL firmware languages, though I do know people do post such code there.

Ok, can I assume I am not allowed to upload a .zip file to GitHub?
How do I get Quartus binaries uploaded to my 'Repository'?
Or, do I somehow place these files within my listed 'Projects' which appear to have no consequences or arent even searchable?
« Last Edit: August 29, 2021, 01:58:30 am by BrianHG »
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3971
  • Country: nz
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #45 on: August 29, 2021, 02:48:14 am »
On github just create a new empty repository (in the menu on the top right of the web page). Hit the green CODE button and copy the ssh URL you find there there.

In your local git repo type "git remote add github <url>" then "git push github"

If you don't already have a local git repo then that's the first step. cd into your project directory and type "git init" and then "git add FOO" where FOO is a file or directory or whitespace separated list of files or directories. Repeat for everything you want sent to github i.e. source code and config files, not output files. Then type "git commit -m 'Initial commit'". And then follow the instructions above to deal with github.
« Last Edit: August 29, 2021, 02:50:17 am by brucehoult »
 
The following users thanked this post: BrianHG

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #46 on: August 29, 2021, 07:22:00 am »
As A side note on how to add every thing in the git repo you can do as flow
if you need to not include some parts from github, like the project outputs you can use a .gitignore file with the directories and files that you don't want to include.


git init
git add .
git commit -m "Ininit repo"
git remote add github <url>
git push github
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 
The following users thanked this post: BrianHG

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #47 on: August 29, 2021, 09:22:50 pm »
If you don't already have a local git repo then that's the first step. cd into your project directory and type "git init" and then "git add FOO" where FOO is a file or directory or whitespace separated list of files or directories. Repeat for everything you want sent to github i.e. source code and config files, not output files. Then type "git commit -m 'Initial commit'". And then follow the instructions above to deal with github.
What do you mean by ', not output files.'?

For example, my Quartus projects do have some binary files and may include a hex file.

Also, when I copy and paste ASCII files/show readme files, why does all my carriage returns disappear?
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #48 on: August 30, 2021, 12:06:14 am »
You can use TortoiseGit utility if you don't feel like messing with command line. That's what I use all the time - I have a Synology NAS which has a private Git server installed. I use Git even for projects that I don't intend to ever publish, as it makes development much easier.
 
The following users thanked this post: BrianHG

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3971
  • Country: nz
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #49 on: August 30, 2021, 02:19:13 am »
If you don't already have a local git repo then that's the first step. cd into your project directory and type "git init" and then "git add FOO" where FOO is a file or directory or whitespace separated list of files or directories. Repeat for everything you want sent to github i.e. source code and config files, not output files. Then type "git commit -m 'Initial commit'". And then follow the instructions above to deal with github.
What do you mean by ', not output files.'?

You don't include output files in a SOURCE CODE control system because they are not source code. The outputs of compilation or synthesis and routing, or whatever it is your project does (I'm talking in general terms here) change every time you run the build process. AND anyone who checks out the project will generate them themselves, from the source files.

If you want to put bitstreams or something somewhere so that people don't have to run synthesis themselves, that's a binary release, which is a different thing. Github has a different place to put releases (or you can put them on any web or ft server etc).

Quote
For example, my Quartus projects do have some binary files and may include a hex file.

If those are inputs to the process then that is fine.

Quote
Also, when I copy and paste ASCII files/show readme files, why does all my carriage returns disappear?

What do you mean "copy and paste"?

Whatever you put into git comes back out absolutely byte identical to what you put in. There is no line ending translation. Git handles binary files just fine, and in fact treats text as binary e.g. diffs are by bytes not lines.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf