Mathias

Unfortunately, the FPGA vendors have decided that this has to be a very complex and challenging thing to pull off, even though it should be trivial. The best way to connect the PS and PL would be to write your own AXI slave or master IP. This is difficult and beyond the scope of many peoples ability. FPGA vendors like this arrangement because their limited function AXI IP uses up huge amounts of PL resources and confines many within the walls of the IP garden.
Putting aside questions as to why you'd want to do what you propose here's one perspective.
Generally, in order to connect the PS with the PL you need to use the AXI bus interfaces provided in the ARM hardware. There are exceptions and a simple UART is one of them. The PS has a lot of interfaces that aren't being used on most ZYNQ boards. One happens to be a 2nd PS UART. You can 'export' the spare PS UART through the EMIO through the PL. Normally, one would connect EMIO signals to PL pins but you can just connect the TxD and RxD to logic in your PL.
From an HDL point of view there are alternates to complex AXI infrastructure. You can instantiate a BRAM controller in your board design and add a dual clock BRAM with one side exposed to the PL. Your HDL just uses the BRAM as normal and your PS can do read/write operations like any other memory connected to the PS. You are still wasting PL resources on AXI infrastructure but it does ease your PL design burden.
While if makes no sense to me I understand why it might be tempting to have a design with an embedded hard ARM processor complex and an additional soft processor in the PL. Conventional software design is just a lot more familiar and comfortable than logic design. The FPGA vendors know this too and will make you pay an exorbitant price for the convenience. But that's the way technology has always been; fast, cheap, simple, convenient has always been over-priced.
Here's a suggestion. Ditch the ZYNQ board. Buy an FPGA board like the ARTY-A7. Learn how to design logic in the HDL or your choice. It's like learning how to break horses. The first attempts will be a rough ride, but eventually you will end up having a greater appreciation for horses and a usable skill that doesn't rely on crutches like a MicroBlaze....

You may still want to work through more parts of the tutorial as ditching the Mig example core will save resources.

Theoretically, there's a lower limit to how fast you can operate DDR memory, but if you are trying to stuff a lot of design into a small part and are having timing closure issues you might try running the DDR controller PHY at a lower data rate. For a lot of applications it might still be plenty fast enough, if all you need is a large storage bucket; see part 2 of the tutorial.

Then again, sometimes one has to abuse the piggy bank a bit more vigorously in order to work with a platform more amendable toward fulfilling one's dream of glory. :)

Are you using the mig project file from Digilent or one that you created through the IP Wizard? I notice that Digilent only supplies sources for the Arty-S7-50.
I notice that your constraints file is for the Arty-S7-25 and the mig-a-prj has this line: <selected>7s/xc7s50-csga324</selected>
I'm not familiar with the Spartan 7 devices so I don't know if there are any clocking restrictions that are different than for other Series 7 devices. I don't see why the code as presented in your git would make Vivado think that sysclk is a LVCMOS33 signal or "Sub-optimal placement for a clock-capable IO pin".
I suspect that you might not be able to follow the tutorial exactly by providing the Mig controller IP a single 200 MHz clock ( or whatever value the datasheet says is in the range for a reference clock. ). You could try following the Digilent Mig reference for your board. The problem is that you will need another clock source for your other system clocks ad they will be unrelated to the DDR clock domain.
Vivado has a problem handling multiple create_clock constraints for the same signal. If you connect sysclk to an MMCM it will create it's own constraints file with a create_clock constraint and generate errors. Did you get a synthesis warning about over-riding this timing constraint? If your design connects sysclk to an MMCM then your toplevel constraint file should not have one. If you connect sysclk directly to HDL logic then you need to have the create_clock timing constraint in your constraint file. If you follow the Digilent Mig project and connect the 100 MHz sysclk directly into the Mig Controller IP then it will ( I believe ) create it's own xdc files and a create_clock constraint.
Vivado doesn't make it easy to round up all of the constraint file in a design that uses its IP.

@Mathias
I have Vivado 2020.2 installed on my Centos box so I brought up your project. I had to "upgrade" the MMCM because Vivado keep changing the way it handles IP.
I found problems.
I had to change the Mig Project settings to match your imp_top.v source.
unchecked the Pin Compatible FPGAs select a 4:1 controller selected 200 MHz for Input Clock Period ( Vivado 2020.2 has a bug that keeps changing this every time you open the IP Wizzard !!) Use the drop-down selector to choose from the list because Vivado has a problem with clock periods specified in ns. selected Use System Clock for Reference clock I hate context sensitive IP Wizards, because they don't show the same choices depending on previous selections and devices.. it can cause a lot of problems.
Your ddr3_addr width is wrong in the imp_top port causing placement errors.
I had to add this line to the Arty-S7-25-Master constraints file:
 set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets sysclk]
