On 3/3/08, Viktor Pracht <[EMAIL PROTECTED]> wrote:
> Timothy Normand Miller wrote:
>
> > We're not doing physical floor-planning here. We're doing high-level
> > Verilog modules. P&R isn't involved. Or do you mean P&R in terms of
> > how the Verilog modules are placed and routed visually in the IDE?
>
>
> I mean the latter. The algorithms will have very much in common with other
> P&R tasks, except that we *want* to stay in a local optimum. One one hand,
> you don't want to align everything manually. On the other hand, you don't
> want your entire schematic to be completely scrambled just because you
> added a single wire. Mirroring the thoughts of the developer is more
> important than having the tightest layout.
For a first run, let's make the placement manual. The routing will
always have to be manual anyhow. The main instance where automatic
would be useful is when we're importing existing code. Then, we want
something half-way sensible on the screen, even though the user will
still have to move things around a bit.
> > Check out NetBeans. Create a simple Swing app. Notice how there are
> > bits of auto-generated code that are hidden by default by the editor
> > but can be expanded to show comments loudly warning about not editing
> > this section of code.
>
>
> NetBeans sucks. Check out JBuilder.
I'll have a look some time. I use NetBeans not because it's it's the
best but because I have invested some time into figuring out how to
use it. If I switch, I'll have to learn another tool. I'm trying to
minimize cognitive load here, which is why I decided to use Java (for
the UI elements) and an IDE in the first place.
> Nothing is hidden and there are no scary warnings anywhere. When you edit
> the size of a widget, the visual editor updates to reflect the change.
I was suggesting that the hiding thing was a benefit. You can always unhide it.
We don't need to get into a debate on the better IDE. Let's just use
an IDE. I'm not very proficient with Java, but Java's GUI system
(Swing, etc.) is very well integrated, and I don't want to screw
around with something else. Since I'm not proficient with Java, I
want an IDE that will let me browse and search the class hierarchy,
show me what methods are available and their parameters, etc.
>
> > We can do the same thing. Some of our stuff is
> > metadata, and when the metadata is missing (for instance from an
> > import of existing code), then we just default to something sensible.
> > Lots of our stuff is auto-generated code that describes the
> > interconnects between modules. The most important part of this, to
> > me, is the interconnecting glue modules that tie other blocks
> > together, because this is the place where I make the most mistakes.
>
>
> 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.
>
> This difference is also the reason why I prefer the single-file approach.
> There will be no Verilog code which the user can't edit. Only the comments
> with the 2D information will need special handling. I hope to reduce that
> special handling to "keep the comment together with the clause it was
> generated for", but otherwise allow any syntactically valid modifications
> of the Verilog code, including adding human-readable comments.
Yeah. Now, this has to be on a per-instance basis. It's not where
the module is defined but where it's instantiated that we need to have
these things. We need something like this:
some_module /* position: X,Y */ instance_name(
.some_port(local_wire) /* position: left,offset */,
...
);
Oh, and positions should be proportional. That is, if you resize an
instance, the port spacing should grow or shrink accordingly.
> If there is a P&R algorithm which can locally optimize a layout, the
> comments only need to encode *which* local optimum to generate. My first
> approach would be to specify a "floor plan", and leave the routing and the
> alignment of blocks to the optimizer. Could this work in real time?
Possibly. I'm starting to think about use cases for this and how some
automatic stuff would be helpful. I want to drop in a module and wire
it up, and I don't want to muck about with fiddly details. For common
templates (like pipeline stages), the ports would default to something
that would generally not require them to be moved.
Plus, it might be cool to have some kind of lego-snap like thing,
where if you bring two modules together in some way, wires
automatically get inserted. So you bring them together, then apart
and position how you like, and you're done. If you want to remove all
the wires, rubber-band select all of them and press Delete.
--
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)
