Author Topic: BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.60.  (Read 56326 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 #50 on: August 31, 2021, 01:57:51 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.
Ok, nice.  I went to Google tutorials on the tool.  Fine.  But still, just even the setup for TortoiseGit is super esoteric.  It's like I'm going back to the 90's with systems setups designed for insiders only.  A putty setup enviroment and public/private key generation + paste and copy URL address from my web browser display status of my generated repository into TortoiseGit.  Seriously, it's 2021.  Could you imagine having to go through this trouble to securely purchase anything on Amazon?

Still, it looks like I'm going to end up using TortoiseGit.
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #51 on: September 01, 2021, 03:54:38 am »
Ok, nice.  I went to Google tutorials on the tool.  Fine.  But still, just even the setup for TortoiseGit is super esoteric.  It's like I'm going back to the 90's with systems setups designed for insiders only.  A putty setup enviroment and public/private key generation + paste and copy URL address from my web browser display status of my generated repository into TortoiseGit.  Seriously, it's 2021.  Could you imagine having to go through this trouble to securely purchase anything on Amazon?

Still, it looks like I'm going to end up using TortoiseGit.
This is a typical example of what happens when you let developers design a user interface. Even after using it for many years professionally, I still stumble upon it every once in a while.

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #52 on: September 01, 2021, 05:44:46 am »
 

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #53 on: September 05, 2021, 04:19:36 am »
Finally!!!!  (Damn javascript bug finally bypassed...)

My GitHub repository release:
https://github.com/BrianHGinc/BrianHG-DDR3-Controller
« Last Edit: September 05, 2021, 08:06:57 am by BrianHG »
 

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #54 on: September 09, 2021, 08:06:24 am »
If anyone has seen some cheap or free Lattice ECP5 LFE5U-25/45/85F boards with at least 1 16 bit DDR3 ram chip and preferably and HDMI output, please link them here...

I am not interested in the LFE5UM as those require a Lattice Diamond License and the goal of my DDR3 controller is to offer a free solution for the most affordable Lattice components.
« Last Edit: September 09, 2021, 08:11:50 am by BrianHG »
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #55 on: September 09, 2021, 11:04:48 am »
Brian play with Gowin too, they are the cheapest,  also they promised to spin out a new chip this year with 12Gb SERDES and internal DDR4 Memory!
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #56 on: September 09, 2021, 05:26:01 pm »
Brian play with Gowin too, they are the cheapest,  also they promised to spin out a new chip this year with 12Gb SERDES and internal DDR4 Memory!
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.
 
The following users thanked this post: ali_asadzadeh

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14230
  • Country: fr
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #57 on: September 09, 2021, 05:28:55 pm »
If anyone has seen some cheap or free Lattice ECP5 LFE5U-25/45/85F boards with at least 1 16 bit DDR3 ram chip and preferably and HDMI output, please link them here...

Free? :-DD

There are very few boards with an ECP5. You have the Lattice dev boards, but they all come with an LFE5UM AFAIR.
Then there is the ULX3S, but no DDR3, just SDRAM. Also boards I mentioned earlier (which are repurposed boards from Colorlight) that you can find on Aliexpress. I have a couple. They are fine. HDMI connector, but no DDR3, only SDRAM...

One such board is the OrangeCrab, ECP5-25F, 1Gbit DDR3, no HDMI connector though, and limited IOs: https://1bitsquared.com/products/orangecrab

I don't know of anything else on the market at the moment.


 
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 #58 on: September 10, 2021, 08:19:23 am »
Quote
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
It's free but not open source. ;)
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline dolbeau

  • Regular Contributor
  • *
  • Posts: 86
  • Country: fr
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #59 on: September 11, 2021, 06:15:23 pm »
I am not interested in the LFE5UM as those require a Lattice Diamond License and the goal of my DDR3 controller is to offer a free solution for the most affordable Lattice components.

Zero idea about Lattice licensing, but the TrellisBoard has a LFE5UM5G-85F and is usable with the Yosys opensource toolchain, including the DDR3 SDRAM. So is the ECPIX5, which (unlike the TrellisBoard) is commercially manufactured.

The FOSS toolchain might not be able to reach the performance of the Lattice toolchain, but might be an interesting option to try nonetheless.
 
The following users thanked this post: BrianHG

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14230
  • Country: fr
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #60 on: September 11, 2021, 06:47:30 pm »
I am not interested in the LFE5UM as those require a Lattice Diamond License and the goal of my DDR3 controller is to offer a free solution for the most affordable Lattice components.

Zero idea about Lattice licensing, but the TrellisBoard has a LFE5UM5G-85F and is usable with the Yosys opensource toolchain, including the DDR3 SDRAM. So is the ECPIX5, which (unlike the TrellisBoard) is commercially manufactured.

As we mentioned, Lattice Diamond requires a subscription license for the LFE5UM. You can see this here: https://www.latticesemi.com/en/Products/DesignSoftwareAndIP/FPGAandLDS/LatticeDiamond

Those are nice boards otherwise, but the above point is certainly a problem...

The FOSS toolchain might not be able to reach the performance of the Lattice toolchain, but might be an interesting option to try nonetheless.

It's interesting. But beyond performance, there are other issues to consider. AFAIK, BrianHG uses SystemVerilog for his developments, and currently, Yosys only supports a subset of SV. I would expect a number of problems trying to compile his code with Yosys. Nonetheless, you can have a look there to check what could possibly be a problem, although they mention supported features - not the ones that aren't, and there are probably many - so I guess it'll be hard to tell before actually trying: https://github.com/YosysHQ/yosys

For those interested, there's a GHDL plugin for Yosys, potentially allowing to use VHDL with the Yosys-based toolchain. I admit I have never gotten around to trying it yet, but I'd be curious.
 
The following users thanked this post: BrianHG

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14230
  • Country: fr
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #61 on: September 12, 2021, 01:19:54 am »
Just adding a quick note about Yosys here, as this post finally decided me to take the plunge.

So, using the latest GHDL, Yosys, Prjtrellis and Nextpnr from git (warning: Yosys/Prjtrellis/Nextpnr take a fair amount of time to build from source), I was able to generate a .bit file from VHDL source files (+.lpf constraint file). The only modification I had to do was on the .lpf file, as nextpnr doesn't support port groups yet (which kind of bites, but that's not a dealbreaker). But all in all, it was smoother than I feared.

