Algorithm 1 Longstaff Schwartz MC method to price American maximum call option on two stocks
8. Bringing Flexibility to FPGA Based Pricing Systems
8.4 The HyPER Pricing System
HyPER is a high-speed pricing system for option pricing in the Heston model. It uses the advanced Multilevel Monte Carlo (MLMC) method and targets hybrid CPU/FPGA systems. To be able to
1.
2.
3.
efficiently price the vast majority of exotic options traded on the market it is based on reusable building blocks. To adapt the FPGA architecture to the requirements of the multilevel simulation in each part of the algorithm, it exploits online dynamic reconfiguration
8.4.1 Modular Pricing Architecture
For each level l the main steps of the MLMC algorithm are:
Simulate N l MC paths and optionally with k = M l time steps.
Calculate the coarse and fine payoff for each path.
Calculate the mean and variance of the difference of all coarse and fine payoffs, according to Eq. (8.3).
This is done for l = l 0, …, L. For practical problems the first level l 0 is typically equal to 1, the multilevel constant M equal to 4, and the maximum level L between 5 and 7. The number of MC steps N M l is roughly the same on each level and in the order of 1012 [8, 11].
Step 1 is the computationally most intensive part of the multilevel algorithm since it requires solving Eq. (8.2). This involves Brownian increment generation (Increment Generator) and calculating the next step of each path, step by step, path by path (Path Generator). In HyPER we therefore implement it on the FPGA part of the hybrid architecture. While for the first level l 0 only one type of paths is calculated (Single-Level Kernel), for higher levels fine and coarse paths are required with the same Brownian increments. This makes the kernel more complicated and involves more logic resources (Multilevel Kernel). This covers the frontend of the HyPER architecture shown in Fig. 8.4.
Fig. 8.4 The HyPER frontend is a modular pipeline in which each blocks are fully utilized in each cycle. Payoff features are user defined and can be extended to generate path dependent features as required for the financial product being prices. While often times only a small set of features are required for a specific product, only the necessary blocks are mapped to the system
The Brownian increments are generated with a uniform Random Number Generator (RNG) and transformed to normally distributed random numbers. We choose the Mersenne Twister MT19937 for the uniform RNG and an Inverse Cumulative Distribution Function (ICDF) approach for the
transformation. We further use antithetic variates as a variance reduction technique [10].
8.4.1.1 Payoff Computation
Part 2 involves the payoff computation and is strongly dependent on the option being priced. With the HyPER architecture we cover arbitrary European options, including barrier options that depend on whether a barrier is hit or not, and Asian options for which the payoff depends on the average of the stock price. For such path dependent payoffs every price of the path has to be considered. This leads to the dilemma that on the one hand a high-throughput payoff computation is needed, since the prices are generated on the FPGA fabric with one value per clock cycle. On the other hand the payoff
computation may involve complex arithmetics that are not used in each cycle. Considering the payoff procedure carefully in the HW/SW splitting process is therefore crucial.
One of the key insights of the HyPER pricing system is to split the discounted payoff function in two separate parts: A path dependent part F i and a path independent part h. The idea is to put the path dependent part F i on the FPGA and the independent part h on CPU. We express the payoff as:
We call the path dependent functions F i features and choose them such that they contain as little arithmetic operations as possible. h does not directly depend on . Let us look at an example: Asian Call options with strike K. Their payoff is given by:
In this case the sum is path dependent and we can identify the result of this sum as feature F:
For each MC path we now get one feature F instead of all prices from all the time steps. This dramatically reduces the bandwidth requirements for the backend, for example on level 5 from one value per cycle to one value every 1,024 cycles.
We have analyzed commonly traded European options1 and extracted five general features with which it is possible to price all of them. They are given in Figs. 8.4 and 8.5. Even highly exotic types like digital Asian barrier options are included. If a feature should not be present for a very specific option type, it can be easily identified and added to the list.
Fig. 8.5 The HyPER backend processes path features generated from the frontend and calculates statistics like the mean and variance of the payoff of the financial product being priced. Since features are generated once per path, the backend can process data from multiple frontends. Due to low demands on later blocks they can be mapped to the backend by the HyPER platform
In general, only very few features are necessary to define the payoff g of an option. This shows the general usefulness of this payoff split and suggest to consider HW/SW partitions after all features have been generated. For the first part of the architecture starting from RNG and continuing with path simulation, a HW/SW split is normally not suggestive due to high bandwidth requirements inside. We call this part of the architecture the HyPER frontend as depicted in Fig. 8.4.
8.4.1.2 HyPER Backend
Everything following is called the HyPER backend. The stock prices in the frontend are calculated as . While some of the features like min⁄max can even be applied to them, for most of the features we have to go back to normal prices at some point. So the backend includes exponential
transformations for log-features, the path independent parts of the payoff functions h (Payoff), and a statistic block that calculates Step 3 of the MLMC algorithm (see Fig. 8.5). The rest of the algorithm is handled on the CPU. On higher levels where fine and coarse paths are calculated, the statistic is evaluated for the differences. The rate of this differences is half the price rate, and we can always use the statistic core with an Initiation Interval (II) of 2, a core that takes one value every second clock cycles. For the first level l 0 we take the core with II = 1. Figure 8.6 shows the complete pricing system, the HyPER architecture.
Fig. 8.6 For a given financial product and hybrid system the HyPER platform generates well-matched HyPER architectures for each level, including an optimal HW/SW partitioning. It is then used by the multilevel control to compute the option price in multiple iterations.
In each iteration a different HyPER architecture might be used and is reconfigured as necessary by the system
8.4.2 Runtime Reconfiguration
The overall performance of the hybrid option pricing system obviously depends on the actual configuration of the platform. It is important to note that for a given payoff function g there are still some degrees of freedom in the architecture, for example:
The number of HyPER instances on the FPGA part,
For each HyPER instance the number of frontends and where to make the HW/SW split in the backend, or
The type of communication core for CPU/FPGA communication.
When running the MLMC algorithm, the backend processes the payoff features F i from the
frontend, one feature set F i per path. For level one, new features are generated every 4th clock cycle, which suggests no HW/SW split inside or after the backend. For level l = 5, features are generated only every 1,024th clock cycle, which suggests an early HW/SW split right after the frontend.
To account for these changing requirements for different levels, we propose an algorithmic extension in which we reconfigure the hybrid system for each level, see Algorithm 1.
This leaves the question on how to find the optimal HyPER configuration on each level, especially for the middle levels l = 2, …, 4. This issue is addressed in the next sections.