cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Anonymous
Not applicable
10,676 Views

tristate source synchronous sdr timing constraint

Hello,

I need some help on how to correctly constrain a bidirectional SDR data bus with respect to internal MMCM generated   clock which is forwarded to the external device  .

I'm working with a  Virtex6 lx240 ml605 EVB.  The EVB has been expanded by means of a custom designed PCB and trough the FMC connector. Concretely our PCB mounts mainly some AD and DAs, a Cypress FX3 USB3.0 microcontroller and a 250 MHz low phase noise clock source. The 250 MHz clock is connected to the FPGA using a global clock pin.

The FPGA is connected to the FX3 using a "synchronous slave fifo interface": bidirectional data bus, some control signals and some FX3 status lines (all FX3  related signals are single ended).

Using an MMCM I generate a 90 MHz clock called pclk (derived from the 250 MHz main clock).

In the FPGA all signals related to the FX3 interface are  under the pclk clock domain.

 

Propagation delays between the FPGA and the FX3 are known.

 

It is relatively unclear to me how I:

- force ISE to minimize the skew between the data output and the clock output

- how to constrain the inputs with respect to the forwarded clock ( plus clock FPGA->FX3, FX3 port delay and data  FX3--> FPGA)

Any help would be really appreciated.

 

Joel

0 Kudos
8 Replies
gszakacs
Professor
Professor
10,671 Views
Registered: ‎08-14-2007

It is relatively unclear to me how I:

- force ISE to minimize the skew between the data output and the clock output

 

You cannot do this with timing constraints!!!  You must do it by design.  Make sure that

all of the registers of the bus are pushed into the IOB's.  If the tristate timing is critical,

then this should be registered in the IOB as well.  Use a DDR output register for clock

forwarding.  If you need to adjust the phase of the clock relative to the data, then this

DDR register needs to be clocked with a separate clock having the appropriate phase shift.

 

- how to constrain the inputs with respect to the forwarded clock ( plus clock FPGA->FX3, FX3 port delay and data  FX3--> FPGA)

 

It's not clear to me what you mean by the forwarded clock here.  You can only specify input timing from

the clock pin that ultimately drives the clock to the input registers.  If you need to have tight input timing,

the best approach is again to place all the input registers in the IOB's and use IDELAY if necessary

to adjust setup and hold.  You can place a constraint of the "OFFSET IN BEFORE" type on the data

inputs with respect to the clock pin (in your case I assume this would be the 250 MHz clock), but that

would not be very meaningful if you're using a derived clock of a different frequency.  So again it

looks like this needs to be done by design.

-- Gabor
0 Kudos
Anonymous
Not applicable
10,667 Views

Thank you for the answer.

For what relates to the data output constrain I'm already using the ODDR based clock forwarding.

In order to push data output register into the IOB I used :

   attribute IOB :  string ;

   attribute IOB of s_fx3_data_out_sinc: signal is "TRUE"; -- push out FF into the pad

 

      gen_o_buff : for n in 0 to 31 generate
         fx3_sio_buff : IOBUF
            port map (
               O  => s_fx3_data_in(n),    
               IO  => fx3_data(n),           -- 3-state bad pad
               I  => s_fx3_data_out_sinc(n),   
               T  => s_fx3_data_dir          -- 3-state enable input, high=input, low=output
            );
      end generate;


      fx3_clk_frwd : ODDR -- Clock forwarding
            generic map(DDR_CLK_EDGE   => "SAME_EDGE",INIT=> '0',SRTYPE=> "SYNC")
            port map (
               Q     => fx3_if_clk,   
               C     => s_fx3_if_clk,            
               CE    => '1',                
               D1    => '1',   
               D2    => '0',  
               R     => s_rst,              
               S     => '0'                 
            );

Does this means that PAR is going to minimize the skew between the output clock and the output data or it there something missing in such approach (as I mentioned data are relatively slow 70.. 100 MHz max)

 

For what relates to the data input:

