6.033: Computer System 
Engineering

6.033: Computer System Engineering - Spring 2003

------------

Design Project 1 Question and Answer: updated 19 March 2003

A design project is a different beast than a quiz. Like in real life a design project is underspecified and it is your job to complete the specification in a sensible way given the overall requirements of the project. Like with designs in practice, the requirements often need some adjustment as the design is fleshed out. Questions and answers will be posted here as they are generated.


Q: The assignment requires me to specify the fault handler. Does this mean we should specify what actions the OS will take on each fault, or just that we should inform the OS what kind of fault ocurred and be sure to prevent any illegal operations from executing?

A: Just tell the OS what happened. An exception is that your design may rely on the memory management system responding to certain kinds of faults that may occur during a correct execution of the program. One example of such a fault that occurs in larger scale systems is page faults. These occur when part of the address space is paged out to disk. When the application tries to access the data, it generates a fault. The handler then reads the data back from disk and resumes the program, which can then perform the access and continue. Your design may (or may not) have situations that are similar in spirit to this.

Q: Can we modify the interfaces given in the design project assignment?

A: If you have a good reason for the change and can justify it, go ahead. In any design project there is usually a negotiation process between groups as they nail down the precise details of the interfaces that they propose to use. If you decide to modify our proposed interfaces, however, it might be a good idea to discuss your change briefly with a staff member to be sure it is something we think is reasonable.

Q: It seems like there might be a potential security problem with the interface. Can't memory be deallocated in one application, then allocated to another, which may in certain circumstances be able to access the data from the old allocation?

A: This may in fact happen with your design, and it is OK if it does. We are not expecting you to prevent an application from accessing data left behind in reallocated physical memory from another application.

Q: Can I put a small amount of cache on to the CPU?

A: You can do this if you want to, but it should be quite small (similar to the 32 byte size identified for the MMU). It is not immediately clear to us why you would like to do this, so we suggest you discuss it with your TA to make sure you are on the right track.

Q: When the application calls into the operating system to grow its memory, where should the new memory be placed in the address space of the application?

A: The obvious thing to do is to simply extend the virtual address space. However, if your design decides to do something different, we have decided that it is OK as long as each individual allocation returns a contiguous part of the address space. Be careful if you do this, however, because it may raise a lot of issues that you'll have to think through.

The above answer overrides the previous answer which was:

A: At the end of its current virtual address space. So, if the application currently has a virtual address space of size 1K and calls the OS to grow its memory by 512 bytes, it should now have a virtual address space of size 1.5K, with the new 512 bytes addressed directly above the end of the old address space.

Q: Does the 4K limit on applications include code and data, just code, or just data?

A: The 4K limit includes both the code and the data. Both are stored in the single address space of the application. So, for example, the first 512 bytes might contain the code, with the next 1K bytes containing the space for the data. This would make a total application size of 1.5Kbytes. Of course, other application sizes and code/data distributions are possible up to 4K total for both code and data.

Q: There are so many design constraints, how do I write about them all?

A: Prioritize your ideas. Decide what elements are most important to your design, and focus on those elements. In almost all design projects, it is possible to spend virtually unlimited time exploring all of the details of the design. Your write up should help the reader by highlighting the overall structure and key elements of your design first, then going into more detail once the reader has had a chance to obtain a good understanding of the high-level structure of the design. This is an example of hierarchy in presentation: an understanding of the high-level structure helps the reader place the details in a conceptually coherent framework, making it much easier to understand and appreciate your design. A flat presentation structure is discouraged - in any design, some things are more important than others. Help the reader by emphasizing high-level structure and key aspects first, then elaborate second.

Q: Is the report single spaced or double spaced?

A: Single spaced.

Q: Are Appendices included in the 8-10 page limit?

A: Yes.

Q: How should I present the pseudocode for my design?

A: Your report will need examples of pseudocode to illustrate your ideas. Remember that the purpose of the pseudocode is to make your ideas precise and understandable to the reader. Pseudocode is therefore intended to be a communication means, and should be presented in a way that maximizes its comprehensibility. We suggest that pseudocode should be chunked into small sections (about 10 lines per chunk) and explained with textual descriptions. Large chunks of pseudocode are not helpful to readers. Also, adding pages and pages of pseudocode in your Appendix is not a wise use of "real estate". All examples of pseudocode should be labeled like a figure (number, title, caption).

Q: Should one program be able to access another program's memory?

A: Your design does not have to support sharing of memory (either read-only or read/write) between programs. Of course, if it does support sharing, great!

Q: Does allocated memory consume power? If I allocate more memory than the program needs, will it increase the power consumption?

