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.
Top //
6.033 home //
Last updated $Date: 2003/03/20 02:17:32 $ by $Author: fdabek $
Design Project 1 Question and Answer: updated 19 March 2003
Questions or comments about this web page? Send e-mail to
6.033-webmaster@mit.edu.