This got me past your DDR problems. You still have some work to do though with constraint assignments.
I don't know why Vivado creates an issue with the clock. Likely, you need to assign the location of the MMCM directly, though Vivado should be smart enough to figure this out on its own. It could be for some other restriction that I haven't tracked down yet.
I posted some files to help you fix the DDR controller issues. Make sure that the mig_a.prj pin location assignments are correct.
The xc7s25 is a really small part in terms of resources so designs involving external DDR memory might be an issue.
datasheet.txt
mig_a.prj

I just looked at Spartan 7 to see if it uses the same MiG as the other Series 7 devices; it does. Follow the tutorial with regards to checking the datasheet for DDR PHY clocking rates. This will likely dictate whether you have a  4:1 or 2:1 controller ( assuming that the MiG for Spartan 7 is the same as Series 7 devices ). I'd advise going to the Digilent product page for your board and using any MiG ,prj and .ucf files that are provided as a starting point. You want to at least start with a working DDR design before trying to add external memory to another project. You will have to edit the ucf file as the Mig gets confused with anything but pin location assignments as I mentioned in the tutorial. Even though the Mig project file is in HTML format you can read it in a text editor to see what settings you should start off with. I've request that Digilent provide a pin location constraints file for their boards that is compatible with the Mig tool but haven't gotten a response.
 
Any logic connected to the UI, such as issuing read or write commands to the DDR controller UI, will need to use the ui_clk. But the rest of your design can use any clock rate. The NexysVideoDdrDemo.vhd project in the 2nd part of the tutorial shows how to do this and pass data between clock domains. The more clock domains you have, the more complicated will be timing closure, especially of the clocks are unrelated. I'd suggest following the example in part 2 of the tutorial. You should spend some time reading the  clocking reference manual for your device. There are a lot of rules and limitations. Once a board has been laid out and pins are assigned to external clock module inputs you can't change them. Often the tools will issue a warning or bitgen failure and you might have to add a constraint such as CLOCK_DEDICATED_ROUTE constraint to your toplevel project constraints file to over-ride the tool behavior. This is due to the board design.

For designs that need to issue commands to the MiG DDR controller as fast as possible you might have to restructure you design to use the ui_clk for the bulk of your design in order to achieve timing closure. Most of the board test results that I added posts about were done with a modified version of the NexysVideoDdrTest.vhd code to issue commands to the DDR as fast as the Mig IP allows. The problem for timing has to do with the behavior of the UI app_rdy signal. For the third part of the tutorial I wanted to simplify the design to emphasize the UI operation so that anyone could add an ILA and see how it operates. For NexysVideoDdrTest it should be obvious that this design can only issue write or read commands once every 4 ui_clk periods. The DDR interface is fast enough that this is often sufficient for most projects. That design was changed considerably for the performance posts of other boards. How one goes about doing that is left as a personal assignment for the reader. The MiG example project is one wy to do it but is almost unreadable. Parameters can be useful or a hindrance.

For really high throughput external memory designs such as the UltraScale+ DDR4 the high data rate might be a problem requiring a design approach that is more complicated than you want to do.

Don't hesitate to ask questions about the code if you are struggling. It seems pretty straightforward to me, but then again I wrote it.

A sure way to introduce timing issues is by failing to properly handle signals crossing clock domains.

Did you see my DDR tutorial ?
https://forum.digilentinc.com/topic/22197-a-guide-to-using-ddr-in-the-all-hdl-design-flow/

Don't get hung up in the details of the memory datasheet specifications. Modern DDR3, DDR4 and newer devices are designed to be used with modern CPU devices not programmable logic. When using FPGA vendor external memory IP stick with the timing, and devices that the IP supports... at least until you have a few successes under your belt. To get started with implementing a successful first DDR project start with the recommended MIG settings provider by the FPGA board vendor; that's what they use to test the boards.

