Re: gEDA-user: Design Flow Roadmap starting point
From: al davis <[EMAIL PROTECTED]> Subject: Re: gEDA-user: Design Flow Roadmap starting point Date: Tue, 3 Apr 2007 20:22:34 -0400 Message-ID: <[EMAIL PROTECTED]> > On Tuesday 03 April 2007 19:38, Magnus Danielson wrote: > > From: al davis <[EMAIL PROTECTED]> > > > I was thinking of using the gnucap "CS" parser class, and > > > doing it like everything else in gnucap, as a language > > > plugin. I am guessing that VHDL will be about 50 lines of > > > code, Verilog will be about 50 lines of code, Spice will be > > > about 2000 lines of code, pcb about 100 lines, not sure > > > about gschem. > > > > Need to look at the gnucap parser class stuff. Otherwise I > > agree. > > The line count is a guess. My point is that VHDL and Verilog > are about the same. Spice is the worst one of all. Others are > between. The fact that VHDL and Verilog are so regular makes > the parsers and generators small. The Spice parser and > generator is huge because the language is so irregular. It > seems every component is different. Index finger to thumb measures are fine. :) The point about irregular languages is indeed a good one. > > Certainly, but for a sufficiently complex thing, type > > filtering isn't helping unless you can construct new types > > out of the old and name them as you like. Compound types of > > various sort comes to mind after some time and ka-bang things > > got a bit complex again. Filtering on attribute names is > > probably a better appoach most of the times. > > That is way too complicated. The type is just a name, used to > group things, so they can be filtered as groups. I was talking about type as in integer, real, string, bit etc. Thus the confusion. > Without > changing anything, it is possible to just use a naming > convention and partial matching to select. I am thinking of > groups like simulation parameters, the hidden attributes that > make gschem work, layout stuff, data coming back from a > simulator. The names cannot be determined in advance. Strings > like what we do now for things like spice sources is not the > way to go long term. To store it, it would need to be able to > be encoded as a single string anyway, so it might make sense to > just do that and forget doing anything special. > Thus, the only type you initially intend to support is string. However, many named constants/attributes/generics of the type string is in there. I forsee alot of other side-information that follows along. We might need different architectures depending on which simulator is going to handle things. A simulation model for one form may not have the same names as another etc. You would also like attributes to propagate out of devices, so that we can have for a signal the shortest rise and fall times, which is immensly usefull for SI and EMC work, just to name one. If you take a few steps back, there are more of these things. Cheers, Magnus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
On Tuesday 03 April 2007 19:38, Magnus Danielson wrote: > From: al davis <[EMAIL PROTECTED]> > > I was thinking of using the gnucap "CS" parser class, and > > doing it like everything else in gnucap, as a language > > plugin. I am guessing that VHDL will be about 50 lines of > > code, Verilog will be about 50 lines of code, Spice will be > > about 2000 lines of code, pcb about 100 lines, not sure > > about gschem. > > Need to look at the gnucap parser class stuff. Otherwise I > agree. The line count is a guess. My point is that VHDL and Verilog are about the same. Spice is the worst one of all. Others are between. The fact that VHDL and Verilog are so regular makes the parsers and generators small. The Spice parser and generator is huge because the language is so irregular. It seems every component is different. > Certainly, but for a sufficiently complex thing, type > filtering isn't helping unless you can construct new types > out of the old and name them as you like. Compound types of > various sort comes to mind after some time and ka-bang things > got a bit complex again. Filtering on attribute names is > probably a better appoach most of the times. That is way too complicated. The type is just a name, used to group things, so they can be filtered as groups. Without changing anything, it is possible to just use a naming convention and partial matching to select. I am thinking of groups like simulation parameters, the hidden attributes that make gschem work, layout stuff, data coming back from a simulator. The names cannot be determined in advance. Strings like what we do now for things like spice sources is not the way to go long term. To store it, it would need to be able to be encoded as a single string anyway, so it might make sense to just do that and forget doing anything special. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
From: al davis <[EMAIL PROTECTED]> Subject: Re: gEDA-user: Design Flow Roadmap starting point Date: Tue, 3 Apr 2007 19:08:27 -0400 Message-ID: <[EMAIL PROTECTED]> Al, > All that is needed is the basic framework. It is really simple. > Most of everything is out, but by picking a standard language > there is a pre-determined way to add later if we need it. Certainly. My point with the exercise was to show just how much of VHDL that is not going in. > > What we need is: > > > > Entity declaration (with generics and ports). > > Architecture. > > Instantiation of other entities. > > Assignment of attributes and generics. > > Assignment of signals. > > UREF's could be converted into labels. > > Not even all of that. Maybe not. This was a very quick and coarse subset exercise. What is needed is a somewhat large subset of VHDL than the current gnetlist VHDL backend generates. You can actually take that subset and extend out from that until you have the features you need. I beleive the relevant comments is still there to help guidance through the VHDL LRM. :-) > > This is not complex stuff and it should be fairly easy to > > generate parser and dumper in C or C++, especially if one > > uses PCCTS/ANTLR. > > I was thinking of using the gnucap "CS" parser class, and doing > it like everything else in gnucap, as a language plugin. I am > guessing that VHDL will be about 50 lines of code, Verilog will > be about 50 lines of code, Spice will be about 2000 lines of > code, pcb about 100 lines, not sure about gschem. Need to look at the gnucap parser class stuff. Otherwise I agree. > The idea is a common framework that gets them all. It must be > able to both parse it and generate it. Certainly. However, many formast have their quirks and limits, so in the end you will find that many formats will be hard to fully support. > > > gnetlist has served us well so far, but we have learned a > > > lot by doing it and using it, and it is time to move on. > > > > Indeed. > > There is lot of old stuff like that. That is my opinion of > Spice, too. It has served us well, time to move on. At least > a few of its creators think so too. Certainly. With "modern" things like VHDL and XML you can take a fresh start, gain a little and loose a little. I've never been a fan of XMLizing things for its own sake thought. > > > gschem attributes need to have types. The type is just a > > > string, but important. That way one type can be those > > > passed to a simulator, another can be those passed back > > > from the simulator, etc. Since the type is just a string, > > > new types can be added at any time. An attribute should be > > > able to have multiple types. > > > > Your uses of types confuses me here. > > The idea here is that if attributes have types it is easy to > filter out or select all attributes of a given type. It also > is easy to make translators. Certainly, but for a sufficiently complex thing, type filtering isn't helping unless you can construct new types out of the old and name them as you like. Compound types of various sort comes to mind after some time and ka-bang things got a bit complex again. Filtering on attribute names is probably a better appoach most of the times. Cheers, Magnus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
On Tuesday 03 April 2007 18:36, Magnus Danielson wrote: > You can strip of many things from VHDL which you will not > initially need. What you end up with very quickly is a small > subset which brings much of the properties which gedas > textual format has. It should be fairly easy to do so. > > Hierarchial stuff is trivial. > Attributes is trivial. > > >From this you can then selectively add things from the VHDL > > standard at need. > > What should one cut out or cut down then? > > Design entities and configurations (Section 1) - all but > config (1.3) Subprograms and packages (Section 2) - cut out > Types (Section 3) - cut down considerably > Declarations (Section 4) - cut down > Specifications (Section 5) - most if not all is in > Names (Section 6) - most if not all is in > Expressions (Section 7) - initially all cut out > Sequential statements (Section 8) - initially all cut out > Concurrent statements (Section 9) - all but 9.5 and 9.6 which > however is cut down All that is needed is the basic framework. It is really simple. Most of everything is out, but by picking a standard language there is a pre-determined way to add later if we need it. > > What we need is: > > Entity declaration (with generics and ports). > Architecture. > Instantiation of other entities. > Assignment of attributes and generics. > Assignment of signals. > UREF's could be converted into labels. Not even all of that. > This is not complex stuff and it should be fairly easy to > generate parser and dumper in C or C++, especially if one > uses PCCTS/ANTLR. I was thinking of using the gnucap "CS" parser class, and doing it like everything else in gnucap, as a language plugin. I am guessing that VHDL will be about 50 lines of code, Verilog will be about 50 lines of code, Spice will be about 2000 lines of code, pcb about 100 lines, not sure about gschem. The idea is a common framework that gets them all. It must be able to both parse it and generate it. > > gnetlist has served us well so far, but we have learned a > > lot by doing it and using it, and it is time to move on. > > Indeed. There is lot of old stuff like that. That is my opinion of Spice, too. It has served us well, time to move on. At least a few of its creators think so too. > > gschem attributes need to have types. The type is just a > > string, but important. That way one type can be those > > passed to a simulator, another can be those passed back > > from the simulator, etc. Since the type is just a string, > > new types can be added at any time. An attribute should be > > able to have multiple types. > > Your uses of types confuses me here. The idea here is that if attributes have types it is easy to filter out or select all attributes of a given type. It also is easy to make translators. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
From: al davis <[EMAIL PROTECTED]> Subject: Re: gEDA-user: Design Flow Roadmap starting point Date: Sun, 18 Mar 2007 01:29:07 -0400 Message-ID: <[EMAIL PROTECTED]> Al, (Jumping into the discussion mid-waters) > I still believe we need an interchange file format, that should > be a VHDL derivative. VHDL has most of the capabilities > needed, and is an industry standard. If something is missing, > we can add it, and propose it back to the standards committee. > They might even welcome it. I think that VHDL is a very good boiler-plate. This approach was used for Boundary Scan files. You can strip of many things from VHDL which you will not initially need. What you end up with very quickly is a small subset which brings much of the properties which gedas textual format has. It should be fairly easy to do so. Hierarchial stuff is trivial. Attributes is trivial. >From this you can then selectively add things from the VHDL standard at need. What should one cut out or cut down then? Design entities and configurations (Section 1) - all but config (1.3) Subprograms and packages (Section 2) - cut out Types (Section 3) - cut down considerably Declarations (Section 4) - cut down Specifications (Section 5) - most if not all is in Names (Section 6) - most if not all is in Expressions (Section 7) - initially all cut out Sequential statements (Section 8) - initially all cut out Concurrent statements (Section 9) - all but 9.5 and 9.6 which however is cut down This is just a swift walk-through of the VHDL standard (using the VHDL-93 that was lying on my desk anyway). Whatever is needed to support AMS infra- structure (i.e. analog signals), which should not be very much. What we need is: Entity declaration (with generics and ports). Architecture. Instantiation of other entities. Assignment of attributes and generics. Assignment of signals. UREF's could be converted into labels. This is not complex stuff and it should be fairly easy to generate parser and dumper in C or C++, especially if one uses PCCTS/ANTLR. Writing up a VHDL equalent format for the geda netlist format should not be too hard. If you want to go beyond the geda netlist format constrains of today, it is fairly easy to do. The one thing which I am not up to date on is how modern character sets is handled etc. > gnetlist really needs to be redone, from the ground up. This > VHDL based intermediate format is the way to do it. > > gnetlist has served us well so far, but we have learned a lot by > doing it and using it, and it is time to move on. Indeed. > > * Similarly, how should gnetlist behave? A use-case list > > would be useful. > > Any extraction should preserve hierarchy, in hopes that the > target tool also benefits from it. If it doesn't, you need a > separate flattener pass, separate from the translation. In a gnetlist rewrite, a flattener could be written and called for those backends that need it. In the other direction, naming conventions may alow for de-flatenations in some cases, so support for that may also be considered. > Regardless, the translation must be 100%, lossless, in both > directions. Indeed. > gschem attributes need to have types. The type is just a > string, but important. That way one type can be those passed > to a simulator, another can be those passed back from the > simulator, etc. Since the type is just a string, new types can > be added at any time. An attribute should be able to have > multiple types. Your uses of types confuses me here. In a future, it is not necessarilly only strings, but it is a good first assumption. > > > * Finally, how should PCB behave with a hierarchical > > schematic? > > Right click on a symbol, select "go inside", and another drawing > opens up showing what's inside. gschem also should act this > way. Indeed. Cheers, Magnus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
> Since it is LISP-ish it seems closest to a common file format language with > gschem, which uses guile. Are there rumors of > planning to stop using guile? > For the current gEDA/gaf: no. -Ales ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
Dan McMahill wrote: how should PCB behave with a hierarchical schematic? by default for each cell to be an entity that you can grab and move around. The ability to visually toggle all hierarchical instances between the contents and a box is fairly useful. [jg]As in Cadence. To save on redraw time for big designs. If you want to edit the contents, you have to descend into the block to edit it. [jg] Some have hinted they want to create unnamed versions on the fly by doing this, but I like to keep the main reuse-identical-cells value at front and have the editing affect all placements of that same named cell. If I want to make a separate version of a layout instance, I have to save as some-new-name to get it. You almost certainly want a mode where when you descend you only see that block in its zero rotation as well as an edit in place mode where you edit the block while all the rest of the board is visible. I'm saying this based on having done quite a bit of hierarchical layout in the ic world. Haven't done it in the board world although I've wished for it a few times. [jg]And I think when organic printable semiconductors become more real, we will be wanting the IC layout style more and more. Our IC's will just be organic and naked-eye-visible is all... I'll add the visual toggle concept to the wiki, along with zero-rotation-as-in-the-orginal on edit by default. http://geda.seul.org/wiki/geda:design_flow_and_hierarchy_roadmap The other ideas Igor and DJ already asked for. And I second all those motions. John Griessen ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
al davis wrote: * Finally, how should PCB behave with a hierarchical schematic? Right click on a symbol, select "go inside", and another drawing opens up showing what's inside. gschem also should act this way. I think what you want is by default for each cell to be an entity that you can grab and move around. The ability to visually toggle all hierarchical instances between the contents and a box is fairly useful. If you want to edit the contents, you have to descend into the block to edit it. You almost certainly want a mode where when you descend you only see that block in its zero rotation as well as an edit in place mode where you edit the block while all the rest of the board is visible. I'm saying this based on having done quite a bit of hierarchical layout in the ic world. Haven't done it in the board world although I've wished for it a few times. -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
Igor2 wrote: On Sun, 18 Mar 2007, al davis wrote: * Finally, how should PCB behave with a hierarchical schematic? Right click on a symbol, select "go inside", and another drawing opens up showing what's inside. gschem also should act this way. I like this idea very much. In case of PCB it also would make sense to add a way to display in place what's inside. With an "expand all" functionality this would allow one to see the whole pcb with all inner structures at once, without needing to export to ps. The ability to "look inside" or "expand all" is a feature that is standard for IC layout editors. Years ago I used a PC board editor that evolved from an IC layout tool and it had this behavior. In particular, you could create sub-blocks of circuitry that might represent individual "devices" (or elements in PCB parlance) or more complex blocks that you might want to repeat. You could add these to your layout (with up to 256 levels of nesting). You could turn on/off the visibility or "editability" of any device at a lower or higher level of nesting than the one you were currently working in. When "editing down" to a lower level device it would leave all the surrounding features (the "context") visible so you see what you were doing. Other copies of the current block could be immediately displayed with the changes you just made. Needless to say, this implementation of heirarchy allowed for some very complex designs and much easier re-use than we have now. Joe T ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
> Couldn't resource file be used with the plugin mode of programming
> to extend function? Since it is LISP-ish it seems closest to a
> common file format language with gschem, which uses guile. Are
> there rumors of planning to stop using guile?
The resource file is purely data. Its primary benefits are that its
syntax is independent of its content, and the values are all strings.
Hence, you can put pretty much any data in it, and pcb can parse it.
Here's a copy of pcb-menu.res:
# -*- c -*-
# Note - pcb-menu.res is used to build pcb-menu.h
# Note - parameters are sensitive to extra spaces around the commas
Mouse =
{
Left = {
Mode(Notify)
up = Mode(Release)
}
Right = {
{ Mode(Save) Mode(Rotate) Mode(Notify) Mode(Release) Mode(Restore) }
}
Middle = {
Pan(1)
up = Pan(0)
ctrl = Pan(thumb,1)
ctrl-up = Pan(thumb,0)
}
Up = Zoom(0.8)
Down = Zoom(1.25)
# If you want zoom to center, do this instead.
#Up = { {Zoom(0.8) Center()} }
#Down = { {Zoom(1.25) Center()} }
}
MainMenu =
{
{File
{"About..." About()}
{"Save layout" Save(Layout)}
{"Save layout as..." Save(LayoutAs)}
{"Revert" Load(Revert,none)}
{"Load layout" Load(Layout)}
{"Load element data to paste-buffer" PasteBuffer(Clear)
Load(ElementTobuffer)}
{"Load layout data to paste-buffer" PasteBuffer(Clear) Load(LayoutTobuffer)}
{"Load netlist file" Load(Netlist)}
{"Load vendor resource file" LoadVendor()}
{"Print layout..." Print()}
{"Export layout..." Export()}
{"Calibrate Printer..." PrintCalibrate()}
-
{"Save connection data of..." foreground=grey50 sensitive=false}
{" a single element" GetXY(press a button at the element location)
Save(ElementConnections)}
{" all elements" Save(AllConnections)}
{" unused pins" Save(AllUnusedPins)}
-
{"Start new layout" New()}
-
{"Quit Program" Quit() m=Q a={"Ctrl-Q" "Ctrlq"}}
}
{View
{"Flip up/down" checked=flip_y SwapSides(V) a={"Tab" "Tab"}}
{"Flip left/right" checked=flip_x SwapSides(H) a={"Shift-Tab"
"ShiftTab"}}
{"Spin 180°" SwapSides(R) a={"Ctrl-Tab" "CtrlTab"}}
{"Swap Sides" SwapSides() a={"Ctrl-Shift-Tab" "Ctrl ShiftTab"}}
{"Center cursor" Center() a={"C" "c"}}
{"Show soldermask" checked=showmask Display(ToggleMask)}
-
{"Displayed element-name..." foreground=grey50 sensitive=false}
{"Description" Display(Description) checked=elementname,1}
{"Reference Designator" Display(NameOnPCB) checked=elementname,2}
{"Value" Display(Value) checked=elementname,3}
{"Lock Names" checked=locknames Display(ToggleLockNames)}
{"Only Names" checked=onlynames Display(ToggleOnlyNames)}
-
{"Pinout shows number" checked=shownumber Display(ToggleName)}
{"Open pinout menu" Display(Pinout) a={"Shift-D" "Shiftd"}}
-
{Zoom
{"Zoom In 2X" Zoom(-2)}
{"Zoom In 20%" Zoom(-1.2) m=Z a={"Z" "z"}}
{"Zoom Out 20%" Zoom(+1.2) m=O a={"Shift-Z" "Shiftz"}}
# If you want zoom to center, do this instead.
#{"Zoom In 20%" Zoom(-1.2) Center() m=Z a={"Z" "z"}}
#{"Zoom Out 20%" Zoom(+1.2) Center() m=O a={"Shift-Z" "Shiftz"}}
{"Zoom Out 2X" Zoom(+2)}
{"Zoom Max" Zoom() m=M a={"V" "v"}}
-
{"Zoom to 0.1mil/px" Zoom(=10)}
{"Zoom to 0.01mm/px" Zoom(=39.37)}
{"Zoom to 1mil/px" Zoom(=100)}
{"Zoom to 0.05mm/px" Zoom(=196.8504)}
{"Zoom to 2.5mil/px" Zoom(=250)}
{"Zoom to 0.1mm/px" Zoom(=393.7)}
{"Zoom to 10mil/px" Zoom(=1000)}
}
{Grid
{"mils" checked=grid_units_mm,0 SetUnits(mil)}
{"mms" checked=grid_units_mm,1 SetUnits(mm)}
{"Display grid" checked=drawgrid Display(Grid)}
{"Realign grid" GetXY(Press a button at a grid point) Display(ToggleGrid)}
{"No Grid" checked=gridsize,1 SetValue(Grid,1)}
-
{ "0.1 mil" checked=gridsize,10 SetUnits(mil) SetValue(Grid,10)}
{ "1 mil" checked=gridsize,100 SetUnits(mil) SetValue(Grid,100)}
{ "5 mil" checked=gridsize,500 SetUnits(mil) SetValue(Grid,500)}
{ "10 mil" checked=gridsize,1000 SetUnits(mil) SetValue(Grid,1000)}
{ "25 mil" checked=gridsize,2500 SetUnits(mil) SetValue(Grid,2500)}
{"100 mil" checked=gridsize,1 SetUnits(mil) SetValue(Grid,1)}
-
{"0.01 mm" checked=gridsize,39 SetUnits(mm) SetValue(Grid,39.37007874)}
{"0.05 mm" checked=gridsize,197 SetUnits(mm) SetValue(Grid,196.85039370)}
{"0.1 mm" checked=gridsize,394 SetUnits(mm) SetValue(Grid,393.70078740)}
{"0.25 mm" checked=gridsize,984 SetUnits(mm) SetValue(Grid,984.25197)}
{"0.5 mm" checked=gridsize,1969 SetUnits(mm) SetValue(Grid,1968.503937)}
{"1 mm"checked=gridsize,3937 SetUnits(mm) SetValue(Grid,3937.00787400)}
-
{"Grid -5mil" SetValue(Grid,-5,mil) a={"Shift-G" "Shiftg"}}
{"Grid +5mil" SetValue(Grid,+5,mil) a={"G" "g"}}
{"Grid -0.05mm" SetValue(Grid,-0.05,mm) a={"Shift-Ctrl-G" "Shift
Ctrlg"}}
{"Grid +0.05mm" SetValue(Grid,+0.05,mm) a={"Ctrl-G" "Ctrlg"}}
}
-
{"Shown Layers"
@layerview
-
Re: gEDA-user: Design Flow Roadmap starting point
DJ Delorie wrote: [Al Davis]>> Design the file format first, then the data structures. The file format should be designed as a language for expressing what you want to express. PCB has a second format it uses called a "resource file". It's a semi-lisp-ish format that allows for arbitrarily nested data, without the complexities of XML (the whole parser is about a page of code). It could be used to hold pretty much anything, but it isn't "designed for the data". Couldn't resource file be used with the plugin mode of programming to extend function? Since it is LISP-ish it seems closest to a common file format language with gschem, which uses guile. Are there rumors of planning to stop using guile? John G PS more condensing and grouping of these ideas done at the wiki. http://geda.seul.org/wiki/geda:design_flow_and_hierarchy_roadmap ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
I corrected the documentation and added the TO220 pads example to the Examples section. Great. Thanks. :) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
On 3/19/07, C P Tarun <[EMAIL PROTECTED]> wrote: > A script to place TO220 pads can be pretty simple (see below). The > poorly named routine element_add_pin_oval overlays a pin, a rounded pad > on the component side and a rounded pad on the solder side. I have been reading your (excellently-formatted reference-class) documentation on your library. The documentation does not mention that add_pin_oval adds two pads on two layers... it seems to say that this is a "hybrid object consisting of a pad and a pin with the same centre point." Is the document out of sync with the library? I corrected the documentation and added the TO220 pads example to the Examples section. (* jcl *) -- http://www.luciani.org ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
On 3/19/07, C P Tarun <[EMAIL PROTECTED]> wrote: > A script to place TO220 pads can be pretty simple (see below). The > poorly named routine element_add_pin_oval overlays a pin, a rounded pad > on the component side and a rounded pad on the solder side. I have been reading your (excellently-formatted reference-class) documentation on your library. The documentation does not mention that add_pin_oval adds two pads on two layers... it seems to say that this is a "hybrid object consisting of a pad and a pin with the same centre point." Is the document out of sync with the library? It is out of sync. I corrected the mistake in the procedure and forgot to update the documentation. Thanks for the report. (* jcl *) -- http://www.luciani.org ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
A script to place TO220 pads can be pretty simple (see below). The poorly named routine element_add_pin_oval overlays a pin, a rounded pad on the component side and a rounded pad on the solder side. I have been reading your (excellently-formatted reference-class) documentation on your library. The documentation does not mention that add_pin_oval adds two pads on two layers... it seems to say that this is a "hybrid object consisting of a pad and a pin with the same centre point." Is the document out of sync with the library? Tarun ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
Very interesting. What's Pcb_8? Where do I find it? I'm looking through your Website to see if there's some Perl module there. Found Pcb_8 in your Perl library documentation. Thanks. Tarun ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
A script to place TO220 pads can be pretty simple (see below). The poorly named routine element_add_pin_oval overlays a pin, a rounded pad on the component side and a rounded pad on the solder side. Very interesting. What's Pcb_8? Where do I find it? I'm looking through your Website to see if there's some Perl module there. Tarun ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
On 3/18/07, C P Tarun <[EMAIL PROTECTED]> wrote:
> You may want to try one of the many footprint scripts that are around.
> Making the footprints in a batch using a script is a lot less error prone
> than one by one in the GUI.
>
> If you are looking for DIPs or SIP headers with rounded pads over pins
> you could try my website.
Actually I've seen some of those scripts and they are lovely for the kind
of things they do. But I need to build much simpler footprints like TO220
devices, but with elongated pads. These are best done by hand, I guess.
I even like TO92 to have elongated pads. I suspect I'm just unsure of my
soldering skills and like larger pads, that's all. :)
A script to place TO220 pads can be pretty simple (see below). The
poorly named routine element_add_pin_oval overlays a pin, a rounded pad
on the component side and a rounded pad on the solder side.
Adding a simple silkscreen would be one or two more lines of code.
(* jcl *)
use strict;
use warnings;
use Pcb_8;
my $Pcb = Pcb_8 -> new(debug => 1);
$Pcb -> element_begin(description => 'TH',
output_file =>
"tmp/" . 'TO220',
dim => 'mils');
my $pin_num = 1;
my @pos = (-100, 0, 0, 0, 100, 0);
while (@pos) {
my ($x, $y) = splice @pos, 0, 2;
$Pcb -> element_add_pin_oval(x => $x,
y => $y,
width => 80,
length => 66,
name => '',
pin_number => $pin_num++,
clearance => 10,
drill_hole => 46,
mask => 10);
}
$Pcb -> element_output();
--
http://www.luciani.org
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
You may want to try one of the many footprint scripts that are around. Making the footprints in a batch using a script is a lot less error prone than one by one in the GUI. If you are looking for DIPs or SIP headers with rounded pads over pins you could try my website. Actually I've seen some of those scripts and they are lovely for the kind of things they do. But I need to build much simpler footprints like TO220 devices, but with elongated pads. These are best done by hand, I guess. I even like TO92 to have elongated pads. I suspect I'm just unsure of my soldering skills and like larger pads, that's all. :) One area where I'll be developing scripts is for simple capacitors. I want pretty-looking non-polar and cylindrical electrolytic caps of various sizes. (No elongated pads needed.) Resistors I've already done by hand. Tarun ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
On 3/18/07, C P Tarun <[EMAIL PROTECTED]> wrote: > > 3. There should be native support for elongated vias (they > > are called "pads" in Eagle) when defining an element. > > The way to do this in pcb is to put a pin and a pad in the same place. > The pin gives you the drill hole, and the pad defines the elongated > copper shape. Yes, I've tried this with my footprints. The problem is that you need two pads (for a traditional double-layer footprint) and you need to edit the text file of the element to set the numbering of the pads. (Can I set the pad number through the GUI of PCB the way I can for the pin number by pressing 'n'?) This approach is error-prone, I felt. When I open up the text file of the element, I see a list of pads but I don't know which two pads are associated with pin 1, and so on. You may want to try one of the many footprint scripts that are around. Making the footprints in a batch using a script is a lot less error prone than one by one in the GUI. If you are looking for DIPs or SIP headers with rounded pads over pins you could try my website. (* jcl *) -- http://www.luciani.org ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
> 3. There should be native support for elongated vias (they > are called "pads" in Eagle) when defining an element. The way to do this in pcb is to put a pin and a pad in the same place. The pin gives you the drill hole, and the pad defines the elongated copper shape. Yes, I've tried this with my footprints. The problem is that you need two pads (for a traditional double-layer footprint) and you need to edit the text file of the element to set the numbering of the pads. (Can I set the pad number through the GUI of PCB the way I can for the pin number by pressing 'n'?) This approach is error-prone, I felt. When I open up the text file of the element, I see a list of pads but I don't know which two pads are associated with pin 1, and so on. It's not heated, it's just nobody has had the time to do it right, yet. For example, a true "multipin" (my name) would need to know more about the physical layer stack than pcb currently knows. But I do envision a "multipin" having the ability to independently specify: * top, inner, and bottom shapes * copper shapes, including hole-to-edge distance and radius of each corner * pads defined by polygons * copper, paste, and mask each independently defined The current plan is to defer this until after the "layer type flags" project is done, as that project gives us proper mask, paste, etc layers. Yes, I've been reading some of the discussions about the "multipin" and the layer-type projects, and I got the sense that these would make a lot of the work easier for elongated pads. I think it's a good idea to do it in the sequence you intend. Will make the implementation a whole lot cleaner and more powerful internally. Tarun -- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
> 3. There should be native support for elongated vias (they > are called "pads" in Eagle) when defining an element. The way to do this in pcb is to put a pin and a pad in the same place. The pin gives you the drill hole, and the pad defines the elongated copper shape. > I suspect that I am unaware of the heated arguments some of > these issues must've seen in the period before I joined the list, > in which case please excuse my raking them up again. :) It's not heated, it's just nobody has had the time to do it right, yet. For example, a true "multipin" (my name) would need to know more about the physical layer stack than pcb currently knows. But I do envision a "multipin" having the ability to independently specify: * top, inner, and bottom shapes * copper shapes, including hole-to-edge distance and radius of each corner * pads defined by polygons * copper, paste, and mask each independently defined The current plan is to defer this until after the "layer type flags" project is done, as that project gives us proper mask, paste, etc layers. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
> I assume that's the reason for PCB, too. No, pcb's plugins are very tightly coupled to the internal data structures. The reason I added pcb's plugins was to let people define their own actions without the cvs-build-merge issues, not as a generic way to allow for future expansion. > You have the order backwards. Design the file format first, > then the data structures. The file format should be designed > as a language for expressing what you want to express. PCB has a second format it uses called a "resource file". It's a semi-lisp-ish format that allows for arbitrarily nested data, without the complexities of XML (the whole parser is about a page of code). It could be used to hold pretty much anything, but it isn't "designed for the data". > > * Finally, how should PCB behave with a hierarchical > > schematic? > > Right click on a symbol, select "go inside", and another drawing > opens up showing what's inside. gschem also should act this > way. I think pcb "blocks" should be translucent. You should have some idea of the physical contents of a block even when you're not editing it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
Another point: I thought it would be useful to have more control over the different attributes which get printed or exported in Gerber plots. I really like the way Eagle breaks all attributes into layers, and then allows me to define a "CAM job" to generate, say, the silkscreen layer. While defining the CAM job, I select whether I want to print the "tnames" layer (in which case the names of the components will be included), or the "tvalues" layer (in which case the values of the components will be included) and so on. In PCB, I can't choose to print just the component outlines and leave out their names in the silk screen layer. I also (IIRC) can't choose to include the values in the silk screen. The default that PCB gives me is useful for most of the cases, but it would be good if this was not hard-coded. Tarun -- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
I am a beginner, and I have a lot of exposure to Eagle, so please
keep these limitations/biases in mind.
I would really like to see the following additions:
1. In gschem, when selecting a footprint, I would like to see the
footprint _and_ its description in a popup window. I should be
able to browse the footprint library _visually_, basically.
2. In PCB, when I create a "Convert buffer contents into an
element", it should ask me for a description of the element.
This should get embedded in the description field in the
element header line.
3. There should be native support for elongated vias (they
are called "pads" in Eagle) when defining an element.
Since pin addition while creating a footprint in PCB is
done by adding a via, maybe this elongated shape should
be added as an option to the via itself, like you can flip
between circular and octagonal. And then of course one
would need the ability to rotate a via, so that the elongated
shape could be aligned the way I want.
The current method to define elongated pads ("pins" in PCB
element terminology) is really roundabout, and error-prone,
and needs manual editing of the element file in a text editor,
if I understand correctly. You have to define (at least) two
pads manually, one for the solder layer, one for the component
layer, and make sure they both match the pin/via in diameter
and centering, and then manually edit the element file to
make the pad numbers match the pin number. I feel elongated
pads is a sufficiently universally used feature to require native
support in the software.
I suspect that I am unaware of the heated arguments some of
these issues must've seen in the period before I joined the list,
in which case please excuse my raking them up again. :)
BTW, I like the way PCB has unified the concepts of pads for
element footprints, vias, and holes. Good engineering design,
I thought. :)
Tarun
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
On Sun, 18 Mar 2007, al davis wrote: >> * Finally, how should PCB behave with a hierarchical >> schematic? > >Right click on a symbol, select "go inside", and another drawing >opens up showing what's inside. gschem also should act this >way. I like this idea very much. In case of PCB it also would make sense to add a way to display in place what's inside. With an "expand all" functionality this would allow one to see the whole pcb with all inner structures at once, without needing to export to ps. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
On Saturday 17 March 2007 00:13, John Griessen wrote: > David Baird wrote: (about data tie ins to higher > abstractions than "just boards")jg I've been thinking (maybe > just dreaming?) about an extensible system which allows the > representation of information which has not yet even been > envisioned, while also providing forwards and backwards > compatibility as new component representations are devised. > For these reasons, OWL struck me somewhat and now I am > learning OWL and trying to see if I can really make it do > what I want. -- A simple example -- convey to a PCB > program that a set of nets are actually grouped That's why gnucap is using plugins now. I assume that's the reason for PCB, too. I think gnucap's approach is more aggressive, in the sense that everything is moving to plugins, making the system completely user configurable. > Stuart Brorson wrote: >The discussion about hierarchy should focus on the > following points: > > * What kind of data structures are desirable? How would > they look? Right now, the main data structure for a schematic > is a linear linked list of graphical objects (for each > schematic page). Some list items point to others (i.e. to > support component attributes). How would that change to > support hierarchy? > > * ONce a datastructure is decided upon, then what does the > file format look like? Note that our current file format > maps fairly closely onto the internal data structures. > Preserving this close mapping is a desirable goal. > Therefore, the data structures defining hierarchy should > more-or-less dictate what the file format should look like. You have the order backwards. Design the file format first, then the data structures. The file format should be designed as a language for expressing what you want to express. If the thing being expressed is a printed circuit board, the language should be meaningful and expressive in that context. If the data structures are already designed, I still say design the file format "first" in the sense that it should ignore the data structures. Fitting the file format to the data structures permanently locks you to the mistakes of the first cut. Designing the file format description language first leaves you free to change the underlying algorithms and data structures later. File formats that are data structure dumps cause big problems in the long run. I still believe we need an interchange file format, that should be a VHDL derivative. VHDL has most of the capabilities needed, and is an industry standard. If something is missing, we can add it, and propose it back to the standards committee. They might even welcome it. gnetlist really needs to be redone, from the ground up. This VHDL based intermediate format is the way to do it. gnetlist has served us well so far, but we have learned a lot by doing it and using it, and it is time to move on. > * How should gschem behave once hierarchy is architected in? > Right now you attach a source= attribute to a symbol. Then > you do "schematic down" on that symbol to dive into the > sub-schematic. Is that OK? Or what's a better scheme? > > And how to handle re-use blocks? That is, if I have a > sub-schematic which I instantiate four times, how should it > be refdesed in the netlist? If I dive into one of the four > instantiations and edit it, is it OK that the other three > instantiations are also updated. > > A list of use-cases would be helpful here. > > * Similarly, how should gnetlist behave? A use-case list > would be useful. Any extraction should preserve hierarchy, in hopes that the target tool also benefits from it. If it doesn't, you need a separate flattener pass, separate from the translation. Regardless, the translation must be 100%, lossless, in both directions. gschem attributes need to have types. The type is just a string, but important. That way one type can be those passed to a simulator, another can be those passed back from the simulator, etc. Since the type is just a string, new types can be added at any time. An attribute should be able to have multiple types. > * Finally, how should PCB behave with a hierarchical > schematic? Right click on a symbol, select "go inside", and another drawing opens up showing what's inside. gschem also should act this way. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
My imediate use for recessing has to do with ridged flex riged boards. In one example we have a circuit board that has for example a ridged section on the right that has a connector, this section has to have one level of thickness. connected to this ridged is a section of flex, on the other side of the section of flex these is a section of ridged material that has a flip chip a resistor and a few capacitors. This second ridged section has a different thickness then the first. It is thinner and we achieve this by having few layers. Continuing on we have another section of flex and then a final section of ridged. This last section of ridged has yet a third thickness then the other two ridged sections. All of this is constructed in layers that are glued and pressed together. So we cut out different holes out of the different layers before aligning them and gluing them and pressing them. Problem is that the pads have to be on different layers. We over came this by pretending at layout that they were different boards and getting the shop to merge the gerbers. I think there is a second reason, (note the i think) in that some very high frequency devices have pins that stick streight out their sides so as to avoid bends. But that these devices also would like to be heat sinked to the ground plane. This is again an I think and I am looking for an example. Steve M. DJ Delorie wrote: >> Yes fab shops can cnc the layers before gluing and pressing them >> together. >> > > Drool. Yeah, you'd need the "layer types" patch to really manage > that, as you'd be able to tag multiple pcb layers as "outline" layers > and associate them with specific board layers or whatnot. > > You could do it now, except that they'd have all the pins' copper on > them as well as the outline. > > The only thing you can't do already is tell pcb to put elements on > inner layers. > > Of course, I'm curious *why* you need to recess parts... > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
> One practical solution for very small parts is to hid the refdes on the > board but make a large assembly drawing that has them. That's almost what I did. I make the refdes's as big as the parts, right on top of them, and printed them out as an assembly drawing. I just didn't put them on a silkscreen. This was about the time I added the lock-text and only-text settings ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
One practical solution for very small parts is to hid the refdes on the board but make a large assembly drawing that has them. Steve Meier DJ Delorie wrote: >> S2/S2/L1 S2/S2/C1 and S2/S2/U1 >> >> is the RenumberBlock funtion capable of this? >> > > It currently pulls the last string of digits (suffix) off for > renumbering, but pulling the first string shouldn't be too hard. It > doesn't give you automatic updating, though. If you edit the master > block, you'd cut out the copies, and re-copy/renumber the master block > to make new copies. > > We could script this if we had an action to select a region, but it > would certainly be better if it "just knew" about such blocks. > > >> Because when you use those virtual 01005 capcitors there isn't a lot >> of room for a readable refdes as it is >> > > Too true. I didn't even bother with a silkscreen on the furnace > board, and that's only 0603s. > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
On Fri, 16 Mar 2007, John Griessen wrote: >John Griessen wrote: >> So, "What do you want? > Please add this to the list: [PCB] an interface for presenting dynamic dialog boxes for importers and wizards similar to the exporters. This would help some plugins to integrate better in the GUI. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
> S2/S2/L1 S2/S2/C1 and S2/S2/U1 > > is the RenumberBlock funtion capable of this? It currently pulls the last string of digits (suffix) off for renumbering, but pulling the first string shouldn't be too hard. It doesn't give you automatic updating, though. If you edit the master block, you'd cut out the copies, and re-copy/renumber the master block to make new copies. We could script this if we had an action to select a region, but it would certainly be better if it "just knew" about such blocks. > Because when you use those virtual 01005 capcitors there isn't a lot > of room for a readable refdes as it is Too true. I didn't even bother with a silkscreen on the furnace board, and that's only 0603s. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
DJ Delorie wrote: >> From PCB, I would like to seperate the hierarchy from the rest of >> the refdes. I would like to be able to layout a hierarchical >> section. I would like to be able to save that section as a seperate >> collection. I would like to be able to paste a copy of that section >> into a larger pcb layout and only have to change the top of >> hierarchy string to correctly interact with the netlist. >> > > PCB doesn't care what the refdes is, a heirarchical one is just as > valid as a common one. I have a RenumberBlock() action that's > designed to make it easier to have repetetive blocks on a board, but I > think you want something more automatic, like the way element data is > grouped as an element. For example, have a block on the board that is > a modular entity. Normally, you can't do anything but move it around > as a whole. A special action "opens" this block (and hides everything > else) so you can edit it. When you're done, it's closed again - and > any copies of the block are automatically updated in place. > > The usual buffer to/from file mechanism should be sufficient > (gui-wise) for saving blocks as files. > > Have you tried using Xfig's group/ungroup/editgroup mechanism? > > > An example of what I was thinking is If I have the following hierarchical refdess S1/S2/L1 and S1/S2/C1 and S1/S2/U1 The hierarchy is S1/S2 the non hierarchy refdes are L1, C1 and U1 I would like to replicate this block and just have to edit once the hierarchy to S2/S2 giving the full hierarchy + refdes to be S2/S2/L1 S2/S2/C1 and S2/S2/U1 is the RenumberBlock funtion capable of this? Plus I would like to be able to say to that block Don't display the hierarchy in the silkscreen. Because when you use those virtual 01005 capcitors there isn't a lot of room for a readable refdes as it is ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
> Yes fab shops can cnc the layers before gluing and pressing them > together. Drool. Yeah, you'd need the "layer types" patch to really manage that, as you'd be able to tag multiple pcb layers as "outline" layers and associate them with specific board layers or whatnot. You could do it now, except that they'd have all the pins' copper on them as well as the outline. The only thing you can't do already is tell pcb to put elements on inner layers. Of course, I'm curious *why* you need to recess parts... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
>> While I am at it. PCB should be able to do hidden vias, buried vias >> and micro vias... >> > > If we can get the "layer types" project done (this is listed as the > non-copper layers project in SoC), we'll be able to have a concept of > a "layer stack" (unless we just assume the physical stack matches the > GUI layer layout). > > The next project after that is what I call a "multi-pin", which is a > standard pin, but with a much more intense copper description, one for > each layer, with drill depth parameters et al. That would include > blind and buried vias. Microvias is just a drill size after that, > unless you need them called out in a different .cnc file > > No a micro via should be the same in the the cnc file. The PCB fab shop will deside how to drill the hole. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
DJ Delorie wrote: > > >> Did I mention the ability to cut out areas of >> layers such that I can resese components into lower layers? >> > > Assuming you know a fab that can mill layers before assembling > them... is that what you're talking about? That would mean having > elements and pads on layers other than the outer two, yes? > > Yes fab shops can cnc the layers before gluing and pressing them together. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
> From PCB, I would like to seperate the hierarchy from the rest of > the refdes. I would like to be able to layout a hierarchical > section. I would like to be able to save that section as a seperate > collection. I would like to be able to paste a copy of that section > into a larger pcb layout and only have to change the top of > hierarchy string to correctly interact with the netlist. PCB doesn't care what the refdes is, a heirarchical one is just as valid as a common one. I have a RenumberBlock() action that's designed to make it easier to have repetetive blocks on a board, but I think you want something more automatic, like the way element data is grouped as an element. For example, have a block on the board that is a modular entity. Normally, you can't do anything but move it around as a whole. A special action "opens" this block (and hides everything else) so you can edit it. When you're done, it's closed again - and any copies of the block are automatically updated in place. The usual buffer to/from file mechanism should be sufficient (gui-wise) for saving blocks as files. Have you tried using Xfig's group/ungroup/editgroup mechanism? > I would like to be able in the netlist to tell pcb which slots are > swapable, which i/o pins are swapable and which pin pairs can > function as differential pairs (these last two have to be able to be > limited to specific banks) such that pcb could correctly change the > net list itself. Then I would like PCB to be able to tell me what > pins and in what order the pins were swapped so that this could be > imported back into the original design. This is the usual back-annotation request, for starters. If we can propogate the slotting information to pcb, perhaps we can figure out a GUI to swap them. > While I am at it. PCB should be able to do hidden vias, buried vias > and micro vias... If we can get the "layer types" project done (this is listed as the non-copper layers project in SoC), we'll be able to have a concept of a "layer stack" (unless we just assume the physical stack matches the GUI layer layout). The next project after that is what I call a "multi-pin", which is a standard pin, but with a much more intense copper description, one for each layer, with drill depth parameters et al. That would include blind and buried vias. Microvias is just a drill size after that, unless you need them called out in a different .cnc file. > Did I mention the ability to cut out areas of > layers such that I can resese components into lower layers? Assuming you know a fab that can mill layers before assembling them... is that what you're talking about? That would mean having elements and pads on layers other than the outer two, yes? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
>From PCB, I would like to seperate the hierarchy from the rest of the refdes. I would like to be able to layout a hierarchical section. I would like to be able to save that section as a seperate collection. I would like to be able to paste a copy of that section into a larger pcb layout and only have to change the top of hierarchy string to correctly interact with the netlist. I would like to be able in the netlist to tell pcb which slots are swapable, which i/o pins are swapable and which pin pairs can function as differential pairs (these last two have to be able to be limited to specific banks) such that pcb could correctly change the net list itself. Then I would like PCB to be able to tell me what pins and in what order the pins were swapped so that this could be imported back into the original design. While I am at it. PCB should be able to do hidden vias, buried vias and micro vias... Did I mention the ability to cut out areas of layers such that I can resese components into lower layers? Finaly I could use all of these by, . say next Tuesday. "I'd gladly pay you Tuesday for a hamberger today" Thanks, Steve M. John Griessen wrote: > John Griessen wrote: >> So, "What do you want? > > The gschem gnetlist PCB gsch2pcb gattrib gerbv wants mentioned > recently and needing discussion are: > > Steve Meier: > 1) hierarchical data and file structures (xml or other) > 2) an integrated hierarchical netlister > 3) use of a better supported scripting language > 4) a method of dynamically partioning devices into meaningfull symbols > 5) a method of communicating between the schematic design and the layout > program on issues of slot swapping, i/o pin swapping, differential i/o > pin swapping, bank swapping > 6) strong drc > > > My plan for dealing with long refdes names e.g.S1/S2/S3/U3 is to hide > > the refdes and create a large box on the silkscreen which is labled S1. > > Then inside the S1 Box, a smaller box on the silcrean labled S2 and > > inside ths S2 box an even smaller box labled S3. The device inside the > > S3 box will have a silk screened comment near it that states U3. > > Svenn Are Bjerkem wrote: (about geda installer)jg > For real day-to-day work the engineer should be > able to decide himself what tool he wants to use > it should be enough to > run a command to have it installed. > > On 3/4/07, Dan McMahill <[EMAIL PROTECTED]> wrote:(about > multiple flows)jg > > I think designing the tool up front to explicitly deal with and support > > 2 different back end flows (layout and simulation in this case) is very > > important. Presumably that will be a good vehicle to making sure it > can > > extend to many back end flows. > > David Baird wrote: (about data tie ins to higher abstractions > than "just boards")jg > I've been thinking (maybe just dreaming?) about an extensible system > which > allows the representation of information which has not yet even been > envisioned, while also providing forwards and backwards compatibility > as new component representations are devised. For these reasons, OWL > struck me somewhat and now I am learning OWL and trying to see if I > can really make it do what I want. -- A simple example -- convey to a > PCB program that a set of nets are actually grouped > > together to form the address bus of a microprocessor system. > > Dan McMahill wrote: (about using gnetman work already done to get > hierarchy )jg > I guess what I'd hate to see is a lot of work put into improving > gnetlist (which needs improving) > only to find that the underlying database structure and methods for > accessing it still > aren't complete enough, fast enough, or scalable enough. > > Stuart Brorson wrote: > The discussion about hierarchy should focus on the > following points: > > * What kind of data structures are desirable? How would they look? > Right now, the main data structure for a schematic is a linear linked > list of graphical objects (for each schematic page). Some list items > point to others (i.e. to support component attributes). How would that > change to support hierarchy? > > * ONce a datastructure is decided upon, then what does the file > format look like? Note that our current file format maps fairly > closely onto the internal data structures. Preserving this close > mapping is a desirable goal. Therefore, the data structures defining > hierarchy should more-or-less dictate what the file format should look > like. > > * How should gschem behave once hierarchy is architected in? Right > now you attach a source= attribute to a symbol. Then you do > "schematic down" on that symbol to dive into the sub-schematic. Is > that OK? Or what's a better scheme? > > And how to handle re-use blocks? That is, if I have a sub-schematic > which I instantiate four times, how should it be refdesed in the > netlist? If I dive into one of the four instantiations and edit it, > is it OK that the other three instantiations are also updated. >
Re: gEDA-user: Design Flow Roadmap starting point
John Griessen wrote: Dan McMahill wrote: (about using gnetman work already done to get hierarchy )jg I guess what I'd hate to see is a lot of work put into improving gnetlist (which needs improving) only to find that the underlying database structure and methods for accessing it still aren't complete enough, fast enough, or scalable enough. and just to clarify, this is a reason to use the gnetman database as opposed to one designed by one of us. -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
John, Keep this up and we are not only going to think you are paying attention but that you are taking notes as well. Steve Meier John Griessen wrote: > John Griessen wrote: >> So, "What do you want? > > The gschem gnetlist PCB gsch2pcb gattrib gerbv wants mentioned > recently and needing discussion are: > > Steve Meier: > 1) hierarchical data and file structures (xml or other) > 2) an integrated hierarchical netlister > 3) use of a better supported scripting language > 4) a method of dynamically partioning devices into meaningfull symbols > 5) a method of communicating between the schematic design and the layout > program on issues of slot swapping, i/o pin swapping, differential i/o > pin swapping, bank swapping > 6) strong drc > > > My plan for dealing with long refdes names e.g.S1/S2/S3/U3 is to hide > > the refdes and create a large box on the silkscreen which is labled S1. > > Then inside the S1 Box, a smaller box on the silcrean labled S2 and > > inside ths S2 box an even smaller box labled S3. The device inside the > > S3 box will have a silk screened comment near it that states U3. > > Svenn Are Bjerkem wrote: (about geda installer)jg > For real day-to-day work the engineer should be > able to decide himself what tool he wants to use > it should be enough to > run a command to have it installed. > > On 3/4/07, Dan McMahill <[EMAIL PROTECTED]> wrote:(about > multiple flows)jg > > I think designing the tool up front to explicitly deal with and support > > 2 different back end flows (layout and simulation in this case) is very > > important. Presumably that will be a good vehicle to making sure it > can > > extend to many back end flows. > > David Baird wrote: (about data tie ins to higher abstractions > than "just boards")jg > I've been thinking (maybe just dreaming?) about an extensible system > which > allows the representation of information which has not yet even been > envisioned, while also providing forwards and backwards compatibility > as new component representations are devised. For these reasons, OWL > struck me somewhat and now I am learning OWL and trying to see if I > can really make it do what I want. -- A simple example -- convey to a > PCB program that a set of nets are actually grouped > > together to form the address bus of a microprocessor system. > > Dan McMahill wrote: (about using gnetman work already done to get > hierarchy )jg > I guess what I'd hate to see is a lot of work put into improving > gnetlist (which needs improving) > only to find that the underlying database structure and methods for > accessing it still > aren't complete enough, fast enough, or scalable enough. > > Stuart Brorson wrote: > The discussion about hierarchy should focus on the > following points: > > * What kind of data structures are desirable? How would they look? > Right now, the main data structure for a schematic is a linear linked > list of graphical objects (for each schematic page). Some list items > point to others (i.e. to support component attributes). How would that > change to support hierarchy? > > * ONce a datastructure is decided upon, then what does the file > format look like? Note that our current file format maps fairly > closely onto the internal data structures. Preserving this close > mapping is a desirable goal. Therefore, the data structures defining > hierarchy should more-or-less dictate what the file format should look > like. > > * How should gschem behave once hierarchy is architected in? Right > now you attach a source= attribute to a symbol. Then you do > "schematic down" on that symbol to dive into the sub-schematic. Is > that OK? Or what's a better scheme? > > And how to handle re-use blocks? That is, if I have a sub-schematic > which I instantiate four times, how should it be refdesed in the > netlist? If I dive into one of the four instantiations and edit it, > is it OK that the other three instantiations are also updated. > > A list of use-cases would be helpful here. > > * Similarly, how should gnetlist behave? A use-case list would be > useful. > > * Finally, how should PCB behave with a hierarchical schematic? > > > > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Design Flow Roadmap starting point
John Griessen wrote: So, "What do you want? The gschem gnetlist PCB gsch2pcb gattrib gerbv wants mentioned recently and needing discussion are: Steve Meier: 1) hierarchical data and file structures (xml or other) 2) an integrated hierarchical netlister 3) use of a better supported scripting language 4) a method of dynamically partioning devices into meaningfull symbols 5) a method of communicating between the schematic design and the layout program on issues of slot swapping, i/o pin swapping, differential i/o pin swapping, bank swapping 6) strong drc > My plan for dealing with long refdes names e.g.S1/S2/S3/U3 is to hide > the refdes and create a large box on the silkscreen which is labled S1. > Then inside the S1 Box, a smaller box on the silcrean labled S2 and > inside ths S2 box an even smaller box labled S3. The device inside the > S3 box will have a silk screened comment near it that states U3. Svenn Are Bjerkem wrote: (about geda installer)jg For real day-to-day work the engineer should be able to decide himself what tool he wants to use it should be enough to run a command to have it installed. On 3/4/07, Dan McMahill <[EMAIL PROTECTED]> wrote:(about multiple flows)jg > I think designing the tool up front to explicitly deal with and support > 2 different back end flows (layout and simulation in this case) is very > important. Presumably that will be a good vehicle to making sure it can > extend to many back end flows. David Baird wrote: (about data tie ins to higher abstractions than "just boards")jg I've been thinking (maybe just dreaming?) about an extensible system which allows the representation of information which has not yet even been envisioned, while also providing forwards and backwards compatibility as new component representations are devised. For these reasons, OWL struck me somewhat and now I am learning OWL and trying to see if I can really make it do what I want. -- A simple example -- convey to a PCB program that a set of nets are actually grouped > together to form the address bus of a microprocessor system. Dan McMahill wrote: (about using gnetman work already done to get hierarchy )jg I guess what I'd hate to see is a lot of work put into improving gnetlist (which needs improving) only to find that the underlying database structure and methods for accessing it still aren't complete enough, fast enough, or scalable enough. Stuart Brorson wrote: The discussion about hierarchy should focus on the following points: * What kind of data structures are desirable? How would they look? Right now, the main data structure for a schematic is a linear linked list of graphical objects (for each schematic page). Some list items point to others (i.e. to support component attributes). How would that change to support hierarchy? * ONce a datastructure is decided upon, then what does the file format look like? Note that our current file format maps fairly closely onto the internal data structures. Preserving this close mapping is a desirable goal. Therefore, the data structures defining hierarchy should more-or-less dictate what the file format should look like. * How should gschem behave once hierarchy is architected in? Right now you attach a source= attribute to a symbol. Then you do "schematic down" on that symbol to dive into the sub-schematic. Is that OK? Or what's a better scheme? And how to handle re-use blocks? That is, if I have a sub-schematic which I instantiate four times, how should it be refdesed in the netlist? If I dive into one of the four instantiations and edit it, is it OK that the other three instantiations are also updated. A list of use-cases would be helpful here. * Similarly, how should gnetlist behave? A use-case list would be useful. * Finally, how should PCB behave with a hierarchical schematic? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
