Mon, 1 Apr 2013, 02:32
A student writes > Professor Patt, > > Could you please clarify a few things for me: Certainly. This student has a lot of questions that I feel require detailed answers. So my response to his few things (five) will be long. Feel free to skip it if you already understand it, or read it carefully if you feel it is useful. > 1) for an interrupt (in general), is the INTV register populated > automatically by the external device, or does the particular interrupt > signal cause a specific vector to be loaded? > i.e. would the device send both a 1-bit alert signal and an 8-bit vector in > parallel to both trigger the interrupt and supply the vector, or would it > simply send the alert signal and have the processor recognize that an alert > on that particular input corresponds to a certain vector? Every interrupt has associated with it an interrupt vector that the hardware uses to access the interrupt vector table in order to find the starting address of the corresponding interrupt service routine. As you know, different interrupts require different service routines. Therefore, they must have different interrupt vectors. If an external device wants service, it raises its interrupt line at the time it wants service. Most likely, the processor is in the middle of executing an instruction. The hardware identifies the highest priority interrupt, and in the last clock cycle of the current instruction's execution, it loads its interrupt vector into the INTV register. The processor also asserts the one-bit INT register signifying that an interrupt wants service. After the current instruction is finished, the state machine uses that one-bit INT register to either continue processing the next instruction OR start the process of initiating the interrupt. One of your jobs is to add the logic to the microsequencer that is necessary to make that happen. > 2) when adding onto the data path and state machine, is there a preference > between adding control store bits vs adding states? I've found that I can > potentially reduce 2 particular states in the interrupt sequence by adding > 2 control store signals. Is it worth increasing the control store by a > couple bits (which will only be used by 1 or 2 states) just to avoid adding > 1 or 2 new states? Whatever you want to is fine with me. Your job is to do what is specified by the Lab 4 specification. You will need to add control signals (bits to the microinstruction). You will need to add states to the state machine. You will need to add logic to the microsequencer and data path. How much of each is up to you. > 3) On the Protection Exception: should the PC always be able to access > system memory (0x0000-0x2FFF), or only in supervisor mode? Implementing > vectors requires the PC be loaded with addresses in system space, but > should we detect a user's attempt to jump into that space by one of the > available opcodes? You are missing something very fundamental. If a program running in user mode tries to access locations in system space, the program causes an exception - an access control violation. We talked about that when we discussed virtual memory. There, the PTE provided the protection field associated with the page. Here, we have hardwired system memory to specific locations (x0000 to x2FFF and xFE00 to xFFFF). HOWEVER, you are not talking about a user program trying to access system memory, you are talking about the hardware needing to access system memory in order to find the starting address of an exception or interrupt service routine. To do this, indeed, the hardware will have to be in supervisor mode. Your state machine, which will initiate the interrupt or exception service routine, AFTER it knows that it is taking an interrupt or exception, must first change the PSR[15] to supervisor mode before it can access the interrupt or exception vector table. > 4) can we assume that the existing hardware for LSHF will not produce an > odd value? Or even better, that all hardware functions as intended, and no > random bit errors occur? I guess this one I will answer with a question: What does LSHF do? > 5) in cases where we use logic blocks to read and produce signals, should > we show the combinational logic required (specific gates + > interconnections) or can we simply include a description of the block's > functionality? In the former case, would you emphasize the intended > functionality of the logic block, or how well we implemented it at the gate > level when judging the design? Logic block details should be included, since it will help us understand what you are designing, but if you use a higher level structures in your logic (e.g., comparators), AND it is clear to us what you are doing, that will be fine. For this lab, our primary concern is function correctness, so if we can easily tell that from your description, that will be good enough. > I apologize if something I asked about was covered elsewhere already. Hope > you hear back from you soon. > > Thanks, > <<name withheld to protect the student who wanted a few things clarified>> Good luck finishing the programming lab. Yale Patt