FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 05-22-2009, 10:20 PM
jleslie48
Guest
 
Posts: n/a
Default INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred ....Warning. Should I care?

warning message:

INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred for signal
<array_reg>. You may be trying to describe a RAM in a way that is
incompatible with block and distributed RAM resources available on
Xilinx devices, or with a specific template that is not supported.
Please review the Xilinx resources documentation and the XST user
manual for coding guidelines. Taking advantage of RAM resources will
lead to improved device usage and reduced synthesis time..



I believe this is the offending code:

-----------------------------------------
entity fifo is
generic(
B: natural:=8; -- number of bits
W: natural:=4 -- number of address bits
);
port(
clk,
reset : in std_logic;
rd,
wr : in std_logic;
w_data : in std_logic_vector (B-1 downto 0);
empty,
notempty,
full : out std_logic;
r_data : out std_logic_vector (B-1 downto 0)
);
end fifo;

architecture arch of fifo is
type reg_file_type is array (2**W-1 downto 0) of
std_logic_vector(B-1 downto 0);
signal array_reg: reg_file_type;


-----------------------------------------



I'm just trying to figure out if this is something I could/should do
something about. I'm working with a spartan 3e chip and here's the
summary:

+++++++++++++++++++++++++++++++++++++++++++++++
Module Name:
lprj_TOP
Errors:
No Errors
Target Device:
xc3s1500-5fg456
Warnings:
98 Warnings
Product Version:
ISE 10.1.03 - Foundation
Routing Results:
All Signals Completely Routed
Design Goal:
Balanced
Timing Constraints:
All Constraints Met
Design Strategy:
Xilinx Default (unlocked)
Final Timing Score:
0 (Timing Report)



raggedstone_uart10 Partition Summary
[-]
No partition information was found.



Device Utilization Summary
[-]
Logic Utilization
Used
Available
Utilization
Note(s)
Number of Slice Flip Flops
2,126
26,624
7%

Number of 4 input LUTs
3,459
26,624
12%

Logic Distribution




Number of occupied Slices
2,900
13,312
21%

Number of Slices containing only related logic
2,900
2,900
100%

Number of Slices containing unrelated logic
0
2,900
0%

Total Number of 4 input LUTs
3,551
26,624
13%

Number used as logic
3,459



Number used as a route-thru
92



Number of bonded IOBs
Number of bonded
33
333
9%

IOB Flip Flops
1



Number of RAMB16s
2
32
6%

Number of MULT18X18s
4
32
12%

Number of BUFGMUXs
1
8
12%


+++++++++++++++++++++++++++++++++++++++++++++++


everything runs ok, I'm just trying to figure out if there is a better
way to do this, am I mis-using the chips resources, or maybe this
warning is meaningless.

Sincerely,

Jon
Reply With Quote
  #2 (permalink)  
Old 05-22-2009, 11:20 PM
jleslie48
Guest
 
Posts: n/a
Default Re: INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred ....Warning. Should I care?

On May 22, 5:26 pm, doug <[email protected]> wrote:

>
> Only FFs have reset.
>



that doesn't mean anything to me. maybe I inlcuded too much code in
the snippet, the only part of the code
that is causing the issue I believe is this:

-----------------------------------------------------------------------------------
type reg_file_type is array (2**W-1 downto 0) of
std_logic_vector(B-1 downto 0);
signal array_reg: reg_file_type;
-----------------------------------------------------------------------------------


the error message in question has no issue with the reset. its
complaining about <array_reg>

Reply With Quote
  #3 (permalink)  
Old 05-22-2009, 11:26 PM
doug
Guest
 
Posts: n/a
Default Re: INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred ....Warning. Should I care?



jleslie48 wrote:

> warning message:
>
> INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred for signal
> <array_reg>. You may be trying to describe a RAM in a way that is
> incompatible with block and distributed RAM resources available on
> Xilinx devices, or with a specific template that is not supported.
> Please review the Xilinx resources documentation and the XST user
> manual for coding guidelines. Taking advantage of RAM resources will
> lead to improved device usage and reduced synthesis time..
>
>
>
> I believe this is the offending code:
>
> -----------------------------------------
> entity fifo is
> generic(
> B: natural:=8; -- number of bits
> W: natural:=4 -- number of address bits
> );
> port(
> clk,
> reset : in std_logic;



Only FFs have reset.


> rd,
> wr : in std_logic;
> w_data : in std_logic_vector (B-1 downto 0);
> empty,
> notempty,
> full : out std_logic;
> r_data : out std_logic_vector (B-1 downto 0)
> );
> end fifo;
>
> architecture arch of fifo is
> type reg_file_type is array (2**W-1 downto 0) of
> std_logic_vector(B-1 downto 0);
> signal array_reg: reg_file_type;
>
>
> -----------------------------------------
>
>
>
> I'm just trying to figure out if this is something I could/should do
> something about. I'm working with a spartan 3e chip and here's the
> summary:
>
> +++++++++++++++++++++++++++++++++++++++++++++++
> Module Name:
> lprj_TOP
> Errors:
> No Errors
> Target Device:
> xc3s1500-5fg456
> Warnings:
> 98 Warnings
> Product Version:
> ISE 10.1.03 - Foundation
> Routing Results:
> All Signals Completely Routed
> Design Goal:
> Balanced
> Timing Constraints:
> All Constraints Met
> Design Strategy:
> Xilinx Default (unlocked)
> Final Timing Score:
> 0 (Timing Report)
>
>
>
> raggedstone_uart10 Partition Summary
> [-]
> No partition information was found.
>
>
>
> Device Utilization Summary
> [-]
> Logic Utilization
> Used
> Available
> Utilization
> Note(s)
> Number of Slice Flip Flops
> 2,126
> 26,624
> 7%
>
> Number of 4 input LUTs
> 3,459
> 26,624
> 12%
>
> Logic Distribution
>
>
>
>
> Number of occupied Slices
> 2,900
> 13,312
> 21%
>
> Number of Slices containing only related logic
> 2,900
> 2,900
> 100%
>
> Number of Slices containing unrelated logic
> 0
> 2,900
> 0%
>
> Total Number of 4 input LUTs
> 3,551
> 26,624
> 13%
>
> Number used as logic
> 3,459
>
>
>
> Number used as a route-thru
> 92
>
>
>
> Number of bonded IOBs
> Number of bonded
> 33
> 333
> 9%
>
> IOB Flip Flops
> 1
>
>
>
> Number of RAMB16s
> 2
> 32
> 6%
>
> Number of MULT18X18s
> 4
> 32
> 12%
>
> Number of BUFGMUXs
> 1
> 8
> 12%
>
>
> +++++++++++++++++++++++++++++++++++++++++++++++
>
>
> everything runs ok, I'm just trying to figure out if there is a better
> way to do this, am I mis-using the chips resources, or maybe this
> warning is meaningless.
>
> Sincerely,
>
> Jon

Reply With Quote
  #4 (permalink)  
Old 05-22-2009, 11:55 PM
Muzaffer Kal
Guest
 
Posts: n/a
Default Re: INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred .... Warning. Should I care?

On Fri, 22 May 2009 14:20:59 -0700 (PDT), jleslie48
<[email protected]> wrote:

>On May 22, 5:26 pm, doug <[email protected]> wrote:
>
>>
>> Only FFs have reset.
>>

>
>
>that doesn't mean anything to me. maybe I inlcuded too much code in
>the snippet, the only part of the code
>that is causing the issue I believe is this:
>
>-----------------------------------------------------------------------------------
> type reg_file_type is array (2**W-1 downto 0) of
> std_logic_vector(B-1 downto 0);
> signal array_reg: reg_file_type;
>-----------------------------------------------------------------------------------
>
>
>the error message in question has no issue with the reset. its
>complaining about <array_reg>


The "warning" is just telling you that it couldn't map your "array" to
memory. Doug has said the reason that couldn't be done probably was
that you have some code which says:

if (reset)
array <= 0