A: The RAM consumes (a small background amount of) power whenever it is turned on. Additional power is consumed whenever the program reads or writes data. Allocating memory does not, but itself, cause the power consumption to go up.

Q: Is there supposed to be some interface for decreasing the amount of memory allocated to a program?

A: We don't ask you to deal with deallocation except to remove an address space entirely when the program finishes.

Q: I'd like to put some additional state on the MMU, say around 128 bytes. Is this a reasonable amount of state to add to the design?

A: In general, you should be comfortable adding a reasonable amount of state to the various parts of the system. 128 bytes might be reasonable in some circumstances, but not this particular circumstance. The kind of state that one would normally add to an MMU must typically be accessed in a very fast, flexible manner. We are happy with 32 bytes of state or less. Anything over that should have a very good justification. Also, if you can get by with less or none at all, great!

Q:How much of the 32K bytes of RAM should I assume the operating system will require?

A: After consulting with the OS guys, we have hammered out the following design.

The above answer overrides the previous answer which was:

You should assume that the operating system is installed in a separate ROM and that all 32K bytes of RAM is available to downloaded applications. Also, you can assume that the operating system has its own RAM for storing its data and that this RAM is separate from the 32K bytes of RAM used to store applications. You can add a reasonable amount (less than 512 bytes or so) of memory to this OS RAM for whatever data structures you might need to support your design.

Q: Do I need to reserve space for things like network buffers?

A: In general, there are two conceptual kinds of memory (both stored in the 32K physical address space): memory for the OS to do its work, and memory for the application to do its work. All of the memory the application needs is addressed in its (maximum size 4K) address space. All of the memory the OS needs to do its work is stored in the OS memory (the second 1 Kilobyte of physical memory), not part of the 32K RAM used to support applications.

You can imagine communication buffers in both the OS and the application. The OS's communication buffers are stored in the separate OS memory described above. The application's communication buffers are stored in its address space.

Q: What is the largest program my design needs to support?

A: You can assume that the largest program you'll ever need to support with this system will be 4K bytes long, and that the mix of programs will include some that are substantially smaller than 4K bytes. Your design should not waste lots of memory if it is called upon to support a range of program sizes between 1K and 4K.

Q: What is the smallest program the system will typically see?

A: In general, your design should be able to support arbitrarily small programs. However, the total number of programs your system will need to support on the mote at any given time is limited. Specifically, your design does not need to support more than 30 programs installed on the mote at any given time. Of course, if you have a more flexible scheme that allows you to can support more than that, great!

To be more specific, your design is OK if it allocates memory in units of 1K bytes, so that each program less than or equal to 1K bytes takes up 1K bytes, greater than 1K bytes but less than or equal to 2K bytes takes up 2K bytes, etc. Of course, if you have a more flexible scheme, that is great!

Q: I'd like to restrict my PIDs to be between 0 and 31, inclusive. Is this reasonable?

A: You can make a working system that does this. However, you might want to make your design a bit more flexible so that it can deal reasonably well with any envisioned upgrades that would allow the system to support a larger number of loaded processes.

Q: Are the instructions and memory for the applications both stored in the 30K RAM available for user programs?

A: Yes, in particular, the address space for each application (which you can assume is less than 4K) includes both the instructions and any memory that the application requires.

Q: The handout states that the mote has a 16 bit bus. I need some control lines to implement my design. Should I use some of these 16 bits for control lines instead of addresses and data?

A: You should feel free to add a (reasonable) number of control lines to the bus if your design needs it, leaving the 16 bits intact for carrying addresses and data.

Q: I need to access the state I've added to the MMU. I'd like to use memory-mapped I/O to do so. Luckily, my design can address the full 32K with only 15 address bits. Can I reserve the top 32K of the address space (all addresses with the top bit set) for accessing these kinds of devices?

A: In general, memory-mapped I/O is a reasonable design choice, so reserving a block of addresses for this kind of functionality is OK. You might want to think, however, about what you might do if the next generation of the mote decides to provide 64K of memory, which seems like a reasonable upgrade.

The alternative to memory-mapped I/O is to provide instructions that perform I/O or access specific parts of the processor/MMU state.

Q: I'd really like to use the top bit of my 16 bit address for doing something really cool. Is this OK?

A: If you can justify the use, fine. But remember that systems often upgrade, and one of the prime upgrade paths might be growing the memory to 64K. Bear in mind that you might be able to achieve the same purpose with a cleaner design that adds a control line or two to the bus.

------------

Questions or comments regarding 6.033? Send e-mail to the TAs at 6.033-tas@mit.edu.
Questions or comments about this web page? Send e-mail to 6.033-webmaster@mit.edu.

Top // 6.033 home // Last updated $Date: 2003/03/20 02:17:32 $ by $Author: fdabek $