It's not uncommon for FPGA boards to be populated with a memory part that can operate with timings that exceed the capabilities of the part. The controlling factor for FPGA devices are in the AC switching specifications for clock generators and buffers. Xilinx devices have a maximum DDR data rate for 4:1 controllers and 2:1 controllers that is spelled out clearly. And then there's the physical board memory layout and buffer switching capabilities to factor in.

I'm no DDR memory expert and frankly haven't had an interest in exploring the limits of FPGA/DDR performance. I really just want to use the storage capabilities that a board provides with the least amount of effort so that I can concentrate on a project.

To complete the board test results for the boards that I have access to here's something that might be of interest.
There aren't too many ZYNQ based boards with external memory connected to the PL. The ZCU106 happens to be one. For some reason Xilinx has decided not to support it with recent versions of its tools....
    the ZCU106 4:1 controller with an 1200 MHz PHY clock and 64-bit DQ bus has a ui_clk of 300 Mhz with 512-bit data
    013B5577 =    20665719  --> wtimer  --> 0.06888573 seconds
    01000000 =    16777216  --> wcount  --> 1073741824 bytes --> 15,587,289,617 bytes/s to write 1 GB
    011087E7 =    17860583  --> rtimer  --> 0.05953528 seconds
    01000000 =    16777216  --> rcount  --> 1073741824 bytes --> 18,035,387,152 bytes/s to read 1 GB
    00000000 =           0  --> errors
It's almost astonishing, to me at least, that the test runs at 300 MHz on hardware; but there it is. Again, you get an average data rate of about 90-94% of the 19200 million bytes/s peak.
The UltraScale+ uses the DDR4 SDRAM MIG 2.2 in Vivado 2019.1. pg150-ultrascale-memory-ip now covers this version. There's no flexibility in the IP design due, in part to the extreme clocking and timing specifications for the DDR4 memory. The MIG constraints files now abstracts pin constraints by using BOARD_PIN instead an actual pin number, and doesn't define any of the other pin constraints so that it's very difficult to find, or more importantly manage, the source code. This is the way that Xilinx is moving; less control for you over your projects and source maintenance, and more obfuscation of the details. Like it or not, you get a MicroBlaze embedded in your design to accomplish the calibration.  The only good news is that the Hardware Manager can find and report the calibration status and results. If, for some reason it can't find the embedded processor, then you can't download code or run any application on the UltraScale+ processor(s)... and yes, I managed to do that briefly. But who can argue with 16 GB/s of data storage bandwidth?
The DDR4 core is a very complex IP and good luck to anyone having to debug it for a custom board.
I had to restart the project a few times. If you start with a board design and include the DDR4 block you HAVE to connect an AXI interface to the memory. Who want's to do that? The whole purpose of having the PL get access to external memory is for your HDL design to use it. But you can create a basic board design with just the ZYNQ and then create the DDR4 core as general purpose IP. Then your code can instantiate the ZYNQ and MIG core with the UI and run the design without doing any SW design of any kind.

@reddishI appreciate the feedback. I still have (at least) one more part to complete, but haven't decided how to approach it yet. Hopefully, more to follow....
Since most FPGA boards have some external memory it shouldn't be as daunting a task to use for projects as tools and board vendors make it out to be. Still, as with the KC705, it can be very difficult to resolve obstacles. I am unaware of any community effort to deal with exposing "hidden" information needed to complete an HDL project using the MIG. Vendor IP shouldn't be so difficult
Thanks for overlooking the typos and rough presentation...
 

Just for fun, I tested the venerable KC705 DDR3 SODIMM:
the KC705 4:1 controller with an 800 MHz PHY clock and 64-bit DQ bus has a ui_clk of 200 Mhz with 512-bit data
00012C53 = 76883 --> wtimer --> 0.000384415 seconds
00010000 = 65536 --> wcount --> 4194304 bytes --> 10,910,874,966 bytes/s to write 4 MB
000117BC = 71612 --> rtimer --> 0.00035806 seconds
00010000 = 65536 --> rcount --> 4194304 bytes --> 11,713,969,726 bytes/s to read 4 MB
00000000 = 0 errors

Done in VIvado 2019.1. The KC705 is lacking a few amenities but certainly has an external memory worthy of the Kintex -2 part. Getting a bitstream with Vivado was an adventure due to a design flaw with the board, and poor support by Xilinx, it's vendor.

