![](http://datasheet.mmic.net.cn/Lattice-Semiconductor-Corporation/ORT8850L-3BM680C_datasheet_99201/ORT8850L-3BM680C_50.png)
Lattice Semiconductor
ORCA ORT8850 Data Sheet
50
Table 16. Operating Modes and Data Paths - SONET Logic Block
All timing is referenced to the clock signal at the FPGA/Core interface. Data is also timed for signals at the
FPGA/Core interface. There will be additional time delays until the interface signals reach the capturing latch. The
primary or secondary path delay is controlled, as noted earlier, and the clock timing at the capture latch can be pre-
dicted. The data delay, however, may be unique to each interconnect routing.
The timing diagrams provide a quantitative picture of the relative importance of setup and hold margins for the
cases discussed. In the diagrams, the launch and capture times and the time difference between the launching and
capturing clock edges are identied. As the time between launch and capture increases (up to a full clock period),
the possibility of a setup time problem decreases. Also, the possibility of a setup time problem decreases for
smaller maximum propagation delay values.
If capture occurs before the next data is launched, a hold time problem cannot occur. In nearly all cases, the differ-
ence between the launch and capture clock edges will be nearly a full clock cycle and the data will be captured
before the next data is launched. This is not guaranteed, however, and ispLEVER timing analysis should be done
for each application.
The general rules used for the FPGA/Core interface are as follows:
1.
If possible, transfers across the FPGA/Core interface should be direct register to register transfers with minimal
or preferably no intervening logic.
2.
Use positive (rising) edge ip-ops in the FPGA for both input and output unless a timing diagram (case 1)
explicitly indicates otherwise, or a special case (long routing path, etc.) is being considered.
3.
Attempt to ‘locate’ the FPGA side ip-ops reasonably close to the interface unless other timing constraints
prevent this. This ‘locate’ is typically achieved by placing a frequency constraint on the FPGA_CLK signal. In
most cases, up the 3 ns of data path delay through the FPGA logic in the ORT8850 is acceptable.
4.
Pay attention to the clock routing resource recommended (these are xed on the ORT8850), and to the delay
and skew limits and the clock source points.
5.
Run Trace setup and hold checks in ispLEVER on the routed design taking the environmental constraints into
account. (See ispLEVER Application Note for details).
For the cases where parallel data is output from the core, the reference clock is also output from the core and the
effects of propagation delay variation are included in the discussion. Propagation delay is dened relative to the
interface signals and thus is the time from the enabling (falling) edge of the clock from the core to the time that data
is guaranteed to be valid at the interface. As an example, for the rst case discussed, the minimum (tprop_min) and
maximum (tprop_max) propagation delays are 0.8 ns. and 4.7 ns. respectively. Therefore the data outputs are sta-
ble for 6.1 ns. (10 ns. - 3.9 ns.) of each clock cycle. The data must be captured during this stable period, i.e., the
data signals must arrive at the capturing latch with adequate setup and hold margins versus the clock signal at the
latch.
In the rst case,
Figure 27, the alignment FIFO is assumed to be bypassed and all timing is with respect to the
recovered clock. The FPGA is latched on the falling edge of the clock, an exception to the general recommenda-
Case
Data (Note: xx
=[AA, …BD])
Data Path
Embedded Core
Clock
Launch/Latch
FPGA Clock
Launch/Latch
Clock/Route
1
DOUTxx[7:0]
Core to FPGA
Falling Edge
CDR_CLK_xx/Secondary
2
DOUTxx[7:0]
Core to FPGA
Falling Edge
Rising Edge
FPGA_SYSCLK/Primary
3
DINxx[7:0]
FPGA to Core
Rising Edge
FPGA_SYSCLK/Primary
4
TOH_OUTxx
Core to FPGA
Rising Edge
From FPGA/Secondary
5
TOH_INxx
FPGA to Core
Falling Edge
Rising Edge
From FPGA/Secondary