1.  The attempt to seperate the inline functions from the .h file into
their own .cc file, failed.  Setup.cc complained about matching multiple
template functions.  The library also doesn't work.  It always give an
unresolvable error for "operator<<(ostream &, String &)".  I can't find
the problem, so I'm giving up.  Ask Alex for further assistance. 
(2/27/95)  We now know why this won't work.  (3/1/95)  Non-template
classes can still be seperated.  Don't know if it's worth the effort.
(3/7/95)  String.h and Symtab.h are now seperated.  TWheel.h has also
been updated so that g++ will compile it.  G++ will now compile the
entire project.  Done! (3/8/95)
(low priority)

2.  For part I, features:
	-- display line number if error is detected during Sim_setup()
	-- non-decimal conversion in $write.  Done! (3/21/95)
	-- add more escape codes to $write, added more (3/21/95)
	-- change "set_text()" in vbs.l to "copy_text" or something
	more descriptive  Done! (Karen)
	-- update the source code to use the new operator[] in the
	list class
(low priority)

3.  Fix the <Stmts> reference in <SeqBlk>.  It is causing core dumps
when the statement is deleted.  Can't delete a reference, or can we?
(high priority).  Fixed. (2/28/95)

4.  Support the $finish system task.  This is needed by the "always@"
construct, started (2/28/95). (high priority).  Finished.  (2/28/95)

5.  Method of implementing event driven simulation

First try:

	1.  Symbol table points to a List<Stmts> of statements
	for triggering.
	2.  When variable is changed (upon assignment operator),
	statements are appended to a list of events to occur.
	3.  In case the same variable is changed more than once
	within the same time unit, we mark the idx in another
	table (same size as symbol table).

	Questions:
	Q1.  Should we create a new object to keep track of the
	link list and the table of indices?
	Q2.  How do we deal with delays inside an event trigger?
	Q3.  What if the 'always' statement uses a delay rather
	than an event?
	Q4.  What if two variables that trigger the same statement
	are modified.

	Answers:
	A1.  For now, lets make it an object.  If we find out later
	that it's easier not to, we just dump it.
	A2.  Is this a problem?  (Question to a question)
	A3.  Treat the delay and event as two types of always
	statement.  I.e. detect them, and do the right thing.
	A4.  Add a trigger status to the Stmts class.

Q4 is killing this attempt.  Due to A4.

Second try:

	1.  Add a status flag to Stmts class.
	2.  When variable changes, statement is appended to time
	wheel on next time unit (CurrentTime+1).
	3.  Stmts is updated so no further trigger can happen.
	4.  Use A3 from first try.

	Q1.  Does this solve all of the above questions?
	A1.  Let's pray!

Second try seems to work.  But $write is not executing.
$write now executes correctly for numeric delays.  (2/28/95)

Third try:

"Always @(a)" happens at the same time unit as when 'a' was modified.
Thus, (2) above is wrong!  We can not add to the time wheel.  It must be
on a seperate link list. 

	Q1.  Why not append to time wheel on the current time?
	A1.  Answer to Q2 will decide.
	Q2.  Is it possible that a statement in the event queue
		might modify a variable which triggered an earlier
		statement on the event queue?  I.e.

	always @a $write(1)...
	always @b $write(2)...
	always @c a = ...(3);
	always @a
		begin(4)
		b = ...;
		c = ...;
		end

Then the event queue looks like this:

	(1) (4) (2) (3) (1) (4) (2) (3) ...

	A2.  Guess we have infinite loop.  But is the above a valid
		description?  There's no syntax error, but a semantic
		error?  I don't see why we can't do Q1.
	Q3.  So what do we do?
	A3.  Add the following...
		0.  Update the EvntCtl class to support the entire
		event construct, including "pos/negedge".  We can
		add multiple monitor variables later (a or b or c etc).
			Add a new class to include "pos/negedge".
			Use a flag to indicate which.  Don't use
			two flags.  Use a List to store more than
			one event monitor.
		1.  Add a flag to Stmts to indicate queued status.
		2.  Add list to symbol table to store the statement
			of the monitored variable.
		3.  When adding to the time wheel, don't make a
		copy of the statement.  We need to update the queued
		status when the statement is executed in the time
		wheel.

There are too many cases for the delay_or_event_control type.  We need
to use polymorphism here to reduce the complexity. (3/4/95)

Updated everything.  Now need to modify Lvalue to do the right thing.
Create EventQueue to support queued events.  We can not simply append
to the time wheel, because statements like $monitor can only be executed
after the current time slot.  So it's better to create another list
for this type of event.
(3/12/95).

Procedural statement "always" now works. (3/14/95)

6.  Add support for don't-care values in our data storage.  I.e.
Our Number class can't store an unknown bit.  But we can't think of
a data type that can do what we need and still support DC's.
(low priority) changed to (high priority)  Finished!  (4/10/95)

7.  Change $write to use a->display() rather than a->Sim_trigger().
After 'always @' works. Problem, display() was not meant for this
purpose... (3/13/95)  Not Doing!!!
(low priority)

8.  Fix Range class to take [0:3] instead of [1:4].
Done (3/21/95).  Update, range selection supports both.  Everything is
now supported.  Finished (4/10/95)

9.  Modulize errors.  maybe create a class?
	strerror
	perror
	errno
(medium priority)  Done!  (3/21/95)

10.  Move all base class definitions to the top of PTypes.h.  This
will allow other classes to use it without reordering them.  Base
classes include the following:
	Expressions
	DelayEvntCtl
	Stmts
	ModuleItems
Update after inclusion of Karen's "if statement".
(high priority)  Done!  (3/17/95)

11.  Change makefile to use g++/flex and -lfl when compiling vbs.l.
flex doesn't have yylineno, so g++ chokes at link time.  but "lex"
has some ANSI problem that chokes gcc.  So I'm stuck between a rock
and a hard place.  Tried, no go!  guess gcc and flex don't mix.
(low priority) (4/11/95)  Done!  (4/11/95)

12.  Add range support.  ie.  a[2:3] = b[5:6];  i don't know if we
should support ranges in expressions.  If so, how do we go about it?
	1.  Add operators to SubBitVector.
	This is not a good solution, because there's a lot of redundency.

	2.  In Eval.cc (RangeId), we return the correct Number if a
	range exists.  This is good for expressions, but will it be
	enough?

	3.  For assignment, we might need to modify Lvalue::Sim_trigger
	to support ranges.
Done!  (4/12/95)

13.  Add support for 'case' statements.  This is a problem.  How do we 
determine which case to execute?  I.e. 'default' case can be located 
anywhere.  How do we determine if we should execute a statement without 
going through the entire list of cases?  For example:

	case (value)
		2'b01: statement_a;
		2'b00: statement_b;
		default: default_statement;
		2'b10: statement_c;
		2'b11: statement_d;

If we use a link list to store all the cases, how do we determine if the 
default case should be chosen?  Hmm, now that I think about it.  Nothing 
says I can't use another data member to represent a 'default' case in my 
'case' object.

14.  Fix alignment problem with comments and tabs.  Make vi use a tabstop
of 5 spacing.  Done! (4/14/95)
