Re: gEDA-user: gEDA/gaf unstable/development snapshot 1.5.2-20090328 released!
On Sun, 2009-04-05 at 21:33 -0400, evan foss wrote:
I have been using this release and I have a question. Did you guys
change the interpritation of gafrc? I keep loading a schematic and it
doesn't seem to render the symbols in the project directory properly.
Shouldn't have, but some scheme syntax for other things might have
changed. Depending on what else you have in there, it might be causing
problems. Anything unusual uin your log window, or gschem.log?
gschem.log is no longer dumped in the current working directory. You
will find one in $HOME/.gEDA/logs/gschem-{date}-{seqno}.log
Regards,
--
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-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chipscope vs. rerouting signals to test pads/pins (was: terminators)
Would like to find out what that iteration to get different outputs is like. Is it like running the place and route pin mapping step for the FPGA you're using without changing the synthesized level of the design? John Griessen OK, I was right, it is fpgaeditor. You will be using the 'probes' portion of it. Here's the run down: 1. write your code. 2. run synthesisis (XST) 3. run place and route 4. Open fpga editor. You can get to it from ISE by clicking the '+' under the map then select 'manually place' button. Alternatively, you launch fpga editor directly from a window browser or even from the command line. Your choice. 5. You need to open the design from within fpga editor. I ran a simple test using a 2 input, 1 output test case. The file was called simple.v so to open the design, I entered simple.ncd which you can browse to. 6. On the right hand side of the gui are a bunch of buttons. Look for the one that says 'probes'. Click it. 7. Use the 'add' button to add a new test point. 8. A popup becomes visible for 'define probe' 9. Select the net you wish to look at. 10. Select the pin you want it to go to, and press the to actually make the selection active. 11. Press OK. This returns you to the probes dialog box where you will see the net has been added, and they tell you what the delay will be in nS. 12. Press the 'bitgen' button, and you are all done. Use the newly created bit file to program your fpga. Lets say you want to remap the pin at a later time. Go back to the probes dialog box, select the signal you want to go, then choose 'delete'. That's it. Go back and remap it the way you want, re-gitgen and load it into the fpga. It's pretty simple once you try it. If you need some screen shots, I could probably provide some. gene ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chipscope vs. rerouting signals to test pads/pins
carzr...@optonline.net wrote: OK, I was right, it is fpgaeditor. You will be using the 'probes' portion of it. Here's the run down: snip If you need some screen shots, I could probably provide some. Thanks for checking this. I've never tried it myself, but can see it would be useful. There's one little bit of advice you might be able to help with - I'm running ISE 10.1.03 on a Fedora 9 system and several of the GUI apps are impossible to run because they're linked against libXm.so.3 which isn't in any of the standard Fedora repositories. I've tried installing the CCRMA openmotif package, but that provides libXm.so.4. Do you have any suggestions on how to get around this? Thanks, Eric ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chipscope vs. rerouting signals to test pads/pins
Eric Brombaugh ebrombau...@cox.net wrote: There's one little bit of advice you might be able to help with - I'm running ISE 10.1.03 on a Fedora 9 system and several of the GUI apps are impossible to run because they're linked against libXm.so.3 which isn't in any of the standard Fedora repositories. I thought one of those GUI apps was the Webpack installer, and they've made it impossible to bypass it by putting all the bits in encrypted (!) ZIPs. At least this was the case the last time I looked at it in late 2005, and this problem (the inability to bypass the installer) was what made me choose Altera over Xilinx. How did you get around the installer block? MS ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chipscope vs. rerouting signals to test pads/pins
Michael Sokolov wrote: I thought one of those GUI apps was the Webpack installer, and they've made it impossible to bypass it by putting all the bits in encrypted (!) ZIPs. At least this was the case the last time I looked at it in late 2005, and this problem (the inability to bypass the installer) was what made me choose Altera over Xilinx. How did you get around the installer block? I've had no trouble installing the full ISE on Fedora and I've been using it since 2005 or so. Webpack's installer is limited to 32-bit systems though, so if you're on a 64-bit system that might be getting in your way. Eric ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chipscope vs. rerouting signals to test pads/pins
On Mon, Apr 06, 2009 at 09:42:30AM -0700, Eric Brombaugh wrote: I've had no trouble installing the full ISE on Fedora and I've been using it since 2005 or so. Webpack's installer is limited to 32-bit systems though, so if you're on a 64-bit system that might be getting in your way. It's pretty easy to run the installer on 64-bit (amd64) Linux, and get a working install. No chroots necessary. The programs do still run the processor in 32-bit mode, of course. I have done it on Debian, but the details are not distribution-specific. The biggest hack is bypassing the stoopid shell scripts that autodetect architecture and figure out which version to install. - Larry ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chipscope vs. rerouting signals to test pads/pins
Larry Doolittle wrote: I have done it on Debian, but the details are not distribution-specific. The biggest hack is bypassing the stoopid shell scripts that autodetect architecture and figure out which version to install. I use debian and would like to hear any hints. John Griessen -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: outline in .ps output
When I export a PCB to a .ps file with the outline option selected it draws the outline on the front and the back pages, but it does not draw it on the frontassembly and backassembly pages. Is there a way to get pcb to draw the outline on these two pages? PCB version is 20081128. Thanks, Duncan -- 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
Re: gEDA-user: outline in .ps output
When I export a PCB to a .ps file with the outline option selected it draws the outline on the front and the back pages, but it does not draw it on the frontassembly and backassembly pages. Is there a way to get pcb to draw the outline on these two pages? You'll need to add code to PrintAssembly() in src/draw.c to find and draw the outline layer. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: terminators
2 thoughts, tune down your edge rate in the FPGA to make the effective bandwidth of your edges lower. square waves are an infinite series of sine waves, trapezoidal are finite. ( roughly speaking ) 3 inches is a 1/8th wave antenna for 500MHz, again roughly ( 1GHz ~= 12 inches ~=1 nS at the speed of light. ) if you worried about signal integrity, ignore the logic analyzer hookup, use some diff probes. as for the terminators, look at the xilinx demo boards, and their drive strength settings. look how closely they matched the clock and data lines lengths. good luck. On Apr 4, 2009, at 12:29 PM, DJ Delorie wrote: I'm getting close to a final design for my SDRAM board, but I'm thinking about termination for the SDRAM signals. This board is faster than anything else I've done before (133MHz 3.3v). Updated images here: http://www.delorie.com/electronics/sdram/ The left half of the board (U2 left, U1) runs at 24 MHz, no problem. The right half of U2, and U2, run at 133MHz. The longest trace is the CLK line, at just over 3 inches, the shortest is just under an inch. However, most of those lines are brought out to logic analyzer connectors, which may add up to another 1.8 inches (DQ11, for example, has a combined length of 3.9 inches). I'm thinking I have enough space to put in some series terminator packs (8x 0402 SMT) but where and how big? Is it relative to which chip is driving the trace? Should the logic analyzer go on the fast side or the slow side, or does it matter? (it's a 500Ms/s analyzer) ___ 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: terminators
tune down your edge rate in the FPGA to make the effective bandwidth of your edges lower. square waves are an infinite series of sine waves, trapezoidal are finite. ( roughly speaking ) 3 inches is a 1/8th wave antenna for 500MHz, again roughly ( 1GHz ~= 12 inches ~=1 nS at the speed of light. ) if you worried about signal integrity, ignore the logic analyzer Yeah but on a pcb, flight-time on FR-4 is around 170pS / inch (off the top of my head, anyway). By way of 'rule of thumb' the trace looks like a transmission line if the flight time is greater than 1/4 wavelength. If 1ns edge rate, then it's 1/4 of 4nS, which translates into about 1 (I think I did that right). So anything longer than 1 will have transmission line affects, and you should consider termination. Xilinx fpga's are very capable of producing 1 nS edges or maybe better. That translates to around 500 MHz. My experience with the slew rate limiting on the spartan-2 is that it doesn't do very much. Dropping the drive strength will definitely slow the edges since the output impedance of the gate goes up and you get an RC rise time affect on the line. As long as the degraded rise-time is ok in your design, this is a good method. gene ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: terminators
On Apr 6, 2009, at 2:51 PM, [1]carzr...@optonline.net wrote: tune down your edge rate in the FPGA to make the effective bandwidth of your edges lower. square waves are an infinite series of sine waves, trapezoidal are finite. ( roughly speaking ) 3 inches is a 1/8th wave antenna for 500MHz, again roughly ( 1GHz ~= 12 inches ~=1 nS at the speed of light. ) if you worried about signal integrity, ignore the logic analyzer Yeah but on a pcb, flight-time on FR-4 is around 170pS / inch (off the top of my head, anyway). By way of 'rule of thumb' the trace looks like a transmission line if the flight time is greater than 1/4 wavelength. If 1ns edge rate, then it's 1/4 of 4nS, which translates into about 1 (I think I did that right). So anything longer than 1 will have transmission line affects, and you should consider termination. my old timer gave me a different way use 1/8th wave antenna on PCB, and the speed of light. 1/4 wave antenna open air interestingly enough they are about the same, it's interesting to see the difference in rules of thumb. a 1ns edge rate if perfectly toggled looks like a sine wave (RC effects) that has just over 2nS period or just under 500MHz 500MHz on FR4 using your numbers of 170ps/inch, about 0.5C :-). From Mathematica, to keep track of my units. Units` Take 170 ps per inch and multiply it by 500 Mega Hertz (170. Pico Second)/(1 Inch) 500 Mega Hertz (85000. Hertz Mega Pico Second)/Inch What is per inches, invert. 1/% (0.117647 Inch)/(Hertz Mega Pico Second) clean it up to inches, nice that Mathematica leaves all of the units in there :-) Convert[%, Inch] 11.7647 Inch Make it a quarter wave antenna %/4 2.94118 Inch How long you need to care after about 3 inches. So slow up your edge rate, with some source resistors or through your drive strength and other settings in the FPGA. now for the 1/8th wave rule of thumb PhysicalConstants` Lets look at the 1/8 th rule and speed of light SpeedOfLight /( 500 Mega Hertz) (149896229 Meter)/(250 Hertz Mega Second) Take it to inches N[Convert[%,Inch]] 23.6057 Inch 1/8th wave antenna %/8 2.95071 Inch All rules of Thumb. Xilinx fpga's are very capable of producing 1 nS edges or maybe better. That translates to around 500 MHz. My experience with the slew rate limiting on the spartan-2 is that it doesn't do very much. Dropping the drive strength will definitely slow the edges since the output impedance of the gate goes up and you get an RC rise time affect on the line. As long as the degraded rise-time is ok in your design, this is a good method. Check your ram's spec sheets, also look at the additional delay that the traces on the far side will be exposed. longest clock Vs. shortest data and vice versa. You want your data eye to be nice and big, the sampling clock right in the middle of it. The cleaner the eye the slower your edge rates can go. gene ___ geda-user mailing list [2]geda-u...@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:carzr...@optonline.net 2. mailto:geda-user@moria.seul.org ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: EDA revenue news link.. gEDA + gerbv screenshot!
They used it for an article on Mentor graphics too :-P ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: terminators
longest clock Vs. shortest data and vice versa. You want your data eye to be nice and big, the sampling clock right in the middle of it. The cleaner the eye the slower your edge rates can go. So, long story short... I need to redesign the board :-( I tried adding serpentines but there isn't enough room to add more than an inch or so, leaving another inch of mismatch. If I reroute the signals under the chip instead of around it, I can save an inch or more, then serpentine the rest to match trace lengths. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: terminators
On Mon, Apr 06, 2009 at 10:03:36PM -0400, DJ Delorie wrote: I tried adding serpentines but there isn't enough room to add more Excellent news for PCB, though. If DJ has trouble laying out serpentines or trombones, a plugin is sure to follow. ;-) -- 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: terminators
Excellent news for PCB, though. If DJ has trouble laying out serpentines or trombones, a plugin is sure to follow. ;-) I didn't have trouble laying them out, I just ran out of room to put them in. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: terminators
On Apr 6, 2009, at 7:03 PM, DJ Delorie wrote: longest clock Vs. shortest data and vice versa. You want your data eye to be nice and big, the sampling clock right in the middle of it. The cleaner the eye the slower your edge rates can go. So, long story short... I need to redesign the board :-( I tried adding serpentines but there isn't enough room to add more than an inch or so, leaving another inch of mismatch. If I reroute the signals under the chip instead of around it, I can save an inch or more, then serpentine the rest to match trace lengths. did you do the math? an inch is 170ps of mismatch. 133MHz is 7.518 ns period so 2.2% error. how good are your memories? if this were say 1033MHz DDR ram modules, you would be hosed. 1.033 GHz is 968ps period 1 inch is 17.6% Its DDR so. 2x 35% error that's toast. but north bridges have tricks up their sleeve they adjust delays in the output and inputs to the ram banks to compensate. ___ 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: terminators
did you do the math? No, I was going by the micron recommendations for SDRAM. They suggest a much closer length match than I'm getting. I suppose I could just clock it slower if it turns out to be too mis-matched. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: terminators
Steven Michalske wrote: Hey Steven, that's a pretty interesting analysis. I just want to add something from Dr. Howard Johnson's book on this stuff. His claim is that you can treat a pcb trace as a lumped system if the trace is less than 1/4 * 'length of the edge'. Well, at 170 ps/inch the length of the edge is about 5.8 - that's exactly 1/2 your result. OK, I see it. Your units work out as: (.170nS/inch) * (500e6 cycles/second) = 0.085 cycles/inch or 11.76 inches/cycle. BUT - this is only 1/2 cycle (only 1 edge), so 11.7 inches/cyle * 0.5 cycle = 5.8 If it were a full cycle, like you said, toggle the edge up then down, the complete wave-length is 11.76 inches in FR4. The whole idea is to keep the trace length short so that reflections don't come back and reclock things, or have the wrong levels, or ringing, or just make a lot of emi. All that junk comes from the signal rattling around from end-to-end. gene ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: terminators
Hey Steven, that's a pretty interesting analysis. I just want to add something from Dr. Howard Johnson's book on this stuff. His claim is that you can treat a pcb trace as a lumped system if the trace is less than 1/4 * 'length of the edge'. Well, at 170 ps/inch the length of the edge is about 5.8 - that's exactly 1/2 your result. If I remove the LA connector and shove the sdram closer to the fpga, I get a trace length range of 2027 mils (CLK) down to 281 mils (DQ7), a mis-match of 1.7 inches, or just under 1/3 of 5.8. I wonder if I could drive the shorter traces less than the longer ones, to match up the edges at the sdram? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: terminators
So, long story short... I need to redesign the board :-( that's funny :) Seriously though, as long as the signal is clean and you make the setup/hold times then you are golden. I don't think %skew is the best way to analyze it. Use the absolute time, draw yourself a timing diagram and see if you are close. You *could* always jockey the output timing from your fpga - but that's not a great way to fix it. Didn't someone else mention using a pll? That could work too. But, honestly, from what I see on your board what's the problem besides the stubs? Oh, and make sure to set the constraints on your fpga so the timing is right-on. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: terminators
That could work too. But, honestly, from what I see on your board what's the problem besides the stubs? If I knew that answer, I wouldn't need to ask all these questions. Oh, and make sure to set the constraints on your fpga so the timing is right-on. Yet another thing to learn how to do... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: terminators
On Mon, Apr 6, 2009 at 9:35 PM, DJ Delorie d...@delorie.com wrote: If I remove the LA connector and shove the sdram closer to the fpga, I get a trace length range of 2027 mils (CLK) down to 281 mils (DQ7), a mis-match of 1.7 inches, or just under 1/3 of 5.8. I wonder if I could drive the shorter traces less than the longer ones, to match up the edges at the sdram? I would get rid of the LA connector. On all my SDRAM designs, I concentrated on short trace lengths rather than matching. Most of my traces were less than 1 inch. All seem to work well at 133 MHz. You may be able to delay some signals in the FPGA with DCMs or IOB delays. I have had one failed board with high speed signals. The nets were all well matched in length (+- 1 inch), but over 6 inches long and with 2 connectors. It was an FPGA board I made connected to an adaptor board connected to a Xilinx FPGA development kit. The traces on the XIlinx board are 4 inches. I was attempting to use 3.3V CMOS, and was having severe problems with reflections. I gave that approach up and will be building my own board with the FG676 Xilinx FPGA on it so that I can reduce trace lengths and/or use LVDS. I was forced into a high data rate by only having 18 pins in each direction and needing to move 250 MB/s in each direction. Darrell Harmon ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: terminators
DJ Delorie wrote: Hey Steven, that's a pretty interesting analysis. I just want to add something from Dr. Howard Johnson's book on this stuff. His claim is that you can treat a pcb trace as a lumped system if the trace is less than 1/4 * 'length of the edge'. Well, at 170 ps/inch the length of the edge is about 5.8 - that's exactly 1/2 your result. If I remove the LA connector and shove the sdram closer to the fpga, I get a trace length range of 2027 mils (CLK) down to 281 mils (DQ7), a mis-match of 1.7 inches, or just under 1/3 of 5.8. I wonder if I could drive the shorter traces less than the longer ones, to match up the edges at the sdram? sounds tricky to do in practice. With the dimensions you just quotes, an sdram write will gain some setup time because the clock gets there later and looses some hold time for the same reason. 1.7 * 170ps/inch = 289 pS. Peeking at the data sheet, that sdram has some tight specs - like 0.8 nS setup. So that mismatch in line length is going to cost you a little less than 1/2 of your budget. I think you are going to need nice crisp edges in order to make the timing specs. Keeping the data and clock lines relatively equal will eliminate skew headaches. Do you have the other side of your board to route on? Maybe that would help. Why don't you use the PQFP208 fpga and use the extra pins for debugging? That will get rid of the stub junk to the emulator. Then move the the SDRAM around to even up the trace length. Terminate the clock line (series terminate at fpga, RC at the other end). Hey, just wondered if you turn the SDRAM 90 degrees, does that help even out the traces? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: terminators
With the dimensions you just quotes, an sdram write will gain some setup time because the clock gets there later and looses some hold time for the same reason. 1.7 * 170ps/inch = 289 pS. Peeking at the data sheet, that sdram has some tight specs - like 0.8 nS setup. So that mismatch in line length is going to cost you a little less than 1/2 of your budget. If the traces are short enough and delays short enough, I can do the setup a half cycle earlier. It makes the state machine a little more difficult, though. It means my time window is now 3.75 nS instead of 7.5 nS but it lets me separate data changes and data sampling. I think the 3A allows me to generate an internal clock that's a quarter phase off from the external clock, too. That gives me another 2nS of setup and hold times. Do you have the other side of your board to route on? Maybe that would help. I do, but I have to manually solder in every single via. My vias are small, but not *that* small. Plus, I can't put vias under anything. Why don't you use the PQFP208 fpga and use the extra pins for debugging? The 3A is not available in that package. The 3E requires 2.5v during programming. Kinda limits my options :-( Hey, just wondered if you turn the SDRAM 90 degrees, does that help even out the traces? I don't know. I'll have to try and see. There's still the 0.8 inches of the sdram's length. I think my best bet is to keep the sdram oriented the way it is, but run the traces to the right-side pins between the left-side pins and under the chip. That way, I only have to make up 450mil of difference due to the chip, and 250 mil due to the FPGA pinout. That's only 700 mil, if I put the chips that far apart a serpentine can make it up. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: terminators
DJ - Before you create another board, could you try using a razor to cut all the logic analyzer traces right near or at the vias? This may help, and if the board doesn't work now, there is no harm in a minute with the knife. I've laid out an interface to a 133Mhz SDRAM, and the path lengths were similar to yours. Works great. No LA connector, though. Tim On Mon, Apr 6, 2009 at 10:35 PM, DJ Delorie d...@delorie.com wrote: Hey Steven, that's a pretty interesting analysis. I just want to add something from Dr. Howard Johnson's book on this stuff. His claim is that you can treat a pcb trace as a lumped system if the trace is less than 1/4 * 'length of the edge'. Well, at 170 ps/inch the length of the edge is about 5.8 - that's exactly 1/2 your result. If I remove the LA connector and shove the sdram closer to the fpga, I get a trace length range of 2027 mils (CLK) down to 281 mils (DQ7), a mis-match of 1.7 inches, or just under 1/3 of 5.8. I wonder if I could drive the shorter traces less than the longer ones, to match up the edges at the sdram? ___ 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: gEDA/gaf unstable/development snapshot 1.5.2-20090328 released!
On Mon, Apr 6, 2009 at 2:31 AM, Peter Clifton pc...@cam.ac.uk wrote:
On Sun, 2009-04-05 at 21:33 -0400, evan foss wrote:
I have been using this release and I have a question. Did you guys
change the interpritation of gafrc? I keep loading a schematic and it
doesn't seem to render the symbols in the project directory properly.
Shouldn't have, but some scheme syntax for other things might have
changed. Depending on what else you have in there, it might be causing
problems. Anything unusual uin your log window, or gschem.log?
I am loading something I made back around version 1.4.0.
gschem.log is no longer dumped in the current working directory. You
will find one in $HOME/.gEDA/logs/gschem-{date}-{seqno}.log
Oh. I was kind of glazzing over the log. It was repeating a message
about missing pin seq=. I had a number of symbols for components
broken into parts.
So my lm339 was lm339-1-pt1.sym, lm339-1-pt2.sym, lm339-1-pt3.sym,
lm339-1-pt4.sym. I left them with identical pinseq attributes set.
What is funny is that gschem 1.4.0.20080127 reads the file correctly
even with the pinseq attributes wrong.
Sorry, I have to get out of my bad habbit of clicking that log window
off with out reading it.
Regards,
--
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-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