What I can say at this point is that Fmax is higher than what I get with Lattice Diamond for the design I tried, but I didn't dig enough to figure out if nextpnr is just being more optimistic, or if it indeed yields faster logic. This was a relatively simple design too, so that may not be as good for larger designs. Another point is that it all runs much faster than the commercial tools (but again, this is probably due, at least partly, to the fact that optimization is less aggressive.)

As I said, I don't know if SV support in Yosys is enough for Brian's work, but it could be worth a shot. With recent versions of GHDL and the combo with Yosys, VHDL support has become pretty good. So now, I'm curious to try this with larger designs.
« Last Edit: September 12, 2021, 01:21:43 am by SiliconWizard »
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 3972
  • Country: nz
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #62 on: September 12, 2021, 03:27:58 am »
I don't know for sure, but it would not surprise me if yosys was using sufficiently better algorithms than FPGA vendor's tools to get better results in a shorter time. It's had a significant and growing amount of work put into it and like most hardware manufacturers FPGA vendor probably don't want to "waste" any more money on software tools than absolutely necessary.

The same as eventually happened with gcc and llvm and the Linux kernel.
 

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #63 on: September 12, 2021, 04:35:24 am »
It's interesting. But beyond performance, there are other issues to consider. AFAIK, BrianHG uses SystemVerilog for his developments, and currently, Yosys only supports a subset of SV. I would expect a number of problems trying to compile his code with Yosys. Nonetheless, you can have a look there to check what could possibly be a problem, although they mention supported features - not the ones that aren't, and there are probably many - so I guess it'll be hard to tell before actually trying: https://github.com/YosysHQ/yosys


My SystemVerilog coding relies on 2 dimensional arrays for IO ports and 'genvar/generate/if' to render repetitious instances of a single module, each one pointing to incremented dimension in one of my 2D arrays.

Also, I use the attribute ' (*preserve*) logic [ x:x ] var_name [ 0:x ] ; ' to force the compiler to not simplify out that particular register bundle, force it to use logic cells to aid in speed optimization.

I also use parameters and localparams, with string support and have a number of 'task' in a few places.

