What is time borrowing: Latches exhibit the property of being transparent when clock is

asserted to a required value. In sequential designs, using latches can enhance performace
of the design. This is possible due to time borrowing property of latches. We can define time
borrowing in latches as follows:
Time borrowing is the property of a latch by virtue of which a path ending at a latch can
borrow time from the next path in pipeline such that the overall time of the two paths
remains the same. The time borrowed by the latch from next stage in pipeline is, then,
subtracted from the next path's time.
The time borrowing property of latches is due to the fact that latches are level sensitive;
hence, they can capture data over a range of times than at a single time, the entire duration
of time over which they are transparent. If they capture data when they are transparent, the
same point of time can launch the data for the next stage (of course, there is combinational
delay from data pin of latch to output pin of latch).

Time Borrowing also known as cycle stealing occurs at a LATCH.

By definition, Time Borrowing is permitting the logic to automatically borrow

time from next cycle, thereby reducing the time available for data to arrive for
the following cycle OR permitting the logic to use slack from the previous cycle,
in the current cycle (explained in FIG # 2).

The slack used from previous cycle ripples through the pipeline automatically.
Time Borrowing (Cycle Stealing) applies ONLY to LATCH based designs, while
Time Stealing for flop based designs.
In FIG # 1 below, time hogging PATH # 1 causes setup violation at FF1. With clock
period of 5 ns, and PATH # 1 consuming 7 ns, timing cannot be met UNLESS,
clock period is changed from 5 ns -> 7 ns (the least. Tpd, setup and hold of FF is
assumed to be 0). Increasing the clock period affects the performance of the
pipeline.
The above timing issue is resolved with SAME clock period of 5 ns, using
TIME BORROWING principle as shown in FIG # 2. In FIG # 2, FF1 is replaced
with LATCH1 which is POSITIVE LEVEL sensitive. This OPENS the LATCH1 at the
same time as FF1 at 0ns, but closes LATCH1 at 2.5 ns ( at negative edge of
CLK1), unlike FF1.
So, PATH # 1 has extra 2.5 ns to borrow from next cycle (as LATCH1 closes at 2.5
ns). Time borrowed by PATH#1 = 2 ns ( PATH # 1 delay (7 ns) CLK period (5 ns).
PATH#1 can use the entire 2.5 ns, but uses only 2 ns, leaving a positive slack of
0.5 ns.

Since LATCH1 closes at 2.5 ns, there is NO TIMING VIOLATION, as data from
PATH # 1 -> LATCH1 arrived 0.5 ns before LATCH1 is closed. Output of LATCH1
is immediately available for combinatorial PATH#2. PATH#2 starts right where
PATH #1 left off, as shown in the fig. (this is important to remember, as Prime
Time uses this principle for Time Borrowing, while reporting ). PATH#2 adds 1 ns
delay from where PATH#1 left off (@ 2 NS ) also referred as the start point (not
the pin G of LATCH1) for FF2.

PATH#2 could have used upto 3 ns (0.5 ns slack from previous stage + 2.5 ns of
half-clk-period of current cycle), but uses only 1 ns. Valid data is available for
capture FF2 at 3 ns. Since rising edge of capture FF2 happens at 5 ns, FF2 has
positive slack of 2 ns (5 ns 3 ns).

This should clear the concept of borrowing time from next cycle & using the
slack from previous cycle.
Timing is met with NO changes to clock, but just by replacing FF1 with LATCH1.
Time borrowing stops once you hit the pipeline with a Flip flop. Ideally, to exploit
Time Borrowing principle fully, pipeline should employ only LATCHES.