Also, all of the Kintex boards that I've tested: KC705, Genesys2, and NetFPGA-1G-CML have the global clock in the wrong half of the FPGA (relative to the DDR pin assignments) so you have to use a CLOCK_DEDICATED_ROUTE_BACKBONE constraint and settle for less than ideal clock routing for designs using the DDR. Intel FPGA evaluation boards tend to have more external clock inputs... but their devices also have a more restrictive clocking infrastructure than the Series 7 devices. Still, for high performance boards like the Genesys2 it would seem prudent to add at least one extra, perhaps programmable, clock input. The difference in cost would be minimal but greatly enhance usability.

Again, all of the test results that I've posted are for a design pushing the MIG DDR3 controller to it's maximum data throughput and not necessarily appropriate for all designs.

I tested the NetFPGA-1G-CML:
  - For the 4:1 controller with an 800 MHz PHY clock the UI runs at 200 MHz and the peak data rate is 1600 bytes/s
    04CCCD1D =    80530717  --> wtimer  --> 0.402653585 seconds
    04000000 =    67108864  --> wcount  --> 536870912 bytes --> 1,333,332,005 bytes/s to write 512 MB
    0475A8C2 =    74819778  --> rtimer  --> 0.37409889 seconds
    04000000 =    67108864  --> rcount  --> 536870912 bytes --> 1,435,104,263 bytes/s to read 512 MB
    00000000 =           0  errors
Again the average UI data rate is about 90% of the peak DDR3 PHY rate. I was wrong in my analysis that the board couldn't achieve a 1600 MT/s DDR3 data rate. This test was created using Vivado 2020.2. For unknown reasons the MIG controller doesn't provide the device_temp output that Vivado 2019.1 does.

I've created a variant of the NexysVideoDdrTest.vhd design associated with part three of the tutorial that submits read or write commands as fast as the MIG DDR3 controller allows. For the Nexys Video board here is a test result that is representative:
    ui_clk is 100 MHz. I'm writing 16 bytes every 10 ns or 1600 bytes/s peak rate
    000130DE  =    78046  --> wtimer  --> 0.00078046 seconds
    00010000  =    65536  --> wcount  --> 1048576 bytes --> 1,343,535,863 bytes/s to write 1 MB
    00011A3D  =    72253  --> rtimer  --> 0.00072253 seconds
    00010000  =    65536  --> rcount  --> 1048576 bytes --> 1,451,256,003 bytes/s to read 1 MB
    00000000  =        0  errors
For the Nexys Video 4:1 controller the peak data rate is 1600 million bytes/s. So, I see about a 90% average data rate compared to the peak data rate for 1 MB.
I also ported the NexysVideoDdrTest to the Genesys 2 board using the MIG settings in the Reference Manual.
    ui_clk is 900/4 = 225 MHz. I'm writing 32 bytes every 1.111 ns** or 7200 bytes/s peak rate
      00013472 =    78962  --> wtimer  --> 0.00035094222 seconds
      00010000 =    65536  --> wcount  --> 2097152 bytes --> 5,975,775,727 bytes/s to write 2 MB
      0001207C =    73852  --> rtimer  --> 0.00032823111 seconds
      00010000 =    65536  --> rcount  --> 2097152 bytes --> 6,389,254,206 bytes/s to read 2 MB
      00000000 =        0  errors
For the Genesys2 I'm seeing about an 88% average data rate to read/write 2 MB compared to the peak data rate. Timing closure is an issue for this board, at the maximum possible data rate, however. That' likely why the Digilent demos run the DDR PHY at a more sedate 400 MHz.
I should mention that , due to the way that the MIG UI works, timing closure will always be a likely issue if you try and run the DDR controller this way. Also, if you have to write or read more than one word to the MIG UI to support the 8 burst data requirement your data throughput will suffer appreciably. For instance, if you have to write 2 words per UI command, then your maximum peak data rate is 1/2 the PHY data rate.
There's good news. There's no significant difference in average data rates for blocks of 1 MB to 512 MB.
NOTE: Once you start getting into weird clock periods, the numbers that the MIG IP requires are somewhat fictional, but I guess that we don't have to worry about that as long as the hardware appears to function properly.. whatever that means.
 

Even if you aren't too interested using the material in this tutorial, it might still be a valuable exercise to go through. FPGA board vendors like to headline the advertisements for their products by highlighting the most optimistic performance statistics, even if they don't have anything to do with actual performance for real-world applications. it's a good idea to have some sort of realistic expectation about what kinds of applications a particular FPGA platform can support. This is especially true if your application requires external memory. Looking at the peak DDR data rate is likely to be very misleading.

