Automatic BUFG insertion on a non clock signal in ISE 12.1
in [FPGA]
|
From: Amish Rughoonundon on 30 Jun 2010 10:37 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]
From: Rob Gaddi on 30 Jun 2010 12:06 On 6/30/2010 7:37 AM, Amish Rughoonundon 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] No idea offhand, but your ack signal is going directly to a top-level pin, not internal logic, right? -- Rob Gaddi, Highland Technology Email address is currently out of order
From: Amish Rughoonundon on 30 Jun 2010 14:28 On Jun 30, 12:06 pm, Rob Gaddi <rga...(a)technologyhighland.com> wrote: > On 6/30/2010 7:37 AM, Amish Rughoonundon 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] > > No idea offhand, but your ack signal is going directly to a top-level > pin, not internal logic, right? > > -- > Rob Gaddi, Highland Technology > Email address is currently out of order yes all ports are going to external FPGA pins Amish
From: Rob Gaddi on 30 Jun 2010 14:39 On 6/30/2010 11:28 AM, Amish Rughoonundon wrote: > On Jun 30, 12:06 pm, Rob Gaddi<rga...(a)technologyhighland.com> wrote: >> On 6/30/2010 7:37 AM, Amish Rughoonundon 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] >> >> No idea offhand, but your ack signal is going directly to a top-level >> pin, not internal logic, right? >> >> -- >> Rob Gaddi, Highland Technology >> Email address is currently out of order > > yes all ports are going to external FPGA pins > Amish It looks like you're trying to infer a D-latch with a preset, tying D=>'0', G=>ms3_N, P=>s_done, Q=>s_doneLatch. Then that feeds a tristate buffer where ms3_n is the tristate enable. I haven't the foggiest idea why you're doing that, and if you take a step back from the problem there's probably a better, synchronous way to do it. But that doesn't change the fact that there's no reason that XST shouldn't be letting you do it the way you're trying to. Only thing I can think of is to try to replacing your behavioral code with direct instantiation. 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? -- Rob Gaddi, Highland Technology Email address is currently out of order
From: Gabor on 30 Jun 2010 14:52
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 |