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
INFO:Xst:738 - HDL ADVISOR - 256 flip-flops were inferred .... Warning. Should I care?
Started by ●May 22, 2009
Reply by ●May 22, 20092009-05-22
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 by ●May 22, 20092009-05-22
On May 22, 5:26 pm, doug <x...@xx.com> 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 by ●May 22, 20092009-05-22
On Fri, 22 May 2009 14:20:59 -0700 (PDT), jleslie48 <jon@jonathanleslie.com> wrote:>On May 22, 5:26 pm, doug <x...@xx.com> 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 by ●May 22, 20092009-05-22
On May 22, 5:55 pm, Muzaffer Kal <k...@dspia.com> wrote:> On Fri, 22 May 2009 14:20:59 -0700 (PDT), jleslie48 > > > > <j...@jonathanleslie.com> wrote: > >On May 22, 5:26 pm, doug <x...@xx.com> 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.comThank you, that makes sense. I'll have to check.
Reply by ●May 26, 20092009-05-26
On May 22, 8:23 pm, jleslie48 <j...@jonathanleslie.com> wrote:> On May 22, 5:55 pm, Muzaffer Kal <k...@dspia.com> wrote: > > > > > On Fri, 22 May 2009 14:20:59 -0700 (PDT), jleslie48 > > > <j...@jonathanleslie.com> wrote: > > >On May 22, 5:26 pm, doug <x...@xx.com> 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 by ●May 26, 20092009-05-26
On May 26, 7:46=A0am, jleslie48 <j...@jonathanleslie.com> wrote:> On May 22, 8:23 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > On May 22, 5:55 pm, Muzaffer Kal <k...@dspia.com> wrote: > > > > On Fri, 22 May 2009 14:20:59 -0700 (PDT), jleslie48 > > > > <j...@jonathanleslie.com> wrote: > > > >On May 22, 5:26 pm, doug <x...@xx.com> wrote: > > > > >> Only FFs have reset. > > > > >that doesn't mean anything to me. =A0maybe I inlcuded too much code =in> > > >the snippet, =A0the only part of the code > > > >that is causing the issue I believe is this: > > > > >--------------------------------------------------------------------=---------------> > > > =A0 type reg_file_type is array (2**W-1 downto 0) of > > > > =A0 =A0 =A0 =A0std_logic_vector(B-1 downto 0); > > > > =A0 signal array_reg: reg_file_type; > > > >--------------------------------------------------------------------=---------------> > > > >the error message in question has no issue with the reset. =A0its > > > >complaining about <array_reg> > > > > The "warning" is just telling you that it couldn't map your "array" t=o> > > memory. Doug has said the reason that couldn't be done probably was > > > that you have some code which says: > > > > if (reset) > > > array <=3D 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. =A0I'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- =A0 type reg_file_type is array (2**W-1 downto 0) of > 25- =A0 =A0 =A0 =A0std_logic_vector(B-1 downto 0); > 26: =A0 signal array_reg: reg_file_type; > 27- =A0 signal w_ptr_reg, w_ptr_next, w_ptr_succ: > 28- =A0 =A0 =A0std_logic_vector(W-1 downto 0); > 29- =A0 signal r_ptr_reg, r_ptr_next, r_ptr_succ: > -- > 39- =A0 process(clk,reset) > 40- =A0 begin > 41- =A0 =A0 if (reset=3D'1') then > 42: =A0 =A0 =A0 =A0array_reg <=3D (others=3D>(others=3D>'0')); > 43- =A0 =A0 elsif (clk'event and clk=3D'1') then > 44- =A0 =A0 =A0 =A0if wr_en=3D'1' then > 45: =A0 =A0 =A0 =A0 =A0 array_reg(to_integer(unsigned(w_ptr_reg))) > 46- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <=3D w_data; > 47- =A0 =A0 =A0 =A0end if; > 48- =A0 =A0 end if; > 49- =A0 end process; > 50- =A0 -- read port > 51: =A0 r_data <=3D array_reg(to_integer(unsigned(r_ptr_reg))); > 52- =A0 -- write enabled only when FIFO is not full > 53- =A0 wr_en <=3D wr and (not full_reg); > 54- > > Ok, so here's all the code pertaining to array_reg, specifically lines > 42, 45, and 51. =A0From what I can understand, it seems that the > professionals here are concerned about line 42; the one resulting from > the reset signal. =A0What 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 by ●May 26, 20092009-05-26
On Tue, 26 May 2009 07:46:48 -0700 (PDT), jleslie48 <jon@jonathanleslie.com> 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 by ●May 26, 20092009-05-26
On May 26, 2:58 pm, Andy Peters <goo...@latke.net> wrote:> On May 26, 7:46 am, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > On May 22, 8:23 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > On May 22, 5:55 pm, Muzaffer Kal <k...@dspia.com> wrote: > > > > > On Fri, 22 May 2009 14:20:59 -0700 (PDT), jleslie48 > > > > > <j...@jonathanleslie.com> wrote: > > > > >On May 22, 5:26 pm, doug <x...@xx.com> 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. > > -aquite 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 by ●May 27, 20092009-05-27
On May 26, 1:13=A0pm, jleslie48 <j...@jonathanleslie.com> wrote:> On May 26, 2:58 pm, Andy Peters <goo...@latke.net> wrote: > > > > > On May 26, 7:46 am, jleslie48 <j...@jonathanleslie.com> wrote: > > > > On May 22, 8:23 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > On May 22, 5:55 pm, Muzaffer Kal <k...@dspia.com> wrote: > > > > > > On Fri, 22 May 2009 14:20:59 -0700 (PDT), jleslie48 > > > > > > <j...@jonathanleslie.com> wrote: > > > > > >On May 22, 5:26 pm, doug <x...@xx.com> wrote: > > > > > > >> Only FFs have reset. > > > > > > >that doesn't mean anything to me. =A0maybe I inlcuded too much c=ode in> > > > > >the snippet, =A0the only part of the code > > > > > >that is causing the issue I believe is this: > > > > > > >----------------------------------------------------------------=-------------------> > > > > > =A0 type reg_file_type is array (2**W-1 downto 0) of > > > > > > =A0 =A0 =A0 =A0std_logic_vector(B-1 downto 0); > > > > > > =A0 signal array_reg: reg_file_type; > > > > > >----------------------------------------------------------------=-------------------> > > > > > >the error message in question has no issue with the reset. =A0it=s> > > > > >complaining about <array_reg> > > > > > > The "warning" is just telling you that it couldn't map your "arra=y" to> > > > > memory. Doug has said the reason that couldn't be done probably w=as> > > > > that you have some code which says: > > > > > > if (reset) > > > > > array <=3D 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. =A0I'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- =A0 type reg_file_type is array (2**W-1 downto 0) of > > > 25- =A0 =A0 =A0 =A0std_logic_vector(B-1 downto 0); > > > 26: =A0 signal array_reg: reg_file_type; > > > 27- =A0 signal w_ptr_reg, w_ptr_next, w_ptr_succ: > > > 28- =A0 =A0 =A0std_logic_vector(W-1 downto 0); > > > 29- =A0 signal r_ptr_reg, r_ptr_next, r_ptr_succ: > > > -- > > > 39- =A0 process(clk,reset) > > > 40- =A0 begin > > > 41- =A0 =A0 if (reset=3D'1') then > > > 42: =A0 =A0 =A0 =A0array_reg <=3D (others=3D>(others=3D>'0')); > > > 43- =A0 =A0 elsif (clk'event and clk=3D'1') then > > > 44- =A0 =A0 =A0 =A0if wr_en=3D'1' then > > > 45: =A0 =A0 =A0 =A0 =A0 array_reg(to_integer(unsigned(w_ptr_reg))) > > > 46- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <=3D w_data; > > > 47- =A0 =A0 =A0 =A0end if; > > > 48- =A0 =A0 end if; > > > 49- =A0 end process; > > > 50- =A0 -- read port > > > 51: =A0 r_data <=3D array_reg(to_integer(unsigned(r_ptr_reg))); > > > 52- =A0 -- write enabled only when FIFO is not full > > > 53- =A0 wr_en <=3D wr and (not full_reg); > > > 54- > > > > Ok, so here's all the code pertaining to array_reg, specifically line=s> > > 42, 45, and 51. =A0From what I can understand, it seems that the > > > professionals here are concerned about line 42; the one resulting fro=m> > > the reset signal. =A0What 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: > =A0 process(clk,reset) > =A0 =A0begin > =A0 =A0 =A0 if (reset=3D'1') then > =A0 =A0 =A0 =A0 =A0w_ptr_reg <=3D (others=3D>'0'); > =A0 =A0 =A0 =A0 =A0r_ptr_reg <=3D (others=3D>'0'); > =A0 =A0 =A0 =A0 =A0full_reg <=3D '0'; > =A0 =A0 =A0 =A0 =A0empty_reg <=3D '1'; > > and as my pointers get reset who cares about the data. =A0System > 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