the FPGA generates the 70 MHz clock signal which is then routed to the FX3 USB 3.0 controller. This means that the data going from FX3 to FPGA is synchronous to the 70 MHz clock output from the FPGA itself (this isn't a source synchronous nor a system synchronous situation right ? In this case the FPGA is providing the clock to the source).

 

Concretely data is ready for read on the "fx3_data" IO pad after :

     path_delay from PFGA(fx3_if_clk) out pad to FX3(clk) in_pad +

     FX3 internal delay data out clk_to_pad +

     path_delay from FX3(data) out_pad to PFGA(fx3_data) IO_pad

 

In this case the only possible input data timing specification is relative to the 70 MHz output clock signal  "fx3_if_clk" or eventually relative to the internal s_fx3_if_clk by adding the additional delay between the internal clock  and the output pad.

 

I hope this description is not resulting too much confusing...

 

 

Am I wrong? Do I miss something; How do I constrain this situation ?

 

Thanks in advance

0 Kudos
avrumw
Guide
Guide
10,659 Views
Registered: ‎01-23-2009

The ODDR for the clock seems correct.

 

However, for the data, its not the instantiation of the IOBUF (alone) that is important to ensure that both the IFF, OFF and TFF are packed into the IOB (and all 3 need to be).

 

For this to work you need the following

 - the I pin of the IOBUF needs to come directly from the Q pin of a flip-flop (and the Q output goes nowhere else)

 - the O pin of the IOBUF needs to go directly to the D input of a flip-flop

 - the T pin of the IOBUF also needs to come directly from the Q pin of a flip-flop (and the Q output goes nowhere else)

 

The first two are fairly obvious. The last one can sometimes trip people up, since there needs to be one TFF for each bit of the bus - you can't just have one and use if for all bits of the bus. So in this case, you need 32 copies of s_fx3_data_dir, each coming from a flip-flop. You will have to convince the synthesis tool to KEEP all 32 copies (it will want to remove 31 of them).

 

You need to check the map reports to make sure that all 3 FFs have been pushed into all 32 IOBs.

 

Now, as for the last part - constraining the returning data against the forwarding clock - you can't (nor do you really want to). OFFSET IN constraints must be related to an input clock pin (that's the rule) - and the only input clock you have is the input the MMCM which is not at the same frequency...

 

The reality here, though, is that the constraint is irrelevent. If the FF is packed in the IOB, then the placment and routing of the capturing flop is fixed, and hence the placer/router can't affect it, so its timing is determined by the FPGA structure.

 

I have posted a number of other answers on threads dealing with how you analyze (MANUALLY) timing of I/O interfaces. This one may help, and this might also have some information.

 

Avrum

0 Kudos
gszakacs
Professor
Professor
10,654 Views
Registered: ‎08-14-2007

"there needs to be one TFF for each bit of the bus - you can't just have one and use if for all bits of the bus."

 

This is definitely not true of the more recent versions of XST.  Enabling register duplication allows

you to use a single output enable and push the replicated flops into multiple IOB's.  I've had no

issues with this, at least using Verilog.

 

I would also double check that the clock is doing what you want.  If the FX3 is sampling data on the rising

edge of the clock and your clock rising edge coincides with the data change, then you can have hold

time violations at the FX3.  A typical way to deal with this without adding a clock to the design is to

reverse the 0 and 1 going to the D1 and D2 inputs of the ODDR to invert the outgoing clock.  This

centers the rising edge in the data output window.  Of cource since this interface is bidirectional using

the same clock, you'd need to change your input sampling point accordingly.

-- Gabor
0 Kudos
Anonymous
Not applicable
10,635 Views

Hi, in order to have the full control on what the tool is doing without too much dependencies from the synthesis and mapping options I unchecked automatic IO packing both from synthesizer and mapper opptions.

IOB are instantiated "manually" and IOB attribute are set explicitly in VHDL.

 

As you told me I duplicated the TFF 32 times,  I verified that I, O and T signals on the IOBUF are all directly connected to one and only one a FF.

After this I did first a synthesis with the IOB of the output data set to FALSE. The static timing showed me up to 4 nS of skew between the output clock and the output data in the clock to pad table.

Then I turned IOB to TRUE and the data to clock skew has been compressed down to 0.4 ns. I assume at this point that clock forwarding and data-clock skew alignment on pad  is working well.

 

Even if the source synchronous output timing seems to be ok,  when I set IOB to TRUE on the output data (the signal between the last FF and the IOBUF) the same attribute is somehow propagated backwards to the other signal even if they are not connected to a pad. As a consequence of this I get a lot of warning from the mapper:

...

WARNING:Pack:2780 - The register

   "fx3_interface_inst/cmd_out_fifo_inst/U0/xst_fifo_generator/gconvfifo.rf/grf.

   rf/rstblk/rd_rst_asreg" has the property IOB=TRUE, but it did not join an IO

   component because it is not connected to any IO element.

WARNING:Pack:2780 - The register

   "fx3_interface_inst/cmd_in_fifo_inst/U0/xst_fifo_generator/gconvfifo.rf/grf.r

   f/rstblk/rd_rst_asreg" has the property IOB=TRUE, but it did not join an IO

   component because it is not connected to any IO element.

