On 3/3/08, André Pouliot <[EMAIL PROTECTED]> wrote: > Why not do the connection between 2 modules be represented as a single > wire? That wire when selected open a windows with a list of the > connection already made and the other connection possible?
This all depends on the situation. Some wires are already going to be multi-bit anyhow. Plus, some of the interconnects will go one way and some will go the other. For instance, when enqueueing into a fifo, you need an enq signal that goes to the fifo and a full signal that comes back from it, and they're both critical. Do you want to combine them into one thing? We're already going to potentially have an issue with pipelines. Unless the templates are REALLY smart, then the data going into and out of a stage is going to be all in one wide bus, which could be a problem, because there are multiple signals inside it. This needs to be handled well. > > All semantically relevant data will be stored as Verilog code. This is an > > important difference between our case and a GUI editor: the 2D layout of > > the schematic is thrown away for synthesis, while the layout of a GUI is > > one of the most important parts. > > > > > > The layout of the GUI shouldn't be in the verilog code. The code as I > see IT should only be affected when you add a description or when you > modify connections. Done right, no one will want to edit the Verilog code directly except in those cases where you have to manually enter some math. In that case, we'll pop up our own internal editor. I'm reminded of visual basic, where you get the callback for a UI element, and what you get in the editor is just the header and footer of a subroutine. Here, the module header is defined in the UI, and the contents is something you type in. Ultimately, everything has to come out as Verilog code so it can be simulated and synthesized. Some code is purely structural, so no one would ever edit the file. But some of it is interesting content that might get edited outside of our hardware IDE. We need to be sure that we make the metadata unintrusive and non-critical. > You probably should make a "project" file. In that file you could put > all the 2D placements elements of the GUI and also a file list to know > where the different verilog file are. Anyway it's a necessity to have a > file with a list of the verilog code used. Why not used it for other > information that's useful for HIDE? I think Viktor pointed out how storing this separately could result in inconsistencies. Keep in mind that most of this metadata will be restricted to where modules are instantiated, and that's mostly machine-generated code that we'd never directly edit. The only medadata you might find in a leaf node module (one where you've manually entered code) is things like DEFAULT positions of ports, and if you don't add defaults, then they're not in that code. Then you just get plain Verilog code, although the formatting of the header will be standardized. Here's how I might design a project: - Get together with colleagues and brainstorm on structure on a whiteboard. - Figure out the most elementary functions (floating point adders, for instance) and hand-code them. - Use the IDE to wire everything together. Alternatively, we could use the IDE in the first step, where only the high-level modules are put in, and we finalize the general structure. Then we can hand-code low-level stuff (in the IDE or not), and then there's not much left to do but to wire in the low-level stuff. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
