Cyclone V WYSIWYG primtives are broken :-(

[Altera_Forum]

This a rather longish complaint. 

Maybe someone from Altera reads it and can me give some idea what to do.  I am trying to implement my own DDR3 memory controller for a Cyclone V device (in pure FPGA logic, not by using a HPS or using any other kind of wizard). Note: I know what I am doing. I have implemented SDRAM, DDR1 SDRAM and DDR2 SDRAM controllers in various Altera FPGAs, without any trouble.   At first I tried to use the ALTDQ_DQS2 IP, because it seems this was the way to go for your own DDR3 memory controller. It turned out that Quartus II is not able to compile the ALTDQ_DQS2 IP for a Cyclone V device. Quartus bails out in the "fitter" stage (tested with Quartus II 13.0, 13.1, 14.0, 14.1).  This is actually not surprising considering the rather poor state of the documentation of the ALTDQ_DQS2 IP: The documentation does not really cover Cyclone V devices. Note that this is a trend: All memory controller related documentation nowadays tries to be "device agnostic", meaning that there is only one huge pile of document (like the External Memory Interface Handbook), which mixes all the different device families together and in turn is COMPLETELY useless if you are interested in low level details, because the different families seem to be wildly different when it comes down to low level details...  So my first wish: PLEASE PLEASE PLEASE write documentation for the different device families again, which covers the specific low level features of the particular device family. It is a nightmare to find out these features via something like the EMIF handbook. It is horrible to read something like "please refer to the EMIF for information about external memory interfaces" in a particular device family manual, just to find out that the EMIF handbook has about 900 pages of which 90% are not relevant for your device family and that the EMIF handbook basically glosses over all the rather interesting and important details.   Now after unsuccessfully trying to use the ALTDQ_DQS2 IP, I started using the Cyclone V WYSIWYG primitives to build my own DDR3 controller. If you don't know these: WYSIWYG primitives are basic building blocks implemented in your FPGA, and by using these primitives in Verilog/VHDL you tell Quartus to directly use these particular building blocks.  Now WYSIWYG primitives are not really documented (maybe there is documentation, but I never found any comprehensive).  So 2nd wish: Please create documentation which shortly describes the WYSIWYG primitives. Note that the device family documentation ALREADY contains details about many of the primitives. For example all the device family documentation I have seen so far, explains in great detail what's inside a Logic Cell (or ALM). All the device family documentation also covers what's in an IO cell ...  Now the missing documentation would not be so bad, because as the Quartus 15.0 help states about WYSIWYG primitives:  "WYSIWYG primitives and atoms also give AMPP partners more control over how their designs are implemented in a device. Altera provides simulation models of atoms for functional and timing simulation in the \quartus\eda\sim_lib directory."  Now unfortunately for Cyclone V this is not entirely true: The VHDL models seem to be missing completely, only some component declarations are left, but no models. Does Altera intend to drop VHDL model support ? If so, could you please announce that loud and clear, so that the users might be prepared ? (It means I probably need to buy Verilog + SystemVerilog simulation licenses to be able to simulate my VHDL design.  No: I am really not thrilled about this...)  Now the more interesting WYSIWYG primitives, especially related to memory controllers,  seem to be only available in ENCRYPTED Verilog. Examples:  cyclonev_phy_clkbuf  cyclonev_leveling_delay_chain  cyclonev_clk_phase_select  cyclonev_lfifo  cyclonev_vfifo  Now why the heck was it decided to provide these only as encrypted verilog ? After simulating most of these it seems the simulation models are more or less trivial, so what's the sense in hiding the SIMULATION behavior behind encryption ? Even worse: The unencrypted simulation models could be used as a very precise documentation of the various WYSIWYG primitives. Because some of them are now encrypted, you have no information at all about what these FPGA blocks do or how you might use them in your own designs.  Then (to finally arrive at the heading I gave this thread): Some component declarations are missing in VHDL. For example cyclonev_lfifo, cyclonev_vfifo do not exist in the VHDL component packages, making it impossible to simulate these in VHDL. (Well you can of course write your own component declarations...)  Some of these primitives seem to exhibit wrong simulation behavior: For example cyclonev_lfifo has a "rstn" input, but the simulation model clearly uses this input as a HIGH ACTIVE reset. Now of course this could simply be a failure of the simulation model, but that would be even worse, because that means you have a discrepancy between simulation and real hardware. Of course because you cannot inspect the source code of the model (its encrypted :-(((( ), you have no clue if this might be just a typo or actually intended. And of course you cannot fix the model easily...  There already seem to be discrepancies between the simulation models and what Quartus II understands for synthesis: The cyclonev_clk_phase_select module/entity, has an input port called "clkin". For simulation you need to connect a [3..0] vector to this port. If you want to synthesize the same cyclonev_clk_phase_select WYSIWYG primitive, Quartus II only expects a single wire (no vector) for the clkin port.  As you can see I am rather frustrated: I have a powerful FPGA device (Cyclone V), which clearly has the right IO features to support DDR3, but unfortunately Altera seems to have decided that these features are not documented, the simulation models are bogus and encrypted so I cannot fix them myself.  So what should I do now, where can I complain more loudly in the hope that someone changes this sorry state of affairs ?  PS: I probably know why Quartus is not able to compile the ALTDQ_DQS2 IP for Cyclone V. But why should I tell Altera, if Altera treats me like a dummy.

[Altera_Forum]

Hi Lundril: 

 I feel your pain, I've came across similar simulation issues with earlier families.  My suggestion is you do the following:  Post a specific issue IE the VHDL simulation model is mission, or incorrect to mysupport  Second contact your distribution partner FAE and get them to push that issue past the front line support personnel. Often the base line support for both Xilinx and Altera is pretty frustrating.. The FAE's vary widely as well, but they at least have contacts into the factory to push the issue up the chain.  If you have an open mysupport case number, they can reference that number and also shadow follow it, so you don't have to describe the issue many times.  The third step is post the issue here, which you did. Depending on the issue, we can be a great help. Unfortunately most of us are not Altera employees. So this particular issue is harder for us to directly fix. :)  Pete

[Altera_Forum]

Was any progress made on this at the end?

[Altera_Forum]

Not from Altera's side. 

 I managed to completely reverse engineer how to interface with the Cyclone V WYSIWYG primitives and was thus able to interface with a DDR3 RAM. This was rather painful and I definitely do not recommend it.  My current impression is, that if you want to do anything with an Altera FPGA, which requires low level knowledge you are completely on your own. Altera will not support you at all; in fact it seems to be completely impossible to find someone inside Altera who is even mildly interested in any of these issues.

[Altera_Forum]

Was there a reason why you wanted to use ALTDQ_DQS instead of the hard memory controller and UniPHY?