Discrete Time Systems
Designs in Vitis Model Composer are discrete time systems. In other words, the signals and the blocks that produce them have associated sample rates. A block’s sample rate determines how often the block is awoken (allowing its state to be updated). Model Composer sets most sample rates automatically. A few blocks, however, set sample rates explicitly or implicitly.
A simple Model Composer model illustrates the behavior of discrete time systems. Consider the model shown below. The model has a gateway driven by a Simulink source (Sine Wave). A second gateway drives a Simulink sink (Scope).
The Gateway In block uses a sample period of one second. The Gateway Out block converts the AMD fixed-point signal back to a double (so it can analyzed in the Simulink scope). It does not alter sample rates. The scope output below shows the unaltered and sampled versions of the sine wave.
Multirate Models
Model Composer supports multirate designs, that is, designs having signals running at several sample rates. Model Composer automatically compiles multirate models into hardware. This makes multirate designs both natural and straightforward to implement in Simulink.
Rate-Changing Blocks
The Model Composer HDL library includes blocks that change sample rates. The most basic rate changers are the Up Sample and Down Sample blocks. As shown in the following figure, these blocks explicitly change the rate of a signal by a fixed multiple that is specified in the block’s dialog box.
Other blocks (for example, the Parallel To Serial and Serial To Parallel converters) change rates implicitly in a way determined by block parameterization.
Consider the simple multirate example below. This model has two sample periods: SP1 and SP2. The Gateway In dialog box defines the sample period SP1. The Down Sample block causes a rate change in the model, creating a new rate SP2 which is half as fast as SP1.
Hardware Oversampling
Some HDL blocks oversample; their internal processing runs at a faster rate than their data rates. In hardware, this means that the block requires more than one clock cycle to process a data sample. In Simulink such blocks do not have an observable effect on sample rates.
Although oversampled blocks do not change the sample rate in Simulink, Model Composer considers their internal rate and all other sample rates when generating hardware clocking logic. This means that you must consider the internal processing rates of oversampled blocks when specifying the Simulink system period in the Model Composer Hub block dialog box.
Asynchronous Clocking
Model Composer focuses on the design of hardware that is synchronous to a single clock. Under some circumstances, you can use it to design systems that contain more than one clock. This is possible if you partition the design into individual clock domains and regulate information exchange between domains using dual port memories and FIFOs. The remainder of this topic focuses exclusively on the clock-synchronous aspects of Model Composer. This discussion is relevant to both single-clock and multiple-clock designs.
Synchronous Clocking
By default, Model Composer creates designs with synchronous clocking. It uses clock enables to implement multiple rates. When Model Composer compiles a model into hardware, it preserves the design's sample rate information so that corresponding portions in hardware run at appropriate rates. In hardware, Model Composer generates related rates by using a single clock with clock enables, one enable per rate. The period of each clock enable is an integer multiple of the period of the system clock.
Inside Simulink, neither clocks nor clock enables are required as explicit signals in a Model Composer design. When Model Composer compiles a design into hardware, it uses the sample rates in the design to deduce what clock enables are needed. To do this, it employs two user-specified values from the Model Composer Hub block: the Simulink system period and FPGA clock period. These numbers define the scaling factor between time in a Simulink simulation, and time in the actual hardware implementation. The Simulink system period must be the greatest common divisor (gcd) of the sample periods in the model. The FPGA clock period is the system clock in nanoseconds. If p represents the Simulink system period, and c represents the FPGA system clock period, then an operation takes kp units of time in Simulink. The same operastion takes k ticks of the system clock (kc nanoseconds) in hardware.
To illustrate this point, consider a model that has three Simulink sample periods 2, 3, and 4. The gcd of these sample periods is 1. This needs to be specified as such in the Simulink system period field for the model. Assume the FPGA clock period is 10 ns. With this information, hardware can determine the corresponding clock enable periods.
In hardware, refer to the clock enables corresponding to the Simulink sample periods 2, 3, and 4 as CE2, CE3, and CE4, respectively. Determine the relationship of each clock enable period to the system clock period. Do this by dividing the corresponding Simulink sample period by the Simulink System Period value. Thus, the periods for CE2, CE3, and CE4 equal 2, 3, and 4 system clock periods, respectively. A timing diagram for the example clock enable signals is shown in the following figure.