[Open-graphics] Google summer of code

[André Pouliot]

Timothy Normand Miller wrote:
> On 3/3/08, André Pouliot <andre.pouliot at gmail.com> 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.