Script for Laboratory: Designing embedded ASIPs - CES

More documents

Recommendations

Info

mkimg mkimg_remotePas mkimg_fromS Script Description mkimg_fromS_remotePas mkall This version is expecting C-Code as input. The syntax is: ../mkimg application.c {CompilerOptions} The compiler options are directly forwarded to the compiler binary. Examples are: “-O0” or “-O4” for different optimization levels. When you want to manually change the created assembly code, then you can copy the .asm file from the created “compiler_temp” subdirectory to the application directory and change the suffix from .asm to .s. Then you can do your modifications in this file and use mkimg_froms_remotePas to create the Test- Data.IM and DM out of this file. Similar to mkimg, except that the assembler “pas” is not executed on your local machine, but instead copied to i80pc06 (a Red Hat machine) and executed there. There are some known problems, when executing “pas” on a non-Red-Hat machine. Similar to mkimg, except that not C-Code is expected as input file, but an assembly file. The syntax is: ../mkimg_fromS application.s Similar to mkimg_fromS, except that the assembler “pas” is not executed on your local machine, but instead copied to i80pc06 (a Red Hat machine) and executed there. There are some known problems, when executing “pas” on a non-Red-Hat machine. Similar to mkimg, except that not only one single C-file is compiled, but all C-Files and S-Files in the current directory will be compiled and they will be linked together with all assembly files in the current directory to form one common binary. The syntax is: ../mkall {CompilerOptions} The output assembly file will be called “NameOfTheApplication- Directory.dlxsim”. The other versions of mkimg create an output filename, that’s similar to the input filename. Figure 8-2 Different versions of “mkimg” The following files are created by the different versions of the mkimg scripts as the actual output: • TestData.IM and TestData.DM: These files contain the memory images for the instruction and data memory. Those images are needed for the VHDL simulation with ModelSim, as explained in Chapter 5.1.4 and they are needed for synthesis, as explained in Chapter 6.3. • ApplicationName.dlxsim: A file for simulating your application in dlxsim, as explained in Chapter 3.3. The different versions of the mkimg scripts do more than only creating the actual output. In fact there are some problems in the automatically generated compiler descriptions and thus in - 74 -
the automatically generated compiler, as shown in Chapter 8.3.2. For the known problems, we wrote a script that is invoked by mkimg to overcome the specific problem. That’s why mkimg is creating so much output on the screen and in the temporary directory. However, generally everything is fine, when the last printed message says: FINISHED “mkimg”. The mkimg scripts for C-files will automatically add a “#define COSY” line at the beginning of the C-file and names the result “ApplicationName.cc”. This way you can use “#ifdef COSY … #else … #endif” constructions to handle a gcc-version and a CoSy-version in the same file. For example, you can add debugging output in the gcc-version or you can implement gcc-versions of CoSy specific inline assembly functions, as shown in Chapter 8.4. This automatically added line will also affect the error messages, as the error message refers to the generated “ApplicationName.cc” file instead of your “Application- Name.c” file. This means, that every printed line number in the error message corresponds to the preceding line in your “ApplicationName.c” file. 8.3.1 Typical reasons why a special instruction is not automatically used There are some cases, where an assembly instruction will not be used, although it should be usable for an application. For example the branch instructions are not automatically made known to the compiler, by the meistercg tool from ASIP Meister, which automatically creates the rules for the compiler generation. Branch instructions need to be added manually to the set of rules, which is not a trivial task, as you have to understand the ASIP Meister specific concepts of rules for branch instructions to do so. Another reason for an unused assembly instruction is a behavior description of this instruction that does not match the application you are compiling. For example you might have defined a shift instruction and you are using a division by 4 in your application. Now you might expect, that the shift instruction is used for this division, as a division by 4 can be expressed with a shift instruction. But unless there is a special rule for this shift instruction that matches a division node with a power-of-2 immediate as input, the shift instruction will not be used. Except the above-mentioned cases, where the CoSy compiler cannot automatically use an instruction without some manual changes to the set of rules, there are cases where an instruction really should be automatically applicable. For such cases we provide a checklist that you should manually inspect to find the problem: • Write an elementary C-Code to force the compiler to use your instruction. Make sure, that the data types are correct. Don’t mix signed with unsigned values. An immediate value for the assembly instruction should always be a constant in the C-code. A register should always be a variable. • Review the instruction_set.arch file in the meister/dlx_basis.sw directory of your current project. Verify the behavior description of your instruction. Sometimes necessary brackets are missing in this file, as explained in Chapter 8.2. - 75 -
Page 1 and 2:
Laboratory: “Designing Applicatio
Page 3 and 4:
6 Validating the CPU in Prototyping
Page 5 and 6:
Figure 1-1 GPPs, ASIPs and ASICs [H
Page 7 and 8:
• Command line interpreter Intera
Page 9 and 10:
i. Copying files: the cp command co
Page 11 and 12:
. Copying via ssh: Not all machines
Page 13 and 14:
dlx_basis Applications ModelSim mei
Page 15 and 16:
makeCoSy contCoSy Filename Explanat
Page 17 and 18:
3 Dlxsim Dlxsim [DLX-Package] is an
Page 19 and 20:
Successful Successful dissolving di
Page 21 and 22:
Instruction Description Instruction
Page 23 and 24: Option Description -dbb# (Debug Bas
Page 25 and 26: Instruction Format Parameters NO_AR
Page 27 and 28: Command Description stop {options}
Page 29 and 30: 3.3.2 Debugging with dlxsim This ch
Page 31 and 32: addComment1(); functionY(); addComm
Page 33 and 34: • If you manually want to write a
Page 35 and 36: 4.3 Tutorial for the “Flexible Ha
Page 37 and 38: in direction; The in keyword means
Page 39 and 40: amount : in std_logic_vector(7 down
Page 41 and 42: Add the three signals to the contro
Page 43 and 44: data_in : in std_logic_vector($W1 d
Page 45 and 46: 5 ModelSim ModelSim is a full-featu
Page 47 and 48: 5.1.3 Compile the project Figure 5-
Page 49 and 50: Mark the wave.do file in your Model
Page 51 and 52: Figure 5-6 ModelSim waves Signal Ex
Page 53 and 54: • Always invoke ModelSim in the s
Page 55 and 56: If you don’t already have a proje
Page 57 and 58: CPU VHDL Files have been generated
Page 59 and 60: After the TestData-files for your a
Page 61 and 62: However, you can’t force the synt
Page 63 and 64: Timing (Timing Analyzer)” will op
Page 65 and 66: 7 Power estimation In this tutorial
Page 67 and 68: - Start the simulation (Simulate/ s
Page 69 and 70: 8 CoSy compiler The CoSy compiler d
Page 71 and 72: When you manually have to fix some
Page 73: of the makeCoSy script. If an error
Page 77 and 78: instruction, as different custom in
Page 79 and 80: Directive Explanation .restrict .ch
Page 81 and 82: Now we will demonstrate how you can
Page 83 and 84: the user changes the value of the b
Page 85 and 86: • Huge decrease of cycle count
Page 87 and 88: of instructions together it might t
Page 89 and 90: Table of Figures Figure 1-1 GPPs, A
Page 91: References [CES] Homepage of the Ch
show all

Script for Laboratory: Designing embedded ASIPs - CES

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?