Re: gEDA-user: Problems cloning from git.gpleda.org
Yes, I made a change which affected http git access. I have re-enabled git access via http. Please try again. Cloning gaf.git works OK, but cloning pcb.git gives the same error gar...@xdcnb047-vbox:~/devel/geda$ git clone http://git.gpleda.org/pcb.git Initialized empty Git repository in /home/gareth/devel/geda/pcb/.git/ warning: remote HEAD refers to nonexistent ref, unable to checkout. You should be careful to avoid pulling from that method too frequently though, as comparative to the git:// method, it can be a bandwidth hog. I have no choice here due to the proxy but I only pull to this machine every week or two. I didn't know it was a more expensive operation, though, I'll keep that in mind. Cheers Gareth ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: ground plan
Hello, What am I missing ? On the component side I only have ground tracks and one additional one. To make a ground plan, I use rectangle, unfortunately, doing so, I get copper every where, ie. the spacing aroud the pins is OK but the track which is not supposed to be grounded is connected to the plan !! Thank for your help. -- --- == Patrick DUPRÉ | | Department of Chemistry| |Phone: (44)-(0)-1904-434384 The University of York | |Fax: (44)-(0)-1904-432516 Heslington | | York YO10 5DD United Kingdom | |email: pd...@york.ac.uk == ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Problems cloning from git.gpleda.org
[snip] Cloning gaf.git works OK, but cloning pcb.git gives the same error gar...@xdcnb047-vbox:~/devel/geda$ git clone http://git.gpleda.org/pcb.git Is this the right URL? I thought it was supposed to be http://git.gpleda.org/git/pcb.git. Please check the gaf.git URL and see if it has a .../git/... in there. -Ales ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Problems cloning from git.gpleda.org
Is this the right URL? I thought it was supposed to be http://git.gpleda.org/git/pcb.git. Please check the gaf.git URL and see if it has a .../git/... in there. -Ales Aaaah, that's it, thanks Ales. I must have being doing a pull on an existing repo rather than a new clone of the gaf repo. That's what I get for trying to do it when I'm tired. Thanks for all the help. Gareth ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: ground plan
You need to make sure that the traces have the attribute clearpoly. I usually do a search and replace in a text editor; I'm not sure if there's a shortcut in PCB that let's you process traces already placed. Under the Settings menu there is an option New lines, arcs, clear polygons that will make sure that any additional lines you place will not be merged into a polygon. -Ethan Patrick Dupre wrote: Hello, What am I missing ? On the component side I only have ground tracks and one additional one. To make a ground plan, I use rectangle, unfortunately, doing so, I get copper every where, ie. the spacing aroud the pins is OK but the track which is not supposed to be grounded is connected to the plan !! Thank for your help. ___ 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: ground plan
On Tue, Feb 10, 2009 at 08:44:15AM -0500, Ethan Swint wrote: You need to make sure that the traces have the attribute clearpoly. I usually do a search and replace in a text editor; I'm not sure if there's a shortcut in PCB that let's you process traces already placed. It's typically the J (for join I suppose) key. Under the Settings menu there is an option New lines, arcs, clear polygons that will make sure that any additional lines you place will not be merged into a polygon. Gabriel ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: ground plan
Thank you very much. You need to make sure that the traces have the attribute clearpoly. I usually do a search and replace in a text editor; I'm not sure if there's a shortcut in PCB that let's you process traces already placed. Under the Settings menu there is an option New lines, arcs, clear polygons that will make sure that any additional lines you place will not be merged into a polygon. -Ethan Patrick Dupre wrote: Hello, What am I missing ? On the component side I only have ground tracks and one additional one. To make a ground plan, I use rectangle, unfortunately, doing so, I get copper every where, ie. the spacing aroud the pins is OK but the track which is not supposed to be grounded is connected to the plan !! Thank for your help. ___ 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 -- --- == Patrick DUPRÉ | | Department of Chemistry| |Phone: (44)-(0)-1904-434384 The University of York | |Fax: (44)-(0)-1904-432516 Heslington | | York YO10 5DD United Kingdom | |email: pd...@york.ac.uk == ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist verilog back end gnet-verilog.scm
Paul Tan wrote: Hi John, There is a BASH script geda_hier_tools.bsh to generate Hierarchical Verilog netlist Thanks Paul, I'm wanting to get things going in an easy to maintain way with as few steps as possible. I'd like to do it in scheme, from one launch of gnetlist, if possible. Then I'll come back to scripts if can't get results. 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: ground plan
Gabriel Paubert wrote: Under the Settings menu there is an option New lines, arcs, clear polygons that will make sure that any additional lines you place will not be merged into a polygon. This very same behavior tripped me up on my first board with PCB. Is there some reason that New Lines... clear polygons is not on by default? The current setting seems to violate the principal of least surprise. -dave ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: ground plan
Is there some reason that New Lines... clear polygons is not on by default? It *is* on by default. The problem is that gsch2pcb doesn't use pcb's defaults. That's why in my tutorials, I don't let gsch2pcb create the initial board. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: ground plan
DJ Delorie wrote: Is there some reason that New Lines... clear polygons is not on by default? It *is* on by default. The problem is that gsch2pcb doesn't use pcb's defaults. That's why in my tutorials, I don't let gsch2pcb create the initial board. Ah... well, then I dereference the pointer and ask the question of gsch2pcb: Is there some reason that New Lines... clear polygons is not set by default by gsch2pcb? It would seem to violate the principal of least surprise. -dave ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: ground plan
Dave N6NZ wrote: Is there some reason that New Lines... clear polygons is not set by default by gsch2pcb? It would seem to violate the principal of least surprise. DJ's mentioned this before. There's a thought or two going on about that. A new version of gschem--PCB flow could drive pcb through an API and take advantage of latest, greatest. So the reason not now, is So it can be even better later. 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: ground plan
Ah... well, then I dereference the pointer and ask the question of gsch2pcb: Is there some reason that New Lines... clear polygons is not set by default by gsch2pcb? It would seem to violate the principal of least surprise. I could be mistaken, but I think the newer repo versions of gsch2pcb do have this enabled by default, but the release versions do not. Could anyone confirm this? If this is the case, how big an issue would it be to add this to the next official release? -- Turn ideas into products - http://www.engineersimplicity.com The Art of Engineering - http://blog.engineersimplicity.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gschem ignoring gafrc?
In my gafrc file in the current directory, I have the line: (paper-size 17.0 11.0) ; tabloid However, this is ignored by gschem even though the status window reports read local gafrc. This behavior turned up in 20081231 from Fedora 10, but was ok in 20081220 from Fedora 8. Any ideas? Its not a big deal in interactive mode, but it messes up the output when running from a script. Thanks, Matt ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem ignoring gafrc?
Am Dienstag, den 10.02.2009, 12:06 -0800 schrieb Matt Ettus: In my gafrc file in the current directory, I have the line: (paper-size 17.0 11.0) ; tabloid For gEDA we have gafrc and gschemrc. Paper size seems to be more related to gschem direct. Indeed, in /usr/share/gEDA/system-gschemrc I see definition of paper sizes, so you may try copy your definition in a (local) gschemrc file. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem ignoring gafrc?
Thanks! That fixed it. Matt On Tue, Feb 10, 2009 at 1:32 PM, Stefan Salewski m...@ssalewski.de wrote: Am Dienstag, den 10.02.2009, 12:06 -0800 schrieb Matt Ettus: In my gafrc file in the current directory, I have the line: (paper-size 17.0 11.0) ; tabloid For gEDA we have gafrc and gschemrc. Paper size seems to be more related to gschem direct. Indeed, in /usr/share/gEDA/system-gschemrc I see definition of paper sizes, so you may try copy your definition in a (local) gschemrc file. ___ 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: gEDA-dev: PCB+GL + **fast polygons!**
**HINT HINT... I WANT FEEDBACK ON THIS BRANCH ...HINT HINT** Now would be the time to grab a copy of the PCB+GL before_pours branch, and have a play to see how it impacts performance on your polygon-intensive board layouts. git clone git://repo.or.cz/geda-pcb/pcjc2.git git checkout -b before_pours origin/before_pours I've seen 170secs of clipping time at load - 10secs on one board, which is nice. ;) Unfortunately, it makes the no-holes dicer much slower (due to the sort of polygon operation it tends to perform - and the extra costs of building / maintaining contour r-trees for all POLYAREA. The GL branch skirts the issue by introducing a new HID API to pass the PolygonType * directly to the render, which plucks out the contours which interesect the viewport and feeds them to the GLUtesselator. This is quite slow at full screen (e.g. probably similar to the current PCB performance - but I didn't benchmark to prove that assertion), and of course.. you don't get the benefit of the no holes polygon cache which I introduced in the branch to improve zooming / panning responsiveness (and any other operations which don't dirty the polygons). If you can stand ugly kludge, the top patch on my local_customisation_no_pours branch implements the extra transparent fill for polygons in thin-draw mode. Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-dev mailing list geda-...@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: order of defparam vs. #(.) parameters in icarus
Matt Ettus wrote: In some Xilinx models, they make instantiations like this: block instance(ports); defparam instance.param=VALUE This normally works ok. The problem is that inside the block, generate statements are being used which are dependent on the value of the parameter. What appears to be happening is that the block is instantiated, and before the defparam line is executed, the decisions are made with the default value of the parameter. The elaboration order of defparams and generate schemes is tricky business and there is a very specific order of events. I put a lot of painful effort into it, but I'm willing to check my work if there is a specific example that generates controversy. -- Steve WilliamsThe woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist verilog back end gnet-verilog.scm
John Griessen wrote: This is probably a Mike Jarabek question: Could be... Sorry for the delay, got swamped. I don't get usable hierarchic netlist output when I have placed schematics and use the gnet-verilog.scm back-end. It drops the module definitions and endmodule statements of the placed symbols that refer to schematics. This is the intended behaviour. The instantiations of the symbols on the page represent instantiations of sub-modules in the design. So, is that the normal behavior, and I need to not use hierarchy, and run gnetlist on every schematic, then cat them together? That could be one way of doing things, but that's not normally how I have seen it done with larger digital designs. (I count modest size FPGA designs too, anything more than a couple of modules.) There seems to be no existing gnetlist concatenate function. Would handling this in scheme be difficult? By this I mean taking all the files referred to by source= attribs and running gnet-verilog.scm on each in order, then putting that to the gnetlist output. gnet-verilog.scm is ready to create a one level netlist -- one module's worth of verilog. If you include a source attribute in your symbols, you will be able to descend into the underlying schematics in gschem, and so will gnetlist, if the heirarchy traversal is enabled. The cost here is that when gnetlist runs, it will flatten the netlist down to the lowest level where there are no source attributes. I don't think this is what you really want though, you will get a single module with duplicated code for every sub module, even if said module is identical to others. Using a makefile is the obvious thought. Make could just take a list or all .sch in a dir and run them and cat them together to a filename. Perhaps you are thinking in too much of a linear way. This is what you probably have to do with a spice deck, but with most Verilog simulators, there is usually a mechanism for a 'manifest' file. I certainly hope that the verilog-ams parser you are using is capable of reading such a file. In practice, this file is simply a list of other file names that make up the design. In a pinch you should be able to craft a master file that does a series of '' 'include filex.v '' reading this master file into the simulator should have the same effect as using cat. Some times the manifest files are automatically generated, you might be able to pull this one off using some make file variables, and some shell code to write out the file. Something along the lines of rm -f manifest ; for i in $(VERILOG_FILES) do echo $i manifest ; done (bash-isms aside) Handling it without make complexity separate from the back end chosen would be nice though, so I ask, Anyone seen existing scheme code that could use source=verilog_io.sch to trigger running it again on the referenced file then outputting that to the same place as usual? I don't see that you should have to do such things, but such a recursive invocation of gnetlist should be possible, at least in theory. Our scheme interpreter has a 'system' call right? Thanks, John Griessen -- Mike Jarabek FPGA/ASIC Designer http://www.sentex.ca/~mjarabek -- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: how to export only part of the schematic into EPS?
Hi, I don't want to export the entire part of my schematic into a EPS image, especially the right bottom part. How can I make it? I remember that I could do it a long time ago, around 2005. When I exported the schematic, I only exported the central part with parts and nets rather than the entire big sheet. Cheers, Forrest -- Forrest Sheng Bao, B.S. EE Ph.D. student/Teaching Assistant, Dept. of Computer Science M.Sc. student/Research Assistant, Dept. of Electrical Computer Engineering Rm 115, Experimental Sciences Building Texas Tech University, Lubbock, Texas, USA [1]http://narnia.cs.ttu.edu References 1. http://narnia.cs.ttu.edu/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: hierarchy: I just don't get it
I made a foo.sch with lots of symbols. The .sym file has a 'source=' attribute and for good measure so does each instance of the symbol. The sub.sch is in the same directory. I have a gafrc: (source-library .) In gschem my symbols appear. I can go 'down' into the symbol. I can go 'down' into the sub.sch named in the source. When I do gsch2pcb (or any gnetlist operation) I only get the few components that are directly in foo.sch. The netlist is empty, none of the subcircuits appear. I can't find anything about the gTAG example that is different from mine. I've tried embedding the symbols but nothing changes. I've added sub.sch to the `project' file but then I just get one orphaned copy of sub.sch and still none of the intended copies. -- Ben Jackson AD7GD b...@ben.com http://www.ben.com/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB + GL latest (patch for indirect rendering support)
Hi Peter and all, Peter Clifton wrote: For those testing the PCB+GL branch git clone git://repo.or.cz/geda-pcb/pcjc2.git git checkout -b before_pours origin/before_pours And to update (easiest I think.. but discards local changes): git fetch git checkout master git branch -D before_pours git checkout -b before_pours origin/before_pours What is: git clone git://repo.or.cz/geda-pcb/pcjc2.git git checkout --track -b before_pours origin/before_pours ?? BTW: Peter, I just recently got a replacement DSL router from the phone company, so I'm behind on testing your stuff. Still have to reconnect the Fedora box. Wireless laptop with Vista (bweerk, cough, cough, ... hairball) has to do for now. BTW2: IMHO, now would be a good time to get your OpenGL branch in the gplgeda.org/pcb.git repo as a separate HID and/or branch as to lower the treshold for testing. (just swap branches and recompile :-) Kind regards, Bert Timmerman. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: What is the logic in gnetlist/spice-sdb when to add a 'X' prefix to an identifier?
On Sun, Feb 8, 2009 at 1:13 PM, al davis ad...@freeelectron.net wrote: On Sunday 08 February 2009, Christoph Lechner wrote: How can it know? Well, I thought: maybe there's some attribute dedicated to this case ... The Spice netlister is loaded with special cases, because the Spice syntax is loaded with special cases. I recommend that you add the X on the schematic. Doesn't the netlister just pass the label through? Not really. If I call the diode XD108, the netlister calls it DXD108. *%^(*^Z^^^(^%((% Like I say This is one of the reasons that those in the know are pressuring for a shift away from the Spice format. Wouldn't it be a work-around to call the diode U108? I'll try that. No. Then you will get DU108. How about a plugin for gschem. It user would flag parts on a schematic as using subcircuits. There should be a script to go threw and slap an X before the refdes name or remove them at will? On Sunday 08 February 2009, al davis wrote: I have been thinking of changing it to ignore the letter when the model name gives enough information to determine the type. That does it .. I guess the only sane thing to do is to make the change. It really makes it easier to ignore the letter, considering plugin conflicts. It is really worse than it looks on the surface. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- http://www.coe.neu.edu/~efoss/ http://evanfoss.googlepages.com/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