As for non-ZYNQ FPGA Xilinx boards with DDR3 there is a large difference between the more capable and less capable boards. The Genesys2 and XEM7320 have 2 16-bit DDR3 devices that work at peak 1800 MT/s and 1600 MT/s respectively. These boards give you the flexibility of using 1 DDR3 controller with a 32-bit DQ bus or 2 DDR3 controllers, each with a 16-bit DQ bus. For FPGA boards sold by Digilent the most disappointing would be the Kintex based NetFPGA-1G-CML. It has one DDR3 device with an 8-bit DQ bus. The reference manual claims a 1600 MT/s DDR3 peak data rate but in actuality, it's less. There's no evidence that anyone, except me, has ever tested the external memory on this board. For a board with 4 1 GbE ports, having a DDR3 that is almost useless for Ethernet applications is very disappointing. The Intel based Cyclone V GT at least has 1 64-bit DDR3 memory connected to a hard external memory controller, as well as a smaller one that can be connected to a soft controller.

We can't stop vendors from claiming misleading or even incorrect performance numbers for their products but we certainly can do our own due diligence to work out if a particular FPGA platform will support our projects. I'd argue that this is a requirement.

Since the major FPGA vendors have removed hard external memory controllers from their devices it's not a bad idea to spend some time trying to work out how well they actually work for your projects. With all datasheets, never take the advertising on page 1 at face value. Sometimes you can figure out what you need to know deep within the datasheet. Sometimes, you have to do some experimenting.
[edit] For the Genesys 2, both DDR3 devices share address and control lines, so operating them independently isn't a possibility.
[another edit] Keep reading because I did execute an 1800 MT/s DDR3 design for the NetFPGA-1G-CML platform.

I've added material for Part 2 of the tutorial. Read both .txt files to follow along. Enjoy. Do post comments whether you find the tutorial useful or not, but especially if you are struggling with porting the code to your board.

The tutorial doesn't mention why you checked the Use Internal Vref box though it comes up as unchecked by default.

If you look at the Nexys Video schematic you will see that on IO bank 35 where the DDR3 signals are connected, the two VREF pins are used as GPIO; in this case as a DQ and DDR3 address pin. So you have to check this option. On a board like the Genesys2 the bank VREF pins are connected to the same net as the DDR3 VREF pins, so you would leave this option unchecked. The Genesys2 uses the Kintex and has the DDR3 signals connected to an HP bank with more features than HR banks so the tutorial doesn't completely cover all of the details for setting up the MiG for that board.

If you are designing a board there are a lot of ways to mess up the external memory interface. Copying a design from another vendor is not a particularly good way to cheat it on doing your homework.

The Mig IP doesn't allow you to assign the system_clock as the reference_clock input unless the Input Clock period is set to 5000ps ( 200 MHz ). Why is that?
According to the Series7 Select IO manual the reference clock for IDELAY can be 190-210 MHz or 290-310 MHz. According to the Artix datasheet we should be able to use either a 200 MHz or 300 MHz IDELAY reference clock for the -1 speed grade. So why doesn't the IP allow for using a 300 MHz system clock as the reference clock for the Nexys Video? The answer is that I don't know.
Interestingly, for the Nexys Video board, if you go with the Vivado 2019.1 default 2:1 controller PHY clock period of 3225ps this translates to a PHY clock of 310.0078 MHz. The MMCM math starts to become a problem, especially if you want a high quality clock for your DDR; and you do.

I've started a thread for people wanting to know how to use the DDR memory on their FPGA boards. I want this to be interactive as it's not possible to provide  a single demo project that works for all boards and all versions of Vivado. To get this started, I've provided a tutorial in the file XilinxDDR_Tutorial_Part_1.txt. As, the name implies this is just the beginning of the tutorial, but if you get through it, you will have a working DDR design running on your hardware.
Not everyone ( perhaps no one? ) will be happy with having to plow through a long text file but there are reasons for why I am presenting this material in this format. Perhaps, I will try and pretty the content up at a later time, if the topic is popular enough.
[Update] I've posted part 2 of the Tutorial. You can follow steps to creating a more useful DDR design by reading the file XilinxDDR_Tutorial_Part_2.txt. This isn't the end.
[Update] I've posted part 3 of the Tutorial in which we look at performance and simulation.
 
