Xilinx Synthesis Tool generates clock signals from combinatorial logic

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