VGUI
Frequently Asked Questions

9-15-1999

Q: Other output formats? . . What is planned?
A: We have been contemplating about adding an EDIF export capability.
Recently we are planning to add a JHDL export capability.
Q: What future enhancements are anticipated?
A: The next planned enhancements are:
  • Ability to launch your favorite text editor from VGUI.
  • Ability to import VHDL or Verilog code for viewing as block-diagrams.
  • Activate un-do feature for all operations.
  • Alternative exports (see above).
Q: Can diagram files be transferred between machines running different operating systems.
A: Yes. The diagram files are stored in plain ASCII text. The same files can be opened, saved, and moved across platforms, and edited by all versions of VGUI. This supports enterprise organizations with heterogeneous computing environments, as well as future public design libraries.
Q: Why only rectangular boxes, not shaped objects?
A: We did a survey of design diagrams and found that most abstract designs are drawn with rectangular function boxes. Only very low-level circuit diagrams used non-rectangular shaped objects, such as resistor (RLC), diode, schematic symbols, or NAND, NOR, NOT gate symbols (which can be represented as boxes too). There are fewer recognized standard schematic symbols for more abstract design objects.

We know many digital designers still design at the gate level. However, as we move into the future with greater use of automatic synthesis, we wish to encourage higher level design methods, while discouraging archaic methods. IE. Use higher-level building blocks. Few should need to be working at the gate level. An often used analogy is the mass-movement from assembly language programming in the 1960's to high-level languages, object oriented, etc. by the 1990's. Although we have received several questions about this issue, we tend to regard the request as being similar to asking for a paper punch-card interface in the midst of the Windows era.

In any case, VGUI does have the capability for displaying arbitrarily shaped objects. We are still considering documenting how to use this feature. If there are enough requests for this, we will document and advertise how to use it.
Q: What about adding guarded-block signal attributes to objects?
A: This is a functional/behavior attribute, not a structural one. We want to keep a clean separation so that VGUI is aimed purely at the structural aspects. Also, such attributes become language-specific. It could hinder the commonality as a general structure capture utility.

We are continuing to investigate this and plan to address this in the future. Specific suggestions are welcome.
Q: Where can I get a good text editor?
A: Several good text editors exist, such as:
  • GEdit. Simple, modern, easy to use.
  • Edt. Simple, easy to learn, light weight. More features than GEdit, such as jump-by-word/page, kill-line/word, mouse copying without loosing insertion point, automatic screen centering, multiple buffers, insert external files, etc..
  • NEdit
  • Vim
Q: How I can select my editor inside V-GUI ?
For example I want to use emacs, how to do it ?
A: You are referring to the case when you reach the bottom of your model hierarchy and you are pointing at a specific block in a diagram. Such a leaf-level block has no underlying diagram; only a textual behavior description. It would seem natural that, if you open a leaf-box, the model's text should pop-up in an editor window.

For now, you have to open your text editor as you normally would, from your text window or file-browser.

We have been considering opening the user's selected text-editor to the model-code from V-GUI in such cases. The mechanics of opening a text-editor from V-GUI are not difficult to implement. However, there are several logistic issues that we are working to solve. For example, V-GUI must keep track of which file the behavior-code for each model is defined in. Several models may be defined in a given file. The user may attempt to open the text-editor on a file that is already openned. Also, should the text-editor open to the line within the file where the model is defined? If a model is not yet defined, should we open a text-editor to a new file, or add it to an existing file. If the user saves a text-model to a new file-name during a V-GUI session, then attempts to re-open the text-model again, will V-GUI know what file to open? Etc..

Minimally, we could ask the user (via a pop-up dialogue), what file to open, and allow only one file to be open at a time, and have V-GUI freeze until the text-file is closed. Would this be sufficiently useful?

We plan to decide these issues and implement this capability by the end of 1999. In the meantime, any suggestions would be very much appreciated.
Q: Do you plan an editor for state machines inside V-GUI ?
A: Currently, V-GUI focuses on structural (connectivity) model aspects only. State machine description would involve the behavior aspects, so we do not plan on addressing this in the near-term.

However in the long-term, we plan to add state-machine and data-flow modes, with their respective code-export functions. This should be relatively straight-forward to implement on V-GUI's basic graphical paradigm. There are many open issues about the generated code-style. Any help or suggestions will be useful and appreciated as these new modes are designed and implemented.
Q: When I add a submodule to a diagram and then change the module's name, the box's type changes from a hierarchical-box (thick-box) to a leaf-device (thin-box). Opening the box no longer opens the sub-diagram. Is this a bug?
A: I suspect the issue is that you are changing the box's type designation to another type, probably to an undefined type, and the undefined type is assumed to be a leaf-device by default.

To change the name of a module-type (a diagram), move to the module's diagram you wish to change the name of, and click under the Edit menu:

Edit / Rename Diagram
You can then rename the module's diagram there.

Then, if you wish devices to be instances of that module, you would change their type designation to the module's new name, so that they bind to that module diagram.

Note that a device instance can be changed from leaf to module (and vice verse) at any time, strictly by virtue of what it points to. 





. . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

(Questions, Comments, & Suggestions: chein@atl.lmco.com)