3wais
Member level 4
- Joined
- Sep 12, 2011
- Messages
- 70
- Helped
- 3
- Reputation
- 6
- Reaction score
- 3
- Trophy points
- 1,288
- Location
- Alexandria,Egypt
- Activity points
- 1,787
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 ;
Bad clock expression: 'Could not determine polarity of clock expression'. (VER-408)
(Input_Clk'event and (Input_Clk = '1' or Input_Clk = '0'))
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 ;
Are you suggesting that DDR output registers cannot be implemented in an ASIC and/or FPGA?SynthWorks, are there some flop with two clock edges pin in your std cell library? I don't think so.
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.
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 ;
Thanks for the explanation. I appreciate your efforts to promote synthesis tools intelligency.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.
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.Another question is which tools presently offer IEEE 1076.6-2004 compliance.
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
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.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
Code: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.
See post#10.
General comment, the existence of this "RTL syntheses" specification doesn't mean, that they are supported by all synthesis tools.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?