imp_top.v imp_top.xdc
XilinxDDR_Turorial_Part_1.txt
NexysVideoDdrDemo.vhd NexysVideoDdrDemo.xdc UART_DEBUGGER2.vhd XilinxDDR_Turorial_Part_2.txt YASUTX.vhd
 
NexysVideoDdrTest.vhd XilinxDDR_Turorial_Part_3.txt

Hi @Mathias
The instructions are long mostly because they are written to be fairly verbose and (ideally) clear.
Vitis should not be that big to install; or at least when I use the self-extracting web installer and only leave board options that I need checked, the final disk installation size of both Vivado and Vitis 2021.1 for me is just shy of 70 GB. Makes me yearn for the less than 15 GB size that 2015.4 was to be sure, but that's neither here nor there.
I asked another co-worker to make a DDR demo and they're hoping to get it completed in the next couple of weeks (in between all of their other tasks and making sure the documentation/tutorial aspect is clean).
Let me know if you have any questions.
Thanks,
JColvin

You don't need need a MicroBlaze, Vitis or the SDK to use DDR in a FPGA application. Digilent has a few demos scattered among the support for various boards that they sell; but they are all board design/ MicroBlaze based. This includes the one that is being offered here.

One problem with creating a comprehensive tutorial involving the MiG is that for different Xilinx families, devices, and memory devices you will not have a consistent experience using the MiG IP. That is settings for some functionality will appear for some combinations of FPGA/Memory devices and not for others. Some options, like 2:1 or 4:1 clock to PHY options will be greyed out for some devices and not others. The official Xilinx documentation for using the MiG is confusing and has errors to add to the confusion. In short, no tutorial that anyone would want to slog through will provide a step by step recipe for creating a DDR design for any particular board. I know this because I've started on such a tutorial and have done HDL (no soft processor) designs for many of the boards sold by Digilent and others.

Just trying to find the correct datasheet for a particular DDR device can be an expedition. There are just too many details to understand.

Providing a project that includes DDR is highly platform dependent. Presenting a tutorial that helps understand how to create a MiG DDR controller from scratch is a lot more complicated due to the reason stated above.

If you want a short, easy to implement, 10 step guide to creating and using a DDR controller for any version of Vivado and any board then I'm sorry to disappoint you... it cant be done; it's either going to be complicated or short on details, not particularly useful to everyone and suitable for a particular platform.

I've just finished creating a MiG controller for the NetFPGA-1G-CML from scratch and connecting it to PCIe and USB 3.0 interfaces for testing in separate projects. While writing to and reading data from DDR in a PC application can be a step, it isn't particularly useful. Usually, designs need to have have at least two channels that can access DDR. Such is the case where one might want to capture ADC samples, or write long DAC samples. Unfortunately, though Xilinx has deemed the hard multi-channel external memory controller to be unnecessary, it hasn't provided the tools with the ability to do multi-channel external memory interface designs, at least for the all HDL design flow. I find this to be curious but not accidental.

Anyway, I aim to post such a tutorial but will be more than pleased to see Digilent do so as well, even if it's specific for one of its boards. Other FPGA board vendors make the effort at providing a demo for their boards that at least do the trivial example... that is providing access to a DDR memory for one channel.

And here lies the problem with the MicroBlaze/board design flow that Digilent and Xilinx are committed to. For smallish devices, after you put all of the extraneous junk into your design there just aren't enough resources left to do what you want to do in your design. And if there isn't any IP to accomplish a design you are stuck. That and of course, you need to use the Xilinx software development tools. And virtually every new release of the tools will break your old designs. This is why this flow is almost unheard of in industry.

[edit] The issues mentioned here are worse than stated. You can't even post a tutorial for a particular FPGA board that Digilent sells because some, like the Arty A7, have variants that uses different speed grades. The 'official' Xilinx documentation for their own IP and tools is not up to date and users have to hunt down every advisory for a particular IP to see what's been officially recognized and addressed, though that doesn't mean fixed.
The best option is to help people understand how to sidestep potholes or work themselves out of them. Personally I think that DDR deserves a special forum spot to itself. If no one else wants to do it then I will. I'm still working out how to present my tutorial, but I'm pretty sure at this point that it won't be a simple to read, one solution for all, tutorial. And that's a good thing if people have problems and post questions about them. The problems that users have implementing DDR is really just a microcosm of the larger FPGA tool/documentation dis-functionality, so understanding how to navigate through DDR implementation is useful for everything else.