how to describe a DDR register in VHDL??

[daniel.kho]

In post number 8 it was provided that IEEE 1076.6-2004 IEEE Standard for VHDL Register Transfer Level (RTL) Synthesis. It was of 2004.

What is the name for the advance latest version?

Regards

One of the many excuses vendors give for not supporting 1076.6-2004 is that this standard has been withdrawn (as per the status of this project). So there is no later version than this, though discussions are on-going at IEEE to subsume this into the main standard. Feel free to join in our discussions.

DDR in- and output registers present in recent FPGA families are expected to be instantiated as low level-primitives. In my view this is rather a feature than a limitation, because you are describing exactly what you get instead bringing up the illusion of a synchronous dual-edge triggered flip-flop which don't exist in actual hardware.

As Jim from Synthworks mentioned, it is the duty of synthesis tools to make sense out of our HDL code and generate appropriate logic based on our code. If there are no dedicated DDR circuitry within the FPGA, then the synthesis tool could infer emulated DDR. But the thing is, FPGAs already have dedicated DDR circuits, so I don't see a reason why the synthesis tool can't automatically infer those dedicated circuits from our behavioural model.

Following your logic (that we instantiate low-level primitives to access DDR features), do you think it's a good idea to write all our flip-flops by instantiating them? I would prefer to describe flip-flops behaviourally:

process(clk) is begin
    if rising_edge(clk) then q<=d; end if;
end process;

rather than instantiating the primitives (such as DFF, DFFE, etc.).

Same logic here. I would prefer synthesis tools to automatically infer DDR output registers based on our behavioural model - they can infer emulated DDR or dedicated DDR depending on whichever is available on silicon.

-daniel

 

[FvM]

Same logic here. I would prefer synthesis tools to automatically infer DDR output registers based on our behavioural model - they can infer emulated DDR or dedicated DDR depending on whichever is available on silicon.

Nothing against it, generally.

As previously discussed, the term DDR can refer to different register configurations. Of course inference would be restricted to exactly the configuration available in hardware. Others are possibly non-synthesizable because no useful emulation with sufficient timing exists. In this situation, I imagine that a feature "inference of DDR registers" may cause more confusion than being helpful.