Xilinx Synthesis Tool generates clock signals from combinatorial logic
in [FPGA]
|
Prev: New 'standard' compact programming header needed!
Next: problem in clock input in virtexpro/spartan3a/spartan3 kit
From: Sharath Raju on 13 May 2010 09:53 Hello, I am facing a problem of clock signals being generated by combinatorial logic. Here is the timing report: TIMING REPORT NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE. FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT GENERATED AFTER PLACE-and-ROUTE. Clock Information: ------------------ -----------------------------------+------------------------+-------+ Clock Signal | Clock buffer(FF name) | Load | -----------------------------------+------------------------+-------+ clk | BUFGP | 23 | Dec_cnt(Dec_cnt1:O) | NONE(*)(Int_count_1) | 10 | -----------------------------------+------------------------+-------+ (*) This 1 clock signal(s) are generated by combinatorial logic, and XST is not able to identify which are the primary clock signals. Please use the CLOCK_SIGNAL constraint to specify the clock signal(s) generated by combinatorial logic. clk is my "true" clock signal, whereas Dec_cnt is some other combinatorial signal. I have tried using the CLOCK_SIGNAL constraint both in my source file, as follows: attribute clock_signal : string; attribute clock_signal of clk : signal is "yes"; attribute clock_signal of Dec_cnt : signal is "no"; and in the xilinx constraints file (.xcf) BEGIN MODEL sdmac NET "clk" CLK_SIGNAL = yes; END; In either case, I get the same problem. Here is my source file: http://sites.google.com/site/brsharath/sdmac_signal_sched.vhd?attredirects=0&d=1 Please help
From: John McCaskill on 13 May 2010 10:18 On May 13, 8:53 am, Sharath Raju <brshar...(a)gmail.com> wrote: > Hello, > > I am facing a problem of clock signals being generated by > combinatorial logic. > > Here is the timing report: > > TIMING REPORT > > NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE. > FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT > GENERATED AFTER PLACE-and-ROUTE. > > Clock Information: > ------------------ > -----------------------------------+------------------------+-------+ > Clock Signal | Clock buffer(FF name) | Load | > -----------------------------------+------------------------+-------+ > clk | BUFGP | 23 | > Dec_cnt(Dec_cnt1:O) | NONE(*)(Int_count_1) | 10 | > -----------------------------------+------------------------+-------+ > (*) This 1 clock signal(s) are generated by combinatorial logic, > and XST is not able to identify which are the primary clock signals. > Please use the CLOCK_SIGNAL constraint to specify the clock signal(s) > generated by combinatorial logic. > > clk is my "true" clock signal, whereas Dec_cnt is some other > combinatorial signal. > > I have tried using the CLOCK_SIGNAL constraint both in my source file, > as follows: > > attribute clock_signal : string; > attribute clock_signal of clk : signal is "yes"; > attribute clock_signal of Dec_cnt : signal is "no"; > > and in the xilinx constraints file (.xcf) > > BEGIN MODEL sdmac > NET "clk" CLK_SIGNAL = yes; > END; > > In either case, I get the same problem. > > Here is my source file:http://sites.google.com/site/brsharath/sdmac_signal_sched.vhd?attredi... > > Please help The problem is this bit of code: process (Inc_cnt, Dec_cnt) begin if Inc_cnt = '1' then Int_count <= Int_count + 1; elsif Dec_cnt = '1' then Int_count <= Int_count - 1; end if; end process; Inc_cnt looks like an asynchronous reset, and Dec_cnt looks like the clock. If you wanted this to be a clocked process, put the clock in the sensitivity list and remove Inc_cnt and Dec_cnt. Regards, John McCaskill www.FasterTechnology.com
From: rickman on 13 May 2010 14:14 On May 13, 10:18 am, John McCaskill <jhmccask...(a)gmail.com> wrote: > On May 13, 8:53 am, Sharath Raju <brshar...(a)gmail.com> wrote: > > > > > Hello, > > > I am facing a problem of clock signals being generated by > > combinatorial logic. > > > Here is the timing report: > > > TIMING REPORT > > > NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE. > > FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT > > GENERATED AFTER PLACE-and-ROUTE. > > > Clock Information: > > ------------------ > > -----------------------------------+------------------------+-------+ > > Clock Signal | Clock buffer(FF name) | Load | > > -----------------------------------+------------------------+-------+ > > clk | BUFGP | 23 | > > Dec_cnt(Dec_cnt1:O) | NONE(*)(Int_count_1) | 10 | > > -----------------------------------+------------------------+-------+ > > (*) This 1 clock signal(s) are generated by combinatorial logic, > > and XST is not able to identify which are the primary clock signals. > > Please use the CLOCK_SIGNAL constraint to specify the clock signal(s) > > generated by combinatorial logic. > > > clk is my "true" clock signal, whereas Dec_cnt is some other > > combinatorial signal. > > > I have tried using the CLOCK_SIGNAL constraint both in my source file, > > as follows: > > > attribute clock_signal : string; > > attribute clock_signal of clk : signal is "yes"; > > attribute clock_signal of Dec_cnt : signal is "no"; > > > and in the xilinx constraints file (.xcf) > > > BEGIN MODEL sdmac > > NET "clk" CLK_SIGNAL = yes; > > END; > > > In either case, I get the same problem. > > > Here is my source file:http://sites.google.com/site/brsharath/sdmac_signal_sched.vhd?attredi... > > > Please help > > The problem is this bit of code: > > process (Inc_cnt, Dec_cnt) > begin > if Inc_cnt = '1' then > Int_count <= Int_count + 1; > elsif Dec_cnt = '1' then > Int_count <= Int_count - 1; > end if; > > end process; > > Inc_cnt looks like an asynchronous reset, and Dec_cnt looks like the > clock. > > If you wanted this to be a clocked process, put the clock in the > sensitivity list and remove Inc_cnt and Dec_cnt. > > Regards, > > John McCaskillwww.FasterTechnology.com This is not describing edge sensitive clocked logic. It is describing a latch. But both signals, Inc_cnt and Dec_cnt would be used to generate the latch enable. So the question is whether the OP intended this to use a latch or if it was supposed to be clocked by a system clock edge. The danger in this case is that the logic is a feedback loop and if the enable is asserted long enough for a change on the output to reach back around to the input, it would be counting up or down at its fastest possible rate the entire time the enable is asserted. I haven't looked at the code. Is it possible this was meant to use separate signals for cur_count and nxt_count with cur_count a register and nxt_count the logic output? Rick
From: John McCaskill on 13 May 2010 15:25 On May 13, 1:14 pm, rickman <gnu...(a)gmail.com> wrote: > On May 13, 10:18 am, John McCaskill <jhmccask...(a)gmail.com> wrote: > > > > > On May 13, 8:53 am, Sharath Raju <brshar...(a)gmail.com> wrote: > > > > Hello, > > > > I am facing a problem of clock signals being generated by > > > combinatorial logic. > > > > Here is the timing report: > > > > TIMING REPORT > > > > NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE. > > > FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT > > > GENERATED AFTER PLACE-and-ROUTE. > > > > Clock Information: > > > ------------------ > > > -----------------------------------+------------------------+-------+ > > > Clock Signal | Clock buffer(FF name) | Load | > > > -----------------------------------+------------------------+-------+ > > > clk | BUFGP | 23 | > > > Dec_cnt(Dec_cnt1:O) | NONE(*)(Int_count_1) | 10 | > > > -----------------------------------+------------------------+-------+ > > > (*) This 1 clock signal(s) are generated by combinatorial logic, > > > and XST is not able to identify which are the primary clock signals. > > > Please use the CLOCK_SIGNAL constraint to specify the clock signal(s) > > > generated by combinatorial logic. > > > > clk is my "true" clock signal, whereas Dec_cnt is some other > > > combinatorial signal. > > > > I have tried using the CLOCK_SIGNAL constraint both in my source file, > > > as follows: > > > > attribute clock_signal : string; > > > attribute clock_signal of clk : signal is "yes"; > > > attribute clock_signal of Dec_cnt : signal is "no"; > > > > and in the xilinx constraints file (.xcf) > > > > BEGIN MODEL sdmac > > > NET "clk" CLK_SIGNAL = yes; > > > END; > > > > In either case, I get the same problem. > > > > Here is my source file:http://sites.google.com/site/brsharath/sdmac_signal_sched.vhd?attredi... > > > > Please help > > > The problem is this bit of code: > > > process (Inc_cnt, Dec_cnt) > > begin > > if Inc_cnt = '1' then > > Int_count <= Int_count + 1; > > elsif Dec_cnt = '1' then > > Int_count <= Int_count - 1; > > end if; > > > end process; > > > Inc_cnt looks like an asynchronous reset, and Dec_cnt looks like the > > clock. > > > If you wanted this to be a clocked process, put the clock in the > > sensitivity list and remove Inc_cnt and Dec_cnt. > > > Regards, > > > John McCaskillwww.FasterTechnology.com > > This is not describing edge sensitive clocked logic. It is describing > a latch. But both signals, Inc_cnt and Dec_cnt would be used to > generate the latch enable. So the question is whether the OP intended > this to use a latch or if it was supposed to be clocked by a system > clock edge. The danger in this case is that the logic is a feedback > loop and if the enable is asserted long enough for a change on the > output to reach back around to the input, it would be counting up or > down at its fastest possible rate the entire time the enable is > asserted. > > I haven't looked at the code. Is it possible this was meant to use > separate signals for cur_count and nxt_count with cur_count a register > and nxt_count the logic output? > > Rick Actually, it is just incorrect. If if is supposed to be a latch (but I hope not), it should also have Int_count in the sensitivity list. As written, it will synthesize with warnings as a latch, but not simulate as one. This is still the cause of Dec_cnt being reported as a clock. Int_count is not used outside of this process, so it is not clear what the intention was. Int_count is also defined as std_logic_vector, which is a problem. A std_logic_vector has no numerical value. I would also replace: use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; with: use IEEE.NUMERIC_STD.ALL; Regards, John McCaskill www.FasterTechnology.com
From: rickman on 13 May 2010 16:56
On May 13, 3:25 pm, John McCaskill <jhmccask...(a)gmail.com> wrote: > On May 13, 1:14 pm, rickman <gnu...(a)gmail.com> wrote: > > > > > On May 13, 10:18 am, John McCaskill <jhmccask...(a)gmail.com> wrote: > > > > On May 13, 8:53 am, Sharath Raju <brshar...(a)gmail.com> wrote: > > > > > Hello, > > > > > I am facing a problem of clock signals being generated by > > > > combinatorial logic. > > > > > Here is the timing report: > > > > > TIMING REPORT > > > > > NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE. > > > > FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT > > > > GENERATED AFTER PLACE-and-ROUTE. > > > > > Clock Information: > > > > ------------------ > > > > -----------------------------------+------------------------+-------+ > > > > Clock Signal | Clock buffer(FF name) | Load | > > > > -----------------------------------+------------------------+-------+ > > > > clk | BUFGP | 23 | > > > > Dec_cnt(Dec_cnt1:O) | NONE(*)(Int_count_1) | 10 | > > > > -----------------------------------+------------------------+-------+ > > > > (*) This 1 clock signal(s) are generated by combinatorial logic, > > > > and XST is not able to identify which are the primary clock signals.. > > > > Please use the CLOCK_SIGNAL constraint to specify the clock signal(s) > > > > generated by combinatorial logic. > > > > > clk is my "true" clock signal, whereas Dec_cnt is some other > > > > combinatorial signal. > > > > > I have tried using the CLOCK_SIGNAL constraint both in my source file, > > > > as follows: > > > > > attribute clock_signal : string; > > > > attribute clock_signal of clk : signal is "yes"; > > > > attribute clock_signal of Dec_cnt : signal is "no"; > > > > > and in the xilinx constraints file (.xcf) > > > > > BEGIN MODEL sdmac > > > > NET "clk" CLK_SIGNAL = yes; > > > > END; > > > > > In either case, I get the same problem. > > > > > Here is my source file:http://sites.google.com/site/brsharath/sdmac_signal_sched.vhd?attredi... > > > > > Please help > > > > The problem is this bit of code: > > > > process (Inc_cnt, Dec_cnt) > > > begin > > > if Inc_cnt = '1' then > > > Int_count <= Int_count + 1; > > > elsif Dec_cnt = '1' then > > > Int_count <= Int_count - 1; > > > end if; > > > > end process; > > > > Inc_cnt looks like an asynchronous reset, and Dec_cnt looks like the > > > clock. > > > > If you wanted this to be a clocked process, put the clock in the > > > sensitivity list and remove Inc_cnt and Dec_cnt. > > > > Regards, > > > > John McCaskillwww.FasterTechnology.com > > > This is not describing edge sensitive clocked logic. It is describing > > a latch. But both signals, Inc_cnt and Dec_cnt would be used to > > generate the latch enable. So the question is whether the OP intended > > this to use a latch or if it was supposed to be clocked by a system > > clock edge. The danger in this case is that the logic is a feedback > > loop and if the enable is asserted long enough for a change on the > > output to reach back around to the input, it would be counting up or > > down at its fastest possible rate the entire time the enable is > > asserted. > > > I haven't looked at the code. Is it possible this was meant to use > > separate signals for cur_count and nxt_count with cur_count a register > > and nxt_count the logic output? > > > Rick > > Actually, it is just incorrect. > > If if is supposed to be a latch (but I hope not), it should also have > Int_count in the sensitivity list. As written, it will synthesize with > warnings as a latch, but not simulate as one. This is still the cause > of Dec_cnt being reported as a clock. > > Int_count is not used outside of this process, so it is not clear what > the intention was. > > Int_count is also defined as std_logic_vector, which is a problem. A > std_logic_vector has no numerical value. > > I would also replace: > > use IEEE.STD_LOGIC_ARITH.ALL; > use IEEE.STD_LOGIC_UNSIGNED.ALL; > > with: > > use IEEE.NUMERIC_STD.ALL; Yeah, I guess the code is pretty ugly. Why, after all these years of people discussing the issues with std_logic_unsigned, et. al., do people still start out this way? Do they teach this in the universities or something? Rick |