Subject:
gpsim's gui
From:
Scott Dattalo ####@####.####
Date:
10 Oct 2004 01:21:19 +0100
Message-Id: <Pine.LNX.4.60.0410091657160.20345@ruckus.brouhaha.com>
It's time to upgrade gpsim's gui and I'd like to solicit your opinions
before proceeding. In particular, I'd be interested in hearing what you
like about the current GUI and what you'd like to see added. I'd also be
interested in what you have to say with the proposals that I'm making.
And before I get too far into this let me say that I'm not criticizing the
contributions Ralf Forsberg has made for gpsim's gui. I think his efforts
are commendable and that gpsim is simply growing beyond what the current
GUI can support. In fact, I'd love to have Ralf participate on the next
phase of enhancing gpsim!
----
As some of you may know, I've been working steadily on gpsim for all this
year. Much of my effort has been focused on adding support for a
proprietary microcontroller. However, at the same time I've been able to
add many new features to simulator. Many of these features are somewhat
transparent, (e.g. register assertions, three-state register values,
strong command line type checking, context debugging). In fact, except for
minor things (like the gray icons on the source lines) I really haven't
changed the outward appearance of the gui.
However, I've had the opportunity to directly interface with users. What's
painfully obvious, is that most users don't give a damn if the simulator
can simulate 20 times faster than real time but can't do what they want!
The challenge of a good simulator is to be both accurate *AND* easy to
use. The accuracy is there, gpsim now needs to address the ease of use.
The biggest complaint that I got was that gpsim has too many windows. In
my proprietary processor there are actually 3 source browser windows
opened. These along with the Dispatch Window, Register Window, and the
Breadboard window quickly clutter up a screen. This is really compounded
on Windows where there is only a single desktop.
So my number one goal is to consolidate these windows and optimize the
graphical real estate that's available.
Scott
Here are list of proposals for improving the GUI:
1) Centralize everything
In version 0.21.3 a separate window is created for every simulator
function. This was fine when there was only a source window and a
register window. However, now it is possible to have multiple source
windows (i.e. context debugging), a register window, an eeprom window,
a stack window, a stopwatch window, a trace window, a watch window, a
breadboard window, and so on. Placing the burden of managing these
windows on the OS is a cop out and makes it difficult to use the
simulator. On Windows, the problem is compounded by the fact that
there's only a single desktop.
So by centralizing, it is proposed that a single window with possibly
detachable children be created as a means for managing all of the GUI
functionality. At the same time, the GUI screen will be optimized for
displaying useful information.
1a) Source browser.
The source browser is the main focus of the simulator. Here are a list
of features to improve it:
- Move the Dispatch Window's Menu to the source browser and get rid of
the Dispatch Window.
- Optionally hide the tabs that display file names. They take up
valuable GUI real estate and are only used to switch between files.
- Add a cursor as an alternative means of aiming focus.
- Change all operations that were pointer-focused to cursor-focused.
E.g. the MOVE PC, Set/clear Break, Execute to here, etc
will all apply to the line associated with the cursor and not the
mouse pointer.
- Dynamic tool tips will display information about objects beneath
the mouse pointer.
- Add a horizontal scroll bar for files that don't fit in the
horizontal space provided.
- Add a status line field indicating the active source file.
- Add a status line field indicating the simulation state. The
simulation states can be: RUNNING, BREAK (stopped), ASSERTION
(stopped), ANIMATE,
2) Watch window
At the moment, the watch window is designed to allow the user to
select a set of variables to watch. It's also possible to select how
the information about the variable can be displayed (e.g. as hex,
decimal, binary, ASCII).
Here are ways to improve it:
- Make the watch window a dockable window in the source browser.
- Variables can only be displayed in only one format at a time (but the
format can be selected on a per variable basis)
- The variable name can be replaced with an address.
- Define two modes for the variables. In the manual mode, a variable
will remain in the watch window until it is manually removed. In
the automatic mode, most recently accessed variables replace the
oldest accessed variables.
- Register breaks can be selected from the watch window.
3) Program Memory window.
At the moment, the program memory window is a notebook with two
pages. One page is the disassembled hex file and the other is a spread
sheet of the opcodes.
Here are ways to improve it:
- Merge the program memory window into the source browser window by
creating new tabs. E.g. it would be as though if two new files are
added to the source browser. One file would be the disassembly and
the other the opcode map.
- Add a source line column to the disassembly window:
ADDR | OPCODE | disassembled instruction | Source line
-- If more one source line produces multiple opcodes (e.g. a macro
expansion) then only the first address will display the source
line. This is somewhat similar to the way the high level
language (JAL and C) are currently parsed by gpsim's source browser.
- Symbolic labels occupy a whole new line (as opposed to creating a
separate column for just labels).
- Assertions occupy a whole new line. In addition, the assertion
expression will be displayed.
- Breakpoints are highlighted by coloring the instruction back
ground red.
- Assertion lines are light yellow if the assertion is currently
false and bright yellow if the assertion is true.
4) Register Window.
At the moment, the register window is a spread sheet-like display of
the processor's RAM. Users can directly edit the register contents by
typing over the displayed values. In addition, a variety of actions
can be accessed by right clicking on a cell.
- Make the register window a dock-able window.
5) Stop watch window
At the moment, the stop watch window shows the number of cycles and
the amount of time that have transpired since it was last told to
start timing. In addition, the cycles can be displayed modulo some
number.
- Make the stop watch window a tool bar item.
6) Bread board window
At the moment, the breadboard window shows a semi-schematical view of
the simulation environment. It is split into a left and right
half. The right half is a drawing canvas that can hold graphical
images of the modules (e.g. a PIC processor is shown as a rectangular
dip package with labeled pins). The left half contains a tree view of
the modules and also provides a mechanism for specifying node
connections. In some since, the breadboard window is a quite powerful
debugging tool. Ideally you'd like to be able to create a schematic of
your simulation environment and then be able to view simulation state
information there. So for example, you'd like to be able to see the
state of I/O pins (this feature exists already) or internal state
(like perhaps the time when a square wave will change states).
- The breadboard window will not be part of the dock-able windows.
- Separate the graphics of a module from the source
code. E.g. provide a mechanism whereby a library of components are
created and individual modules can select. So for example if a PIC
is in a TQFP package, then the TQFP component will be the one
selected.
- provide a method for instantiating built in stimuli.
- provide a method for loading an external library (this sort of
exists, but needs improving).
- It may make sense to make the bread board viewer a separate application.
7) Trace Window.
At the moment, the trace window is a separate window that shows the
simulation trace buffer for the last 50 cycles or so.
- dock this into the source browser some how...
8) Stack Window
9) Oscilloscope Window
Currently, this window is inhibited.
10) Key Bindings
Currently, all key binds are statically defined in the source code. It
would be convenient to dynamically redefine them. In addition, create
new actions for keys (e.g. like I/O pin toggling).
- create a dialog window that allows a key (along with an optional
modifier) to be associated with an action.
11) Environment settings.
On Linux and UNIX OSes, gpsim currently records window state
information in the file ~/.gpsim. On Windows, this information is
recorded in a gpsim registry entry. It's proposed that the environment
settings be split into two components. The first will be a component
that is used to store information that is unique to a user (e.g. key
bindings). The second will be a component that is unique to a project
(e.g. the window positions). Project environment settings will reside
in a file and can be either command line or menu loadable. The System
environment settings reside in the same place they currently do. The
project settings supersede the environment settings.
