Department of Electrical and Computer Engineering The University of Texas at Austin ECE 382N, Spring 2002 Y. N. Patt, D. N. Armstrong Project FAQ Last Updated: 9 May 2002 Q: Could you please clarify when our projects will be tested? Is it on the date of the final design review or when the final report is due? A: Please note we need to aim to have the projects ready for testing on the date/time of your final review, not the time that the final report is due. That is, try to have your projects ready for testing by April 29-30 or May 1, and then take the next week to write your report by May 10. Please send me email if you're not clear on this. Q: I have one question about the instruction format. One variation of the JMP (3-358) is EA cp. But when I look up what 'cp' means, it means 6bytes value following the opcode. So where do we put this 6 bytes value? A: For the following far jump instruction: EA cp JMP ptr16:32 Jump far, abolute, address given in operand The ptr16:32 is confusing because this gets translated in the following manner: EA <32-bit offset> <16-bit selector> Also see page B-10 of Vol. 2, where this is shown in the manual. Q: [This is duplicated from hwk 5 FAQ:] I think the hw5 faq is unclear regarding the fan out. I can't find any mention of fan out on any of the assignment specs. Do we, or do we not, have to obey a limit of max fan out of 5? Please clarify. A: It is a project requirement that gates with a fan out of 5 or more require buffers. Q: [This is duplicated from hwk 5 FAQ:] I just wanted to verify that I understand the 1KB limit on cache size. As I understand it, the 1KB is the maximum total of I-Cache plus D-Cache. Also, the 1KB doesn't include the storage needed for tags - meaning that we can actually use a little more than 1KB of RAM including the tags. Do I have this right? A: Yes, you have this right. Q: Can you confirm if we are expected to adhere to the PUSH ESP and PUSH SP behavior as implemented in the 286 and onward. According to the manual (page 3-650), push SP on the 8086 would push the decremented SP on the stack whereas in the 286 and onward the unmodified SP is pushed on the stack. A: Use the 286 and onward mode, please. Q: Just confirming - we do not have to implement the address-size override prefix right? And hence we can assume that we will have at most 3 prefix bytes for any instruction. A: Yes, the project clarifications link on the homeworks page of the website provides these details. Q: Is EIP an architecturally visible register ? A: Yes. Q: In stack segment If I do a push and an exceptrion happens, is it sufficent to just decrement the stack pointer (or increment) to undo it or do we actually need to undo the writing in the stack ? A: I'd recommend not writing to memory til you're confident you're not going to get an exception. On an exception, memory must be in a consitent state-- that is, what it was before the push instruction. Q: Are we expected to have support for misaligned memory accesses for our project? A: Yes. Q: I'm wondering if we're going to be able to use all the elements in the library file for the project? A: Yes, though there are restrictions such as using the RAM parts for the cache. Q: What physical data are we going to be required to deliver, such as general floor-planning? A: Floor-planning is not necessary for this project. Q: What about interconnect delays? Does Verilog have the capability of timing based on loads (such as for large fan-outs), and are we going to have take that into acount? A: You are required to include buffers to deal with large fan-outs. Q: What about clock buffering and skew, and early mode timing? A: Don't worry about buffering the clock. Q: Does the fan-out requirement apply to the clock as well? A: Nope, no need to buffer the clock. Q: For the REP MOVS instruction, the default segment registers used for the string move are as follows: DS for the source, ES for the destination. how does the segment override prefix work for this instruction? do we override one (if so, which one?) or both? A: See the description of MOVS in Vol 2, p. 3-479-- only the DS segment may be overridden. Q: Can we assume in the test cases that all words and double words in the data cache are alligned (that is they will not cross cache line boundaries)? Obviously we can not make this assumption for the Icache and need to add extra logic for instructions that cross cache line boundaries, but for dcache it is usually the case that data will be alligned, correct? A: No, data can be unaligned in the D-Cache. It may usually be the case that it is aligned (as in a good compiler will know to align data values), but you must be able to handle the non-aligned case. Q: Also, just to vent a little, it seems totally uninstructive (i.e. just a lot of busy work) for us to code our control logic using structural verilog. HW4 gave us a necessary taste of building control logic in structural verilog, but continuing to do so for the rest of the project seems like orders of magnitude more work that it is worth. I wouldn't imagine any companies actually do this. Maybe I'm missing something though? A: The philosophy of the class is that you are to have direct knowledge of what goes on at the gate level of your processor. Sometimes, this involves tedious work. I suggest you write some perl scripts to help you out. Q: Is a DMA device required for the project? A: I have a clarification on the matter of a DMA device in your project. A DMA device is not required but instead is optional for the project. It'd be nice to have one but it's understandable that as you get down to the wire, this may well get dropped. If you have any questions on this, let me know. Q: On this one I've heard different thing. I was talking to one of the groups and they said that in thier review they were told that we needed to have two I/O's one was supposed to be an easy one like keyboard or monitor, and the other was supposed to be more difficult like a DMA controller. Is that still the case? A: No, that's no longer the case. A DMA device is desirable but not required. Q: For our interrupt handling, do we only need to pretend there is one type of external interrupt? Therefore basically, all we need to handle are exceptions and one external interrupt. Thanks, A: Correct. At least one external interrupt and at least two exceptions (general purpose and page fault). Q: Will the segment limit quantity be a quantity relative to the base address of the segment? A: Yes, the segment limit is a relative value. Q: What is the size (in bits) of a segment limit quantity? Will it be 16 bits, or more? A: Segment limits are 20-bit values which you will be able to expand out to hardcoded 32-bit values. I will provide directions for this when I announce the values I'd like you to use in your design. Q: The segment limit which will be provided, will it be aligned to Instruction/Page ie. will it be the case ever that some part of the instruction is valid and some part of it falls outside the limit. A: You're not guaranteed that this will be true. You must check that the entire piece of data that you're accessing falls withint the segment limit. Q: Is it okay to assume that push and pop can have segment override? A: Yes, the stack operations can have overrides. (See next question.) Q: In the faq, you say that push and pop operations can have segment overrides. The manual says stack operations should always reference the stack segment (vol. 1, p. 3-19). A: The segment override applies to the POP destination or the PUSH source. Not the stack access which always uses the SS segment. Q: When moving a value into a seg register, how is the segment register operand specified? I assume it is in the reg/opcode field of the ModR/M byte, but Table 2-2 does not specify this anywhere. I assume that we use the bit specifications as listed on page 3-4. ES=0, CS=1, etc. Is this correct? A: What you describe is correct. Q: You mentioned something in class about not worrying about flags we don't use. I assume this only means ones that our instructions don't affect. For example, several instructions set the parity flag (PF), but none of them will ever test it. Just wanted to make sure we're still supposed to implement those flags. A: See the general clarifications page for the EFLAGS you are to implement. You do need to implement those that are set but not tested. Q: Can a memory access be across two pages or do we assume that memory accesses occur only occur within a page ? A: A memory access can cross a page boundary. Q: Also, when there is an exception, do we go to the exception handler defined in the Interrrupt Descriptor Table? If we do, when it returns do we continue processing the i-stream we left off? A: When there is an exception, you jump to the address specified in the interrupt descriptor table. The routine returns with a IRET instruction. One of the things the IRET instruction does is load the previous EIP and CS values in order that you continue processing where you left off in the instruction stream. Q: After reading section 6.2.2 of volume 1 (page6-3), i just wanted to reconfirm the satck alignments specifications. are we still having an unaligned stack? A: Yes, it's still possible for you to have an unaligned stack. You are not responsible for the added complexity listed in this section, e.g., the D flag in the segment descriptors. Instead use the data size of the push and pop instructions to determine the current stack size. It's up to the programmer to get it right for the purpose of this project. Q: Is the i/o devices always comunicationg in terms of DWord or is it adjustable like any other memory address (B/Word/Dword) depending on opcode. A: Depends on your design of the I/O device. Many solutions could work here. Q: I had a question regarding the library ram cell which we're supposed to use for the cache. It has only a single port. So, does that mean we're not supposed to have more than one port to the cache ? Also, would duplicating the cache in order to be able to read and write to the cache mean that we can only use half the allowed size in each (256 B, say, if I had my I-cache and D-cache size equal to 512 B each)? Is there any other way out? A: Try interleaving instead of duplicating for more ports. Q: I know we are supposed to use the ram (not sram) parts for the cache, but which memory parts (ram or sram) should we use for main memory? A: Use the SRAM parts for main memory, please. Q: Just wondering about the files, which will initialise our 32K memory. One will atleast need 256 parts of 128*8bit sram ie. there will be about 256 different initialisation files(for each ram part) which one will need to make from your testcase file. A: The test programs will be relatively small.. you needn't initialize all of the memory modules beyond those that contain test code. Q: There are several instructions who's effect on certian flags is undefined (example OF set by ROR by any number other than 1). I take this to mean that I can chose what happens, and if someone wants to test it, it is up to them to use and instruction that explicity sets it before using it -i.e. they shouldn't assume any result in the OF flag will still be there after a Rotate instruction. Wanted to make sure this was right. A: Yes, I agree. If the flag is undefined, the software cannot count on the bit to be meaningful. Q: Can I assume the six pages you'll give us are contiguous? A: Nope. Q: And do the contents of hardcoded TLB entries specified by you include all information about read/write flag, present flag, virtual page number, physical page number? A: Yes. Q: On startup, what value should be loaded into the EIP? All zeros makes sense, but maybe you have something else in mind. A: Start up with 0 in the EIP and 0 in the segment registers, please. Q: Main memory size is 32kbytes (which will mean a 15-bit physical address space). Can we assume that memory-mapped I/O devices will be mapped to addresses within this space? i.e. some addresses within physical memory will not be usable because they will overlap with the address of an I/O device. A: Exactly right. I will be giving you 6 out of 8 TLB entries. The unused physical pages are yours to do with what you will... I/O for example. Q: Do we need to support immediate values larger than 31 for the BTS instruction in the BTS r/m32, imm8 form? A: For the BTS r/m32, imm8 instruction, the offset, represented by the immediate value, falls within the range 0 to 31. Q: I would like to know what you think about driving the bus to an undetrmined state for 15ns. A: You should've have two drivers driving the bus with different values at the same time. This would have bad effects "under the hood" of your logic gates. Q: Now I'm working on the WriteBack (Store) stage, which is the final stage of the pipeline. I remembered that during the design review, you said that we'd better to have a store buffer in the store stage to improve the efficiency in case of D-cache misses. Is it required? A: It is not required but it is a very good performance enhancement and makes a lot of sense in a pipeline design. Q: Please correct me if my understanding of the store buffer is wrong: In case of cache hit, the data is directly written into D-cache; In case of cache miss, the data is first written to the Store buffer, which is actually a FIFO queue. At some point, D-cache will get the data and remove it from the top of the buffer. A: This isn't quite right. The store buffer comes in handy when an instruction in the Write Back stage wants to write back while, at the same time, an instruction in the Memory stage wants to read from the cache. A variation on this scheme works in the following manner (this is a simplified explaination and there are still some important details to work out). The instruction in the Memory Access stage reads from the Cache and the instruction in the Write Back stage writes to the store buffer. This lets loads proceed and makes stores wait-- which is desirable, see why? Now there are some complications that go along with this which include looking in the store buffer before going to the cache to find the most current data. Q: So when shall the D-cache be updated with the contents of the store buffer? A: When it's convenient. Q: And how can we check the memory dependency if some instruction's results are in the D-cache and some of them are still in the store buffer? A: I'll leave this and the other complications to you. Come talk to me if you still need help after reading the above. Q: Will the test program have the 0th memory address (boot location) in the beginning of the file, or at the end? A: Beginning Q: Hex or binary? Or do we need to handle either? A: Hex Q: Can we split up the test file into multiple re-ordered, smaller files to load the test program into a hierarchy of sram instantiations? A: Yes. Q: 4. Can we initialize the main memory to some intitial condition within the top-level testbench (behavioral code) in case the tests are shorter than the full capacity of main memory? A: You don't need to bother initializing all of memory. Q: It would be great if you could provide a sample test file (not one of the official tests, just the same format) before the design review so all the groups could iron out any interface mismatches ahead of time. A: Agreed. I will send an announcement when this is available. Q: I just need to know what you have decided about the case of exceptions for pushes. Is it okay to assume that we cannot have any exceptions on a push? A: No push exceptions. Q: Do we handle the interrupt after HLT? HLT makes machine halt state and enabled interrupt makes resume the machine. Do I understand correctly? A: We won't test waking up after a hlt instruction though you are certainly welcome to implement this. Q: My question is will the segment limit be greater than 64K or less than (or equal to) 64K? A: The segment limit registers are 32-bits wide therefore larger than 64K. Q: or, put another way to use your dcache_buster example, for the first instruction, the number "00" right after "BA" in address 0.....is that "00" at address 1, or at address 4? A: Yes, the 00 following the BA is at address 1, not address 4. Q: second about the interupt handler, is the IDTR a virtual address or a physical address? A: virtual address. Q: what do you use to go from assembly to machine code? hopefully not by hand. A: You can use as86 on a linux machine to generate code however you must be careful because this assembler will probably not give you exactly what you want. You'll probably have to do a fair amount of grunt work by hand. Q: during the final design review, how will the procedure for demoing the things which we have added . Eg we have a [undisclosed performance enhancements], I doubt the test programs will test any of these. i assume that in addition to the interrupt testing program , we will have to write our own programs which tests these auxilarry structures. A: That is correct, you'll be responsible for writing test programs that demonstrate the functionality of these features. Q: is there a way, in the compiler, to check for sourceless and sinkless nets? this would save us valuable debug time.... A: I don't know of a way to do this. If anyone knows, let me know and I'll post the answer. Q: [Regarding the interpretation of the segment limits,] So should we revert to byte level check which does not ignore the lowest 12 bits of the effective address (offset)? A: Think of it as though I, by way of the segment limits provided, control both the segment limit register and the granularity flag. This interpretation does not violate the ISA, provides me greater flexibility in my test programs, and, hopefully, simplifies your design. [That is, interprete the segment limits I gave you as segment limits, requiring no manipulation on your part.] Q: when are we going to be given the test programs for the design review, and when will you need us to show you they work? A: We'll try to do this the day before your design review, if possible. It will be arranged on a per group basis. Earlier the better. Q: Do we need to handle page faults during rep movs? (Either by saving the initial value in ECX or by pushing the current value of the "walking" memory operands on the stack?) A: Yes, you do need to handle page faults in the rep movs routine. Your h/w is not responsible for saving the "walking" memory operands, that is the exception handler's responsibility.