Re: gEDA-user: Split ground planes and zero ohm jumpers
> > In theory, we could support that flag in *any* object, but I'm not > sure how to manage the relationship between, say, a non-net trace on > an inner plane and the schematic/netlist. I asked someone who used a > BigName EDA package how they did it, and they had a completely > different class of object for these - a net-linking object in the > schematics, netlist, and layout. > We use two objects for net and connectivity manipulation in schematics. Shorts, that map to a special class of footprints that can be placed on inner layers. Aliases, these map two net names to the same net and an attribute on the primary net marks it as the name it should use. Where the highest primary name in the hierarchy is used. Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Split ground planes and zero ohm jumpers
On Fri, Apr 8, 2011 at 2:18 PM, DJ Delorie wrote: > >> # shorting trace >> Pad [ -1.550mm 0.000mm 1.550mm 0.000mm 0.5mm 0.5mm 0.700mm "c" "c" >> "square" ] > > > Perhaps a new flag for pads that means "non-net copper" ? Then > "square,nonnet" (for example) tells 'o' to ignore that copper when > determining connectivity, but DRC would still check it for > manufacturability. > > In theory, we could support that flag in *any* object, but I'm not > sure how to manage the relationship between, say, a non-net trace on > an inner plane and the schematic/netlist. I asked someone who used a > BigName EDA package how they did it, and they had a completely > different class of object for these - a net-linking object in the > schematics, netlist, and layout. > Seems like a neat concept. Suppose it would be treated as regular copper throughout PCB except that when the netlister got to it, it would not cross it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: inherited attributes
On Fri, 2011-04-08 at 16:29 -0400, Vincent wrote: > Here are the 2 sym original and the modified respectively. You have modified much... This is the output of gsymcheck for the second symbol, please check. stefan@AMD64X2 ~/ttt $ gsymcheck -vv s2.sym Read garbage in [/home/stefan/ttt/s2.sym] : >> << Checking: /home/stefan/ttt/s2.sym Warning: Found the same number in a pinnumber attribute and in a net attribute [16] ERROR: Invalid pintype=PWR attribute ERROR: Invalid pintype=IN attribute ERROR: Invalid pintype=IN attribute ERROR: Invalid pintype=IN attribute ERROR: Found duplicate pinseq=6 attribute in the symbol ERROR: Found duplicate pinseq=6 attribute in the symbol 1 warnings found 6 ERRORS found ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Split ground planes and zero ohm jumpers
> # shorting trace > Pad [ -1.550mm 0.000mm1.550mm 0.000mm 0.5mm 0.5mm 0.700mm "c" "c" > "square" ] Perhaps a new flag for pads that means "non-net copper" ? Then "square,nonnet" (for example) tells 'o' to ignore that copper when determining connectivity, but DRC would still check it for manufacturability. In theory, we could support that flag in *any* object, but I'm not sure how to manage the relationship between, say, a non-net trace on an inner plane and the schematic/netlist. I asked someone who used a BigName EDA package how they did it, and they had a completely different class of object for these - a net-linking object in the schematics, netlist, and layout. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Split ground planes and zero ohm jumpers
John Griessen:
...
> Do we have a way to make a zero Ohm "two terminal" footprint with some copper
> inside,
> or pad overlap, that connects the pads and fits with the pcb program?
> I can't remember for sure, but think not...
> Another way to say that is, can we have footprint
> numbered pads of different number that touch?
Like this?
# 3216 / 1206 as "connecting" footprint
Element ["" "" "??" "" 0 0 -0.7mm -0.8mm 0 100 ""]
(
Pad [ -1.550mm -0.350mm -1.550mm 0.350mm 1.3mm 0.5mm 1.500mm "1" "1"
"square" ]
Pad [ 1.550mm -0.350mm1.550mm 0.350mm 1.3mm 0.5mm 1.500mm "2" "2"
"square" ]
# shorting trace
Pad [ -1.550mm 0.000mm1.550mm 0.000mm 0.5mm 0.5mm 0.700mm "c" "c"
"square" ]
ElementLine [ -2.460mm 1.260mm2.460mm 1.260mm 0.32mm ]
ElementLine [ 2.460mm 1.260mm2.460mm -1.260mm 0.32mm ]
ElementLine [ 2.460mm -1.260mm -2.460mm -1.260mm 0.32mm ]
ElementLine [ -2.460mm -1.260mm -2.460mm 1.260mm 0.32mm ]
)
Works perfectly fine (for the attaced pcb file) till you press "o":
Warning! Net "unnamed_net1" is shorted to net "unnamed_net3"
Warning! Net "unnamed_net1" is shorted to F1 pad c
Warning! Net "unnamed_net3" is shorted to net "unnamed_net1"
Warning! Net "unnamed_net3" is shorted to F1 pad c
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
# release: pcb 1.99z
# date:Fri Apr 8 22:32:50 2011
# user:karl (Karl Hammar,Lilla Aspö 148 / 742 94 Östhammar,0173 140 57,0173
140 51)
# host:opal.lcl.aspodata.se
# To read pcb files, the pcb version (or the git source date) must be >= the
file version
FileVersion[20100606]
PCB["" 157480 157480]
Grid[984.251953 0 0 0]
Cursor[0 0 0.00]
PolyArea[2.00]
Thermal[0.50]
DRC[1023 1023 1023 1023 1496 1023]
Flags("nameonpcb,autodrc,uniquename,clearnew,locknames,hidenames")
Groups("1,c:2,s:3:4:5:6:7:8")
Styles["Signal,1000,3600,2000,1000:Power,2500,6000,3500,1000:Fat,4000,6000,3500,1000:Skinny,600,2402,1181,600"]
Symbol(' ' 18)
(
)
Symbol('!' 12)
(
SymbolLine(0 45 0 50 8)
SymbolLine(0 10 0 35 8)
)
Symbol('"' 12)
(
SymbolLine(0 10 0 20 8)
SymbolLine(10 10 10 20 8)
)
Symbol('#' 12)
(
SymbolLine(0 35 20 35 8)
SymbolLine(0 25 20 25 8)
SymbolLine(15 20 15 40 8)
SymbolLine(5 20 5 40 8)
)
Symbol('$' 12)
(
SymbolLine(15 15 20 20 8)
SymbolLine(5 15 15 15 8)
SymbolLine(0 20 5 15 8)
SymbolLine(0 20 0 25 8)
SymbolLine(0 25 5 30 8)
SymbolLine(5 30 15 30 8)
SymbolLine(15 30 20 35 8)
SymbolLine(20 35 20 40 8)
SymbolLine(15 45 20 40 8)
SymbolLine(5 45 15 45 8)
SymbolLine(0 40 5 45 8)
SymbolLine(10 10 10 50 8)
)
Symbol('%' 12)
(
SymbolLine(0 15 0 20 8)
SymbolLine(0 15 5 10 8)
SymbolLine(5 10 10 10 8)
SymbolLine(10 10 15 15 8)
SymbolLine(15 15 15 20 8)
SymbolLine(10 25 15 20 8)
SymbolLine(5 25 10 25 8)
SymbolLine(0 20 5 25 8)
SymbolLine(0 50 40 10 8)
SymbolLine(35 50 40 45 8)
SymbolLine(40 40 40 45 8)
SymbolLine(35 35 40 40 8)
SymbolLine(30 35 35 35 8)
SymbolLine(25 40 30 35 8)
SymbolLine(25 40 25 45 8)
SymbolLine(25 45 30 50 8)
SymbolLine(30 50 35 50 8)
)
Symbol('&' 12)
(
SymbolLine(0 45 5 50 8)
SymbolLine(0 15 0 25 8)
SymbolLine(0 15 5 10 8)
SymbolLine(0 35 15 20 8)
SymbolLine(5 50 10 50 8)
SymbolLine(10 50 20 40 8)
SymbolLine(0 25 25 50 8)
SymbolLine(5 10 10 10 8)
SymbolLine(10 10 15 15 8)
SymbolLine(15 15 15 20 8)
SymbolLine(0 35 0 45 8)
)
Symbol(''' 12)
(
SymbolLine(0 20 10 10 8)
)
Symbol('(' 12)
(
SymbolLine(0 45 5 50 8)
SymbolLine(0 15 5 10 8)
SymbolLine(0 15 0 45 8)
)
Symbol(')' 12)
(
SymbolLine(0 10 5 15 8)
SymbolLine(5 15 5 45 8)
SymbolLine(0 50 5 45 8)
)
Symbol('*' 12)
(
SymbolLine(0 20 20 40 8)
SymbolLine(0 40 20 20 8)
SymbolLine(0 30 20 30 8)
SymbolLine(10 20 10 40 8)
)
Symbol('+' 12)
(
SymbolLine(0 30 20 30 8)
SymbolLine(10 20 10 40 8)
)
Symbol(',' 12)
(
SymbolLine(0 60 10 50 8)
)
Symbol('-' 12)
(
SymbolLine(0 30 20 30 8)
)
Symbol('.' 12)
(
SymbolLine(0 50 5 50 8)
)
Symbol('/' 12)
(
SymbolLine(0 45 30 15 8)
)
Symbol('0' 12)
(
SymbolLine(0 45 5 50 8)
SymbolLine(0 15 0 45 8)
SymbolLine(0 15 5 10 8)
SymbolLine(5 10 15 10 8)
SymbolLine(15 10 20 15 8)
SymbolLine(20 15 20 45 8)
SymbolLine(15 50 20 45 8)
SymbolLine(5 50 15 50 8)
SymbolLine(0 40 20 20 8)
)
Symbol('1' 12)
(
SymbolLine(5 50 15 50 8)
SymbolLine(10 10 10 50 8)
SymbolLine(0 20 10 10 8)
)
Symbol('2' 12)
(
Re: gEDA-user: Power users us normal users, a conflict?
Hello: First of all, a aclaration for Stephan Boettcher: I'm not refering how power users to a CLI users, power users is a user that have a great knowledge of using the tools, all the tools including makefiles, bash, gEDA... I'm a CLI users and, certainly, I'm not a power user. El 08/04/11 21:16, John Doty escribió: On Apr 8, 2011, at 1:22 AM, Stephan Boettcher wrote: I do not see a conflict between GUI and make, the first ist a good way to make features of the second discoverable. Only if each individual tool is *simple*. Complex menus make features *less* discoverable. Besides, if your use case doesn't correspond *exactly* to the necessarily limited imagination > of the developer of a "feature", then that "feature" is just more fog, hiding the real "feature" > you want, or wasting your time by making it difficult to discover that the "feature" > is missing. In other words, GUI scales just as badly as a discovery tool as it does as an automation tool. > Therefore, adding capability should either involve: 1. More independent tools in the kit, or 2. *Less* GUI. Or a better GUI. Really, I'm thinking that we are talking the same but in different approaches: I'm talking about don't scare new users with a *seems too dificult and too ugly CLI tool* and you are talking that do less GUI because GUI block the users in his way to convert in power-users. Both are talking about the users, and the how work be done. John wants to make sure that the make-power is not compromised for the sake of the integrated GUI. But that should not discourage development in that area. But the design practices are incompatible. GUI is sensibly designed from the top down >(from appearance), while a flexible toolkit needs to be designed from the bottom up (build fundamental capabilities first, compose "features" from them). A Makefile often does much more sophisticated things than merely orchestrate a series of virtual button pushes. Then we need a different aproaches: let's look to other project, for example, rkward: http://rkward.sourceforge.net/ Rkward is a GUI for R app/language, but is console oriented, you have a console, you have a editor for writing scripts and you have several menus to do tipical actions. New users (like me) use these menus and can do some work quickly, but there are a new feature that give users a extra point: the menu actions are translate to code and you can view it before and after of doing the action. Rkward have a command log view where user can look to see code actions. This is a example of how GUI helps the user without become a ballast. In gEDA world we have KJWaves in a similar approaching, and I know for a project in a city nearest to me, ESpice (for Español Spice), where they build a GUI around Ngspice, and is console oriented: http://espice.ugr.es/images/screenshots/screen2-big.jpg http://espice.ugr.es/index2.html Is not the correct way? Couldn't we have a tool thinking in new, and novice, users that helps them without scare? Is the answer is no, then I add: we need too much more documentation (and, yes, we need too much more documentation in any way). gEDA and especially PCB suffer a lot from lack of discoverability. PCB is more complex, so the scaling problem is more evident. It suffers from the > related problem of being a grab-bag of GUI features without a solid foundation of clean, > well-factored capabilities. gschem and gnetlist could be better too, but they're already > unusually good by this measure. I can't talk about PCB, but gschem is a good tool, not really difficult to do the work with it from scratch. I do not believe that a GUI frontend to gaf, pcb, spice is the way to go. That prevents dicoverability. My productivity with proprietary tools always got a boost as soon as I learned how to call the components individually. This was not always easy to discover. I have the same experience. It relates to my main point here: GUI does not scale well for the automation of complex jobs. I don't have the experience, but because I start calling each tool individually (gEDA user from begin). However, I can see that you say, I can view it in each users that without a GUI they can't do nothing. But, I can see that you are a power users (I read the list, you can't hide it to me), I'm only a normal user, almost a novice and I say that took the needs of the novices too, offer them the greats tools that gaf, pcb and free spice tools are, but offer them too the help (and a big one is this list) in the shape of *interfaces* easy to use without these interfaces be a *big begin problem*. And,hey! We are talking about free software, we don't have our hands enchained with the need of profits, we can *invent a new way*. (I hope that I could transmit some of my idea, language is a terrible frustation to me, I can't do all good that I want with english, sorry too much about). Best regards. Salud y Re
gEDA-user: inherited attributes
# From: Kai-Martin Knaak
# Date: Thu, 07 Apr 2011 13:32:42 +0200
Vincent wrote:
> How the inherited attributes are entered in components? I couldn't
find
> any information. I modified some preexisting component and then
entered
> new name, footprint etc. If check the box of inherited attributes
they
> show grayed but they are there. will they be disabled if the box is
left
> unchecked? Or need to be totally removed?
Can you attach the symbol, before and after modification, so we can
take
a look at what you did?
Here are the 2 sym original and the modified respectively.
thank you.
v 20081231 1
P 0 3400 300 3400 1 0 0
{
T 200 3450 5 8 1 1 0 6 1
pinnumber=4
T 200 3350 5 8 0 1 0 8 1
pinseq=1
T 350 3400 9 8 1 1 0 0 1
pinlabel=D1
T 350 3400 5 8 0 1 0 2 1
pintype=in
}
P 2000 3400 1700 3400 1 0 0
{
T 1800 3450 5 8 1 1 0 0 1
pinnumber=2
T 1800 3350 5 8 0 1 0 2 1
pinseq=2
T 1650 3400 9 8 1 1 0 6 1
pinlabel=Q1
T 1650 3400 5 8 0 1 0 8 1
pintype=out
}
P 0 3000 300 3000 1 0 0
{
T 200 3050 5 8 1 1 0 6 1
pinnumber=5
T 200 2950 5 8 0 1 0 8 1
pinseq=3
T 350 3000 9 8 1 1 0 0 1
pinlabel=D2
T 350 3000 5 8 0 1 0 2 1
pintype=in
}
P 2000 3000 1700 3000 1 0 0
{
T 1800 3050 5 8 1 1 0 0 1
pinnumber=7
T 1800 2950 5 8 0 1 0 2 1
pinseq=4
T 1650 3000 9 8 1 1 0 6 1
pinlabel=Q2
T 1650 3000 5 8 0 1 0 8 1
pintype=out
}
P 0 2600 300 2600 1 0 0
{
T 200 2650 5 8 1 1 0 6 1
pinnumber=12
T 200 2550 5 8 0 1 0 8 1
pinseq=5
T 350 2600 9 8 1 1 0 0 1
pinlabel=D3
T 350 2600 5 8 0 1 0 2 1
pintype=in
}
P 2000 2600 1700 2600 1 0 0
{
T 1800 2650 5 8 1 1 0 0 1
pinnumber=10
T 1800 2550 5 8 0 1 0 2 1
pinseq=6
T 1650 2600 9 8 1 1 0 6 1
pinlabel=Q3
T 1650 2600 5 8 0 1 0 8 1
pintype=out
}
P 0 2200 300 2200 1 0 0
{
T 200 2250 5 8 1 1 0 6 1
pinnumber=13
T 200 2150 5 8 0 1 0 8 1
pinseq=7
T 350 2200 9 8 1 1 0 0 1
pinlabel=D4
T 350 2200 5 8 0 1 0 2 1
pintype=in
}
P 2000 2200 1700 2200 1 0 0
{
T 1800 2250 5 8 1 1 0 0 1
pinnumber=15
T 1800 2150 5 8 0 1 0 2 1
pinseq=8
T 1650 2200 9 8 1 1 0 6 1
pinlabel=Q4
T 1650 2200 5 8 0 1 0 8 1
pintype=out
}
P 2000 1700 1800 1700 1 0 0
{
T 1800 1750 5 8 1 1 0 0 1
pinnumber=3
T 1800 1650 5 8 0 1 0 2 1
pinseq=9
T 1650 1700 9 8 1 1 0 6 1
pinlabel=Q1
T 1650 1700 5 8 0 1 0 8 1
pintype=out
}
V 1750 1700 50 6 0 0 0 -1 -1 0 -1 -1 -1 -1 -1
P 0 1400 200 1400 1 0 0
{
T 200 1450 5 8 1 1 0 6 1
pinnumber=1
T 200 1350 5 8 0 1 0 8 1
pinseq=10
T 350 1400 9 8 1 1 0 0 1
pinlabel=CLR
T 350 1400 5 8 0 1 0 2 1
pintype=in
}
V 250 1400 50 6 0 0 0 -1 -1 0 -1 -1 -1 -1 -1
P 2000 1300 1800 1300 1 0 0
{
T 1800 1350 5 8 1 1 0 0 1
pinnumber=6
T 1800 1250 5 8 0 1 0 2 1
pinseq=11
T 1650 1300 9 8 1 1 0 6 1
pinlabel=Q2
T 1650 1300 5 8 0 1 0 8 1
pintype=out
}
V 1750 1300 50 6 0 0 0 -1 -1 0 -1 -1 -1 -1 -1
P 2000 900 1800 900 1 0 0
{
T 1800 950 5 8 1 1 0 0 1
pinnumber=11
T 1800 850 5 8 0 1 0 2 1
pinseq=12
T 1650 900 9 8 1 1 0 6 1
pinlabel=Q3
T 1650 900 5 8 0 1 0 8 1
pintype=out
}
V 1750 900 50 6 0 0 0 -1 -1 0 -1 -1 -1 -1 -1
P 0 600 300 600 1 0 0
{
T 200 650 5 8 1 1 0 6 1
pinnumber=9
T 200 550 5 8 0 1 0 8 1
pinseq=13
T 375 600 9 8 1 1 0 0 1
pinlabel=CLK
T 375 600 5 8 0 1 0 2 1
pintype=clk
}
P 2000 500 1800 500 1 0 0
{
T 1800 550 5 8 1 1 0 0 1
pinnumber=14
T 1800 450 5 8 0 1 0 2 1
pinseq=14
T 1650 500 9 8 1 1 0 6 1
pinlabel=Q4
T 1650 500 5 8 0 1 0 8 1
pintype=out
}
V 1750 500 50 6 0 0 0 -1 -1 0 -1 -1 -1 -1 -1
B 300 300 1400 3300 3 0 0 0 -1 -1 0 -1 -1 -1 -1 -1
T 300 4140 5 10 0 0 0 0 1
device=74175
T 300 3940 5 10 0 0 0 0 1
footprint=DIP16
T 1700 3700 8 10 1 1 0 6 1
refdes=U?
T 300 4350 5 10 0 0 0 0 1
description=quad D-flip-flop with clear
T 300 4950 5 10 0 0 0 0 1
numslots=0
T 300 4550 5 10 0 0 0 0 1
net=Vcc:16
T 300 4750 5 10 0 0 0 0 1
net=GND:8
T 300 3640 9 10 1 0 0 0 1
74175
L 350 1525 625 1525 3 0 0 0 -1 -1
L 1500 1825 1650 1825 3 0 0 0 -1 -1
L 1450 1425 1650 1425 3 0 0 0 -1 -1
L 1475 1025 1650 1025 3 0 0 0 -1 -1
L 1450 625 1650 625 3 0 0 0 -1 -1
L 375 600 300 650 3 0 0 0 -1 -1
L 375 600 300 550 3 0 0 0 -1 -1
T 300 5150 5 10 0 0 0 0 1
documentation=http://www-s.ti.com/sc/ds/sn74hc175.pdf
v 20110115 2
P 100 3500 300 3500 1 0 0
{
T 300 3550 5 8 1 1 0 6 1
pinnumber=10
T 300 3450 5 8 0 1 0 8 1
pinseq=10
T 450 3500 9 8 1 1 0 0 1
pinlabel=/CEO
T 450 3500 5 8 0 1 0 2 1
pintype=in
}
P 2100 3100 1800 3100 1 0 0
{
T 1895 3145 5 8 1 1 0 0 1
pinnumber=16
T 1900 3050 5 8 0 1 0 2 1
pinseq=16
T 1745 3095 9 8 1 1 0 6 1
pinlabel=VIN
T 1750 3100 5 8 0 1 0 8 1
pintype=PWR
}
P 100 3000 300 3000 1 0 0
{
T 300 3050 5 8 1 1 0 6 1
pinnumber=12
T 450 3000 9 8 1 1 0 0 1
pinlabel=/OE
T 450 3000 5 8 0 1 0 2 1
pintype=in
T 100 3000 5 10 0 1 0 0 1
pinseq=12
}
P 100 2400 300 2400 1 0 0
{
T 300 2450 5 8 1 1 0 6 1
pinnumber=3
T 450 2400 9 8 1 1 0 0 1
pinlabel=/WE
T 450 2400 5 8 0 1 0 2 1
pintype=in
T 100 2400 5 10 0 1 0 0 1
pinseq=3
}
P 1600 100 1600 400 1 0 0
{
T 1495 350 5 8 1 1 180 6 1
pinnumber=2
T 1550 300 5 8 0 1 270 2 1
pinseq=6
T 1600 455 9 8 1 1 90 0 1
pinlabel=X2
T 1600 450 5 8 0 1 270 8 1
pintype=out
}
P 100 1700 300 1700 1 0 0
{
T 300 1750 5 8 1 1 0 6 1
pinnumber=11
T 450 170
Re: gEDA-user: Split ground planes and zero ohm jumpers
rickman writes: > On 4/7/2011 1:13 PM, Stephan Boettcher wrote: >> rickman writes: >> >>> I have to say I am philosophically opposed to any feature that allows >>> a design to pass DRC when the layout differs from the schematic. >> Just to get the terminology right: >> >> DRC has no business to care about the schematics at all. There shall be >> a tool to check if the layout implements the schematics netlist, but >> that is a different issue. >> >> PCB implements this distiction properly. DRC checks consider coper >> structures as layed out when evaluating the rules, without regard to the >> netlist. >> >> The Rat's-nest (O-key) ignores DRC rules when checking connectivity. > > Ok, if you want to be pedantic the net list is not the schematic, but > if the netlist differs from the schematic, then you have another > problem. My point is, what I (we?) call DRC in the PCB program context is the Menu item Connects -> Design_Rule_Checker. This action does not check if two nets are connected or not. It just checks if the connection has the proper copper width. It does not care which copper belongs to which net, or if all pins on a net are really connected. And, yes, that may be pedantic, but I believe in this context we should get the teminology right in our discussions. This is independent of the issues you are arguing, though. > DRC is a part of my design process which includes a verification that > the layout matches the net list. In fact, my number 1 "design rule" > to be checked is that they match. What button I push to get the tool > to do my required design rule checking is irrelevant. It is just a > tool and does not define my process. > > So my point is that adding an attribute to any copper to tell the tool > to ignore the connectivity violates my idea of design rule checking. > > Rick -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: lost mail
> Date: Fri, 8 Apr 2011 14:48:19 -0400 > From: DJ Delorie > The gEDA mailing lists are archived off the gEDA web page: > http://geda.seul.org/wiki/geda:mailinglists > Thank you ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Power users us normal users, a conflict?
On Apr 8, 2011, at 1:22 AM, Stephan Boettcher wrote: > > I do not see a conflict between GUI and make, the first ist a good way > to make features of the second discoverable. Only if each individual tool is *simple*. Complex menus make features *less* discoverable. Besides, if your use case doesn't correspond *exactly* to the necessarily limited imagination of the developer of a "feature", then that "feature" is just more fog, hiding the real "feature" you want, or wasting your time by making it difficult to discover that the "feature" is missing. In other words, GUI scales just as badly as a discovery tool as it does as an automation tool. Therefore, adding capability should either involve: 1. More independent tools in the kit, or 2. *Less* GUI. > John wants to make sure > that the make-power is not compromised for the sake of the integrated > GUI. But that should not discourage development in that area. But the design practices are incompatible. GUI is sensibly designed from the top down (from appearance), while a flexible toolkit needs to be designed from the bottom up (build fundamental capabilities first, compose "features" from them). A Makefile often does much more sophisticated things than merely orchestrate a series of virtual button pushes. > > gEDA and especially PCB suffer a lot from lack of discoverability. PCB is more complex, so the scaling problem is more evident. It suffers from the related problem of being a grab-bag of GUI features without a solid foundation of clean, well-factored capabilities. gschem and gnetlist could be better too, but they're already unusually good by this measure. > > I do not believe that a GUI frontend to gaf, pcb, spice is the way to > go. That prevents dicoverability. My productivity with proprietary > tools always got a boost as soon as I learned how to call the components > individually. This was not always easy to discover. I have the same experience. It relates to my main point here: GUI does not scale well for the automation of complex jobs. --- John Doty Noqsi Aerospace, Ltd. This message contains technical discussion involving difficult issues. No personal disrespect or malice is intended. If you perceive such, your perception is simply wrong. I'm a busy person, and in my business "go along to get along" causes mission failures and sometimes kills people, so I tend to be a bit blunt. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: lost mail
The gEDA mailing lists are archived off the gEDA web page: http://geda.seul.org/wiki/geda:mailinglists ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: lost mail
Hello, A. I have reason to believe that same of my mail got lost, is there any way to have resend the past 3 days that is from 4/5, 4/6, 4/7 or where could I retrieve. thanks Vinny ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Split ground planes and zero ohm jumpers
On 04/08/2011 11:44 AM, Russell Dill wrote: I'm not sure if it could be done simpler, but for a special copper trace that connects two planes, you would do DRC twice, one time ignoring between the trace and plane A, and another between the trace and plane B. That is a method consistent with complex designs and wanting a "pilot checklist" of to dos before sending it to the fab. The bigger the layout, the more it compares to chip business with its "tape out" checklists and strict methods to avoid an error. So if you decide you need to "do things mostly the same twice" to catch potential errors, you begin to really need automation with a make file (or a GUI front end to make), or it becomes a drag to do your method. Do we have a way to make a zero Ohm "two terminal" footprint with some copper inside, or pad overlap, that connects the pads and fits with the pcb program? I can't remember for sure, but think not... Another way to say that is, can we have footprint numbered pads of different number that touch? John -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Split ground planes and zero ohm jumpers
On 4/8/2011 12:57 PM, Mark Rages wrote: On Fri, Apr 8, 2011 at 11:39 AM, rickman wrote: On 4/7/2011 1:13 PM, Stephan Boettcher wrote: rickmanwrites: I have to say I am philosophically opposed to any feature that allows a design to pass DRC when the layout differs from the schematic. Just to get the terminology right: DRC has no business to care about the schematics at all. There shall be a tool to check if the layout implements the schematics netlist, but that is a different issue. PCB implements this distiction properly. DRC checks consider coper structures as layed out when evaluating the rules, without regard to the netlist. The Rat's-nest (O-key) ignores DRC rules when checking connectivity. Ok, if you want to be pedantic the net list is not the schematic, but if the netlist differs from the schematic, then you have another problem. DRC is a part of my design process which includes a verification that the layout matches the net list. In fact, my number 1 "design rule" to be checked is that they match. What button I push to get the tool to do my required design rule checking is irrelevant. It is just a tool and does not define my process. So my point is that adding an attribute to any copper to tell the tool to ignore the connectivity violates my idea of design rule checking. Rick Rick, your idea about DRC and the pureness of connectivity is wrong. Connectivity is insufficient for real world designs, which is the point of all this discussion. It's possible to have a design with perfect connectivity that doesn't work. Any analog or RF design, and a lot of high-speed digital designs, require a lot more attention than getting connectivity right. So the desire to tag certain nets / connections as controlled impedance, no DRC, equal trace length, etc. Regards, Mark markrages@gmail I don't know how you get from my statements to suggesting that I don't agree that tags should be used. Controlled impedance and equal trace length have nothing to do with what I said. If you have some portion of your design that you need to exclude from DRC, I would suggest that you need to adjust your design rules. It may be that the tool is not sophisticated enough to accommodate the needed design rules, but saying that it is desirable to exclude portions of a design from design rule checking is a very poor way of dealing with the limitations of a tool. I would much prefer to have the design rule violations reported and then allow the designer to sign off that these violations are not a problem. It can be too easy to make a mistake when excluding a design rule check and missing a violation that results in a problem. Too often people confuse the functionality of a tool with the process of verifying correctness of a design. I done't want a tool dictate my design rule process. If the tool has limitations, I prefer to have it report problems that I can then manually verify are not problems than to run the risk of missing problems that cost time and money. The problem of connectivity of nets can be handled without violating design rules. I do this using a part footprint that connects the two nets. This shows up on the schematic as the single connection point between the two nets, is reflected in the netlist as the only point of connection of the two distinct nets and can be verified in design rule checking that the nets are connected no where other than by this footprint. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Split ground planes and zero ohm jumpers
On Fri, Apr 8, 2011 at 11:39 AM, rickman wrote: > On 4/7/2011 1:13 PM, Stephan Boettcher wrote: >> >> rickman writes: >> >>> I have to say I am philosophically opposed to any feature that allows >>> a design to pass DRC when the layout differs from the schematic. >> >> Just to get the terminology right: >> >> DRC has no business to care about the schematics at all. There shall be >> a tool to check if the layout implements the schematics netlist, but >> that is a different issue. >> >> PCB implements this distiction properly. DRC checks consider coper >> structures as layed out when evaluating the rules, without regard to the >> netlist. >> >> The Rat's-nest (O-key) ignores DRC rules when checking connectivity. > > Ok, if you want to be pedantic the net list is not the schematic, but if > the netlist differs from the schematic, then you have another problem. > > DRC is a part of my design process which includes a verification that the > layout matches the net list. In fact, my number 1 "design rule" to be > checked is that they match. What button I push to get the tool to do my > required design rule checking is irrelevant. It is just a tool and does not > define my process. > > So my point is that adding an attribute to any copper to tell the tool to > ignore the connectivity violates my idea of design rule checking. > > Rick Rick, your idea about DRC and the pureness of connectivity is wrong. Connectivity is insufficient for real world designs, which is the point of all this discussion. It's possible to have a design with perfect connectivity that doesn't work. Any analog or RF design, and a lot of high-speed digital designs, require a lot more attention than getting connectivity right. So the desire to tag certain nets / connections as controlled impedance, no DRC, equal trace length, etc. Regards, Mark markrages@gmail -- Mark Rages, Engineer Midwest Telecine LLC markra...@midwesttelecine.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Split ground planes and zero ohm jumpers
On Fri, Apr 8, 2011 at 9:39 AM, rickman wrote: > On 4/7/2011 1:13 PM, Stephan Boettcher wrote: >> >> rickman writes: >> >>> I have to say I am philosophically opposed to any feature that allows >>> a design to pass DRC when the layout differs from the schematic. >> >> Just to get the terminology right: >> >> DRC has no business to care about the schematics at all. There shall be >> a tool to check if the layout implements the schematics netlist, but >> that is a different issue. >> >> PCB implements this distiction properly. DRC checks consider coper >> structures as layed out when evaluating the rules, without regard to the >> netlist. >> >> The Rat's-nest (O-key) ignores DRC rules when checking connectivity. > > Ok, if you want to be pedantic the net list is not the schematic, but if > the netlist differs from the schematic, then you have another problem. > > DRC is a part of my design process which includes a verification that the > layout matches the net list. In fact, my number 1 "design rule" to be > checked is that they match. What button I push to get the tool to do my > required design rule checking is irrelevant. It is just a tool and does not > define my process. > > So my point is that adding an attribute to any copper to tell the tool to > ignore the connectivity violates my idea of design rule checking. > I'm not sure if it could be done simpler, but for a special copper trace that connects two planes, you would do DRC twice, one time ignoring between the trace and plane A, and another between the trace and plane B. Or perhaps just run that portion of the DRC twice. Or just make a special region where the connectivity between net A and net B is ignored where they touch. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Split ground planes and zero ohm jumpers
On 4/7/2011 1:13 PM, Stephan Boettcher wrote: rickman writes: I have to say I am philosophically opposed to any feature that allows a design to pass DRC when the layout differs from the schematic. Just to get the terminology right: DRC has no business to care about the schematics at all. There shall be a tool to check if the layout implements the schematics netlist, but that is a different issue. PCB implements this distiction properly. DRC checks consider coper structures as layed out when evaluating the rules, without regard to the netlist. The Rat's-nest (O-key) ignores DRC rules when checking connectivity. Ok, if you want to be pedantic the net list is not the schematic, but if the netlist differs from the schematic, then you have another problem. DRC is a part of my design process which includes a verification that the layout matches the net list. In fact, my number 1 "design rule" to be checked is that they match. What button I push to get the tool to do my required design rule checking is irrelevant. It is just a tool and does not define my process. So my point is that adding an attribute to any copper to tell the tool to ignore the connectivity violates my idea of design rule checking. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Split ground planes and zero ohm jumpers
On Apr 8, 2011, at 1:13 AM, Stephan Boettcher wrote: > rickman writes: > >> I have to say I am philosophically opposed to any feature that allows >> a design to pass DRC when the layout differs from the schematic. > > Just to get the terminology right: > > DRC has no business to care about the schematics at all. There shall be > a tool to check if the layout implements the schematics netlist, but > that is a different issue. > DRC vs ERC. A while back I proposed that there were object attributes that allowed for a single connection from a net. If the ERC caught more than one connection from that net. > PCB implements this distiction properly. DRC checks consider coper > structures as layed out when evaluating the rules, without regard to the > netlist. > > The Rat's-nest (O-key) ignores DRC rules when checking connectivity. > > -- > Stephan > > > ___ > 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: Power users us normal users, a conflict?
Rubén Gómez Antolí writes: > Hi again: > > El 08/04/11 01:30, Peter Clifton escribió: >> On Thu, 2011-04-07 at 16:00 -0600, John Doty wrote: >>> On Apr 7, 2011, at 3:06 PM, Rubén Gómez Antolí wrote: You are right but, what about the users? >>> >>> I *am* a user. > > I'm too. Both of you now pushed some users aside somehow, one calling the GUI users _consumers_, the other calling CLI users _power users_. I do not see a conflict between GUI and make, the first ist a good way to make features of the second discoverable. John wants to make sure that the make-power is not compromised for the sake of the integrated GUI. But that should not discourage development in that area. >>> gEDA is software that caters to the needs of users. But >>> it's not for passive *consumers* of software. There are plenty of >>> other tools for them. I sincerely hope that gEDA's power and >>> productivity are never abridged to make it more palatable to >>> consumers. > > John, I'm not attack the powerful of gEDA, I'm really agree with the > multiple pieces of powerful software that compounds it, and I love too > the posibilty of use makefiles, but... > > I tell you a short history: I have a friend, he is really good in > electronics and yes, he uses other comercial apps (and he's testing > Qucs). I try to come him with us, but, stop, if I tell him to need to > learn Bash, Makefiles, Gnuplot and other "esotheric" languages... ¡oh, > wait! He only wants to do some electronics work. He cannot be really good, when we stays in the GUI forever. At least not efficiently. An expert in any field needs to use learn the tools of his trade, or hire personel that does. None of the languages you quoted are esotheric. Users of commercial tools learn more esotheric scripting languages to achieve what open tools can partly achieve with these non-esotheric tools. These non-esotheric tools are useful for all kinds of productivity boost besides eda. > Who is wrong? Possibly anyone, then, what about do a easy curve of > learning? Why we have to lost a potentially users which should > contribute in some way to gEDA? For a leak of a good interface* to do > in a easy way the work? I say no. Try to tell him about doing some > makefiles and, definitively all lost, we and they. gEDA and especially PCB suffer a lot from lack of discoverability. There a powerful features in PCB that are inaccessible from the GUI, and those features that are accessible do not provide hints how to access them from scripts. And AFAIK there is still no complete list of all actions available. I do not believe that a GUI frontend to gaf, pcb, spice is the way to go. That prevents dicoverability. My productivity with proprietary tools always got a boost as soon as I learned how to call the components individually. This was not always easy to discover. gschem modes, like emacs modes may be a good way forward. If you target simulation, provide a menu that highlights spice attributes, and spice components, with descriptive names. Just make sure you can switch to different modes on the same schematic, to use what is left of multi-target capabilities in gschem. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