If it can handle these plus 'if (x=y) $stop', 'if (x=y) $error' and '$display ("msg")' or '$warning ("msg")' during compile time, my code should work.

If 'yosys' can handle this much, then the rest of my code operates down at a simplistic regular 'Verilog' level and it should work.  (IE: I went to SystemVerilog exclusively for the 2D interconnected IO ports capability.)  The dumber the compiler, the better FMAX you can expect from my coding style.  (IE: Cranking up Altera's Quartus 'speed' optimizations to the max actually slows down my designs, optimize for Area and my FMAX usually goes through the roof...)

The problem is how many Lattice users use 'yosys' and with a fresh Win7 install and nothing else, can I get it running, or, do I require other utils and need to build it on my system?
« Last Edit: September 12, 2021, 04:42:02 am by BrianHG »
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14230
  • Country: fr
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #64 on: September 12, 2021, 09:46:04 pm »
It's interesting. But beyond performance, there are other issues to consider. AFAIK, BrianHG uses SystemVerilog for his developments, and currently, Yosys only supports a subset of SV. I would expect a number of problems trying to compile his code with Yosys. Nonetheless, you can have a look there to check what could possibly be a problem, although they mention supported features - not the ones that aren't, and there are probably many - so I guess it'll be hard to tell before actually trying: https://github.com/YosysHQ/yosys


My SystemVerilog coding relies on 2 dimensional arrays for IO ports and 'genvar/generate/if' to render repetitious instances of a single module, each one pointing to incremented dimension in one of my 2D arrays.

Also, I use the attribute ' (*preserve*) logic [ x:x ] var_name [ 0:x ] ; ' to force the compiler to not simplify out that particular register bundle, force it to use logic cells to aid in speed optimization.

I also use parameters and localparams, with string support and have a number of 'task' in a few places.

If it can handle these plus 'if (x=y) $stop', 'if (x=y) $error' and '$display ("msg")' or '$warning ("msg")' during compile time, my code should work.

If 'yosys' can handle this much, then the rest of my code operates down at a simplistic regular 'Verilog' level and it should work.  (IE: I went to SystemVerilog exclusively for the 2D interconnected IO ports capability.)  The dumber the compiler, the better FMAX you can expect from my coding style.  (IE: Cranking up Altera's Quartus 'speed' optimizations to the max actually slows down my designs, optimize for Area and my FMAX usually goes through the roof...)

The problem is how many Lattice users use 'yosys' and with a fresh Win7 install and nothing else, can I get it running, or, do I require other utils and need to build it on my system?

The easiest way of using Yosys on Windows is to use MSYS2, which has pre-built packages for Yosys.
https://www.msys2.org/
https://packages.msys2.org/group/mingw-w64-x86_64-eda

For a usable Yosys toochain, you'll need to install from MSYS2:
mingw-w64-x86_64-nextpnr
mingw-w64-x86_64-prjtrellis
mingw-w64-x86_64-yosys
(additionally, mingw-w64-x86_64-ghdl-llvm for those willing to use VHDL.)

This is done via the MSYS2 console with:
Code: [Select]
pacman -S mingw-w64-x86_64-nextpnr mingw-w64-x86_64-prjtrellis mingw-w64-x86_64-yosys
I have tried Yosys with more complex projects, and this wasn't as pain-free as with the first, simple one. Expect any Lattice generated IP, if you want to reuse this, to require some manual modifications. Also, some Lattice primitives may not be supported or not completely well.

I've found some oddities regarding VHDL support too (through the yosys ghdl plugin), while the same code using GHDL for simulation is fine...

So, not tried SV yet, but I would expect a number of unsupported features that may drive you nuts. Would be interesting to get feedback on this.

And if you need any generated IP, you're also in for a rough ride.

Lastly, there is no support, currently, for timing constraints for IOs in nextpnr (the P&R tool), which, for designs such as a DDR3 controller, could be a real problem.
 

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #65 on: September 17, 2021, 03:54:33 am »
LOL, the ~150 stock of Arrow Deca boards for the last 6 months have just all sold out in 2 days.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14230
  • Country: fr
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #66 on: September 17, 2021, 07:09:37 pm »
LOL, the ~150 stock of Arrow Deca boards for the last 6 months have just all sold out in 2 days.

You should get a commission. :-DD
 

Offline SpacedCowboy

  • Frequent Contributor
  • **
  • Posts: 292
  • Country: gb
  • Aging physicist
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #67 on: September 18, 2021, 12:43:45 am »
Well, I guess we'll now get to see if they were just selling off old stock to get rid, hence the low price, or if more will become available...
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14230
  • Country: fr
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #68 on: September 20, 2021, 12:13:49 am »
Just a note regarding SV support in Yosys and Brian's DDR3 controller.

I tried analyzing the SV files with Yosys, and get a bunch of syntax errors. SV support looks pretty preliminary.
I'm not good enough with SV to be able to help here. But someone who is could have a go if they're ready to issue a number of tickets in the Yosys project, and be patient.
Meanwhile, I'm afraid it's absolutely not an option. Yet.
 
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 #69 on: September 28, 2021, 03:36:02 am »
Ok, I thought some may want to know about DDR pin planning in Quartus.

I've attached 2 screenshots of Quartus' pin planner, 1 for Cyclone_IV and 1 for Max_10.

You will see that I have chosen x8 devices even though we are suing an x16 DDR3 ram chip.  I have done this since the x16 DDR3 actually has 2 groups of DQS basically making it 2 x8 devices.

Here is the Max_10 device:


As for the Cyclone_IV (included Cyclone III), you will notice that there exists the DQS, but not a DQS_n.  My DDR3 ram controller will still work, however, it requires you connect the DDR3's DQS_n to the adjacent DQS IO within the same x8 bank.  Preferably a emulated differential pair as long as it is within the same IO bank, even if it isn't highlighted as being part of the same x8 group.  (Quartus' reported polarity of this differential pair doesn't matter.  So long as the DQS pin is connected to the DQS on the DDR3 and the differential pair gets connected to DQS# on the DDR3 even if Quartus' pin planner says that the x8 DQS pin is the negative part of the differential pair.)


The data mask pins also need to be placed inside the same associated x8 group.

Remember to check the data sheets as some older Cyclones have higher IO performance on the top and bottom rows compared to the left and right sides.  You want to use the higher speed performance IOs.

The CK and CK_n pins should be a differential pair close to the center of everything if you are using more than 1 DDR3 ram chip, otherwise, either end or center will do.

Note that the MAX_10 devices as well as Cyclone_V do have a dedicated CK and CK_n pin for DDR3.  You will need to use these for your DDR3 CK/CK_n if you want full compatibility with Altera's DDR3 controller.

Download Arrow DECA's schematics to get a complete example of the DDR3 wiring.
« Last Edit: September 28, 2021, 04:09:51 am by BrianHG »
 

Offline Wiljan

  • Regular Contributor
  • *
  • Posts: 225
  • Country: dk
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #70 on: September 30, 2021, 02:15:48 pm »
Hi Brian

I got hold on 2 x TFP401 boards from https://learn.adafruit.com/adafruit-tfp401-hdmi-slash-dvi-decoder-to-40-pin-ttl-display
I got them to be able to measure on the V-sync on 2 x HDMI signals to see if the sync locked together (they were)

I then realizes I way back on  Cyclone III had a board from Bitec using the same chip TFP401 and I did look a bit into the datasheets and schematic.

So the TFP401 does decode a HDMI (up to 1920x1080@60) to 3 x 8bit R,G,B and sync and pixel clock and the do use 3v3 as output same as DECA GPIO pins.

So I have made some flat cable connection to the DECA board on GPIO J8

Code: [Select]
I have GND connection on a separate wire

GPIO0_D0 = B0
GPIO0_D1 = B1
GPIO0_D2 = B2
GPIO0_D3 = B3
GPIO0_D4 = B4
GPIO0_D5 = B5
GPIO0_D6 = B6
GPIO0_D7 = B7

GPIO0_D8 = G0
GPIO0_D9 = G1
GPIO0_D10 = G2
GPIO0_D11 = G3
GPIO0_D12 = G4
GPIO0_D13 = G5
GPIO0_D14 = G6
GPIO0_D15 = G7

GPIO0_D16 = R0
GPIO0_D17 = R1
GPIO0_D18 = R2
GPIO0_D19 = R3
GPIO0_D20 = R4
GPIO0_D21 = R5
GPIO0_D22 = R6
GPIO0_D23 = R7

GPIO0_D24 = GND (No Use)
GPIO0_D25 = PIXCLK
GPIO0_D26 = ACTIVE
GPIO0_D27 = HSYNC
GPIO0_D28 = VSYNC
GPIO0_D29 = DISPEN
GPIO0_D30 = NC
GPIO0_D31 = GND (No use)


So my question is if you could recommend how best to write those signal to the RAM ... I looking on the GFX_Demo in Q15

My idea was to also add the second TF401 on the the left over GPIO's and then show a part of the 2 HDMI inputs at the same time on the output.
Like a DVE (not need to scale)  just crop and move some area out of input 1 and 2 and combine them on the output.



Hope it makes sense
 

Offline Yansi

  • Super Contributor
  • ***
  • Posts: 3891
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #71 on: September 30, 2021, 02:59:26 pm »
Amazing work and thanks for sharing Brian!

I hope in the near future I will have the time and courage to finally start toying more seriously with the FPGAs and DDR3 will definitely come into play then.  Now back to my flat reconstruction and electronics lab rebuild.
 
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 #72 on: September 30, 2021, 11:52:56 pm »
@Wiljan, good luck.

  You would end up using the same strategy, but in reverse which my GFX demo 'BHG_vpg' uses.  Make a dual clock ram port buffer with 2 lines worth of buffer memory, 32bit aRGB in, 128 bit out.  Clock the input and make an active even/odd line & VS / HS / V_ENA all generated on the capture board's CLK input sampling active pixels into the dual port ram.  Transfer a copy of those 4 status flags to the CMD_CLK clock domain and make a reverse to my 'BrianHG_display_rmem' which will take the line buffer's 128bit side and store it into a selected ram address.

  Note that with work, you can optimize all the code to run on 24bit instead of 32bit graphics if you like, or use 16 RGB, or even use 4:2:2 16 bit YUV bit graphics if there are enough color for you giving you the ability to access and process mix 4x1080p screens/display buffers simultaneously in real time (16 bit color, ram at 400MHz) with still some free access time for a CPU core.

  The 128bit DDR3 access port is the only way to ensure you saturate your read and writes access to the DDR3 memory making a non-stop sequential burst.  You may also organize the available DDR3 ram so that you place a different graphics buffer or video frame in a different DDR3 bank location to optimize simultaneous frame access.

Yes, just re-hack up my 'BHG_vpg' and 'BrianHG_display_rmem' -> 'BHG_vpg_IN' and 'BrianHG_display_Wmem' as they already have 90% of what you need.

On the input side, you may 'crop' the DVE from the source with x-on and x-off start and stop coordinates.  You would need to adjust the DDR3 write width in your 'BrianHG_display_Wmem', or, just do everything in the  'BrianHG_display_Wmem' with the knowledge that you will start and stop every 4 pixels on the x axis for 32bit color.  Y axis will be adjustable line by line.

*Note that I did not include methods of figuring out what your source resolution is or interlace support.
« Last Edit: October 01, 2021, 03:17:52 am by BrianHG »
 

Offline BrianHGTopic starter

  • Super Contributor
  • ***
  • Posts: 7638
  • Country: ca
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #73 on: October 01, 2021, 05:35:16 am »
@Wiljan, one mistake:

Quote
just do everything in the  'BrianHG_display_Wmem' with the knowledge that you will start and stop every 4 pixels on the x axis for 32bit color.

My mistake, I forgot that you have the 'write mask' capability which will allow pixel precision writes down to 8 bit pixels while still using my multiport in 128bit mode to retain full sequential burst speed.  It's only the question of 128bit/4 pixel horizontal alignment.  There are ways to solve this as well at the CMD_CLK stage with a 4 position 224 bit to 128 bit shift register.

It is better to try to do any cropping and computation in the CMD_CLK domain while the sampler input to the dual port line buffer memory should have absolute minimal logic.
« Last Edit: October 01, 2021, 05:54:32 am by BrianHG »
 

Offline Wiljan

  • Regular Contributor
  • *
  • Posts: 225
  • Country: dk
Re: BrianHG_DDR3_CONTROLLER open source DDR3 controller.
« Reply #74 on: October 01, 2021, 05:53:26 pm »
Thank you Brian, I will for sure reuse most of your great code.
I will let you know when I  have some progress.
Thx 👍
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf