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]

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

On Jun 30, 12:06=A0pm, Rob Gaddi
<rga...@technologyhighland.com> wrote:
> On 6/30/2010 7:37 AM, Amish Rughoonundon wrote:
>
>
>
>
>
> > Hi,
> > =A0 I have a very simple design using a latch. I know latches should no=
t
> > 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
> > =A0 =A0 =A0 port(
> > =A0 =A0 =A0 =A0 =A0 ms3_n : in STD_LOGIC;
> > =A0 =A0 =A0 =A0 =A0 ack : out STD_LOGIC;
> > =A0 =A0 =A0 =A0 =A0 s_done : in std_logic
> > =A0 =A0 =A0 =A0 =A0 );
> > end dspInterfaceTest;
>
> > architecture dspInterfaceTest of dspInterfaceTest is
>
> > =A0 =A0 =A0signal s_doneLatch : std_logic;
> > begin
>
> > =A0 =A0 =A0p_doneLatch : process(s_done, ms3_n)
> > =A0 =A0 =A0begin
> > =A0 =A0 =A0 =A0 =A0if(s_done =3D '1') then
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0s_doneLatch<=3D '1';
>
> > =A0 =A0 =A0 =A0 =A0elsif(ms3_n =3D '1') then
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0s_doneLatch<=3D '0';
> > =A0 =A0 =A0 =A0 =A0end if;
>
> > =A0 =A0 =A0end process p_doneLatch;
>
> > =A0 =A0 =A0ack<=3D 'Z' when ms3_n =3D '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

On 6/30/2010 11:28 AM, Amish Rughoonundon wrote:
> On Jun 30, 12:06 pm, Rob Gaddi<rga...@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

On Jun 30, 10:37=A0am, Amish Rughoonundon
<amishrughoonun...@gmail.com>
wrote:
> Hi,
> =A0I 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
> =A0 =A0 =A0port(
> =A0 =A0 =A0 =A0 =A0ms3_n : in STD_LOGIC;
> =A0 =A0 =A0 =A0 =A0ack : out STD_LOGIC;
> =A0 =A0 =A0 =A0 =A0s_done : in std_logic
> =A0 =A0 =A0 =A0 =A0);
> end dspInterfaceTest;
>
> architecture dspInterfaceTest of dspInterfaceTest is
>
> =A0 =A0 signal s_doneLatch : std_logic;
> begin
>
> =A0 =A0 p_doneLatch : process(s_done, ms3_n)
> =A0 =A0 begin
> =A0 =A0 =A0 =A0 if(s_done =3D '1') then
> =A0 =A0 =A0 =A0 =A0 =A0 s_doneLatch <=3D '1';
>
> =A0 =A0 =A0 =A0 elsif(ms3_n =3D '1') then
> =A0 =A0 =A0 =A0 =A0 =A0 s_doneLatch <=3D '0';
> =A0 =A0 =A0 =A0 end if;
>
> =A0 =A0 end process p_doneLatch;
>
> =A0 =A0 ack <=3D 'Z' when ms3_n =3D '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

On Jun 30, 2:52=A0pm, Gabor
<ga...@alacron.com> wrote:
> On Jun 30, 10:37=A0am, Amish Rughoonundon <amishrughoonun...@gmail.com>
> wrote:
>
>
>
>
>
> > Hi,
> > =A0I 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
> > =A0 =A0 =A0port(
> > =A0 =A0 =A0 =A0 =A0ms3_n : in STD_LOGIC;
> > =A0 =A0 =A0 =A0 =A0ack : out STD_LOGIC;
> > =A0 =A0 =A0 =A0 =A0s_done : in std_logic
> > =A0 =A0 =A0 =A0 =A0);
> > end dspInterfaceTest;
>
> > architecture dspInterfaceTest of dspInterfaceTest is
>
> > =A0 =A0 signal s_doneLatch : std_logic;
> > begin
>
> > =A0 =A0 p_doneLatch : process(s_done, ms3_n)
> > =A0 =A0 begin
> > =A0 =A0 =A0 =A0 if(s_done =3D '1') then
> > =A0 =A0 =A0 =A0 =A0 =A0 s_doneLatch <=3D '1';
>
> > =A0 =A0 =A0 =A0 elsif(ms3_n =3D '1') then
> > =A0 =A0 =A0 =A0 =A0 =A0 s_doneLatch <=3D '0';
> > =A0 =A0 =A0 =A0 end if;
>
> > =A0 =A0 end process p_doneLatch;
>
> > =A0 =A0 ack <=3D 'Z' when ms3_n =3D '1' else s_doneLatch;
>
> > end dspInterfaceTest;
> > [/CODE]
>
> What FPGA family is this going into? =A0For the Spartan 3 series you
> still
> have latches in the fabric, but they use a clock routing connection
> for
> the gate input. =A0That could explain the automatic BUFG insertion. =A0Yo=
u
> can shut this off by giving your ms3_n signal a BUFFER_TYPE of
> "none". =A0See 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 =3D '0') then
            s_doneLatch <=3D '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

On Jun 30, 4:58=A0pm, Amish Rughoonundon
<amishrughoonun...@gmail.com>
wrote:
> On Jun 30, 2:52=A0pm, Gabor <ga...@alacron.com> wrote:
>
>
>
> > On Jun 30, 10:37=A0am, Amish Rughoonundon <amishrughoonun...@gmail.com>
> > wrote:
>
> > > Hi,
> > > =A0I have a very simple design using a latch. I know latches should n=
ot
> > > 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
> > > =A0 =A0 =A0port(
> > > =A0 =A0 =A0 =A0 =A0ms3_n : in STD_LOGIC;
> > > =A0 =A0 =A0 =A0 =A0ack : out STD_LOGIC;
> > > =A0 =A0 =A0 =A0 =A0s_done : in std_logic
> > > =A0 =A0 =A0 =A0 =A0);
> > > end dspInterfaceTest;
>
> > > architecture dspInterfaceTest of dspInterfaceTest is
>
> > > =A0 =A0 signal s_doneLatch : std_logic;
> > > begin
>
> > > =A0 =A0 p_doneLatch : process(s_done, ms3_n)
> > > =A0 =A0 begin
> > > =A0 =A0 =A0 =A0 if(s_done =3D '1') then
> > > =A0 =A0 =A0 =A0 =A0 =A0 s_doneLatch <=3D '1';
>
> > > =A0 =A0 =A0 =A0 elsif(ms3_n =3D '1') then
> > > =A0 =A0 =A0 =A0 =A0 =A0 s_doneLatch <=3D '0';
> > > =A0 =A0 =A0 =A0 end if;
>
> > > =A0 =A0 end process p_doneLatch;
>
> > > =A0 =A0 ack <=3D 'Z' when ms3_n =3D '1' else s_doneLatch;
>
> > > end dspInterfaceTest;
> > > [/CODE]
>
> > What FPGA family is this going into? =A0For the Spartan 3 series you
> > still
> > have latches in the fabric, but they use a clock routing connection
> > for
> > the gate input. =A0That could explain the automatic BUFG insertion. =A0=
You
> > can shut this off by giving your ms3_n signal a BUFFER_TYPE of
> > "none". =A0See the XST manual for more on how to do this.
>
> > Regards,
> > Gabor
>
> Rob,
> =A0actually there is a typo. It should be
> elsif(dsp_ms_three_n =3D '0') then
> =A0 =A0 =A0 =A0 =A0 =A0 s_doneLatch <=3D '0';
>
> =A0this 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

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=AE device primitives in the Hardware
" Description Language (HDL) source code.
"
<snip>
"
" VHDL Xilinx=AE 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