Virtex® Family FPGAs

[flitch@home]

Hi,

I am having a problem persuading the tools to implement a flip flop to retime my inputs in the IOB rather than in the core.

The complication is that the inputs are LVDS and I need to sample them using an associated input clock (also LVDS) because the data "eye" is quite small. If I run the design normally then I get the retiming stages in the core and a delay report of 5ns from input to being sampled at the FF input. This is too slow - generally as well as for my design!

I have tried using the following attribute construction in my VHDL,

 -- Force the register into the IOB using an attribute  
attribute iob : string;
attribute iob of iob_reg : label is "true";

-- IOB register retiming using raw clock
iob_reg :   process(ir_clock_i)
   begin
      if rising_edge(ir_clock_i) then
         ir_data0_idelay <= ir_data0_i;
         ir_data1_idelay <= ir_data1_i;
         ir_data2_idelay <= ir_data2_i;
         ir_data3_idelay <= ir_data3_i;
         ir_sync_idelay  <= ir_sync_i;
      end if;
end process iob_reg;

This appears to have no effect as the delays are the same and when I look in the floorplanner there is no logic in the IOB cell. The VHDL  file is not at the top level, but is embedded in the hierachy, so this might be the problem.

In previous generations I could have used the a library cell for an LVDS input with an associated FF. However, these are not supported for V5.

I am using ISE10.1 SP3 by the way. My device is a FX130T. 

So how do you do it?

I don't want to use IDELAY, I just want a FF.

Thanks Pete 

[luisb]

Make sure that ir_data#_i signals (or signals leading up to ir_data#_i) are not being used anywhere else in the design.  

You can also try the IOB constraint on the ir_data#_idelay signals instead of the label.  It would look something like this:

attribute iob : string;
attribute iob of ir_data0_idelay : signal is "true";

You may also want to double check your ir_clock_i.  Make sure that if it's coming from a BUFR, that this BUFR is in the same region as your I/Os.

[flitch@home]

Hi,

Thanks for the hints.

Do I have to use a BUFR to drive the IOB flip flops?

I wanted to use the ir_clock signal direct from the pin (LVDS input).

Thanks PM

[gszakacs]

If the clock comes in on the same clock region as the data inputs and uses a

clock-capable I/O you can use a BUFR or a BUFIO to drive local clock resources.

If the clock is on a global clock pin you should use a BUFG.  If the clock is diferential

you should always instantiate the input buffer, IBUFDS for normal IO pins or

IBUFGDS for global clock inputs.

[flitch@home]

Hi,

Thanks for the reponse, but this is not really a clock question. The issue is how to get the tools to pack things into the IOB.

I have been doing some more research, largely on this forum, and it would appear that for Virtex 5 at least the tools do not automatically pack the IOBs. This is not improved by the use of VHDL attributes, or "offset in" timing constraints.

Looking at our Virtex 5 designs, none of them have any user logic in the IOBs.

The solution would seem to be to identify the bits you want to be implemented in the IOBs in the .ucf file and apply the IOB=TRUE or IOB=FORCE attribute to make the tools either do it, or in the case of the latter, refuse to do it but provide a useful error message.

Best wishes

PM

[gszakacs]

For XST there is a property (-iob) under the Xilinx-specific options called "Pack I/O Registers into IOBs".

I usually set this to "Yes" which is similar to globally attaching IOB=TRUE to all I/O registers.  You can

also select "Auto" to pack registers if required to meet your offset timing constraints.  If this is set to "No",

nothing will be packed into IOB's.  "Auto" should be the default setting.

There is another process option for Map (-pr) that allows you to do further packing of registers

into IOB's during the packing & placement phase.  It defaults to "Off" but has also options "For Inputs and Outputs,"

"For Inputs Only," and "For Outputs Only."

HTH,

Gabor