Re: gEDA-user: Design Flow Roadmap starting point
On Sun, 18 Mar 2007, al davis wrote: >> * Finally, how should PCB behave with a hierarchical >> schematic? > >Right click on a symbol, select "go inside", and another drawing >opens up showing what's inside. gschem also should act this >way. I like this idea very much. In case of PCB it also would make sense to add a way to display in place what's inside. With an "expand all" functionality this would allow one to see the whole pcb with all inner structures at once, without needing to export to ps. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
On Saturday 17 March 2007 00:13, John Griessen wrote: > David Baird wrote: (about data tie ins to higher > abstractions than "just boards")jg I've been thinking (maybe > just dreaming?) about an extensible system which allows the > representation of information which has not yet even been > envisioned, while also providing forwards and backwards > compatibility as new component representations are devised. > For these reasons, OWL struck me somewhat and now I am > learning OWL and trying to see if I can really make it do > what I want. -- A simple example -- convey to a PCB > program that a set of nets are actually grouped That's why gnucap is using plugins now. I assume that's the reason for PCB, too. I think gnucap's approach is more aggressive, in the sense that everything is moving to plugins, making the system completely user configurable. > Stuart Brorson wrote: >The discussion about hierarchy should focus on the > following points: > > * What kind of data structures are desirable? How would > they look? Right now, the main data structure for a schematic > is a linear linked list of graphical objects (for each > schematic page). Some list items point to others (i.e. to > support component attributes). How would that change to > support hierarchy? > > * ONce a datastructure is decided upon, then what does the > file format look like? Note that our current file format > maps fairly closely onto the internal data structures. > Preserving this close mapping is a desirable goal. > Therefore, the data structures defining hierarchy should > more-or-less dictate what the file format should look like. You have the order backwards. Design the file format first, then the data structures. The file format should be designed as a language for expressing what you want to express. If the thing being expressed is a printed circuit board, the language should be meaningful and expressive in that context. If the data structures are already designed, I still say design the file format "first" in the sense that it should ignore the data structures. Fitting the file format to the data structures permanently locks you to the mistakes of the first cut. Designing the file format description language first leaves you free to change the underlying algorithms and data structures later. File formats that are data structure dumps cause big problems in the long run. I still believe we need an interchange file format, that should be a VHDL derivative. VHDL has most of the capabilities needed, and is an industry standard. If something is missing, we can add it, and propose it back to the standards committee. They might even welcome it. gnetlist really needs to be redone, from the ground up. This VHDL based intermediate format is the way to do it. gnetlist has served us well so far, but we have learned a lot by doing it and using it, and it is time to move on. > * How should gschem behave once hierarchy is architected in? > Right now you attach a source= attribute to a symbol. Then > you do "schematic down" on that symbol to dive into the > sub-schematic. Is that OK? Or what's a better scheme? > > And how to handle re-use blocks? That is, if I have a > sub-schematic which I instantiate four times, how should it > be refdesed in the netlist? If I dive into one of the four > instantiations and edit it, is it OK that the other three > instantiations are also updated. > > A list of use-cases would be helpful here. > > * Similarly, how should gnetlist behave? A use-case list > would be useful. Any extraction should preserve hierarchy, in hopes that the target tool also benefits from it. If it doesn't, you need a separate flattener pass, separate from the translation. Regardless, the translation must be 100%, lossless, in both directions. gschem attributes need to have types. The type is just a string, but important. That way one type can be those passed to a simulator, another can be those passed back from the simulator, etc. Since the type is just a string, new types can be added at any time. An attribute should be able to have multiple types. > * Finally, how should PCB behave with a hierarchical > schematic? Right click on a symbol, select "go inside", and another drawing opens up showing what's inside. gschem also should act this way. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
My imediate use for recessing has to do with ridged flex riged boards. In one example we have a circuit board that has for example a ridged section on the right that has a connector, this section has to have one level of thickness. connected to this ridged is a section of flex, on the other side of the section of flex these is a section of ridged material that has a flip chip a resistor and a few capacitors. This second ridged section has a different thickness then the first. It is thinner and we achieve this by having few layers. Continuing on we have another section of flex and then a final section of ridged. This last section of ridged has yet a third thickness then the other two ridged sections. All of this is constructed in layers that are glued and pressed together. So we cut out different holes out of the different layers before aligning them and gluing them and pressing them. Problem is that the pads have to be on different layers. We over came this by pretending at layout that they were different boards and getting the shop to merge the gerbers. I think there is a second reason, (note the i think) in that some very high frequency devices have pins that stick streight out their sides so as to avoid bends. But that these devices also would like to be heat sinked to the ground plane. This is again an I think and I am looking for an example. Steve M. DJ Delorie wrote: >> Yes fab shops can cnc the layers before gluing and pressing them >> together. >> > > Drool. Yeah, you'd need the "layer types" patch to really manage > that, as you'd be able to tag multiple pcb layers as "outline" layers > and associate them with specific board layers or whatnot. > > You could do it now, except that they'd have all the pins' copper on > them as well as the outline. > > The only thing you can't do already is tell pcb to put elements on > inner layers. > > Of course, I'm curious *why* you need to recess parts... > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog with Xilinx simprims...
Wow, thanks for the quick responses ! > Does iverilog support SDF backannotation? The SDF has the delay > information. Ah ! Now you mention it, I remember removing a $sdf_annotate line from the generated verilog file. It was causing an error with vvp, so I just removed the offending line and quickly forgot about it... The error is: "$sdf_annotate: This task is not defined by any modules." I just found a topic about iSDF in this mailing list; I will see what I can do with that. > Any specific reason why you're running a post-fit simulation? The > RTL simulation tells you if your logic is functionally correct, and > the static timing analyzer (using your timing constraints) tells you > if you've met timing. If both are good, there's no need to run a > post-fit simulation. Well, that's where I'm most confused. I followed some instructions that explained how to use TestBencher (part of ISE). Is that what you are referring to? What I saw of it didn't impress me much... For my design, I didn't specify any timing constraints since I'm not concerned so much about speed as correct operation. Also, the amount of specify-able stuff was overwhelming, so I decided to skip that part 8~) My reasoning was that I would run a post-fit simulation, and see if there were any glitches, or unusual operation. Mostly, I was thinking about timing hazards. But your comment makes me ask: does the fitted design guarantee a glitch-free operation ? (the only remaining issue would be speed, hence the timing constraints) I should also add that I'm fairly new to digital design, so I might be missing the point entirely. > Dr. Deming told us that the Asian focus on direction of most closely > approaching perfection is a better goal than arbitrarily chosen > accept/reject criteria American style. Perhaps he was thinking > orientally? While I tend to agree with the oriental principle, I can't pretend to be looking for perfection for the moment. Functionality would be a good start ! Perfection can come later; I need to walk before I can run... Thanks for your time, Christian -- CSB [EMAIL PROTECTED] -- http://www.fastmail.fm - Same, same, but differentÂ… ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
> One practical solution for very small parts is to hid the refdes on the > board but make a large assembly drawing that has them. That's almost what I did. I make the refdes's as big as the parts, right on top of them, and printed them out as an assembly drawing. I just didn't put them on a silkscreen. This was about the time I added the lock-text and only-text settings ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
One practical solution for very small parts is to hid the refdes on the board but make a large assembly drawing that has them. Steve Meier DJ Delorie wrote: >> S2/S2/L1 S2/S2/C1 and S2/S2/U1 >> >> is the RenumberBlock funtion capable of this? >> > > It currently pulls the last string of digits (suffix) off for > renumbering, but pulling the first string shouldn't be too hard. It > doesn't give you automatic updating, though. If you edit the master > block, you'd cut out the copies, and re-copy/renumber the master block > to make new copies. > > We could script this if we had an action to select a region, but it > would certainly be better if it "just knew" about such blocks. > > >> Because when you use those virtual 01005 capcitors there isn't a lot >> of room for a readable refdes as it is >> > > Too true. I didn't even bother with a silkscreen on the furnace > board, and that's only 0603s. > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog with Xilinx simprims...
Andy Peters wrote: the static timing analyzer (using your timing constraints) tells you if you've met timing. If both are good, there's no need to run a post-fit simulation. Dr. Deming told us that the Asian focus on direction of most closely approaching perfection is a better goal than arbitrarily chosen accept/reject criteria American style. Perhaps he was thinking orientally? Anyway, that wasn't his question. He asked how to get the timing info into iverilog. John Griessen PS No specific knowledge of Xilinx, can't help, CSB. (If I'm correct, those are defined in the *.v files of the XILINX/verilog/src/simprims/ directory, one file for each module.) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog with Xilinx simprims...
On Mar 17, 2007, at 3:15 PM, CSB wrote: Hi all, I am trying to use Iverilog along with xilinx's SIMPRIMS. Well, I managed, but I am getting strange results with simulations. I'll try to explain how I'm doing this (I'm new to CPLDs, Verilog and Icarus...) First, I generate the post-fit verilog module from Xilinx ISE project navigator. This is the .v file containing all the nets and gates, for example X_AND2, etc... If I'm correct, those are defined in the *.v files of the XILINX/verilog/src/simprims/ directory, one file for each module. They all contain timing information, which is what I'm after. So, I add "-y%XILINX%/verilog/src/simprims/" to my iverilog command, and it generates no error. Then, I run vvp, and generate a VCD from my testbench. So far, so good. I open the VCD, but it seems like the timing information hasn't been simulated. For example, there is no delay between a clock event and a counter update, etc. The levels are all OK, states are the same as the pre-synthesis simulation, so I really have no clue of what's wrong. One thing I've noticed is that the SIMPRIMS modules all have a `timescale directive, the glbl.v file has a different one, and my testbench is again different... could it be that some timing gets "rounded" off ? Thanks for any info, Christian Does iverilog support SDF backannotation? The SDF has the delay information. Any specific reason why you're running a post-fit simulation? The RTL simulation tells you if your logic is functionally correct, and the static timing analyzer (using your timing constraints) tells you if you've met timing. If both are good, there's no need to run a post-fit simulation. -a ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Icarus Verilog with Xilinx simprims...
Hi all, I am trying to use Iverilog along with xilinx's SIMPRIMS. Well, I managed, but I am getting strange results with simulations. I'll try to explain how I'm doing this (I'm new to CPLDs, Verilog and Icarus...) First, I generate the post-fit verilog module from Xilinx ISE project navigator. This is the .v file containing all the nets and gates, for example X_AND2, etc... If I'm correct, those are defined in the *.v files of the XILINX/verilog/src/simprims/ directory, one file for each module. They all contain timing information, which is what I'm after. So, I add "-y%XILINX%/verilog/src/simprims/" to my iverilog command, and it generates no error. Then, I run vvp, and generate a VCD from my testbench. So far, so good. I open the VCD, but it seems like the timing information hasn't been simulated. For example, there is no delay between a clock event and a counter update, etc. The levels are all OK, states are the same as the pre-synthesis simulation, so I really have no clue of what's wrong. One thing I've noticed is that the SIMPRIMS modules all have a `timescale directive, the glbl.v file has a different one, and my testbench is again different... could it be that some timing gets "rounded" off ? Thanks for any info, Christian -- CSB [EMAIL PROTECTED] -- http://www.fastmail.fm - Email service worth paying for. Try it for free ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: File corrupted after segmentation fault in pcb
If you edit the .pcb file and remove all the Rats[] entries (they're all at the end) it will at least load. However, all the layer information is missing, so you'll have to re-add all the layers and redefine the layer groups. Do you have a save file in /tmp, or in the same directory as the original file but with '-' appended? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: File corrupted after segmentation fault in pcb
Hi all! I tried out the gEDA package and I am very impressed! My thanks to all who contributed to this project! I created a layout in pcb and just needed the last finish before the board was done. Unfortunately I marked two rats nets together with my component which I wanted to delete. When I hit the delete button pcb gave me a segmentation fault, and now the layout file is corrupted. I know the layout file is ASCII, but as a first time user it is not trivial to repair the file. Therefore, I will ask any of you to help me repair the file. I have no auto-backup since this apparently does not work quite yet in pcb. The files are located here: Layout file: http://kom.aau.dk/~mwbe03/msp430-eval.pcb Netlist: http://kom.aau.dk/~mwbe03/msp430-eval.net Footprints: http://kom.aau.dk/~mwbe03/footprints/ Version: #> pcb -V PCB version 20070208 Debugger output: #> gdb pcb msp430-eval.pcb GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain \ conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for \ details. This GDB was configured as "i486-slackware-linux"...Using host \ libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /opt/geda/geda-install/bin/pcb Program received signal SIGSEGV, Segmentation fault. DrawRat (Line=0xb745e5c0, unused=0) at draw.c:1878 1878 if (TEST_FLAG (SELECTEDFLAG | FOUNDFLAG, Line)) Just for the records; The debugger solution above were found using google when trying to search for a solution to my problem. Thank you for any pointers or solutions to my problem. Cheers, Mikael ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: updated design flow wiki
http://geda.seul.org/wiki/geda:design_flow_and_hierarchy_roadmap Has current comments pro and con and feasibility. I paraphrased and edited. Please tell me if it was too much without YELLING. :-) John G ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Re: Design Flow Roadmap starting point
DJ Delorie <[EMAIL PROTECTED]> wrote: > >> While I am at it. PCB should be able to do hidden vias, buried vias >> and micro vias... > > If we can get the "layer types" project done (this is listed as the > non-copper layers project in SoC), we'll be able to have a concept of > a "layer stack" (unless we just assume the physical stack matches the > GUI layer layout). > > The next project after that is what I call a "multi-pin", which is a > standard pin, but with a much more intense copper description, one for > each layer, with drill depth parameters et al. That would include > blind and buried vias. Microvias is just a drill size after that, > unless you need them called out in a different .cnc file. I use the CR5000 system at my work, where you can define so called padstack. With it, you can place any copper, non copper layers, than you can use your padstack to build elements up. The copper and non-copper layers are totally independent. BTW hard drc. With CR5000, you can define so called Ignore areas (as non copper layers). For example, an area, where you can not place wire, another where you can not place other components. IMHO, these are very useful features. Just my HUF 100... -- Levente http://web.interware.hu/lekovacs ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
