how to describe a DDR register in VHDL??

[3wais]

How to describe a Double Data Rate (DDR) Register in VHDL ??

I tried a process like this :

process(Input_Clk,Input_Data,Reset_Control)
	begin
		if (Reset_Control = '1') then
			Output_Data 	<= (others => '0');
		elsif (Input_Clk'event) then
			Output_Data 	<= Input_Data;
		end if;
	end process ;

but then Design Compiler complains :

 Bad clock expression: 'Could not determine polarity of clock expression'. (VER-408)

I tried to use

(Input_Clk'event and (Input_Clk = '1' or Input_Clk = '0'))

but it also generates an error.

I cannot use them in 2 separate processes because then it will generate an error on multiple processes driving a signal.

what is the proper way to do this ??

 

[FvM]

VHDL is a hardware description language. If used for logic synthesis (in contrast to simulation or general modelling), it can only describe structures that are available in the respective logic hardware. But no usual programmable logic has registers that can be clocked at both edges.

It's however not quite clear what you want to achieve. The term DDR is used for specific hardware structures in modern digital logic. They are not simply registering the same input data on both clock edges, as suggested in your code lines. They are either reading (DDR input) or sending (DDR output) different data on both clock edges, working as a clocked demultiplexer or multiplexer. These operation could be basically described in HDL, but to map the function to the dedicated DDR IO blocks in specific logic hardware, you'll instantiate low lewel primitives. Refer to the hardware and library manuals of your programmable logic.

 

[3wais]

I'll describe what I'm trying to do briefly, maybe it can help.

I have this open source DDR3 Controller which is written for Xilinx Spartan FPGAs. and I'm trying to translate it to some form that is suitable for ASIC synthesis tools.
The file relies heavily on Xilinx's ISERDES2 and OSERDES2 for switching between the FPGA's clock domain and DDR3's clock domain, I'm trying to do the same using a 3 stage CDC synchronizer which requires 3 registers in the DDR3 clock domain.

How can I describe this? or maybe I'm working this the wrong way?

 

[SynthWorks]

Have you tried the following? If this fails, submit a bug report against it as it is compliant with 1076.6-2004.

process(Input_Clk,Reset_Control)
	begin
		if (Reset_Control = '1') then
			Output_Data 	<= (others => '0');
		elsif  rising_edge(Input_Clk) then
			Output_Data 	<= Input_Data;
		elsif falling_edge(Input_Clk) then
			Output_Data 	<= Input_Data;
		end if;
	end process ;

 

[rca]

SynthWorks, are there some flop with two clock edges pin in your std cell library? I don't think so.

 

[SynthWorks]

SynthWorks, are there some flop with two clock edges pin in your std cell library? I don't think so.

Are you suggesting that DDR output registers cannot be implemented in an ASIC and/or FPGA?

The job of an HDL is to describe the logic operation. It is up to the synthesis tool is to translate it into the best implementation available in your library. If the library is missing the appropriate output register cells, then the implementation may be a multiplexer following two registers (one clocked on the rising edge and one on the falling edge).

Jim

 

[rca]

Seriously if you found a synthesis tool which are able to describe what you mention, I don't trust it.
If my RTL code describe only one flop, I don't want to have two flops instantiate in my netlist.

This king of code is only for testbench never applicable for hardware perspective (FPGa or ASIC).

- - - Updated - - -

Your RTL code need to describe what you wrote.

- - - Updated - - -

I means the two flops with muxing logic.

 

[FvM]

The usual DDR output register implementation (two registers and a mux selecting between both outputs) is functionally different from the register described in the codes of post #1 or post #4. IEEE 1076.6-2004 IEEE Standard for VHDL Register Transfer Level (RTL) Synthesis contains an example of a dual edge clocked register, but of course, it will be only availabe for synthesis if the involved hardware provides a respective functionality.

It should be possible to make DDR input and output registers similar to the dedicated FPGA DDR IO in ASICs. I don't think that it's primarly a tools problem. If the functions can't be inferred from a RTL description, you have to refer to a gate level description.

 

[SynthWorks]

The usual DDR output register implementation (two registers and a mux selecting between both outputs) is functionally different from the register described in the codes of post #1 or post #4. ...
If the functions can't be inferred from a RTL description, you have to refer to a gate level description.

I was vice-chair of the 1076.6-2004 effort. We talked about what should a tool do if there was not a matching library cell. The answer is the "usual DDR output implementation". As long as the simulation semantics match the implementation, whether the implementation uses a DDR cell or it implements it as the two register solution is no different.

If you started synthesis with an ASIC tool some time ago (I started in 1992), you might be familiar with a similar transformation that was done for internal tristates for the following. If you have an ASIC library with tristates, you should try it as the results may surprise you - the code reflects a tristate on the input to the flipflop, yet the synthesis tool correctly moves the tristate to the output and correctly puts a flipflop on the tristate control.

process(Clk)
begin
  if  rising_edge(Clk) then
    if tristate_enable = '1' then
       Output_Data 	<= Input_Data;
    else
       Output_Data 	<= (others => 'Z');
    end if ; 
  end if ; 
end process ;

The reason I show the tristate example is to demonstrate that even early synthesis tools could handle this sort of transformation, so it is not unreasonable to expect them to handle the two edge flipflop example.

If your vendor has not implemented this yet, it is time for you to file a bug report so they can get busy and get it done.

Best Regards,
Jim Lewis

 

[FvM]

I was vice-chair of the 1076.6-2004 effort. We talked about what should a tool do if there was not a matching library cell. The answer is the "usual DDR output implementation". As long as the simulation semantics match the implementation, whether the implementation uses a DDR cell or it implements it as the two register solution is no different.

Thanks for the explanation. I appreciate your efforts to promote synthesis tools intelligency.

Another question is which tools presently offer IEEE 1076.6-2004 compliance. I'm mainly working with FPGA design and tools that don't have it. Most of the constructs described in 1076.6 are however supported, so the standard is still a good reference for RTL coding.

 

[SynthWorks]

Another question is which tools presently offer IEEE 1076.6-2004 compliance.

I haven't been check for complete tool compliance. IEEE never certifies tool compliance. Many vendor's licensing discourages benchmarking. Instead, I code my hardware, and when I bump into something that I really need, like this one, I make sure to file bug reports. The more people that file them, the more they listen.

If you file one, and they disagree with you, make sure to post it here, at stack overflow, or comp.lang.vhdl. Then we can comment and can call them out on it. I am especially tired of a vendor saying they cannot synthesize something, yet they can provide a wizard and/or macro for the same thing - which basically says we can synthesize it, but we want you to use our macro instead because it locks you into our tool/parts.

Jim

 

[daniel.kho]

If you file one, and they disagree with you, make sure to post it here, at stack overflow, or comp.lang.vhdl. Then we can comment and can call them out on it. I am especially tired of a vendor saying they cannot synthesize something, yet they can provide a wizard and/or macro for the same thing - which basically says we can synthesize it, but we want you to use our macro instead because it locks you into our tool/parts.
Jim

Jim, I'm tired of vendors giving me the same line such as the following as well. They have been basically telling me the same thing 2 to 3 years ago:

####### Snippet from Altera Service Request #######

Dear Daniel.

Currently, Dual-edge-triggered flip-flop have not been supported by Quartus II yet. We had file an enhancement to our development team regarding this.

Altera will try to support this in the future release of Quartus II. We shall set this Service request to close pending.

####### end of SR #######

I keep getting these sort of replies from Altera, but everytime I waited for a new release (I waited for years), they seem to be doing nothing about my request.

I will be pointing them to an older request I filed a long while back (actually I filed this at least twice before), and see if they start acting on it. I doubt they will do anything unless enough people start bugging them about this.

regards, daniel

 

[FvM]

I don't expect that Altera seriously considers to implement emulated dual-edge clocked registers in the Quartus tools nor that any major FPGA vendor does. In so far the quoted answer to your service request is probably misleading.

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.

 

[sun_ray]

Will the DDR code in Verilog corresponding to the VHDL code as suggested by SynthWorks be like this?

always @(clk or reset)

if (reset)

q <= 1'b0;

else if (posedge clk)

q<= d;

else if (negedge clk)

q<= d;

Regards

 

[FvM]

The construct is not corresponding to the template for modelling of edge-sensitive storage devices and won't be synthesized.

IEEE Std 1364.1-2002 (Verilog Register Transfer Level Synthesis) assumes that there can be only one synchronous event in a FF description which is represented by the final else statement.

You have to refer to a combination of two FFs and a mux like below

always @(posedge clk)
  q1<= d;

always @(negedge clk)
  q2<= d;

assign q = clk?q1:q2;

 

[sun_ray]

The construct is not corresponding to the template for modelling of edge-sensitive storage devices and won't be synthesized.

IEEE Std 1364.1-2002 (Verilog Register Transfer Level Synthesis) assumes that there can be only one synchronous event in a FF description which is represented by the final else statement.

You have to refer to a combination of two FFs and a mux like below

always @(posedge clk)
  q1<= d;

always @(negedge clk)
  q2<= d;

assign q = clk?q1:q2;

How will the code provided in VHDL by Synthwork will be synthesizable then? There is also two synchronous event in the FF description, rising_edge, falling_edge.

Regards

 

[FvM]

How will the code provided in VHDL by Synthwork will be synthesizable then? There is also two synchronous event in the FF description, rising_edge, falling_edge.

It won't be synthesized by most FPGA tools, I fear. As Synthwork explained, he expects that the tools should be intelligent enough to emulate the dual-edge registers by suitable constructs. This idea is promoted by the respective VHDL RTL synthesis specification. Apart from the situation with VHDL tools, it's clear that the Verilog RTL synthesis specification don't provide a dual edge option.

I think, from a hardware designers viewpoint, it's better anyway not to rely on tools intelligency but to describe a hardware that's actually feasible with the used silicon.

 

[sun_ray]

FvM or anybody

There is a name of a synthesizable Verilog by IEEE and the name is IEEE 1364.1. What is the name of the corresponding file for synthesizable VHDL by IEEE?

Regards

 

[FvM]

See post#10.

General comment, the existence of this "RTL syntheses" specification doesn't mean, that they are supported by all synthesis tools.

 

[sun_ray]

See post#10.

General comment, the existence of this "RTL syntheses" specification doesn't mean, that they are supported by all synthesis tools.

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