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: Rob Gaddi on 13 May 2010 17:13 On 5/13/2010 1:56 PM, rickman wrote: > 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 I know that all of Xilinx's example code and templates still don't use numeric_std. No idea how the template code from the other vendors looks. -- Rob Gaddi, Highland Technology Email address is currently out of order
From: John McCaskill on 13 May 2010 17:43 On May 13, 4:13 pm, Rob Gaddi <rga...(a)technologyhighland.com> wrote: > On 5/13/2010 1:56 PM, rickman wrote: > > > > > 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 > > I know that all of Xilinx's example code and templates still don't use > numeric_std. No idea how the template code from the other vendors looks. > > -- > Rob Gaddi, Highland Technology > Email address is currently out of order This is starting to change. The Xilinx VHDL course recommends numeric_std since the 11.1 version, and the create new source wizard in ISE 12.1 uses numeric_std now. I still see templates and examples that don't use it. I expect (but don't know) that will change over the next few releases. Regards, John McCaskill www.FasterTechnology.com
From: Sharath Raju on 13 May 2010 23:11 On May 14, 2:43 am, John McCaskill <jhmccask...(a)gmail.com> wrote: > On May 13, 4:13 pm, Rob Gaddi <rga...(a)technologyhighland.com> wrote: > > > > > On 5/13/2010 1:56 PM, rickman wrote: > > > > 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 > > > I know that all of Xilinx's example code and templates still don't use > > numeric_std. No idea how the template code from the other vendors looks. > > > -- > > Rob Gaddi, Highland Technology > > Email address is currently out of order > > This is starting to change. The Xilinx VHDL course recommends > numeric_std since the 11.1 version, and the create new source wizard > in ISE 12.1 uses numeric_std now. I still see templates and examples > that don't use it. I expect (but don't know) that will change over the > next few releases. > > Regards, > > John McCaskillwww.FasterTechnology.com Thanks for your inputs. I don't want the process (Inc_cnt, Dec_cnt) to be a clocked process. Inc_cnt and Dec_cnt are control signals that if set, either increment or decrement the Int_count counter signal. Hence the reason for putting Inc_cnt and Dec_cnt in the sensitivity list. The purpose of the code is to : 1. delay del_X signal by one clock cycle, 2. Multiply X (8-bit) and del_X (8-bit), and accumulate the product into a register Y (24 bit). I have split the accumulation into two steps. 14 bit addition (Sum signal) , followed by a 10-bit counter that updates the (Int_count signal) if an overflow (Inc_cnt signal) or a borrow (Dec_cnt signal) is generated by the addition operation.
From: Andy Peters on 14 May 2010 18:36 On May 13, 2:43 pm, John McCaskill <jhmccask...(a)gmail.com> wrote: > On May 13, 4:13 pm, Rob Gaddi <rga...(a)technologyhighland.com> wrote: > > > > > On 5/13/2010 1:56 PM, rickman wrote: > > > > 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 > > > I know that all of Xilinx's example code and templates still don't use > > numeric_std. No idea how the template code from the other vendors looks. > > > -- > > Rob Gaddi, Highland Technology > > Email address is currently out of order > > This is starting to change. The Xilinx VHDL course recommends > numeric_std since the 11.1 version, and the create new source wizard > in ISE 12.1 uses numeric_std now. I still see templates and examples > that don't use it. I expect (but don't know) that will change over the > next few releases. It only took about a decade of complaints and Web Cases to make this happen ... -a
From: Sharath Raju on 18 May 2010 01:32 On May 16, 11:07 am, Ralf Hildebrandt <Ralf-Hildebra...(a)gmx.de> wrote: > Am 13.05.2010 16:18, schrieb John McCaskill: > > > 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. > > You pointed out a very bad piece of code, but it is not a flipflop - it > is a latch as rickman has already pointed out. > > It has 2 big design errors: > > 1) muxed latch: Inc_cnt and Dec_cnt drive latch-enable and mux-select. > This is very bad design because no one can say if the latch-enable or > the mux-select chances first in the moment when Inc_cnt / Dec_cnt become > inactive. > > 2) infinite loop: As long as Inc_cnt / Dec_cnt is enable, Int_count is > incremented / decremented. During simulation this problem did not show > up, because the sensitivity list of this process is incomplete. Put > Int_count into the sensitivity list and the simulator will freeze forever.. > > Ralf I have rewritten the bad piece of code, but still a latch is synthesized for Int_count signal. Can anybody tell what is wrong with this piece of code ? process (Inc_cnt, Dec_cnt, RST) begin if RST = '0' then Int_count <= (others => '0'); elsif Inc_cnt = '1' then Int_count <= Int_count + 1; elsif Dec_cnt = '1' then Int_count <= Int_count - 1; else Int_count <= Int_count + 0; -- I want to do a "no operation" here. end if; end process;
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: New 'standard' compact programming header needed! Next: problem in clock input in virtexpro/spartan3a/spartan3 kit |