Re: gEDA-user: Functional blocks and PCB format changes
On Sat, Sep 04, 2010 at 01:16:01AM -0400, Rick Collins wrote: > But I suppose it is better to re-invent the wheel. There is no reason to > try to foster any sort of compatibility in file formats between all the > different CAD tools. There are always conversion programs to be written, > no? > > Rick Please note: I am not saying this for or against XML. I just felt like the above sentences implied using a specific file format is an ultimate solution for compatibility. Please always read "XML" as "any standard or widespread format, text or binary, for example json, plist, sql dumps, whatever". Using xml as file format for PCB (or any CAD program) will not automatically make it compatible with any other CAD program. I see two different things here. 1. Use a file format that is well documented and known (this can be a standard format like XML, json, plist, or a custom format with proper documentation). 2. How the content is actually represented. Point 1. is a basis, a must. Without that, we can not talk about making two programs compatible, since the data can not be read or written by the other program. However, just being able to read the file, but not understanding what they mean, won't make any compatibility. Thus point 2. is a must too. XML may or may not be a good solution for 1., but doesn't do _anything_ to 2. The current file format is plain text and documented enough (in worst case by the source code) that any developer has the chance to parse or generate it, this it also fulfills the reqiurements in 1. Switching (or not switching) to XML will not make a real difference in compatibility. Switching to any standard format may ease implementation as one doesn't need to write a custom parser. But don't overestimate this part either: using a parser generator helps a lot, and even going without that, I strongly believe that finally the real complex and big part of the work is 2., not 1. Making two CAD programs compatible is harder on the "how we represent the design internally" level than "how do we convert the representation to an actual file format". Regards, Tibor Palinkas ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
> The "heavy" issue is a red herring The "heavy" issue impacts the difficulty in using XML as a toolkit. > But I suppose it is better to re-invent the wheel. There is no > reason to try to foster any sort of compatibility in file formats > between all the different CAD tools. That's a real red herring, since nearly all non-free cad tools use proprietary binary formats anyway. There's nothing to be compatible *with*. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
> 1. Refuse to export-as-footprints any PCB with more than one copper >layer. This will likely eliminate the most common problems. Edge connectors. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
> If we tagged individual objects with rules it would be difficult to edit > rules in a systemetic way. So I don't think that's a good way to go. No, we tag objects with rule *names*. Hopefully rules can nest, so you can have meta-rules like "signal-line-rule" or "12vac rule". Without a tag, you'd get synthetic tags like "line-rule" or "pin-rule". > Speed might be a problem, but again, Lisp would be a huge boon to this, > if only because of the immense amount of AI-related stuff out there. gschem uses a lot of lisp (in the guise of Guile). No thanks. Despite PCBs being object oriented, they're not *data* oriented like Lisp is. > C++ would be a definite improvement. However, it's a scary-huge language No, it's not. It has much more *capability* than C but you don't *have* to use it all. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
> What level of self proving would Andrew need to do to be eligible for > Linux Fund payment? LF work is a contract between LF and the developer. It's up to the developer to prove themselves to LF, not to us. > How's the fund doing these days? Must still be lower than one > action item, or we would have heard, I bet. We need to do a release so the "done work" can be considered closed. I need to find time for that too :-P ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
Given the choice between lisp (lol) and xml, the winner is absolutely clear. There are even less lisp users than there are Linux users, and that's a sad statistic. -tc On Sat, Sep 4, 2010 at 2:16 PM, Rick Collins wrote: > At 12:11 AM 9/4/2010, you wrote: >> >> On Fri, Sep 03, 2010 at 11:29:58PM -0400, Rick Collins wrote: >> > XML? What's wrong with XML? Heavy? How heavy are a few electrons >> > anyway? >> > >> >> For most data, XML ends up being > 50% tags (and < 50% data). It's hard to >> read for humans, bandwidth-intensive for machines, difficult to parse and >> generally ugly. >> >> Plus, the entire spec is enormous, and using only a subset of the spec >> means that we've lost a lot of the compatibility arguments in favor of >> it. >> >> >> Andrew > > Don't hold back, tell us how you really feel! > > The spec is large because it addresses a wide range of design aspects, which > is one of the great reasons for using it, one file for the entire design, > schematic, layout, mechanical, etc, even board lay up. So the compatibility > issue is moot because any one app only needs to deal with the portion that > applies to it. Just don't muck with the other parts. > > The "heavy" issue is a red herring (are you planning on hosting this on a > cell phone maybe?) No PCB file format is going to be easy for humans to > read. Bandwidth? Back to the MCU in the cell phone I guess. "Ugly", now > there is a great technical argument. > > But I suppose it is better to re-invent the wheel. There is no reason to > try to foster any sort of compatibility in file formats between all the > different CAD tools. There are always conversion programs to be written, > no? > > Rick > > > ___ > 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: Functional blocks and PCB format changes
At 12:11 AM 9/4/2010, you wrote: On Fri, Sep 03, 2010 at 11:29:58PM -0400, Rick Collins wrote: > XML? What's wrong with XML? Heavy? How heavy are a few electrons anyway? > For most data, XML ends up being > 50% tags (and < 50% data). It's hard to read for humans, bandwidth-intensive for machines, difficult to parse and generally ugly. Plus, the entire spec is enormous, and using only a subset of the spec means that we've lost a lot of the compatibility arguments in favor of it. Andrew Don't hold back, tell us how you really feel! The spec is large because it addresses a wide range of design aspects, which is one of the great reasons for using it, one file for the entire design, schematic, layout, mechanical, etc, even board lay up. So the compatibility issue is moot because any one app only needs to deal with the portion that applies to it. Just don't muck with the other parts. The "heavy" issue is a red herring (are you planning on hosting this on a cell phone maybe?) No PCB file format is going to be easy for humans to read. Bandwidth? Back to the MCU in the cell phone I guess. "Ugly", now there is a great technical argument. But I suppose it is better to re-invent the wheel. There is no reason to try to foster any sort of compatibility in file formats between all the different CAD tools. There are always conversion programs to be written, no? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
On Fri, Sep 03, 2010 at 04:44:14PM -0700, Andrew Poelstra wrote: > >However, this also brings the ability to edit PCB components individually, >which means that some parts could have different layers than others, for >example. And then you have to deal with layer mappings and stuff and it's >a huge complicated mess, both for the user and in the code. > For layer mappings, things don't necessarily have to be difficult. Especially if we had a good file format, people could write their own scripts if they want to do crazy things. In the meantime, we could: 1. Refuse to export-as-footprints any PCB with more than one copper layer. This will likely eliminate the most common problems. 2. As for PCB components that are themselves PCBs (ie, recursive PCBs), we could present the user with a mapping dialog when he tries to import a sub-PCB. The dialog would look something like (when importing a 6-layer sub-PCB into a 5-layer PCB): Imported PCB Current PCB Silk --> Silk Top--> Top Layer One --> Layer One Layer Two --> Layer Two Layer Three--> Bottom Bottom --> *New Layer...* The left-hand column is read-only. The right-hand column consists of drop-down boxes listing all the existing layers. Selecting *New Layer...* would pop up the New Layer dialog. We could even store this mapping information in the .pcb file and allow the user to change it after-the-fact. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus verilog Synthesis
Hi, Thanks for the response. I was under the impression that Icarus was moving towards synthesis capability. I have the 0.8.1 Icraus version with me. I have made the source code compilable in Visual Studio 2005 though its not fully complete. May I know the reason as to why synthesis capability is being dropped ? I am really interested in making Icarus synthesizable. Here is my idea: I transform the Verilog code containing behavioral statements into verilog code that contains only gate level instantiations. This is passed as input to ABC Logic synthesis tool. Finally the output generated by ABC is passed to Versatile Place and Route(VPR) program which generates the bitstream. Regards, Ronald On 9/4/10, Stephen Williams <[1]st...@icarus.com> wrote: What are you trying to do? Are you really trying to "synthesize" your Verilog design, meaning you are trying to generate a bit stream to load into your FPGA? Or are you trying to compile and simulate your Verilog? Icarus Verilog is mostly a *simulator*, not a synthesizer. There were some synthesis capabilities back in the 0.8 release, but that support has been largely dropped in the 0.9 releases or current devel branch. Verilog code generator? OK, this suggests that you really are trying to *synthesize* (and not simulate) and no, not even the 0.8 release supported synthesis of user defined tasks. Ronald Mathias wrote: >Hi, > > > >I have written a verilog code that makes use of a user defined task to >do some computation. The task takes two parameters as input and one >parameter as output. > > > >When I try to synthesize it, I get the following error: > > > >internal error: NetProc::nex_output not implemented on object >type NetUTask > >internal error: NetProc::nex_output not implemented on object >type NetUTask > >Does this mean that icarus verilog has not yet support for synthesis of >user defined tasks? > >When I try to send the elaborated netlist to the verilog code generator >back end, the task definition is missing from the output. > >Is this a bug or the verilog code generator backend is still not >completely implemented ? > >Regards, > >Ronald -- Steve Williams"The woods are lovely, dark and deep. steve at [2]icarus.com But I have promises to keep, [3]http://www.icarus.com and lines to code before I sleep, [4]http://www.picturel.com And lines to code before I sleep." ___ geda-user mailing list [5]geda-u...@moria.seul.org [6]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:st...@icarus.com 2. http://icarus.com/ 3. http://www.icarus.com/ 4. http://www.picturel.com/ 5. mailto:geda-user@moria.seul.org 6. 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: Functional blocks and PCB format changes
On Fri, Sep 03, 2010 at 11:29:58PM -0400, Rick Collins wrote: > XML? What's wrong with XML? Heavy? How heavy are a few electrons anyway? > For most data, XML ends up being > 50% tags (and < 50% data). It's hard to read for humans, bandwidth-intensive for machines, difficult to parse and generally ugly. Plus, the entire spec is enormous, and using only a subset of the spec means that we've lost a lot of the compatibility arguments in favor of it. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
On Fri, Sep 03, 2010 at 11:00:43PM -0400, DJ Delorie wrote: > > Re: functional blocks > > If we contemplate changing the PCB file format, it would be nice if we > went with something that was intrinsically extensible. Knowing that > the 5th element in a list with '[' means "clearance" is a bad format, > but seeing "clearance=5mil" in a list of attributes is much better. > We use something suitable as our menu resource, but folks have argued > for XML too. I don't want to bring in something as heavy and complex > as XML, but maybe a small parser like our resource parser that "just > happened" to use XML format would buy us some usefulness at low cost. > XML is far too heavy, agreed, and it's signal-to-noise ratio is abysmal. I think that using a Lisp (or Lispy-looking) format would be extensible, easy to parse, and make the most people happy. Plus, it would make it very easy to manipulate PCBs in Lisp, which is a far nicer language to work with than Perl, which AFAICT is the most common language for gEDA hacking. > For performance reasons, it might be useful to have both an ASCII and > a compiled binary format for these, with a converter. I've done stuff > like this before; parsing a huge ascii file is a CPU hog compared to > something designed to be digested by a program. > > Note we already have the ability to store attributes at the layout, > layer, and element level. Perhaps that would be one place to hold new > DRC rules? If we tagged the rulesets, we could then assign those tags > to objects on the board, although storing such tags means a file > format change. Maybe the new format can specify mandatory stuff as > the first few non-tagged values (like line start/end coordinates) and > have everything else be tagged after that (like clearance=1mm) so it's > more free-form? We'd need some meta-rules for specifying defaults. > I made another post to this list wherein I suggested structuring DRC rules as objects in their own right: consisting of a filter (what it affects) and a rule (what it requires). If we tagged individual objects with rules it would be difficult to edit rules in a systemetic way. So I don't think that's a good way to go. > Re: DRC > > Our DRC engine could use a complete rewrite. It doesn't get arcs > right, for example. It would be nice if it told us the *actual* > design rules used (what's the closest cross-net spacing? Smallest > drill? Etc) too. > Speed might be a problem, but again, Lisp would be a huge boon to this, if only because of the immense amount of AI-related stuff out there. > ... > > Some of that work can be made easier to code if we switch to C++ > officially so we can use a real OO language instead of the OO hack we > currently have. There's a patch in the tracker to make the code > C++-compatible, someone (i.e. me) needs to review it so we can get it > committed and start seeing who'll have problems if we switch to C++. > C++ would be a definite improvement. However, it's a scary-huge language and I'm not sure the pros would outweigh the cons. (Of course, it's a far easier port than any other language would be.) There aren't a lot of other compiled languages to consider, though, that would do what we want with the speed that we need. What is the opinion of D in this group? > Then you could have each object know how to draw itself (or part of > itself, usually by layers) just by foo->draw(). I don't think this is > *needed* though. We just need a new object type that is itself a PCB > (or at least the PCB->Data structure, like a Buffer), a way to nest > all the draw/find/select etc stuff, and a way to tell the GUI which > object(s) you're editing. That automatically gives you a footprint > editor too :-) > Agreed, but given the pain it would take to create a workable PCB object, I think we'd be better off just going to a real OO language. > If you'd rather work on the GUI, though, that's also a needed project. > It would be nice if the GTK gui supported all the modern Gnome stuff, > like dockable toolbars and menus-with-icons. The SOW has an entry for > that also. > I really don't want to do GUI work, but I'm finding it's necessary to developing functional blocks. Mainly because without GUI support, having functional blocks is nearly useless. And in the process, I'm learning Gtk and GUI development in general. And learning is always a good thing :). For now, modernizing the entire GUI is well beyond my abilities. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
XML? What's wrong with XML? Heavy? How heavy are a few electrons anyway? There is already a preliminary XML based CAD data spec proposed by IPC, you know, the guys who write specs for the PCB assembly industry... I don't know if it is the best thing ever invented and I expect the spec is not complete enough for everyone to make their data files 100% compatible without a lot of communication, but wouldn't it be a great idea to at least start on a path which could result in a common data base for CAD packages? What a concept! The spec I have seen that looks like it would apply is IPC-2511B. These things don't seem to be free, but I found this one somewhere, maybe on the IPC site. Rick At 11:00 PM 9/3/2010, you wrote: Re: functional blocks If we contemplate changing the PCB file format, it would be nice if we went with something that was intrinsically extensible. Knowing that the 5th element in a list with '[' means "clearance" is a bad format, but seeing "clearance=5mil" in a list of attributes is much better. We use something suitable as our menu resource, but folks have argued for XML too. I don't want to bring in something as heavy and complex as XML, but maybe a small parser like our resource parser that "just happened" to use XML format would buy us some usefulness at low cost. For performance reasons, it might be useful to have both an ASCII and a compiled binary format for these, with a converter. I've done stuff like this before; parsing a huge ascii file is a CPU hog compared to something designed to be digested by a program. Note we already have the ability to store attributes at the layout, layer, and element level. Perhaps that would be one place to hold new DRC rules? If we tagged the rulesets, we could then assign those tags to objects on the board, although storing such tags means a file format change. Maybe the new format can specify mandatory stuff as the first few non-tagged values (like line start/end coordinates) and have everything else be tagged after that (like clearance=1mm) so it's more free-form? We'd need some meta-rules for specifying defaults. Re: DRC Our DRC engine could use a complete rewrite. It doesn't get arcs right, for example. It would be nice if it told us the *actual* design rules used (what's the closest cross-net spacing? Smallest drill? Etc) too. Re: recursive PCBs I think the first step in this type of change is to tag layers by type. I've spec'd this out before, I think, and it's the "Upgrade of layer and design objects" in our big "statement of work" (SOW): http://www.geda.seul.org/wiki/geda:pcb_funding_sow Those items are approximately in do-in-this-order order, but the GUI stuff can go anywhere. Anyway, layer design tags each layer with a type, such as "top side silk" or "inner keepout" (a combination of a "where" and a "what", and optional "invert"). This is the basis for elements-as-pcbs and nested pcbs. The tricky part is not the data structures, but mapping the various layers in each submodule. For example, if you imported a two-layer board module into a four-layer board, what happens? Or an element description with "keepaway" on "all inner layers", how does that map to a six-layer board? Etc. Some of that work can be made easier to code if we switch to C++ officially so we can use a real OO language instead of the OO hack we currently have. There's a patch in the tracker to make the code C++-compatible, someone (i.e. me) needs to review it so we can get it committed and start seeing who'll have problems if we switch to C++. Then you could have each object know how to draw itself (or part of itself, usually by layers) just by foo->draw(). I don't think this is *needed* though. We just need a new object type that is itself a PCB (or at least the PCB->Data structure, like a Buffer), a way to nest all the draw/find/select etc stuff, and a way to tell the GUI which object(s) you're editing. That automatically gives you a footprint editor too :-) If you'd rather work on the GUI, though, that's also a needed project. It would be nice if the GTK gui supported all the modern Gnome stuff, like dockable toolbars and menus-with-icons. The SOW has an entry for that also. ___ 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: Functional blocks and PCB format changes
DJ Delorie wrote: If you'd rather work on the GUI, though, that's also a needed project. It would be nice if the GTK gui supported all the modern Gnome stuff, like dockable toolbars and menus-with-icons. The SOW has an entry for that also. What level of self proving would Andrew need to do to be eligible for Linux Fund payment? How's the fund doing these days? Must still be lower than one action item, or we would have heard, I bet. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
Re: functional blocks If we contemplate changing the PCB file format, it would be nice if we went with something that was intrinsically extensible. Knowing that the 5th element in a list with '[' means "clearance" is a bad format, but seeing "clearance=5mil" in a list of attributes is much better. We use something suitable as our menu resource, but folks have argued for XML too. I don't want to bring in something as heavy and complex as XML, but maybe a small parser like our resource parser that "just happened" to use XML format would buy us some usefulness at low cost. For performance reasons, it might be useful to have both an ASCII and a compiled binary format for these, with a converter. I've done stuff like this before; parsing a huge ascii file is a CPU hog compared to something designed to be digested by a program. Note we already have the ability to store attributes at the layout, layer, and element level. Perhaps that would be one place to hold new DRC rules? If we tagged the rulesets, we could then assign those tags to objects on the board, although storing such tags means a file format change. Maybe the new format can specify mandatory stuff as the first few non-tagged values (like line start/end coordinates) and have everything else be tagged after that (like clearance=1mm) so it's more free-form? We'd need some meta-rules for specifying defaults. Re: DRC Our DRC engine could use a complete rewrite. It doesn't get arcs right, for example. It would be nice if it told us the *actual* design rules used (what's the closest cross-net spacing? Smallest drill? Etc) too. Re: recursive PCBs I think the first step in this type of change is to tag layers by type. I've spec'd this out before, I think, and it's the "Upgrade of layer and design objects" in our big "statement of work" (SOW): http://www.geda.seul.org/wiki/geda:pcb_funding_sow Those items are approximately in do-in-this-order order, but the GUI stuff can go anywhere. Anyway, layer design tags each layer with a type, such as "top side silk" or "inner keepout" (a combination of a "where" and a "what", and optional "invert"). This is the basis for elements-as-pcbs and nested pcbs. The tricky part is not the data structures, but mapping the various layers in each submodule. For example, if you imported a two-layer board module into a four-layer board, what happens? Or an element description with "keepaway" on "all inner layers", how does that map to a six-layer board? Etc. Some of that work can be made easier to code if we switch to C++ officially so we can use a real OO language instead of the OO hack we currently have. There's a patch in the tracker to make the code C++-compatible, someone (i.e. me) needs to review it so we can get it committed and start seeing who'll have problems if we switch to C++. Then you could have each object know how to draw itself (or part of itself, usually by layers) just by foo->draw(). I don't think this is *needed* though. We just need a new object type that is itself a PCB (or at least the PCB->Data structure, like a Buffer), a way to nest all the draw/find/select etc stuff, and a way to tell the GUI which object(s) you're editing. That automatically gives you a footprint editor too :-) If you'd rather work on the GUI, though, that's also a needed project. It would be nice if the GTK gui supported all the modern Gnome stuff, like dockable toolbars and menus-with-icons. The SOW has an entry for that also. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
Andrew Poelstra wrote: However, this also brings the ability to edit PCB components individually, which means that some parts could have different layers than others, for example. And then you have to deal with layer mappings and stuff and it's a huge complicated mess, both for the user and in the code. Dang! It IS a huge complicated mess. But then, you could not try to please all, and it can simplify down to "use some external script to do remappings of reused components that have different layers", and the excitement pops right back up. JG -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Functional blocks and PCB format changes
Hey all, I am working on the structuring PCB files in terms of functional blocks, and generalizing/extending the DRC rule format. (Things have slowed down as summer is ending but I am still working on this.) Mostly I am doing GUI work, since that is more-or-less stateless; I can spend 20 minutes reading docs or GTK code and not worry about making it work with PCB. But for the underlying logic: Naturally, I want to avoid any breaking changes to the PCB format, both to increase the chances of my code being accepted, as well as the obvious compatibility reasons. So I have a few thoughts: 1. Initially my plan was to tag every object in the PCB with a functional block. This would make attaching multiple tags easy, though it might bloat the file, and would be slow to initially parse and search. 2. Another idea would be to create functional blocks as "recursive PCBs". This has been mentioned a few times on the list, and creates all sorts of exciting possibilities - from importing recursive schematics to reusing layout parts to clearer source control of PCBs. However, this also brings the ability to edit PCB components individually, which means that some parts could have different layers than others, for example. And then you have to deal with layer mappings and stuff and it's a huge complicated mess, both for the user and in the code. What do you guys think I should do? What would require the fewest changes to the PCB format, if any? Generalized DRC rules at least could be tacked on anywhere and would be quietly ignored by old versions of pcb, right? Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Color silk layers in pcb
On Fri, Sep 03, 2010 at 06:40:05PM +0200, Pawel Kusmierski wrote: > > Is anybody willing to elaborate on how difficult would it be > to modify the pcb source code to color-differentiate three or four > silk layers and be able to selectively hide/show them? > It will probably be more work than it should be, since there is special logic in place to handle the silk and via layers, and a switch statement in nearly every layer-handling function to deal with it. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus verilog Synthesis
What are you trying to do? Are you really trying to "synthesize" your Verilog design, meaning you are trying to generate a bit stream to load into your FPGA? Or are you trying to compile and simulate your Verilog? Icarus Verilog is mostly a *simulator*, not a synthesizer. There were some synthesis capabilities back in the 0.8 release, but that support has been largely dropped in the 0.9 releases or current devel branch. Verilog code generator? OK, this suggests that you really are trying to *synthesize* (and not simulate) and no, not even the 0.8 release supported synthesis of user defined tasks. Ronald Mathias wrote: >Hi, > > > >I have written a verilog code that makes use of a user defined task to >do some computation. The task takes two parameters as input and one >parameter as output. > > > >When I try to synthesize it, I get the following error: > > > >internal error: NetProc::nex_output not implemented on object >type NetUTask > >internal error: NetProc::nex_output not implemented on object >type NetUTask > >Does this mean that icarus verilog has not yet support for synthesis of >user defined tasks? > >When I try to send the elaborated netlist to the verilog code generator >back end, the task definition is missing from the output. > >Is this a bug or the verilog code generator backend is still not >completely implemented ? > >Regards, > >Ronald -- Steve Williams"The 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: Color silk layers in pcb
No, FreePCB is a separate project with no links in any way. I have used it for a couple of projects and like it pretty well, but it is hard to get changes made. The developer was on a hiatus for some time, but is back now. He has a long list of bug fixes and suggestions people would like to see implemented. He also has some philosophical difference with me. I would consider creating my own branch of the project, but I don't own the tools to build it with and no one has done that yet, so I don't know how well it would be received. I don't want to muddy the waters with different versions, even if they are just small UI changes, unless we can find a way to make it part of the main branch with perhaps build options or something. In the meantime I am working on the wiki as my small contribution. Too bad it is down... :^( I may also help with some peripheral tools such as a BOM/xyrs file manager. The one someone else contributed does not fully utilize the info potentially available from the schematic. I know pretty much nothing about PCB so I can't even give you a basic comparison of the two. I am here to try to learn what this is about and where it is going. Maybe I'll want to get on board at some point. Rick At 05:40 PM 9/3/2010, you wrote: On Fri, Sep 3, 2010 at 6:49 PM, Rick Collins wrote: > I can't answer your question, but I have one of my own. I use FreePCB and > have requested, along with others, that we be able to designate layers as > "documentation" such as assembly info, mechanical details, etc. Is that > what you are looking for or do you want these layers to be usable to produce > the silk screen Gerber files? I suppose once the layers are created, it > would not be any extra effort to allow them to be used in the Gerber file. > Does PCB have the ability to combine multiple layers into a single Gerber > file? That would do the trick. I just want to have more than two silk layers and be able to tell them apart by color. That would make it just so much easier to design a pcb that would fit into a case, and know where to cut holes in it at the same time. By the way, is FreePCB related to gEDA pcb in any way? Kind regards, -- Pawel Kusmierski ___ 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: Color silk layers in pcb
On Fri, Sep 3, 2010 at 6:49 PM, Rick Collins wrote: > I can't answer your question, but I have one of my own. I use FreePCB and > have requested, along with others, that we be able to designate layers as > "documentation" such as assembly info, mechanical details, etc. Is that > what you are looking for or do you want these layers to be usable to produce > the silk screen Gerber files? I suppose once the layers are created, it > would not be any extra effort to allow them to be used in the Gerber file. > Does PCB have the ability to combine multiple layers into a single Gerber > file? That would do the trick. I just want to have more than two silk layers and be able to tell them apart by color. That would make it just so much easier to design a pcb that would fit into a case, and know where to cut holes in it at the same time. By the way, is FreePCB related to gEDA pcb in any way? Kind regards, -- Pawel Kusmierski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: error while loading shared libraries: libltdl.so.3:
k...@kdream.com: > k...@red:/home/backup/Work/BuddiPole/Schematic/condisp $ gschem > condisp-*.sch > gschem: error while loading shared libraries: libltdl.so.3: cannot open > shared object file: No such file or directory ... > So do I have to reinstall the whole gEDA system? You could try to find the missing libs. You need the libltdl3 package. Download the .deb file, from an ubunto or debian mirror and try to dpkg -i it, hopefully there will be no installation conflicts -- or you could compile it from source if that fails. In debian the package file is eg. in http://ftp.se.debian.org/debian/pool/main/libt/libtool/libltdl3_1.5.26-4+lenny1_i386.deb You could probably replace ftp.se.debian.org with a suitable ubunto mirror. Regards, /Karl Hammar - Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: error while loading shared libraries: libltdl.so.3:
I upgraded my Ubuntu 08.04 to 10.04 and now gschem will not work. k...@red:/home/backup/Work/BuddiPole/Schematic/condisp $ gschem condisp-*.sch gschem: error while loading shared libraries: libltdl.so.3: cannot open shared object file: No such file or directory I checked Synaptic Package manager and it says libtdl7 is installed. I did find this: libltdl3: Package libltdl3 has no available version, but exists in the database. This typically means that the package was mentioned in a dependency and never uploaded, has been obsoleted or is not available with the contents of sources.list So do I have to reinstall the whole gEDA system? What is the best way to do this? Kip -- Kipton Moravec AE5IB .- . . .. -... "Always do right; this will gratify some people and astonish the rest." --Mark Twain ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Color silk layers in pcb
I can't answer your question, but I have one of my own. I use FreePCB and have requested, along with others, that we be able to designate layers as "documentation" such as assembly info, mechanical details, etc. Is that what you are looking for or do you want these layers to be usable to produce the silk screen Gerber files? I suppose once the layers are created, it would not be any extra effort to allow them to be used in the Gerber file. Does PCB have the ability to combine multiple layers into a single Gerber file? Rick At 12:40 PM 9/3/2010, you wrote: On Fri, Sep 3, 2010 at 1:51 PM, Stefan Salewski wrote: > On Fri, 2010-09-03 at 11:53 +0200, Pawel Kusmierski wrote: > > Dear fellow GEDA-users, > >Can I get pcb to either treat a layer other than the default silk as > >non-metal > >(so it would not short pads and mess up nets), > Please note, your SUBJECT may be misleading... > > No, currently we have only one silk layer. You may "miss-use" other > copper layers for that task -- it may work when that layer is not in > your real copper layer groups, but unfortunately it still connects to > vias and can generate shorts. I did that for visual marks, distinct from > other silk marks, and I copy that layer to silk before gerber > production. (Some of us hope that sometimes we will have general propose > layers, so that we can select type and other parameters separate...) > Thanks for your answer Stefan. I have my visual marks just over vias, and it shorts them together, so I will look for some other solution. Is anybody willing to elaborate on how difficult would it be to modify the pcb source code to color-differentiate three or four silk layers and be able to selectively hide/show them? Kind regards, -- Pawel Kusmierski ___ 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: Color silk layers in pcb
On Fri, Sep 3, 2010 at 1:51 PM, Stefan Salewski wrote: > On Fri, 2010-09-03 at 11:53 +0200, Pawel Kusmierski wrote: > > Dear fellow GEDA-users, > > Can I get pcb to either treat a layer other than the default silk as > > non-metal > > (so it would not short pads and mess up nets), > Please note, your SUBJECT may be misleading... > > No, currently we have only one silk layer. You may "miss-use" other > copper layers for that task -- it may work when that layer is not in > your real copper layer groups, but unfortunately it still connects to > vias and can generate shorts. I did that for visual marks, distinct from > other silk marks, and I copy that layer to silk before gerber > production. (Some of us hope that sometimes we will have general propose > layers, so that we can select type and other parameters separate...) > Thanks for your answer Stefan. I have my visual marks just over vias, and it shorts them together, so I will look for some other solution. Is anybody willing to elaborate on how difficult would it be to modify the pcb source code to color-differentiate three or four silk layers and be able to selectively hide/show them? Kind regards, -- Pawel Kusmierski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Color silk layers in pcb
On Fri, 2010-09-03 at 11:53 +0200, Pawel Kusmierski wrote: > Dear fellow GEDA-users, >Can I get pcb to either treat a layer other than the default silk as >non-metal >(so it would not short pads and mess up nets), Please note, your SUBJECT may be misleading... No, currently we have only one silk layer. You may "miss-use" other copper layers for that task -- it may work when that layer is not in your real copper layer groups, but unfortunately it still connects to vias and can generate shorts. I did that for visual marks, distinct from other silk marks, and I copy that layer to silk before gerber production. (Some of us hope that sometimes we will have general propose layers, so that we can select type and other parameters separate...) Best regards Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Color silk layers in pcb
Dear fellow GEDA-users, Can I get pcb to either treat a layer other than the default silk as non-metal (so it would not short pads and mess up nets), or draw "different" silk layers as separate objects, in different colors? My problem is following: I have a case consisting of two haves, upper and lower. I'm in ecstasy, because I managed to transform the manufacturer's drawing to a pcb file using proper scale with pstoedit. Now I have to-scale drawing of both halves, and I was happily using different colors for them, having them on a different layers. I was able to hide either or both, until it became clear, that they are treated as metal, even when not visible, and are short-circuiting my signals, which is a pain. I moved them to the silk layer, but then I can not tell what is what. I also tried manualy editing the pcb file, and renamed the layers to silk, but it didn't help much. Is there an easy way (configuration) or just the hard way (code)? If only the hard, where does one start, and is it something on an order of horus, days or weeks? Thank you if you got that far, and in advance, for the answer. -- Pawel Kusmierski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
