Cyclone V WYSIWYG primtives are broken :-(

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.