me and my groupmate would like to ask HELP on this one we are required to implement a simulator for a simplified DLX processor, miniDLX. The miniDLX processor offers the following subset of DLX instructions:
1. R-type instructions: ADD, SUB, AND, XOR, SGT
2. I-type instructions: BNEZ, LW, SW, ADDI
3. J-type instruction: J
The miniDLX processor is based on the DLX architecture. Suggested programming language to be used is C.
The objective this project is to “execute” the program using pipeline #2 with the following schemes to solve the hazards:
• Structural Hazard: Separate Memory
• Data Hazard: NO Forwarding (Set B/C/D/E), Forwarding (Set F)
• Control Hazard: Pipeline Freeze

In this case project, we will write the following modules:
1. Utility program to input value for registers R1 to R31
2. Write a simulator program using pipeline #2

A.) Simulation Program
Simulate the program based from the input files: FILENAME.COD; FILENAME.DAT & REGISTER.REG. FILENAME.COD is a file representing the “instruction” memory. It contains the op-code of the program. Each line is sequential in nature (i.e., 1st line is the 1st instruction, 2nd line is the 2nd instruction, etc.) and represents op-code in hex format. The program is always assumed to start at address 0 and succeeding address is incremented by 4. The opcode of the instructions are as follows:
Instruction Opcode Function
ADD 000000 00000000010
SUB 000000 00000000110
AND 000000 00000000000
XOR 000000 00000000001
SGT 000000 00000000111
BNEZ 010000 Not applicable
LW 010001 Not applicable
SW 010010 Not applicable
ADDI 010011 Not applicable
J 100000 Not applicable

FILENAME.DAT is a file representing the “data” memory. Each line is sequential in nature (i.e., 1st line is the 1st word data, 2nd line is the 2nd word data.) and in hex format. The data is always assumed to start at address 0 and the succeeding address is incremented by 4.
Simulate the instructions by showing the contents of the registers/memory that will be affected in each clock cycle (i.e., like the examples shown above) Thus:
Cycle 1: IF/ID.IR, IF/ID.NPC, PC;
Cycle 2:ID/EX.A, ID/EX.B, ID/EX. IMM, ID/EX.IR;
Cycle 3:EX/MEM.ALUOUTPUT, EX/MEM.ALUOUTPUT, EX/MEM.B (for LW & SW)
Cycle 4:MEM/WB.IR, MEM/WB.ALUOUTPUT ( for ALU), MEM/WB.LMD (for LW), MEM[ALUOUTPUT] (for SW)
Cycle 5: Register affected
Note: Obviously, the simulation assumes separate memory for data and program. PC starts at zero.

Note: There is no “COND” register in pipeline #2. Please refer to the appropriate algorithm for Pipeline #2

Note: The affected registers/memory should contain the actual value.

Note: FILENAM.DAT and FILENAME.COD is provided by the professor.

Note: You have the option of having text-based or graphics-based output. The most important part is the correctness of value.


we dont know were to start, please give us clear coding on this to starto to..thanks

OK: I'll start:


Just kidding ---Actually, that's not where I (usually) start.

You seem to have a program specification in the form of a problem statement. Before writing "#include <iostream>", make a plan. (Ya gotta have a plan.) Before you make a plan, you might want to ask yourself the following questions:

Are there any parts of the problem statement that you don't understand?

Are you already familiar with DLX architecture (like from your class notes or textboot)?

Of the specifications of "mini" DLX are there any that conflict with what you already know about DLX? Are there any parts of your problem statement that do not appear in the DLX architecture? Or does the problem statement give a proper subset of DLX functionality?

Don't do a single other thing until you understand the problem statement (every part of it). Don't start writing code until you have worked out a method for implementing the simulator.

Now, in order to complete the assignment, you have to understand how the CPU works (not the actual implementation details of the hardware/firmware design, but a logical sequence of steps that executing a program will require).

In Most General Terms, a CPU is memory controller state machine with inputs and outputs that can be gated through certain logic and arithmetic elements. Instructions as to what specific operations are to be carried out are contained in memory that can be read by the CPU state machine.

How are you going to simulate such a thing with a C (or C++) program? Oh, yeah, you asked me first, didn't you?

In Most General Terms here's how I look at typical CPU operation.

Suppose I turn the power on (or hit the big red "Reset" button, or whatever...). What happens (viewing this as an outsider, not a CPU designer)? What does the CPU do? How would you write a job description for a cpu if it were a person and not a piece of silicon (or gallium arsenide, or silly putty, or...)?

Maybe something like the following:

1. Go to a certain "magic" memory location (maybe 0000000 or fffffff8 or whatever).

2. Read the contents of that location into an Instruction Register

3. Examine certain bits of the Instruction Register to find out what operation is being commanded. (The Op Code.)

4a. Some instructions set control bits for internal logic to cause the contents of some register to be transferred to or from a particular memory location. The address of the memory location could be part of the same instruction word that holds the Op Code. In general, the address could be given by the contents of some other register, determined by other bits of the same instruction word, or could be determined by some other mechanism. The point is that something about this instruction word (or some word associated with this instruction word) gives information about source and destination of some "data transfer". Not all Op Codes specify a "data transfer", but a lot of them do.

4b. Depending on the architecture there may be one or more "accumulators" that are designed to hold data words on which some arithmetic or logical operations are possible. So an instruction can designate that contents of a certain memory location (or some other register) can be added to the previous contents of a certain register. Etc.