...

 

As I told in a previous post I simply set IOB to true on the net between the last FF and the IOBUF I port:

 

   attribute IOB :  string ;

   attribute IOB of s_fx3_data_out     : signal is "TRUE"; -- push out FF into the IOB

 

It seems to me that the mapper starts to apply the IOB = TRUE also to the other signals even if they are coming before the last s_fx3_data_out FF.

 

Do I miss something ?

 

 

I've now the mapper reporting me in  Section 6 - IOB Properties

 

:

  

| fx3_data<25>            | IOB          | BIDIR     | LVCMOS25             |       | 12       | SLOW | IFF          |          |          |
|                                    |                  |                  |                      |       |          |      | OFF          |          |          |
|                                    |                  |                  |                      |       |          |      | TFF          |          |          |
| fx3_data<26>            | IOB          | BIDIR     | LVCMOS25             |       | 12       | SLOW | IFF          |          |          |
|                                    |                  |                  |                      |       |          |      | OFF          |          |          |
|                                    |                  |                  |                      |       |          |      | TFF          |          |          |
| fx3_data<27>            | IOB          | BIDIR     | LVCMOS25             |       | 12       | SLOW | IFF          |          |          |
|                                    |                  |                  |                      |       |          |      | OFF          |          |          |
|                                    |                  |                  |                      |       |          |      | TFF          |          |          |
| fx3_data<28>            | IOB          | BIDIR     | LVCMOS25             |       | 12       | SLOW | IFF          |          |          |
|                                    |                  |                  |                      |       |          |      | OFF          |          |          |
|                                    |                  |                  |                      |       |          |      | TFF          |          |          |
| fx3_data<29>            | IOB          | BIDIR     | LVCMOS25             |       | 12       | SLOW | IFF          |          |          |
|                                    |                  |                  |                      |       |          |      | OFF          |          |          |
|                                    |                  |                  |                      |       |          |      | TFF          |          |          |
| fx3_data<30>            | IOB          | BIDIR     | LVCMOS25             |       | 12       | SLOW | IFF          |          |          |
|                                    |                  |                  |                      |       |          |      | OFF          |          |          |
|                                    |                  |                  |                      |       |          |      | TFF          |          |          |
| fx3_data<31>             | IOB         | BIDIR     | LVCMOS25             |       | 12       | SLOW | IFF          |          |          |
|                                    |                  |                  |                      |       |          |      | OFF          |          |          |
|                                    |                  |                  |                      |       |          |      | TFF          |          |          |

| fx3_if_clk_top          | IOB          | OUTPUT    | LVCMOS25             |       | 12       | FAST | ODDR         |          |          |

 

I suppose this the confirmation that IFF,OFF and TFF have been packed into IOB  as wanted. Right?

 

If yes am I' right on assuming that  there is almost no delay between the input data pad and the first FF (which I assume is now placed into the IOB) ?.

 

Thanks and best regards

Joel

0 Kudos
avrumw
Guide
Guide
10,625 Views
Registered: ‎01-23-2009

Yes.

 

However, just because the delay from the input to the IOB FF is small (or virtually 0), this doesn't necessarily mean the interface is going to work. The whole path needs to be considered

 

  - the internal drives an ODDR to generate the forwarded clock

  - the forwarded clock goes out an OBUF

  - the clock goes on the board to your destination device

  - the destination devices generates data with some min and max Clock->Q

  - the return data travels back to the FPGA on the board

  - the return data goes through the IBUF

  - the return data needs to meet the SU/H time requirement of the IOB FF

 

You have to manually figure out if this is going to work... Even if everything is kept "as small as possible" doesn't mean this is necessarily going to work. In fact, you may need to add delay (using an IDELAY) to make this work, depending on the analysis.

 

The other forum posts I referenced talk about analyzing these kinds of paths.

 

Avrum

0 Kudos
Anonymous
Not applicable
10,617 Views

ok, thanks, your answer confirms what I was assuming. Manual  S/H verification and IODELAY adjustment are the next steps.

 

What about the warnings? why is ISE applying IOB=TRUE on other signals when I clearly enabled it just on one ?

 

Regards, Joel

0 Kudos
gszakacs
Professor
Professor
10,606 Views
Registered: ‎08-14-2007

You might want to check your settings for synthesis and Map.  Each one has

options for pushing registers into IOB's.  This global setting can also cause

warnings if it is set to "yes" (synthesis) or "For inputs and outputs" (Map).

-- Gabor
0 Kudos