Timothy Normand Miller wrote:
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?
I was more talking at a structural level. The 1 wire I was talking is
more of a line representing that there is a link between 2 modules. In
that line representation there is a list of the signal already connected
and of those that could be connected between the 2 modules. Why I
suggests that is also to diminish the clutter on the workspace. I have
worked with some modules that have more than 50 ports in some case. It
would become a mess to handle multiple wire for the connection between 2
modules.
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.
Do we need to have template to auto generate section of code? Because
for that Mathlab with Sysgen is doing a pretty good job. I was thinking
of something more of structural editor. If someone write a library of
components it could always be used to create a design with only the
graphical interface.
> 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.
I'm more for the approach of someone make the High level design in the
IDE and split everything in small module. People code the modules. The
IDE would be used to wire in modules or create a structures with the
different modules inside and generate the verilog/VHDL for those.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