or something similar. As "only ffs have reset" this "array" can't be
mapped to memory. If you have code like this, remove it, add an
initial statement to clear array instead and try again.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com
Reply With Quote
  #5 (permalink)  
Old 05-23-2009, 02:23 AM
jleslie48
Guest
 
Posts: n/a
Default Re: INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred ....Warning. Should I care?

On May 22, 5:55 pm, Muzaffer Kal <[email protected]> wrote:
> On Fri, 22 May 2009 14:20:59 -0700 (PDT), jleslie48
>
>
>
> <[email protected]> wrote:
> >On May 22, 5:26 pm, doug <[email protected]> wrote:

>
> >> Only FFs have reset.

>
> >that doesn't mean anything to me. maybe I inlcuded too much code in
> >the snippet, the only part of the code
> >that is causing the issue I believe is this:

>
> >-----------------------------------------------------------------------------------
> > type reg_file_type is array (2**W-1 downto 0) of
> > std_logic_vector(B-1 downto 0);
> > signal array_reg: reg_file_type;
> >-----------------------------------------------------------------------------------

>
> >the error message in question has no issue with the reset. its
> >complaining about <array_reg>

>
> The "warning" is just telling you that it couldn't map your "array" to
> memory. Doug has said the reason that couldn't be done probably was
> that you have some code which says:
>
> if (reset)
> array <= 0
>
> or something similar. As "only ffs have reset" this "array" can't be
> mapped to memory. If you have code like this, remove it, add an
> initial statement to clear array instead and try again.
> --
> Muzaffer Kal
>
> DSPIA INC.
> ASIC/FPGA Design Services
>
> http://www.dspia.com


Thank you, that makes sense. I'll have to check.

Reply With Quote
  #6 (permalink)  
Old 05-26-2009, 04:46 PM
jleslie48
Guest
 
Posts: n/a
Default Re: INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred ....Warning. Should I care?

On May 22, 8:23 pm, jleslie48 <[email protected]> wrote:
> On May 22, 5:55 pm, Muzaffer Kal <[email protected]> wrote:
>
>
>
> > On Fri, 22 May 2009 14:20:59 -0700 (PDT), jleslie48

>
> > <[email protected]> wrote:
> > >On May 22, 5:26 pm, doug <[email protected]> wrote:

>
> > >> Only FFs have reset.

>
> > >that doesn't mean anything to me. maybe I inlcuded too much code in
> > >the snippet, the only part of the code
> > >that is causing the issue I believe is this:

>
> > >-----------------------------------------------------------------------------------
> > > type reg_file_type is array (2**W-1 downto 0) of
> > > std_logic_vector(B-1 downto 0);
> > > signal array_reg: reg_file_type;
> > >-----------------------------------------------------------------------------------

>
> > >the error message in question has no issue with the reset. its
> > >complaining about <array_reg>

>
> > The "warning" is just telling you that it couldn't map your "array" to
> > memory. Doug has said the reason that couldn't be done probably was
> > that you have some code which says:

>
> > if (reset)
> > array <= 0

>
> > or something similar. As "only ffs have reset" this "array" can't be
> > mapped to memory. If you have code like this, remove it, add an
> > initial statement to clear array instead and try again.
> > --
> > Muzaffer Kal

>
> > DSPIA INC.
> > ASIC/FPGA Design Services

>
> >http://www.dspia.com

>
> Thank you, that makes sense. I'll have to check.


C:\jon\fpga_uartjl_01\Pchu_cc02\ms_d04\source>grep -in -B3 -A3
array_reg fifo.vhd

