Bottom Up Modeling. Using the block diagrams of the Top Down analysis, for the hardware part, the designer starts to model each block. Modeling is done with a Hardware Description Language which can be low level as VHDL or Verilog or a modern high level language as Maxeler Java Extension[Maxeler], Vivado C/C++ [Vivado], SystemC [SystemC] etc. The designer can also use modules from module libraries, such as protocol implementations, DDR controllers, video controllers, several filters or even a general purpose processor. The designer can also use other design tools as Xilinx Coregen[Coregen],MatLab Simulink [Simulink], which produce modules for specific technology. With such tools the designers usually produce memory controllers, floating point arithmetic units or even modules implementing more complex arithmetic operations. In this procedure an equivalent functional module is built for each block. The module is tested for the equivalent functionality vs. the initial model. The results of the tested modules are validated vs. the results that are produced from the corresponding software solution. After the testing phase the integration procedure commences. Usually two tested modules are connected as a subsystem and the functionality of the subsystem is proved to be equivalent to the reference system. Then, a new tested module is added and with this procedure is repeated adding a new block. In that manner designer follows the reverse procedure of the Top Down analysis, building the complete system using subsystems as in the block diagram. Modular modeling and integration are really useful to the design procedure as several designers can work in parallel, following the block diagram and the interface descriptions. In that manner the design procedure is significantly faster vs. a serial implementation of the hardware components. The independent working designers procedure proves how crucial is to have a proper and well defined Top Down analysis, as any functional overlap between the blocks, or any ambiguous description of interfaces can lead to block diagram revision and consequently to new block modeling for several blocks.
Bottom Up Modeling. First, the CPU resolves the building of the interconnection between the CPU and the reconfigurable part. Second, the CPU sends a signal that initializes the EH structure and the corresponding counters. Next, the reconfigurable module takes either a stream of elements with values 1s or 0s with their corresponding timestamps or a stream of timestamps for estimation. The update process is separated into two stages: the first stage omits the expired data from the processing bucket while during the second one a new value from the input or the previous bucket is put in the bucket. In case of a new input, the timestamp of the new value is passed into the first level bucket. As shown in Figure 19, the buckets are 1-D arrays in range of [6, 20], as analyzed in Section 5.3.3, which work like a complex shift-register. In other words, when a new timestamp- value arrives at the input of a bucket all the previous values are shifted to the right for one position. After the insertion completes, there is specific logic which checks for merging condition for the last two elements of the bucket. If a new merged value needs to be passed to the next level, it is stored in the pipeline registers and the process continues the second level during the second clock cycle. The important issue here is that our implementation is fully pipelined which means that each level can serve the insertion/merge of a different timestamp. In other words, our proposed system exploits the fine grained parallelization that the hardware can offer by processing in parallel N different input values (like the number of total levels). Moreover, our proposed system implements the estimation processing either for the total window or for a specific timestamp. As shown in Figure 19, the EH module takes as input the timestamp that we want to estimate the number of elements with value 1. In case, that we want to calculate the 1‟s estimation value of the complete processing window, we pass the timestamp value -1. During the estimation processing, the value passes to the first level, where the estimation module calculates the estimation of this level. At the next clock cycle, the estimated value of the present level with the estimation timestamp passes to the next level bucket. The processing finishes when the score reaches to the last level and it returns back to the CPU. It is clear that our proposed architecture is fully pipelined taking advantage of the hardware fine grained parallelization.
Bottom Up Modeling. In this section we begin by describing in detail each individual component of Figure 22 and then we mention how they are interconnected. CPU Code Both components included in the CPU Code module have been provided by LibSVM. Nevertheless, we have applied several modifications to the source code in order to allow the integration of software and hardware.
