[Open-graphics] Google summer of code

[André Pouliot]

Viktor Pracht 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.
>   
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?
>   
>> 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.
>
> 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.
>
>   
>> 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.
>
>   
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.
> 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.
>   
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?
> 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?
>
>
> - Viktor Pracht
>