23-architecture arch of fifo is
24- type reg_file_type is array (2**W-1 downto 0) of
25- std_logic_vector(B-1 downto 0);
26: signal array_reg: reg_file_type;
27- signal w_ptr_reg, w_ptr_next, w_ptr_succ:
28- std_logic_vector(W-1 downto 0);
29- signal r_ptr_reg, r_ptr_next, r_ptr_succ:
--
39- process(clk,reset)
40- begin
41- if (reset='1') then
42: array_reg <= (others=>(others=>'0'));
43- elsif (clk'event and clk='1') then
44- if wr_en='1' then
45: array_reg(to_integer(unsigned(w_ptr_reg)))
46- <= w_data;
47- end if;
48- end if;
49- end process;
50- -- read port
51: r_data <= array_reg(to_integer(unsigned(r_ptr_reg)));
52- -- write enabled only when FIFO is not full
53- wr_en <= wr and (not full_reg);
54-

Ok, so here's all the code pertaining to array_reg, specifically lines
42, 45, and 51. From what I can understand, it seems that the
professionals here are concerned about line 42; the one resulting from
the reset signal. What would be the correct way to implement this
concept?

In C I would of just done a memset(array_reg, 0, sizeof(array_reg))
but we ain't in C world any more...

Reply With Quote
  #7 (permalink)  
Old 05-26-2009, 08:58 PM
Andy Peters
Guest
 
Posts: n/a
Default Re: INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred ....Warning. Should I care?

On May 26, 7:46*am, jleslie48 <[email protected]> wrote:
> On May 22, 8:23 pm, jleslie48 <[email protected]> wrote:
>
>
>
> > On May 22, 5:55 pm, Muzaffer Kal <[email protected]> wrote:

>
> > > On Fri, 22 May 2009 14:20:59 -0700 (PDT), jleslie48

>
> > > <[email protected]> wrote:
> > > >On May 22, 5:26 pm, doug <[email protected]> wrote:

>
> > > >> Only FFs have reset.

>
> > > >that doesn't mean anything to me. *maybe I inlcuded too much code in
> > > >the snippet, *the only part of the code
> > > >that is causing the issue I believe is this:

>
> > > >-----------------------------------------------------------------------------------
> > > > * type reg_file_type is array (2**W-1 downto 0) of
> > > > * * * *std_logic_vector(B-1 downto 0);
> > > > * signal array_reg: reg_file_type;
> > > >-----------------------------------------------------------------------------------

>
> > > >the error message in question has no issue with the reset. *its
> > > >complaining about <array_reg>

>
> > > The "warning" is just telling you that it couldn't map your "array" to
> > > memory. Doug has said the reason that couldn't be done probably was
> > > that you have some code which says:

>
> > > if (reset)
> > > array <= 0

>
> > > or something similar. As "only ffs have reset" this "array" can't be
> > > mapped to memory. If you have code like this, remove it, add an
> > > initial statement to clear array instead and try again.
> > > --
> > > Muzaffer Kal

>
> > > DSPIA INC.
> > > ASIC/FPGA Design Services

>
> > >http://www.dspia.com

>
> > Thank you, that makes sense. *I'll have to check.

>
> C:\jon\fpga_uartjl_01\Pchu_cc02\ms_d04\source>grep -in -B3 -A3
> array_reg fifo.vhd
>
> 23-architecture arch of fifo is
> 24- * type reg_file_type is array (2**W-1 downto 0) of
> 25- * * * *std_logic_vector(B-1 downto 0);
> 26: * signal array_reg: reg_file_type;
> 27- * signal w_ptr_reg, w_ptr_next, w_ptr_succ:
> 28- * * *std_logic_vector(W-1 downto 0);
> 29- * signal r_ptr_reg, r_ptr_next, r_ptr_succ:
> --
> 39- * process(clk,reset)
> 40- * begin
> 41- * * if (reset='1') then
> 42: * * * *array_reg <= (others=>(others=>'0'));
> 43- * * elsif (clk'event and clk='1') then
> 44- * * * *if wr_en='1' then
> 45: * * * * * array_reg(to_integer(unsigned(w_ptr_reg)))
> 46- * * * * * * * * <= w_data;
> 47- * * * *end if;
> 48- * * end if;
> 49- * end process;
> 50- * -- read port
> 51: * r_data <= array_reg(to_integer(unsigned(r_ptr_reg)));
> 52- * -- write enabled only when FIFO is not full
> 53- * wr_en <= wr and (not full_reg);
> 54-
>
> Ok, so here's all the code pertaining to array_reg, specifically lines
> 42, 45, and 51. *From what I can understand, it seems that the
> professionals here are concerned about line 42; the one resulting from
> the reset signal. *What would be the correct way to implement this
> concept?


Simply delete the asynchronous reset stuff in lines 41 and 42, and
change the "elsif" on line 43 to a simple "if."

> In C I would of just done a memset(array_reg, 0, sizeof(array_reg))
> but we ain't in C world any more...


Indeed -- think HARDWARE.

Since you are describing a FIFO, there's no need to reset the memory.
Simply resetting the read and write pointers effectively clears the
memory. You will never read from an empty FIFO and a FIFO write
guarantees that you read valid data.

-a
Reply With Quote
  #8 (permalink)  
Old 05-26-2009, 09:26 PM
Muzaffer Kal
Guest
 
Posts: n/a
Default Re: INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred .... Warning. Should I care?

On Tue, 26 May 2009 07:46:48 -0700 (PDT), jleslie48
<[email protected]> wrote:

>39- process(clk,reset)
>40- begin
>41- if (reset='1') then
>42: array_reg <= (others=>(others=>'0'));
>43- elsif (clk'event and clk='1') then
>44- if wr_en='1' then
>45: array_reg(to_integer(unsigned(w_ptr_reg)))
>46- <= w_data;
>47- end if;
>48- end if;
>49- end process;
>50- -- read port
>51: r_data <= array_reg(to_integer(unsigned(r_ptr_reg)));
>52- -- write enabled only when FIFO is not full
>53- wr_en <= wr and (not full_reg);
>54-
>
>Ok, so here's all the code pertaining to array_reg, specifically lines
>42, 45, and 51. From what I can understand, it seems that the
>professionals here are concerned about line 42; the one resulting from
>the reset signal. What would be the correct way to implement this
>concept?
>

Remove reset from line 39, delete lines 41 & 42 and change elsif on 43
to if.

>In C I would of just done a memset(array_reg, 0, sizeof(array_reg))
>but we ain't in C world any more...


No you're not but things are not that different. Treat this array
contents as automatic variables ie don't use the values if you haven't
written to them first.
Also in an FPGA, you can even get it to be cleared too but you have to
do a little bit more work.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com
Reply With Quote
  #9 (permalink)  
Old 05-26-2009, 10:13 PM
jleslie48
Guest
 
Posts: n/a
Default Re: INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred ....Warning. Should I care?

On May 26, 2:58 pm, Andy Peters <[email protected]> wrote:
> On May 26, 7:46 am, jleslie48 <[email protected]> wrote:
>
>
>
> > On May 22, 8:23 pm, jleslie48 <[email protected]> wrote:

>
> > > On May 22, 5:55 pm, Muzaffer Kal <[email protected]> wrote:

>
> > > > On Fri, 22 May 2009 14:20:59 -0700 (PDT), jleslie48

>
> > > > <[email protected]> wrote:
> > > > >On May 22, 5:26 pm, doug <[email protected]> wrote:

>
> > > > >> Only FFs have reset.

>
> > > > >that doesn't mean anything to me. maybe I inlcuded too much code in
> > > > >the snippet, the only part of the code
> > > > >that is causing the issue I believe is this:

>
> > > > >-----------------------------------------------------------------------------------
> > > > > type reg_file_type is array (2**W-1 downto 0) of
> > > > > std_logic_vector(B-1 downto 0);
> > > > > signal array_reg: reg_file_type;
> > > > >-----------------------------------------------------------------------------------

>
> > > > >the error message in question has no issue with the reset. its
> > > > >complaining about <array_reg>

>
> > > > The "warning" is just telling you that it couldn't map your "array" to
> > > > memory. Doug has said the reason that couldn't be done probably was
> > > > that you have some code which says:

>
> > > > if (reset)
> > > > array <= 0

>
> > > > or something similar. As "only ffs have reset" this "array" can't be
> > > > mapped to memory. If you have code like this, remove it, add an
> > > > initial statement to clear array instead and try again.
> > > > --
> > > > Muzaffer Kal

>
> > > > DSPIA INC.
> > > > ASIC/FPGA Design Services

>
> > > >http://www.dspia.com

>
> > > Thank you, that makes sense. I'll have to check.

>
> > C:\jon\fpga_uartjl_01\Pchu_cc02\ms_d04\source>grep -in -B3 -A3
> > array_reg fifo.vhd

>
> > 23-architecture arch of fifo is
> > 24- type reg_file_type is array (2**W-1 downto 0) of
> > 25- std_logic_vector(B-1 downto 0);
> > 26: signal array_reg: reg_file_type;
> > 27- signal w_ptr_reg, w_ptr_next, w_ptr_succ:
> > 28- std_logic_vector(W-1 downto 0);
> > 29- signal r_ptr_reg, r_ptr_next, r_ptr_succ:
> > --
> > 39- process(clk,reset)
> > 40- begin
> > 41- if (reset='1') then
> > 42: array_reg <= (others=>(others=>'0'));
> > 43- elsif (clk'event and clk='1') then
> > 44- if wr_en='1' then
> > 45: array_reg(to_integer(unsigned(w_ptr_reg)))
> > 46- <= w_data;
> > 47- end if;
> > 48- end if;
> > 49- end process;
> > 50- -- read port
> > 51: r_data <= array_reg(to_integer(unsigned(r_ptr_reg)));
> > 52- -- write enabled only when FIFO is not full
> > 53- wr_en <= wr and (not full_reg);
> > 54-

>
> > Ok, so here's all the code pertaining to array_reg, specifically lines
> > 42, 45, and 51. From what I can understand, it seems that the
> > professionals here are concerned about line 42; the one resulting from
> > the reset signal. What would be the correct way to implement this
> > concept?

>
> Simply delete the asynchronous reset stuff in lines 41 and 42, and
> change the "elsif" on line 43 to a simple "if."
>
> > In C I would of just done a memset(array_reg, 0, sizeof(array_reg))
> > but we ain't in C world any more...

>
> Indeed -- think HARDWARE.
>
> Since you are describing a FIFO, there's no need to reset the memory.
> Simply resetting the read and write pointers effectively clears the
> memory. You will never read from an empty FIFO and a FIFO write
> guarantees that you read valid data.
>
> -a


quite right,

the other process has:
process(clk,reset)
begin
if (reset='1') then
w_ptr_reg <= (others=>'0');
r_ptr_reg <= (others=>'0');
full_reg <= '0';
empty_reg <= '1';

and as my pointers get reset who cares about the data. System
resources went dramatically down as a result of the changes, however
two warnings are now being generated that were never there before:


WARNING Route - CLK Net:clk_2mhz is being routed on general routing
resources. If you are trying to use local clocking techniques,
evaluate the placement of the clock's source and loads to ensure it
meets the guidelines for local clocking. Otherwise, consider placing
this clock on a dedicated clock routing resource. For more information
on clock routing resources, see the target architecture's user guide.

WARNING Route - CLK Net:clk_7812hz is being routed on general routing
resources. If you are trying to use local clocking techniques,
evaluate the placement of the clock's source and loads to ensure it
meets the guidelines for local clocking. Otherwise, consider placing
this clock on a dedicated clock routing resource. For more information
on clock routing resources, see the target architecture's user guide.

I can't imagine why these are showing up as a result of "fixing" the
other error.

Reply With Quote
  #10 (permalink)  
Old 05-27-2009, 06:51 PM
Andy Peters
Guest
 
Posts: n/a
Default Re: INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred ....Warning. Should I care?

On May 26, 1:13*pm, jleslie48 <[email protected]> wrote:
> On May 26, 2:58 pm, Andy Peters <[email protected]> wrote:
>
>
>
> > On May 26, 7:46 am, jleslie48 <[email protected]> wrote:

>
> > > On May 22, 8:23 pm, jleslie48 <[email protected]> wrote:

>
> > > > On May 22, 5:55 pm, Muzaffer Kal <[email protected]> wrote:

>
> > > > > On Fri, 22 May 2009 14:20:59 -0700 (PDT), jleslie48

>
> > > > > <[email protected]> wrote:
> > > > > >On May 22, 5:26 pm, doug <[email protected]> wrote:

>
> > > > > >> Only FFs have reset.

>
> > > > > >that doesn't mean anything to me. *maybe I inlcuded too much code in
> > > > > >the snippet, *the only part of the code
> > > > > >that is causing the issue I believe is this:

>
> > > > > >-----------------------------------------------------------------------------------
> > > > > > * type reg_file_type is array (2**W-1 downto 0) of
> > > > > > * * * *std_logic_vector(B-1 downto 0);
> > > > > > * signal array_reg: reg_file_type;
> > > > > >-----------------------------------------------------------------------------------

>
> > > > > >the error message in question has no issue with the reset. *its
> > > > > >complaining about <array_reg>

>
> > > > > The "warning" is just telling you that it couldn't map your "array" to
> > > > > memory. Doug has said the reason that couldn't be done probably was
> > > > > that you have some code which says:

>
> > > > > if (reset)
> > > > > array <= 0

>
> > > > > or something similar. As "only ffs have reset" this "array" can'tbe
> > > > > mapped to memory. If you have code like this, remove it, add an
> > > > > initial statement to clear array instead and try again.
> > > > > --
> > > > > Muzaffer Kal

>
> > > > > DSPIA INC.
> > > > > ASIC/FPGA Design Services

>
> > > > >http://www.dspia.com

>
> > > > Thank you, that makes sense. *I'll have to check.

>
> > > C:\jon\fpga_uartjl_01\Pchu_cc02\ms_d04\source>grep -in -B3 -A3
> > > array_reg fifo.vhd

>
> > > 23-architecture arch of fifo is
> > > 24- * type reg_file_type is array (2**W-1 downto 0) of
> > > 25- * * * *std_logic_vector(B-1 downto 0);
> > > 26: * signal array_reg: reg_file_type;
> > > 27- * signal w_ptr_reg, w_ptr_next, w_ptr_succ:
> > > 28- * * *std_logic_vector(W-1 downto 0);
> > > 29- * signal r_ptr_reg, r_ptr_next, r_ptr_succ:
> > > --
> > > 39- * process(clk,reset)
> > > 40- * begin
> > > 41- * * if (reset='1') then
> > > 42: * * * *array_reg <= (others=>(others=>'0'));
> > > 43- * * elsif (clk'event and clk='1') then
> > > 44- * * * *if wr_en='1' then
> > > 45: * * * * * array_reg(to_integer(unsigned(w_ptr_reg)))
> > > 46- * * * * * * * * <= w_data;
> > > 47- * * * *end if;
> > > 48- * * end if;
> > > 49- * end process;
> > > 50- * -- read port
> > > 51: * r_data <= array_reg(to_integer(unsigned(r_ptr_reg)));
> > > 52- * -- write enabled only when FIFO is not full
> > > 53- * wr_en <= wr and (not full_reg);
> > > 54-

>
> > > Ok, so here's all the code pertaining to array_reg, specifically lines
> > > 42, 45, and 51. *From what I can understand, it seems that the
> > > professionals here are concerned about line 42; the one resulting from
> > > the reset signal. *What would be the correct way to implement this
> > > concept?

>
> > Simply delete the asynchronous reset stuff in lines 41 and 42, and
> > change the "elsif" on line 43 to a simple "if."

>
> > > In C I would of just done a memset(array_reg, 0, sizeof(array_reg))
> > > but we ain't in C world any more...

>
> > Indeed -- think HARDWARE.

>
> > Since you are describing a FIFO, there's no need to reset the memory.
> > Simply resetting the read and write pointers effectively clears the
> > memory. You will never read from an empty FIFO and a FIFO write
> > guarantees that you read valid data.

>
> > -a

>
> quite right,
>
> the other process has:
> * process(clk,reset)
> * *begin
> * * * if (reset='1') then
> * * * * *w_ptr_reg <= (others=>'0');
> * * * * *r_ptr_reg <= (others=>'0');
> * * * * *full_reg <= '0';
> * * * * *empty_reg <= '1';
>
> and as my pointers get reset who cares about the data. *System
> resources went dramatically down as a result of the changes,


I'm glad the suggestion worked for you!

> however
> two warnings are now being generated that were never there before:
>
> WARNING Route - CLK Net:clk_2mhz is being routed on general routing
> resources. If you are trying to use local clocking techniques,
> evaluate the placement of the clock's source and loads to ensure it
> meets the guidelines for local clocking. Otherwise, consider placing
> this clock on a dedicated clock routing resource. For more information
> on clock routing resources, see the target architecture's user guide.
>
> WARNING Route - CLK Net:clk_7812hz is being routed on general routing
> resources. If you are trying to use local clocking techniques,
> evaluate the placement of the clock's source and loads to ensure it
> meets the guidelines for local clocking. Otherwise, consider placing
> this clock on a dedicated clock routing resource. For more information
> on clock routing resources, see the target architecture's user guide.
>
> I can't imagine why these are showing up as a result of "fixing" the
> other error.


Sounds like the clock signals are coming into the FPGA on non-clock
pins. You probably didn't see this error before because the original
warnings/complaints were issued by XST (the synthesis tool) and you
went no further. Now that the source synthesizes, the place and route
tools take over, and the warning you get is issued by the router.

Check your UCF and pin selection.

-a
Reply With Quote
  #11 (permalink)  
Old 05-27-2009, 10:14 PM
jleslie48
Guest
 
Posts: n/a
Default Re: INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred ....Warning. Should I care?

On May 27, 12:51 pm, Andy Peters <[email protected]> wrote:
> On May 26, 1:13 pm, jleslie48 <[email protected]> wrote:
>
>
>


>
> > > > 23-architecture arch of fifo is
> > > > 24- type reg_file_type is array (2**W-1 downto 0) of
> > > > 25- std_logic_vector(B-1 downto 0);
> > > > 26: signal array_reg: reg_file_type;
> > > > 27- signal w_ptr_reg, w_ptr_next, w_ptr_succ:
> > > > 28- std_logic_vector(W-1 downto 0);
> > > > 29- signal r_ptr_reg, r_ptr_next, r_ptr_succ:
> > > > --
> > > > 39- process(clk,reset)
> > > > 40- begin
> > > > 41- if (reset='1') then
> > > > 42: array_reg <= (others=>(others=>'0'));
> > > > 43- elsif (clk'event and clk='1') then
> > > > 44- if wr_en='1' then
> > > > 45: array_reg(to_integer(unsigned(w_ptr_reg)))
> > > > 46- <= w_data;
> > > > 47- end if;
> > > > 48- end if;
> > > > 49- end process;
> > > > 50- -- read port
> > > > 51: r_data <= array_reg(to_integer(unsigned(r_ptr_reg)));
> > > > 52- -- write enabled only when FIFO is not full
> > > > 53- wr_en <= wr and (not full_reg);
> > > > 54-

>
> > > > Ok, so here's all the code pertaining to array_reg, specifically lines
> > > > 42, 45, and 51. From what I can understand, it seems that the
> > > > professionals here are concerned about line 42; the one resulting from
> > > > the reset signal. What would be the correct way to implement this
> > > > concept?

>
> > > Simply delete the asynchronous reset stuff in lines 41 and 42, and
> > > change the "elsif" on line 43 to a simple "if."

>
> > > > In C I would of just done a memset(array_reg, 0, sizeof(array_reg))
> > > > but we ain't in C world any more...

>
> > > Indeed -- think HARDWARE.

>
> > > Since you are describing a FIFO, there's no need to reset the memory.
> > > Simply resetting the read and write pointers effectively clears the
> > > memory. You will never read from an empty FIFO and a FIFO write
> > > guarantees that you read valid data.

>
> > > -a

>
> > quite right,

>
> > the other process has:
> > process(clk,reset)
> > begin
> > if (reset='1') then
> > w_ptr_reg <= (others=>'0');
> > r_ptr_reg <= (others=>'0');
> > full_reg <= '0';
> > empty_reg <= '1';

>
> > and as my pointers get reset who cares about the data. System
> > resources went dramatically down as a result of the changes,

>
> I'm glad the suggestion worked for you!
>
>
>
> > however
> > two warnings are now being generated that were never there before:

>
> > WARNING Route - CLK Net:clk_2mhz is being routed on general routing
> > resources. If you are trying to use local clocking techniques,
> > evaluate the placement of the clock's source and loads to ensure it
> > meets the guidelines for local clocking. Otherwise, consider placing
> > this clock on a dedicated clock routing resource. For more information
> > on clock routing resources, see the target architecture's user guide.

>
> > WARNING Route - CLK Net:clk_7812hz is being routed on general routing
> > resources. If you are trying to use local clocking techniques,
> > evaluate the placement of the clock's source and loads to ensure it
> > meets the guidelines for local clocking. Otherwise, consider placing
> > this clock on a dedicated clock routing resource. For more information
> > on clock routing resources, see the target architecture's user guide.

>
> > I can't imagine why these are showing up as a result of "fixing" the
> > other error.

>
> Sounds like the clock signals are coming into the FPGA on non-clock
> pins. You probably didn't see this error before because the original
> warnings/complaints were issued by XST (the synthesis tool) and you
> went no further. Now that the source synthesizes, the place and route
> tools take over, and the warning you get is issued by the router.
>
> Check your UCF and pin selection.
>
> -a


H'mmm, I checked the place and route report before and after the
change in code. the Warnings are definitely not there when the 256
flip-flop warning is in place.

I'll have to take a look at the UCF and see what can be done with the
pins I'm using. I'm a bit confused about that, I thought GPIO is
GPIO, I'm sending in a signal, and that's it, but I know that there is
a document out there from Xilinx (how they love their documents) that
says something about the pins... lets me check and see what I can
find.

Reply With Quote
  #12 (permalink)  
Old 05-28-2009, 01:35 AM
rickman
Guest
 
Posts: n/a
Default Re: INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred ....Warning. Should I care?

On May 27, 4:14 pm, jleslie48 <[email protected]> wrote:
> On May 27, 12:51 pm, Andy Peters <[email protected]> wrote:
>
>
>
> > On May 26, 1:13 pm, jleslie48 <[email protected]> wrote:

>
> > > > > 23-architecture arch of fifo is
> > > > > 24- type reg_file_type is array (2**W-1 downto 0) of
> > > > > 25- std_logic_vector(B-1 downto 0);
> > > > > 26: signal array_reg: reg_file_type;
> > > > > 27- signal w_ptr_reg, w_ptr_next, w_ptr_succ:
> > > > > 28- std_logic_vector(W-1 downto 0);
> > > > > 29- signal r_ptr_reg, r_ptr_next, r_ptr_succ:
> > > > > --
> > > > > 39- process(clk,reset)
> > > > > 40- begin
> > > > > 41- if (reset='1') then
> > > > > 42: array_reg <= (others=>(others=>'0'));
> > > > > 43- elsif (clk'event and clk='1') then
> > > > > 44- if wr_en='1' then
> > > > > 45: array_reg(to_integer(unsigned(w_ptr_reg)))
> > > > > 46- <= w_data;
> > > > > 47- end if;
> > > > > 48- end if;
> > > > > 49- end process;
> > > > > 50- -- read port
> > > > > 51: r_data <= array_reg(to_integer(unsigned(r_ptr_reg)));
> > > > > 52- -- write enabled only when FIFO is not full
> > > > > 53- wr_en <= wr and (not full_reg);
> > > > > 54-

>
> > > > > Ok, so here's all the code pertaining to array_reg, specifically lines
> > > > > 42, 45, and 51. From what I can understand, it seems that the
> > > > > professionals here are concerned about line 42; the one resulting from
> > > > > the reset signal. What would be the correct way to implement this
> > > > > concept?

>
> > > > Simply delete the asynchronous reset stuff in lines 41 and 42, and
> > > > change the "elsif" on line 43 to a simple "if."

>
> > > > > In C I would of just done a memset(array_reg, 0, sizeof(array_reg))
> > > > > but we ain't in C world any more...

>
> > > > Indeed -- think HARDWARE.

>
> > > > Since you are describing a FIFO, there's no need to reset the memory.
> > > > Simply resetting the read and write pointers effectively clears the
> > > > memory. You will never read from an empty FIFO and a FIFO write
> > > > guarantees that you read valid data.

>
> > > > -a

>
> > > quite right,

>
> > > the other process has:
> > > process(clk,reset)
> > > begin
> > > if (reset='1') then
> > > w_ptr_reg <= (others=>'0');
> > > r_ptr_reg <= (others=>'0');
> > > full_reg <= '0';
> > > empty_reg <= '1';

>
> > > and as my pointers get reset who cares about the data. System
> > > resources went dramatically down as a result of the changes,

>
> > I'm glad the suggestion worked for you!

>
> > > however
> > > two warnings are now being generated that were never there before:

>
> > > WARNING Route - CLK Net:clk_2mhz is being routed on general routing
> > > resources. If you are trying to use local clocking techniques,
> > > evaluate the placement of the clock's source and loads to ensure it
> > > meets the guidelines for local clocking. Otherwise, consider placing
> > > this clock on a dedicated clock routing resource. For more information
> > > on clock routing resources, see the target architecture's user guide.

>
> > > WARNING Route - CLK Net:clk_7812hz is being routed on general routing
> > > resources. If you are trying to use local clocking techniques,
> > > evaluate the placement of the clock's source and loads to ensure it
> > > meets the guidelines for local clocking. Otherwise, consider placing
> > > this clock on a dedicated clock routing resource. For more information
> > > on clock routing resources, see the target architecture's user guide.

>
> > > I can't imagine why these are showing up as a result of "fixing" the
> > > other error.

>
> > Sounds like the clock signals are coming into the FPGA on non-clock
> > pins. You probably didn't see this error before because the original
> > warnings/complaints were issued by XST (the synthesis tool) and you
> > went no further. Now that the source synthesizes, the place and route
> > tools take over, and the warning you get is issued by the router.

>
> > Check your UCF and pin selection.

>
> > -a

>
> H'mmm, I checked the place and route report before and after the
> change in code. the Warnings are definitely not there when the 256
> flip-flop warning is in place.
>
> I'll have to take a look at the UCF and see what can be done with the
> pins I'm using. I'm a bit confused about that, I thought GPIO is
> GPIO, I'm sending in a signal, and that's it, but I know that there is
> a document out there from Xilinx (how they love their documents) that
> says something about the pins... lets me check and see what I can
> find.


You can use a GPIO pin as a clock line. It will come in through the
GPIO buffers, get routed onto logic routing resources and, if it
drives a significant amount of logic. eventually be used to drive a
global clock line. The part that *might* not be good is the GPIO and
general logic routing since it adds a lot of delay. This is only a
problem if you are using this clock to drive FFs that have inputs or
outputs on I/O pins and you care about the I/O timing. If this clock
is only used for logic that does not using inputs or outputs on I/O
pins, then it is not an issue.

Rick
Reply With Quote
  #13 (permalink)  
Old 05-28-2009, 06:43 PM
jleslie48
Guest
 
Posts: n/a
Default Re: INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred ....Warning. Should I care?

On May 27, 4:14 pm, jleslie48 <[email protected]> wrote:
> On May 27, 12:51 pm, Andy Peters <[email protected]> wrote:
>
>
>
> > On May 26, 1:13 pm, jleslie48 <[email protected]> wrote:

>
> > > > > 23-architecture arch of fifo is
> > > > > 24- type reg_file_type is array (2**W-1 downto 0) of
> > > > > 25- std_logic_vector(B-1 downto 0);
> > > > > 26: signal array_reg: reg_file_type;
> > > > > 27- signal w_ptr_reg, w_ptr_next, w_ptr_succ:
> > > > > 28- std_logic_vector(W-1 downto 0);
> > > > > 29- signal r_ptr_reg, r_ptr_next, r_ptr_succ:
> > > > > --
> > > > > 39- process(clk,reset)
> > > > > 40- begin
> > > > > 41- if (reset='1') then
> > > > > 42: array_reg <= (others=>(others=>'0'));
> > > > > 43- elsif (clk'event and clk='1') then
> > > > > 44- if wr_en='1' then
> > > > > 45: array_reg(to_integer(unsigned(w_ptr_reg)))
> > > > > 46- <= w_data;
> > > > > 47- end if;
> > > > > 48- end if;
> > > > > 49- end process;
> > > > > 50- -- read port
> > > > > 51: r_data <= array_reg(to_integer(unsigned(r_ptr_reg)));
> > > > > 52- -- write enabled only when FIFO is not full
> > > > > 53- wr_en <= wr and (not full_reg);
> > > > > 54-

>
> > > > > Ok, so here's all the code pertaining to array_reg, specifically lines
> > > > > 42, 45, and 51. From what I can understand, it seems that the
> > > > > professionals here are concerned about line 42; the one resulting from
> > > > > the reset signal. What would be the correct way to implement this
> > > > > concept?

>
> > > > Simply delete the asynchronous reset stuff in lines 41 and 42, and
> > > > change the "elsif" on line 43 to a simple "if."

>
> > > > > In C I would of just done a memset(array_reg, 0, sizeof(array_reg))
> > > > > but we ain't in C world any more...

>
> > > > Indeed -- think HARDWARE.

>
> > > > Since you are describing a FIFO, there's no need to reset the memory.
> > > > Simply resetting the read and write pointers effectively clears the
> > > > memory. You will never read from an empty FIFO and a FIFO write
> > > > guarantees that you read valid data.

>
> > > > -a

>
> > > quite right,

>
> > > the other process has:
> > > process(clk,reset)
> > > begin
> > > if (reset='1') then
> > > w_ptr_reg <= (others=>'0');
> > > r_ptr_reg <= (others=>'0');
> > > full_reg <= '0';
> > > empty_reg <= '1';

>
> > > and as my pointers get reset who cares about the data. System
> > > resources went dramatically down as a result of the changes,

>
> > I'm glad the suggestion worked for you!

>
> > > however
> > > two warnings are now being generated that were never there before:

>
> > > WARNING Route - CLK Net:clk_2mhz is being routed on general routing
> > > resources. If you are trying to use local clocking techniques,
> > > evaluate the placement of the clock's source and loads to ensure it
> > > meets the guidelines for local clocking. Otherwise, consider placing
> > > this clock on a dedicated clock routing resource. For more information
> > > on clock routing resources, see the target architecture's user guide.

>
> > > WARNING Route - CLK Net:clk_7812hz is being routed on general routing
> > > resources. If you are trying to use local clocking techniques,
> > > evaluate the placement of the clock's source and loads to ensure it
> > > meets the guidelines for local clocking. Otherwise, consider placing
> > > this clock on a dedicated clock routing resource. For more information
> > > on clock routing resources, see the target architecture's user guide.

>
> > > I can't imagine why these are showing up as a result of "fixing" the
> > > other error.

>
> > Sounds like the clock signals are coming into the FPGA on non-clock
> > pins. You probably didn't see this error before because the original
> > warnings/complaints were issued by XST (the synthesis tool) and you
> > went no further. Now that the source synthesizes, the place and route
> > tools take over, and the warning you get is issued by the router.

>
> > Check your UCF and pin selection.

>
> > -a

>
> H'mmm, I checked the place and route report before and after the
> change in code. the Warnings are definitely not there when the 256
> flip-flop warning is in place.
>
> I'll have to take a look at the UCF and see what can be done with the
> pins I'm using. I'm a bit confused about that, I thought GPIO is
> GPIO, I'm sending in a signal, and that's it, but I know that there is
> a document out there from Xilinx (how they love their documents) that
> says something about the pins... lets me check and see what I can
> find.


OK, so from the UCF I was provided here is the system clock:

---------------------------------
#DRIGMORN PACKAGE IS CP132/CPG132
#
#####################################
#CLOCK
#####################################
NET "SYSTEM_CLOCK" LOC = "M6";
-----------------------------------------------------------------

And from the DS312.pdf, the 'spartan-3E Fpga family: complete data
sheet' document for the spartan 3E I find this:

----------------------------------------------------------------------------------------
Table 132: CP132 Package Pinout (Continued)


XC3S250E
Bank XC3S100E XC3S500E
Pin Name Pin
Name CP132 Ball Type
....
2 IP_L05N_2/M2/GCLK1 IP_L05N_2/M2/GCLK1
N6 DUAL/GCLK
2 IP_L05P_2/RDWR_B/GCLK0 IP_L05P_2/RDWR_B/GCLK0
M6 DUAL/GCLK
....

DS312-4 (v3.7) April 18, 2008 www.xilinx.com
175
Product Specification

----------------------------------------------------------------------------------------

so here is how the system clock is defined in the ucf, no attributes
are assigned to the M6 pin, and
the only attributes at all I see in the whole UCF is:

NET "RXD" LOC = "A7" | PULLUP; #INPUT FROM RS232 CHIP

a PULLUP.

So now I want a 2MHZ "clock" on some other pin, what is the criteria I
should be looking for in a candidate pin?
is that DUAL/GCLK thing significant, or am I supposed to use some
attribute? For that matter what is the full set of
attributes that is available, is it described in any manual? And
Further, am I even on the right track? Is this even the correct
manual to be looking at for this info???
Reply With Quote
  #14 (permalink)  
Old 05-28-2009, 09:06 PM
Andy Peters
Guest
 
Posts: n/a
Default Re: INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred ....Warning. Should I care?

On May 28, 9:43*am, jleslie48 <[email protected]> wrote:
> On May 27, 4:14 pm, jleslie48 <[email protected]> wrote:
>
>
>
> > On May 27, 12:51 pm, Andy Peters <[email protected]> wrote:

>
> > > On May 26, 1:13 pm, jleslie48 <[email protected]> wrote:

>
> > > > > > 23-architecture arch of fifo is
> > > > > > 24- * type reg_file_type is array (2**W-1 downto 0) of
> > > > > > 25- * * * *std_logic_vector(B-1 downto 0);
> > > > > > 26: * signal array_reg: reg_file_type;
> > > > > > 27- * signal w_ptr_reg, w_ptr_next, w_ptr_succ:
> > > > > > 28- * * *std_logic_vector(W-1 downto 0);
> > > > > > 29- * signal r_ptr_reg, r_ptr_next, r_ptr_succ:
> > > > > > --
> > > > > > 39- * process(clk,reset)
> > > > > > 40- * begin
> > > > > > 41- * * if (reset='1') then
> > > > > > 42: * * * *array_reg <= (others=>(others=>'0'));
> > > > > > 43- * * elsif (clk'event and clk='1') then
> > > > > > 44- * * * *if wr_en='1' then
> > > > > > 45: * * * * * array_reg(to_integer(unsigned(w_ptr_reg)))
> > > > > > 46- * * * * * * * * <= w_data;
> > > > > > 47- * * * *end if;
> > > > > > 48- * * end if;
> > > > > > 49- * end process;
> > > > > > 50- * -- read port
> > > > > > 51: * r_data <= array_reg(to_integer(unsigned(r_ptr_reg)));
> > > > > > 52- * -- write enabled only when FIFO is not full
> > > > > > 53- * wr_en <= wr and (not full_reg);
> > > > > > 54-

>
> > > > > > Ok, so here's all the code pertaining to array_reg, specifically lines
> > > > > > 42, 45, and 51. *From what I can understand, it seems that the
> > > > > > professionals here are concerned about line 42; the one resulting from
> > > > > > the reset signal. *What would be the correct way to implementthis
> > > > > > concept?

>
> > > > > Simply delete the asynchronous reset stuff in lines 41 and 42, and
> > > > > change the "elsif" on line 43 to a simple "if."

>
> > > > > > In C I would of just done a memset(array_reg, 0, sizeof(array_reg))
> > > > > > but we ain't in C world any more...

>
> > > > > Indeed -- think HARDWARE.

>
> > > > > Since you are describing a FIFO, there's no need to reset the memory.
> > > > > Simply resetting the read and write pointers effectively clears the
> > > > > memory. You will never read from an empty FIFO and a FIFO write
> > > > > guarantees that you read valid data.

>
> > > > > -a

>
> > > > quite right,

>
> > > > the other process has:
> > > > * process(clk,reset)
> > > > * *begin
> > > > * * * if (reset='1') then
> > > > * * * * *w_ptr_reg <= (others=>'0');
> > > > * * * * *r_ptr_reg <= (others=>'0');
> > > > * * * * *full_reg <= '0';
> > > > * * * * *empty_reg <= '1';

>
> > > > and as my pointers get reset who cares about the data. *System
> > > > resources went dramatically down as a result of the changes,

>
> > > I'm glad the suggestion worked for you!

>
> > > > however
> > > > two warnings are now being generated that were never there before:

>
> > > > WARNING Route - CLK Net:clk_2mhz is being routed on general routing
> > > > resources. If you are trying to use local clocking techniques,
> > > > evaluate the placement of the clock's source and loads to ensure it
> > > > meets the guidelines for local clocking. Otherwise, consider placing
> > > > this clock on a dedicated clock routing resource. For more information
> > > > on clock routing resources, see the target architecture's user guide.

>
> > > > WARNING Route - CLK Net:clk_7812hz is being routed on general routing
> > > > resources. If you are trying to use local clocking techniques,
> > > > evaluate the placement of the clock's source and loads to ensure it
> > > > meets the guidelines for local clocking. Otherwise, consider placing
> > > > this clock on a dedicated clock routing resource. For more information
> > > > on clock routing resources, see the target architecture's user guide.

>
> > > > I can't imagine why these are showing up as a result of "fixing" the
> > > > other error.

>
> > > Sounds like the clock signals are coming into the FPGA on non-clock
> > > pins. You probably didn't see this error before because the original
> > > warnings/complaints were issued by XST (the synthesis tool) and you
> > > went no further. Now that the source synthesizes, the place and route
> > > tools take over, and the warning you get is issued by the router.

>
> > > Check your UCF and pin selection.

>
> > > -a

>
> > H'mmm, * I checked the place and route report before and after the
> > change in code. *the Warnings are definitely not there when the 256
> > flip-flop warning is in place.

>
> > I'll have to take a look at the UCF and see what can be done with the
> > pins I'm using. *I'm a bit confused about that, I thought GPIO is
> > GPIO, I'm sending in a signal, and that's it, but I know that there is
> > a document out there from Xilinx (how they love their documents) that
> > says something about the pins... *lets me check and see what I can
> > find.

>
> OK, so from the UCF I was provided here is the system clock:
>
> ---------------------------------
> #DRIGMORN PACKAGE IS CP132/CPG132
> #
> #####################################
> #CLOCK
> #####################################
> NET "SYSTEM_CLOCK" LOC = "M6";
> -----------------------------------------------------------------
>
> And from the DS312.pdf, the 'spartan-3E Fpga family: complete data
> sheet' document for the spartan 3E I find this:
>
> ----------------------------------------------------------------------------------------
> Table *132: *CP132 Package Pinout (Continued)
>
> XC3S250E
> Bank * * *XC3S100E * * * * * * * * * * * * * * * * *XC3S500E
> * * * * * * *Pin Name * * * * * * * * * * * * * * * * * *Pin
> Name * * * * * * * * * * *CP132 Ball * * Type
> ...
> 2 * *IP_L05N_2/M2/GCLK1 * * * * * * * IP_L05N_2/M2/GCLK1
> N6 * * * * * * *DUAL/GCLK
> 2 * *IP_L05P_2/RDWR_B/GCLK0 * * IP_L05P_2/RDWR_B/GCLK0
> M6 * * * * * * *DUAL/GCLK
> ...
>
> DS312-4 (v3.7) April 18, 2008 * * * * * * *www.xilinx.com
> 175
> Product Specification
>
> ----------------------------------------------------------------------------------------
>
> so here is how the system clock is defined in the ucf, no attributes
> are assigned to the M6 pin, and


OK, this is fine -- M6 is a global clock pin (GCLK) and as such when
synthesized, the tools should automatically infer an IBUFG for it. But
apparently they don't. Does SYSTEM_CLOCK drive any other non-clock
resources?

> the only attributes at all I see in the whole UCF is:
>
> NET "RXD" LOC = "A7" * *| PULLUP; * #INPUT FROM RS232 CHIP
>
> a PULLUP.
>
> So now I want a 2MHZ "clock" on some other pin, what is the criteria I
> should be looking for in a candidate pin?
> is that DUAL/GCLK thing significant, or am I supposed to use some
> attribute? *For that matter what is the full set of
> attributes that is available, is it described in any manual? *And
> Further, am I even on the right track? *Is this even the correct
> manual to be looking at for this info???


The family data sheet tells you which pins are to be used for clock
inputs: they are GCLK and in some families LHCLK, RHCLK, or CC. "Dual"
simply means that the pins have one function during FPGA configuration
and another afterwards.

So for Spartan 3E simply choose one of the many GCLK pins. I would
avoid the pins that also have a configuration function (I think GCLK1
is like that).

-a
Reply With Quote
  #15 (permalink)  
Old 05-28-2009, 09:50 PM
jleslie48
Guest
 
Posts: n/a
Default Re: INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred ....Warning. Should I care?

On May 28, 3:06 pm, Andy Peters <[email protected]> wrote:
> On May 28, 9:43 am, jleslie48 <[email protected]> wrote:
>
>
>
> > On May 27, 4:14 pm, jleslie48 <[email protected]> wrote:

>
> > > On May 27, 12:51 pm, Andy Peters <[email protected]> wrote:

>
> > > > On May 26, 1:13 pm, jleslie48 <[email protected]> wrote:

>
> > > > > > > 23-architecture arch of fifo is
> > > > > > > 24- type reg_file_type is array (2**W-1 downto 0) of
> > > > > > > 25- std_logic_vector(B-1 downto 0);
> > > > > > > 26: signal array_reg: reg_file_type;
> > > > > > > 27- signal w_ptr_reg, w_ptr_next, w_ptr_succ:
> > > > > > > 28- std_logic_vector(W-1 downto 0);
> > > > > > > 29- signal r_ptr_reg, r_ptr_next, r_ptr_succ:
> > > > > > > --
> > > > > > > 39- process(clk,reset)
> > > > > > > 40- begin
> > > > > > > 41- if (reset='1') then
> > > > > > > 42: array_reg <= (others=>(others=>'0'));
> > > > > > > 43- elsif (clk'event and clk='1') then
> > > > > > > 44- if wr_en='1' then
> > > > > > > 45: array_reg(to_integer(unsigned(w_ptr_reg)))
> > > > > > > 46- <= w_data;
> > > > > > > 47- end if;
> > > > > > > 48- end if;
> > > > > > > 49- end process;
> > > > > > > 50- -- read port
> > > > > > > 51: r_data <= array_reg(to_integer(unsigned(r_ptr_reg)));
> > > > > > > 52- -- write enabled only when FIFO is not full
> > > > > > > 53- wr_en <= wr and (not full_reg);
> > > > > > > 54-

>
> > > > > > > Ok, so here's all the code pertaining to array_reg, specifically lines
> > > > > > > 42, 45, and 51. From what I can understand, it seems that the
> > > > > > > professionals here are concerned about line 42; the one resulting from
> > > > > > > the reset signal. What would be the correct way to implement this
> > > > > > > concept?

>
> > > > > > Simply delete the asynchronous reset stuff in lines 41 and 42, and
> > > > > > change the "elsif" on line 43 to a simple "if."

>
> > > > > > > In C I would of just done a memset(array_reg, 0, sizeof(array_reg))
> > > > > > > but we ain't in C world any more...

>
> > > > > > Indeed -- think HARDWARE.

>
> > > > > > Since you are describing a FIFO, there's no need to reset the memory.
> > > > > > Simply resetting the read and write pointers effectively clears the
> > > > > > memory. You will never read from an empty FIFO and a FIFO write
> > > > > > guarantees that you read valid data.

>
> > > > > > -a

>
> > > > > quite right,

>
> > > > > the other process has:
> > > > > process(clk,reset)
> > > > > begin
> > > > > if (reset='1') then
> > > > > w_ptr_reg <= (others=>'0');
> > > > > r_ptr_reg <= (others=>'0');
> > > > > full_reg <= '0';
> > > > > empty_reg <= '1';

>
> > > > > and as my pointers get reset who cares about the data. System
> > > > > resources went dramatically down as a result of the changes,

>
> > > > I'm glad the suggestion worked for you!

>
> > > > > however
> > > > > two warnings are now being generated that were never there before:

>
> > > > > WARNING Route - CLK Net:clk_2mhz is being routed on general routing
> > > > > resources. If you are trying to use local clocking techniques,
> > > > > evaluate the placement of the clock's source and loads to ensure it
> > > > > meets the guidelines for local clocking. Otherwise, consider placing
> > > > > this clock on a dedicated clock routing resource. For more information
> > > > > on clock routing resources, see the target architecture's user guide.

>
> > > > > WARNING Route - CLK Net:clk_7812hz is being routed on general routing
> > > > > resources. If you are trying to use local clocking techniques,
> > > > > evaluate the placement of the clock's source and loads to ensure it
> > > > > meets the guidelines for local clocking. Otherwise, consider placing
> > > > > this clock on a dedicated clock routing resource. For more information
> > > > > on clock routing resources, see the target architecture's user guide.

>
> > > > > I can't imagine why these are showing up as a result of "fixing" the
> > > > > other error.

>
> > > > Sounds like the clock signals are coming into the FPGA on non-clock
> > > > pins. You probably didn't see this error before because the original
> > > > warnings/complaints were issued by XST (the synthesis tool) and you
> > > > went no further. Now that the source synthesizes, the place and route
> > > > tools take over, and the warning you get is issued by the router.

>
> > > > Check your UCF and pin selection.

>
> > > > -a

>
> > > H'mmm, I checked the place and route report before and after the
> > > change in code. the Warnings are definitely not there when the 256
> > > flip-flop warning is in place.

>
> > > I'll have to take a look at the UCF and see what can be done with the
> > > pins I'm using. I'm a bit confused about that, I thought GPIO is
> > > GPIO, I'm sending in a signal, and that's it, but I know that there is
> > > a document out there from Xilinx (how they love their documents) that
> > > says something about the pins... lets me check and see what I can
> > > find.

>
> > OK, so from the UCF I was provided here is the system clock:

>
> > ---------------------------------
> > #DRIGMORN PACKAGE IS CP132/CPG132
> > #
> > #####################################
> > #CLOCK
> > #####################################
> > NET "SYSTEM_CLOCK" LOC = "M6";
> > -----------------------------------------------------------------

>
> > And from the DS312.pdf, the 'spartan-3E Fpga family: complete data
> > sheet' document for the spartan 3E I find this:

>
> > ----------------------------------------------------------------------------------------
> > Table 132: CP132 Package Pinout (Continued)

>
> > XC3S250E
> > Bank XC3S100E XC3S500E
> > Pin Name Pin
> > Name CP132 Ball Type
> > ...
> > 2 IP_L05N_2/M2/GCLK1 IP_L05N_2/M2/GCLK1
> > N6 DUAL/GCLK
> > 2 IP_L05P_2/RDWR_B/GCLK0 IP_L05P_2/RDWR_B/GCLK0
> > M6 DUAL/GCLK
> > ...

>
> > DS312-4 (v3.7) April 18, 2008 www.xilinx.com
> > 175
> > Product Specification

>
> > ----------------------------------------------------------------------------------------

>
> > so here is how the system clock is defined in the ucf, no attributes
> > are assigned to the M6 pin, and

>
> OK, this is fine -- M6 is a global clock pin (GCLK) and as such when
> synthesized, the tools should automatically infer an IBUFG for it. But
> apparently they don't. Does SYSTEM_CLOCK drive any other non-clock
> resources?
>
> > the only attributes at all I see in the whole UCF is:

>
> > NET "RXD" LOC = "A7" | PULLUP; #INPUT FROM RS232 CHIP

>
> > a PULLUP.

>
> > So now I want a 2MHZ "clock" on some other pin, what is the criteria I
> > should be looking for in a candidate pin?
> > is that DUAL/GCLK thing significant, or am I supposed to use some
> > attribute? For that matter what is the full set of
> > attributes that is available, is it described in any manual? And
> > Further, am I even on the right track? Is this even the correct
> > manual to be looking at for this info???

>
> The family data sheet tells you which pins are to be used for clock
> inputs: they are GCLK and in some families LHCLK, RHCLK, or CC. "Dual"
> simply means that the pins have one function during FPGA configuration
> and another afterwards.
>
> So for Spartan 3E simply choose one of the many GCLK pins. I would
> avoid the pins that also have a configuration function (I think GCLK1
> is like that).
>
> -a


OK, so I'm looking at the correct thing to fix my warning? My place
and route is
complaining that clk_78122hz is being routed on general routing
resources. my use of
clk_7812hz is:

--
JB_Top.vhd:351: signal clk_7812hz : std_logic := '0'; -- this is the
clock for the 128uS period,its actally 7812.5hz
JB_Top.vhd-361-
--
JB_Top.vhd-443-clock_7812hz: PROCESS ( system_clock_used )
JB_Top.vhd-444-BEGIN
JB_Top.vhd-445- IF ( rising_edge(system_clock_used)) then
JB_Top.vhd:446: IF ( clk_7812hz_countdown = 0) THEN
JB_Top.vhd:447: clk_7812hz_countdown <=
clk_7812hz_clock_count;
JB_Top.vhd:448: --clk_7812hz_countdown <= 6399; --
base clock choice
JB_Top.vhd:449: clk_7812hz <= NOT clk_7812hz;
JB_Top.vhd:450: if (clk_7812hz = '0') Then
JB_Top.vhd:451: clk_7812hz_tick <= '1';
JB_Top.vhd-452- end if;
JB_Top.vhd-453- else
JB_Top.vhd:454: clk_7812hz_tick <= '0';
JB_Top.vhd:455: clk_7812hz_countdown <=
clk_7812hz_countdown -1;
JB_Top.vhd-456- End if; -- countdown ife
JB_Top.vhd-457-
JB_Top.vhd-458- END IF;
JB_Top.vhd-459-END PROCESS clock_7812hz;
JB_Top.vhd-460-
JB_Top.vhd-461-
JB_Top.vhd:462:clock_7812_ctr: PROCESS ( clk_7812hz )
JB_Top.vhd-463-BEGIN
JB_Top.vhd:464: IF ( rising_edge(clk_7812hz)) then
JB_Top.vhd-465- time_cntr_128us <= time_cntr_128us
+1;
JB_Top.vhd-466- uptime_at_128us <=
time_cntr_500ns;
JB_Top.vhd-467-
--
JB_Top.vhd-506-
JB_Top.vhd-507-
JB_Top.vhd-508--- this clock is not uart related
JB_Top.vhd:509:clock_20s: PROCESS ( clk_7812hz )
JB_Top.vhd-510-BEGIN
JB_Top.vhd:511: IF ( rising_edge(clk_7812hz)) then
JB_Top.vhd-512- IF ( clk_20s_countdown = 0) THEN
JB_Top.vhd-513- clk_20s_countdown <= 78_125;
JB_Top.vhd-514- clk_20s <= NOT clk_20s;

What's the issue? its not even going on an output pin.

Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Xilinx SRL's and sync flip flops motty FPGA 1 03-13-2007 04:48 PM
t flip flops [email protected] VHDL 18 05-24-2006 07:05 PM
t flip flops [email protected] VHDL 0 05-17-2006 05:23 PM
Latches and flip flops crazyrdx VHDL 6 04-10-2006 01:09 AM
Problem with flip-flops on Spartan 3 Rob Gaddi FPGA 3 03-27-2005 11:14 PM


All times are GMT +1. The time now is 02:57 AM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved