Automatic BUFG insertion on a non clock signal in ISE 12.1
in [FPGA]
|
From: Amish Rughoonundon on 30 Jun 2010 16:58 On Jun 30, 2:52 pm, Gabor <ga...(a)alacron.com> wrote: > On Jun 30, 10:37 am, Amish Rughoonundon <amishrughoonun...(a)gmail.com> > wrote: > > > > > > > Hi, > > I have a very simple design using a latch. I know latches should not > > be used but it is a necessary evil in this case for speed reason. If > > someone can find as fast of a way to do this with synchronous logic, I > > would love to hear it. > > > My question is that ISE 12.1 is inserting a BUFG in between the input > > ms3_n and the latch input during synthesis. I do not understand why. > > I do not have any constraint on this code at all. > > > If anybody has a good explanation, I would really appreciate it > > because I am at a loss. Thanks, > > Amish > > > [CODE] > > library IEEE; > > use IEEE.STD_LOGIC_1164.all; > > > entity dspInterfaceTest is > > port( > > ms3_n : in STD_LOGIC; > > ack : out STD_LOGIC; > > s_done : in std_logic > > ); > > end dspInterfaceTest; > > > architecture dspInterfaceTest of dspInterfaceTest is > > > signal s_doneLatch : std_logic; > > begin > > > p_doneLatch : process(s_done, ms3_n) > > begin > > if(s_done = '1') then > > s_doneLatch <= '1'; > > > elsif(ms3_n = '1') then > > s_doneLatch <= '0'; > > end if; > > > end process p_doneLatch; > > > ack <= 'Z' when ms3_n = '1' else s_doneLatch; > > > end dspInterfaceTest; > > [/CODE] > > What FPGA family is this going into? For the Spartan 3 series you > still > have latches in the fabric, but they use a clock routing connection > for > the gate input. That could explain the automatic BUFG insertion. You > can shut this off by giving your ms3_n signal a BUFFER_TYPE of > "none". See the XST manual for more on how to do this. > > Regards, > Gabor Rob, actually there is a typo. It should be elsif(dsp_ms_three_n = '0') then s_doneLatch <= '0'; this is used to connect to the acknowledge line of a dsp. When the dsp toggle the ms3_n line low, I needed the FPGA to respond immediately bringing the ack line low. When the FPGA is done processing the request, it would set ack high and when the dsp is done grabbing the data and set ms3_n high, the ack output will immediately be tri-stated. I wanted it to be really fast, less than 5 ns if possible but from my testing it does not seem it will be possible due to routing delay. Gabor, I think you are right looking at the FPGA editor, it seems the LATCH uses a clock input connected to ms3_n. I guess in Spartan 3E there is no other way to do a latch so the synthesizer adds a BUFG to the line automatically. Setting buffer_type seems to fix the problem. Thanks for the input, that was a real help Amish
From: Gabor on 30 Jun 2010 18:27 On Jun 30, 4:58 pm, Amish Rughoonundon <amishrughoonun...(a)gmail.com> wrote: > On Jun 30, 2:52 pm, Gabor <ga...(a)alacron.com> wrote: > > > > > On Jun 30, 10:37 am, Amish Rughoonundon <amishrughoonun...(a)gmail.com> > > wrote: > > > > Hi, > > > I have a very simple design using a latch. I know latches should not > > > be used but it is a necessary evil in this case for speed reason. If > > > someone can find as fast of a way to do this with synchronous logic, I > > > would love to hear it. > > > > My question is that ISE 12.1 is inserting a BUFG in between the input > > > ms3_n and the latch input during synthesis. I do not understand why. > > > I do not have any constraint on this code at all. > > > > If anybody has a good explanation, I would really appreciate it > > > because I am at a loss. Thanks, > > > Amish > > > > [CODE] > > > library IEEE; > > > use IEEE.STD_LOGIC_1164.all; > > > > entity dspInterfaceTest is > > > port( > > > ms3_n : in STD_LOGIC; > > > ack : out STD_LOGIC; > > > s_done : in std_logic > > > ); > > > end dspInterfaceTest; > > > > architecture dspInterfaceTest of dspInterfaceTest is > > > > signal s_doneLatch : std_logic; > > > begin > > > > p_doneLatch : process(s_done, ms3_n) > > > begin > > > if(s_done = '1') then > > > s_doneLatch <= '1'; > > > > elsif(ms3_n = '1') then > > > s_doneLatch <= '0'; > > > end if; > > > > end process p_doneLatch; > > > > ack <= 'Z' when ms3_n = '1' else s_doneLatch; > > > > end dspInterfaceTest; > > > [/CODE] > > > What FPGA family is this going into? For the Spartan 3 series you > > still > > have latches in the fabric, but they use a clock routing connection > > for > > the gate input. That could explain the automatic BUFG insertion. You > > can shut this off by giving your ms3_n signal a BUFFER_TYPE of > > "none". See the XST manual for more on how to do this. > > > Regards, > > Gabor > > Rob, > actually there is a typo. It should be > elsif(dsp_ms_three_n = '0') then > s_doneLatch <= '0'; > > this is used to connect to the acknowledge line of a dsp. When the > dsp toggle the ms3_n line low, I needed the FPGA to respond > immediately bringing the ack line low. When the FPGA is done > processing the request, it would set ack high and when the dsp is done > grabbing the data and set ms3_n high, the ack output will immediately > be tri-stated. > > I wanted it to be really fast, less than 5 ns if possible but from my > testing it does not seem it will be possible due to routing delay. > > Gabor, > I think you are right looking at the FPGA editor, it seems the LATCH > uses a clock input connected to ms3_n. I guess in Spartan 3E there is > no other way to do a latch so the synthesizer adds a BUFG to the line > automatically. Setting buffer_type seems to fix the problem. Thanks > for the input, that was a real help > Amish That's good. Be aware that the more recent FPGA architectures have gotten rid of the D-latch mode of the fabric flip-flops. This seems to be a trend based on most of the market changing from ASIC prototyping to production delivery vehicles. You can still make asynchronous sequential logic using LUT's, but the performance will not be as good. Regards, Gabor
From: Brian Davis on 30 Jun 2010 20:33 Rob Gaddi wrote: > > I know that for Spartan-6 they've crippled the libraries so that you > can't actually do direct instantiation anymore from HDL, but maybe > if you broke down and did a schematic design for that block? > You and John Larkin have both posted that you can no longer instantiate simple FD-something primitives with Spartan6. I don't have 12.x here at home to test, but LOC'd FDx's still work fine in 10.x on V5 with a nearly identical IOB structure; barring any new version tool bugs, they should also work for S6. See my post from last week's thread: http://groups.google.com/group/comp.arch.fpga/msg/b12a845e6b89e340 Note that the simplified buffer-only IOB pad structure in the newer families means you need to LOC the FD primitive to the adjacent OLOGIC site rather than the IOB pad location if you are using LOCs; placing the IOB attribute on the primitive might still do this automatically without needing an explicit LOC on the primitive. When Xilinx went from one libraries guide to family specific guides several versions ago, they dropped the descriptions of the non-native simple primitives from the family guides, but they are all still available in the unisim library. These primitives in the unisim package are all black-boxed and should be properly mapped to the appropriate device-specific element for any FPGA target family. At least that is how it's intended to work, see the primitives section of the S6/V6 XST guide: http://www.xilinx.com/support/documentation/sw_manuals/xilinx12_1/xst_v6s6.pdf XST User Guide for Virtex-6 and Spartan-6 Devices UG687 (v 12.1) Page 271 : " " XST provides dedicated VHDL and Verilog libraries to simplify " instantiation of Xilinx® device primitives in the Hardware " Description Language (HDL) source code. " <snip> " " VHDL Xilinx® Device Primitives Device Libraries " " In VHDL, declare library UNISIM with its package vcomponents " in the HDL source code. " " library unisim; " use unisim.vcomponents.all; " " The HDL source code for this package is located in the following " file of the XST installation: " vhdl\src\ unisims\unisims_vcomp.vhd " Brian
First
|
Prev
|
Pages: 1 2 Prev: Testbench Next: Xilinx xapp175, empty + full flag really synchronous? |