cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
1,292 Views
Registered: ‎12-19-2017

What does T_SPIccm, T_SPICCFC stands for?

Jump to solution

I have a problem with 7 series datasheet.

In Master SPI Flash Master Mode Programming Switching Characteristics.

 

What does Tspiccm & Tspiccfc stands for?

Doest it define as the timing after CCLK falling edge?

 

ccm_ccfc.jpg

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Scholar
Scholar
1,576 Views
Registered: ‎02-27-2008

It means from the clock edge to the data (valid), it is not more than 8ns,

 

Austin Lesea
Principal Engineer
Xilinx San Jose

View solution in original post

0 Kudos
7 Replies
Highlighted
Scholar
Scholar
1,261 Views
Registered: ‎02-27-2008

Well,

 

Setup is time before the clock edge, Hold is time after.  So the first column is 3ns setup is required BEFORE the edge, and 0ns HOLD time is required after the edge (data is allowed to change immediately/at the same time as the edge).

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Highlighted
Contributor
Contributor
1,254 Views
Registered: ‎12-19-2017

@austin

 

Thanks for you reply.

 

I am confused about the two later column. MOSI clock to out/ FCS_B clock to out.

Does it mean signal is avaliable with 8 ns after cclk falling-edge? 

 

 

0 Kudos
Highlighted
Scholar
Scholar
1,577 Views
Registered: ‎02-27-2008

It means from the clock edge to the data (valid), it is not more than 8ns,

 

Austin Lesea
Principal Engineer
Xilinx San Jose

View solution in original post

0 Kudos
Highlighted
Visitor
Visitor
483 Views
Registered: ‎08-26-2019

@austin wrote:

It means from the clock edge to the data (valid), it is not more than 8ns,

 


Which clock edge does "the clock edge" refer to, though? Is it from the rising edge of CCLK or the falling edge? From figure 2-13 in UG470:

 

Figure 2-13 from UG470Figure 2-13 from UG470

It looks like both MOSI and FCS_B are driven out on the falling edge of CCLK, but I can't find anywhere on either UG470, XAPP586, or DS181 that says whether MOSI and FCS_B are driven from the rising or falling edge of CCLK. Figure 3 in XAPP1233 (for Ultrascale devices), also seems to imply that the MOSI and FCS_B lines are driven by the CCLK falling edge.

 

Figure 3, XAPP1233Figure 3, XAPP1233

 

It's critical to know which edge these specifications refer to. We need to meet timing from the falling edge of FCS_B to the first rising edge of CCLK. Same for any change on MOSI to the CCLK rising edge. Both T_SPICCM and T_SPICCFC are 8 ns. If these 8 ns are calculated form the falling edge of CCLK, then in the best possible case (memory has a setup requirement of 0 ns, there is no CCLK-MOSI or CCLK-FCS_B skew on the board, and CCLK has perfect 50% duty cycle) the minimum half-clock period for CCLK would be 8ns. This would imply a full-cycle period of 16ns, or 62.5 MHz. With a reasonable set up time of 3ns, and a duty cycle of 40% that goes down to 36MHz.

All of this makes me want to believe that the specification is given from the rising edge of CCLK, despite what the figures above show. After all, the "Configuration Clock Calculation Example" sections of the XAPPs cited above don't consider T_SPICCM and T_SPICCFC at all. If these specifications were given from the falling edge, then the Configuration Clock Calculation Examples are not really looking at the worst-case timing, and it's not really possible to configure the part at anything faster than 62.5MHz.

Could you please clarify which clock-edge these specifications refer to and, if they refer to the falling edge, why aren't T_SPICCM and T_SPICCFC considered in the XAPP calculations?

0 Kudos
Highlighted
465 Views
Registered: ‎01-22-2015

@ro_ca 

I think that the following text from page-53 of UG470(v1.13.1) will help answer your questions:

The CCLK frequency starts at 3 MHz typical providing sufficient margin for the FCS_B and MOSI activity. The CCLK frequency increases if the ConfigRate option is utilized after the start of the read, where only the SPI clock-to-data output timing and FPGA DIN setup timing need to be considered.

That is, CCLK is slow enough during write-to-flash so that T_SPICCM and T_SPICCFC are not a factor.  Then, CCLK speed is fast during read-from-flash and when T_SPICCM and T_SPICCFC do not apply.

Mark

Highlighted
Visitor
Visitor
447 Views
Registered: ‎08-26-2019

This makes sense iff the CCLK speed change happens halfway through an endlessly long read. So if I'm understanding correctly, the FPGA will request a read using the slow clock (and MOSI/FCS_B timing is satisfied), then when the FPGA reads the instruction to switch to EMCCLK or to a faster internal CCLK, it does so "on the fly", without issuing a separate read. Is this accurate?

0 Kudos
Highlighted
437 Views
Registered: ‎01-22-2015

@ro_ca 

…the FPGA will request a read using the slow clock (and MOSI/FCS_B timing is satisfied), then when the FPGA reads the instruction to switch to EMCCLK or to a faster internal CCLK, it does so "on the fly", without issuing a separate read.
This is also my interpretation of the comment from UG470.  I think your comment, “without issuing a separate read”,  must be true, otherwise (as you say) the interface could not pass timing analysis with some of the faster EMCCLK.  We can probably generalize your comment and say that all write-to-flash commands must be done (and are done automatically by the FPGA) before the switch from slow-to-fast CCLK.

I just used an oscope on a Kintex-7 board where we use ConfigRate option to set CCLK frequency to 33MHz.  After power-up, I can see that CCLK starts at 3MHz and then, sometime later, automatically switches to 33MHz.

Mark