System-on-Chip Environment: SCE Version 2.2.0 Beta; Tutorial | ||
---|---|---|
Prev | Chapter 4. Custom Hardware Design | Next |
So far, we performed allocation, scheduling and binding of which information is annotated into the SFSMD model. Then the SFSMD model should be refined into cycle-accurate RTL model, which is represented by finite state machine with data (FSMD). The cycle-accurate model will reflect all scheduling and binding information.
Basically, this step will split the state to the multiple states reflecting scheduling information. Now each state will take exactly one clock period to perform.
The RTL refinement tool can generate cycle-accurate FSMD models in various hardware description languages such as Verilog HDL and Handel-C in addition to SpecC. The Verilog HDL model will be used as input for commercial logic synthesis tool like Design Compiler from Synopsys. Also the Handel-C model will be fed into Celoxica Design Kit to generate gate-level netlist.
We refine the SFSMD model to a cycle-accurate model by selecting Synthesis->RTL Refinement from the menu bar.
The refinement step will split the state into multiple states reflecting the scheduling information. Also, each state will take exactly one clock period to execute.
The RTL Refinement dialog box pops up showing us all options which can be used for the refinement tool. At the top of the dialog box, a pull-down list is available to select the desired behavior to be refined. The default behavior is the one that is highlighted in the behavior hierarchy tree. For our demo, select "Code_10i40_35bits (HW)" from the list then left click on Start to begin RTL refinement. Notice that like in the earlier refinement phases, we have options for partial refinement steps. The user might avoid some binding steps if he wants to look at intermediate models. Also note that we have selected a clock period of 10 ns, corresponding to the speed of our custom hardware unit. It may be recalled that while selecting the hardware component, we specified a hardware component with clock speed of 100 Mhz, which imposes a clock period of 10 ns.
The RTL refinement tool can generate cycle-accurate FSMD model in various hardware description language such as Verilog HDL and Handel-C in addition to SpecC. The Verilog HDL model will be used to be input of the commercial logic synthesis tools such as Design Compiler from Synopsys. Also the Handel-C model will be fed into Celoxica Design Kit to generate gate-level netlist. In this demo, we will generate SpecC RTL and Verilog HDL model for the design.
Change the output file name for the Verilog HDL model to "VocoderRTL.v".
Note that the RTL refinement step generates a new RTL model for 6 sub-behaviors of the behavior "Code_10i40_35bits", as seen in the logging window. Also note that a new model "VocoderFsmd.rtl.sir" is added in the Project manager window.
Like before, we must give our new model a suitable name. We can do this by right clicking on "VocoderFsmd.rtl.sir" and selecting Rename from the pop up menu. Rename the model to "VocoderRTL.sir".
In order to look at RTL model for the behavior "Build_Code_RTL", select Synthesis->Schedule & Bind RTL from the menu bar.
In the right-most column of the RTL Scheduling and Binding window, some states are split to multiple states. For example, state S9 is split to 6 states, S9, S9_1, ..., S9_5. Note that the delay of these states is less than 10 ns in Delay in the right-most column.
Left click on Cancel.
We now browse through the newly created model in the Design hierarchy window. Note that the type of the instance "build_code" has now changed to "Build_Code_RTL" after RTL refinement.
Select the behavior "Build_Code_RTL" by left clicking on it. We now take a look at the synthesized source code to see if the RTL refinement tool has correctly generated the RTL model. Do this by selecting View->Source from the menu bar.
If the reader is not interested, he or she may skip this section to go directly to Section 4.5.4.
The SpecC Editor pops up showing the RTL code for behavior, "Build_Code_RTL." Scrolling down the editor window shows several function declarations in this behavior. It is to be noted that these declarations correspond to the functions implemented for the allocated RTL components. Also, we can observe a FSMD construct with 10 ns clock period.
Scrolling down further shows the assignments for the state variables. Recall that the RTL synthesis produced 112 states. These states are enumerated here from 0 through 111. Note the final assignment (S_EXIT = 111). Further observations of the generated code show read/write operations on the register files. For instance, RF1 is the register file written in the statement RF1[0] = BUS1; as shown in state S9.
Check out the Verilog code generated in the file VocoderRTL.v. This code is generated by the RTL refinement tool. The designer may go the shell and launch his favorite editor to browse through the generated Verilog code.
If the reader is not interested, she or he can skip this section to go directly to Section 4.5.5.
Note that the Verilog code has corresponding modules for 6 sub-behaviors of Code_10i40_35bits.
In the Verilog code, we use "case" construct to represent FSMD. All states are defined by parameter construct. If "_start_" signal is activated, FSMD begins to execute and then if FSMD reaches state S_EXIT, "_done_" signal is asserted and FSMD will end to execute and will wait for the next entry of execution.
Now, we have to create an executable for the generated FSMD model by selecting Validation->Compile from the menu bar.
If reader is not interested, she or he can skip this section to go directly Chapter 5.
Note that the RTL model compiles correctly generating the executable VocoderRTL as seen in the logging window. We now proceed to simulate the model by selecting Validation->Simulate from the menu bar.
The simulation window pops up showing the progress and successful completion of simulation. We are thus ensured that the RTL refinement step has taken place correctly. Also note that we can perform the RTL refinement on any behavior of our choice. This indicates that the user has complete freedom of delving into one behavior at a time and testing it thoroughly. Since the other behaviors are at a higher level of abstraction, the simulation speed is much faster than the situation when the entire model is synthesized. This is a big advantage with our methodology and it enables partial simulation of the design. The designer does not have to refine the entire design to simulate just one behavior in RTL.
In this simulation, we see the delay per frame in RTL model increases to 18.13 ns from 17.05 ns compared to SFSMD model. Because each state in the SFSMD model is split into multiple states by scheduling and binding.