4c. Other instructions may be used to cause transfer of program control to some specific memory location. The transfer might be conditional (That is, a program may be directed to go to a certain location if the results of some previous arithmetic operation gave value of zero, for example.) There may be certain specialized transfer instructions that have other effects. (Branch to subroutine, for example may do something special. Return from subroutine will do something special. Some instructions may have combinations of data transfer and control transfer. Some may have one and not the other.

5a. All instructions (except, maybe "HALT", if there is such a thing) will be followed by another instruction. The address of the next instruction to be executed may be part of the instruction word that holds the OP code. In many CPUs (most, these days), the next instruction might be implied to be the one in memory immediately after the current location. CPUs like this have something called a Program Counter, whose contents will give the address of the next instruction. "Control transfer" instructions (4c above) may load the program counter directly with a specific address, or may tell the CPU to go to a certain memory location to get the next address, or may even tell the CPU to calculate the next address according to contents of some memory location and the contents of some internal register. It can get pretty complicated. If the current instruction is not one of these "control transfer" instructions, or if the "control transfer" instruction is conditional and the condition is not satisfied, then the program counter is simply incremented (so that it will hold the next memory address after the current one).

5b. For some CPUs the contents of the program counter can be forced to certain values in response to a defined set of external conditions (logic value changes from an external pin), or from timer counter conditions or other internal conditions such as having some arithmetic operation result in an "overflow". These conditions can interrupt the usual flow of the processor and make it go to certain special program parts (interrupt service routines) that do something special and then allow the CPU to return to the previous sequence.

In any case, whatever happens at a given instruction, the program counter is updated and the process continues back at step 2.


So, here are a few things your program will need:

1. Variables (or arrays) that represent the internal registers: Program Counter, other registers (accumulators, etc.)

2. If the program is going to be reading and writing to memory, you might make an array that represents data memory. If the actual cpu has many megabytes of memory, you might make a restriction that only deals with a small amount of memory.

3. If the program memory space different from data memory space, then you might make a separate array for program memory. You could even just leave the program instructions in the program file and seek back and forth in that file to get to specific instruction addresses. It would probably be easier just to use an array (assuming the size restrictions are acceptable). If the program memory space is the same as the data space, then you would have an array large enough to handle both. The simplest array would have a size of, say 1024, with array element zero representing memory address zero.

4. You are going to have to be able to fetch an instruction from memory (read that value from the program data array or from the file). Your program will have to look at the bits that define the Op Code. One way to implement the instruction set simulator is simply to have a switch statement that results in calling a particular function that performs the task for each supported Op Code. There may be some functions common to more than one task, or some functions may be able to do the work of more than one instruction type. Here's where you get creative.

5. Part of each instruction's function will be to indicate to the CPU what the memory location of the next instruction will be. So your program simulator could consist of a big loop like the steps I showed above.

6. If you are going to read the program from a file into memory, do it. Then transfer to whatever "reset" location is defined for your CPU (or simulate going there) to pick up the first instruction of your program. Then step through the loop until you reach "HALT" or whatever stopping condition you have defined. (Computers that don't have "HALT" might have an instruction that says "Branch to the address that contains this instruction", the hardware equivalent of an infinite loop.

7. Now if there are any special features (pipeline), they might make the program a little more intricate, and all such things have to be taken into consideration, but they shouldn't affect your understanding of the basic functionality. On the other hand, if you completely write the program without any special features, you might find that there are lots of things that you will have to throw away in order to put in the "good stuff". That's why I think it's best to have a plan that includes everything before you start writing code.

OK: Your turn.

Regards,

Dave

"Ya gotta have a plan."
---davekw7x

Thanks Dave, but i need something that is solid like a code, or chunks of code for the problem.
but not like the code that you gave, hehehe.
thanks for the advices it gave me something to consider..thanks

Actually, Dave gave you exactly what you needed -- a way to figure out what you need to do. Since Dave is not on your team and won't get graded, he should not give you code, especially since you didn't post any yourselves (see the Guidelines)

True, since your description mentioned C. Change #include <iostream> to #include <stdio.h>

Good... Understanding the problem is more important than writing the code. If you don't understand, what is there to write?

__________________

Cow: You're a lawyer too?
Mooseblood (mosquito): Ma'am, I was already a bloodsucking parasite. All I needed was a briefcase!

Actually the problem statement suggested that it be implemented in C. Since the request was posted on the C++ board, I gave a (somewhat frivolous, I admit) program skeleton in valid, standard C++. Sometimes assumptions like this are invalid, although I try really hard to fit my answer to the implied needs of the posters. And please note that my use of the phrase implied needs is meant to imply that posters would probably have a better chance of getting meaningful help if they would ask specific questions --- as mentioned a time or three in your excellent Guidelines document, Walt.

Sometimes it's hard to know what question to ask, but just typing in the entire homework assignment (or copy/pasting into the post) is usually not very enlightening for people trying to help. However, I do my best.

To the Original Poster:

Here are three things that I am pretty sure of (I may be wrong --- but I don't think so):

1. I am not going to write the program.
2. Walt is not going to write the program.
3. The program is not going to write itself.

Regards,

Dave

It sounds to me like you need to write a virtual machine. To implement your CPU, you will probably want to use a FSM and surround it with the various I/O facilities that it will need.

If you're having trouble coming up with code, why not start with a bit of pseudo-code or even comment lines that give you a guideline for what you think that you'll need to do in real code? That way, as you better understand the entire scope of the work, you can add a bit here and there as you understand it...kind of like fitting a jigsaw puzzle together. You kind of have to look around a lot until you find a couple of pieces that will likely fit together and then build on what you've got.

This appears to be a very non-trivial project. In such cases, divide and conquer is usually a good approach.


:davis:

thanks gus for the commens andsugesion you guys really helped, im starting my program now, but its really slow, i also trin doing it on VB.thanks