xcircuit-dev — XCircuit news and discussion

[Xcircuit-dev] XCircuit and GTK

[R. T. E. <ti...@st...>]

Dear Jeremy,

> Date: Sat, 12 Jan 2002 22:03:23 -0500 (EST)
> From: Jeremy T Braun <jt...@MI...>
> Subject: Gtk and XCircuit...
> To: ti...@ba...
> 
> a while ago I wrote to you about adding (converting?) xcircuit to Gtk
> instead of Xw..
> 
> I've got a fair amount of free time for the rest of january with nothing
> in site to do, so I was wondering if you're still interested in this? (as
> I recall, you weren't sure at the time).
> 
> Thoughts?
> Jeremy

   I have just written a little manifesto for xcircuit, magic, PCB, gEDA,
etc., outlining how they can all fit into the "ScriptEDA" idea
(http://www-cad.eecs.berkeley.edu/~pinhong/scriptEDA).  Read the two papers
from that site first, then read my "manifesto" (which will have to be
tomorrow, because I forgot to upload it yesterday).  In part of the
manifesto, I'm more or less committing myself to allow xcircuit to either
run its own GUI, or relinquish its GUI to a controlling interpreter.
This is going to require that xcircuit's GUI be carefully extracted from
the rest of the program.  Then, implementing another GUI should be
relatively painless.  The question is, is it worth doing a new GUI in
Gtk, or is it better to start building the GUI in Python or Tcl, with
direct calls to Tkinter or Tk?  The first thing to do is to identify
all of the callback functions used by the GUI, and to shred apart the
xcircuit main() routine and put it back together so that it doesn't
directly create any widgits itself.  Then all of the GUI routines that
I wrote myself, like the menu building routine "makesubmenu" and such,
need to be placed in a separate source file, so they can be ignored when
warranted.  Most of this stuff is in "xcircuit.c", but bits and pieces
have ended up spread out all over the source code (for instance, there's
a single call in files.c to XwTextCopyBuffer(), which gets the contents
of the selection buffer, but really ought to call an intermediate routine
which hides the fact that the selection buffer capture is part of the
Xw widget set).  Another problem is that many of the Xw widgets are kept
as global variables.  The main offenders are sitting in xcircuit.c, lines
112 and 114.

   The main problem I see is that I don't know how compatible Gtk is with
Xt---I make a lot of low-level Xt calls, and those will be MUCH harder
to pull out of the code (do "grep Xt *.c" on the source directory and see
what I mean).  That being said, I also admit that the selfsame routines
are the cause of much pain and suffering.  For instance, the timer
functions, implemented with XtAppAddTimeOut(), interact VERY POORLY (to
say the least) with some systems, apparently a window manager problem.
The WM gets the xcircuit timeout confused with the screensaver timeout,
causing the whole screen to go blank when a button is pressed and
occasionally causing server lockup.  But that might not be a good
example, because it could be replaced with the OS signal timer and
bypass the X server altogether.

   Anyway, if that discussion hasn't put you off the idea of rewriting
the XCircuit GUI, then we should start putting together something of an
API which would give some kind of framework for making the core of
xcircuit GUI-independent, then we can divide up the tasks that need to
be done.

   I'm going to CC this email to the xcircuit-dev mailing list, because
it is definitely more than a one-person job (else I would have done it
myself by now), and it is likely more than a two-person job (any other
takers?).  By the way, as mentioned above, I will try to remember to
upload my "ScriptEDA manifesto" tonight, and I will also post that to
all the appropriate mailing lists (gEDA, magic-dev, and xcircuit-dev).

   As I have mentioned to others, but I don't know if it's widely known,
starting next week I will be working Thursdays and Fridays from home,
doing exclusively EDA programming and development related to ScriptEDA.
I'm doing this as an employee of MultiGiG, Ltd., Wellingborough, England,
but they are committed to the idea of "open source", so everything I do
will be under GPL copyright (except for a few minor things related to
their IP about fast clocking structures in VLSI hardware).  My goal this
time is to get essentially everybody who is doing any open-source EDA
tool development on the same project without trying to restrict or
redefine the development direction of any individual project (that is
to say, without offending anybody).  I was quite successful at pulling
together the "magic development team" from disparate parts, and perhaps
I have just become cocky, but I want to attempt the same thing on a
grander scale.

						Regards,
						Tim

[Xcircuit-dev] XCircuit output error

[R. T. E. <ti...@st...>]

Dear Conrad,
   Version 2.5.3 fixes the Spice output error.  You were correct in your
assessment of the bug, which has to do with clear_traversed and is also
subtle;  the changes required to fix it the "right" way spanned several
source files, so I will just suggest that you get 2.5.3 from the
xcircuit.ece.jhu.edu website.
						Regards,
						Tim

[Xcircuit-dev] xcircuit 2.5.1, spice netlist bug and quick patch to netlist.c

[Conrad H Z. <nos...@um...>]

problem:  flat spice netlist works fine, hierarchical netlist only
outputs root cell
version: xcircuit-2.5.1

attatched is a hackish fix for the problem.  something  is wrong with
the original clear_traversed routine,

i can send a xcircuit file that fails if needed to reproduce the bug.

--conrad

[Xcircuit-dev] RE: 7400 series library

[Stephen H. <hon...@li...>]

Dear Timothy,

>The chip numbering system was written before I came up with the 
>"libinst" idea, and I was already aware of problems with the auto-numbering, 
>which fails to work correctly under a number of situations. The condition 
>which you related, in which you got "U1-1-" and "U2-2-", highlights one of 
>these problems. The auto-numbering routine doesn't understand that the two 
>parts are supposed to be the same chip. On the whole, though, there is no 
>way to know which instances are supposed to go with which chip.

I always find it amazing how clear the answer to my questions become only 
SECONDS AFTER I click the "Send" button on my e-mail client, and with no way 
to quickly stop the transmission.

It was only then that I remembered that I needed to manually edit the U? for 
each instance that I placed on a schematic (as I had done for years on other 
systems and software).

>P.S.---There's still the issue of Vdd/GND pin connections. Apparently some 
>schematic capture systems put Vdd and GND pins on each instance. At least 
>one of the instances per chip should have explicit connections to Vdd and 
>GND in the schematic. A PCB netlist requires these pins, to be correct. 

>If you can think of a better method for Vdd/GND connections, though, please 
>let me know.

I guess a quick and dirty way to solve the issue of chips containing more 
than one type of gate and the issue of Vdd/GND pins would be as follows:

Create the base object such as 7400-1 with no parameterized labels and 
include the Vdd/GND connections on this object.

Next, create another base object 7400-2 with all necessary parameters and 
exclude the Vdd/GND connections.  The remaining 2 gates in this series would 
be an instance of the 7400-2 object.

Of course there are a few drawbacks to this as well.  The first being the 
doubling in size of the library file.  The second is the need to manually 
edit the .lps file to provide the correct pin numbering which excludes the 
Vdd/GND pins.  Of course I have been manually editing the "libinst" entries 
in this manner anyhow.

>At present, connecting multiple instances to Vdd and GND will generate 
>redundant entries in the PCB netlist, but I can get rid of that behavior. 

Perhaps this is the better way?

Sincerely,

Stephen Hughes
Honeycomb Electronics, Audio and Research, Inc.

[Xcircuit-dev] 7400 series library

[R. T. E. <ti...@st...>]

Dear Stephen,

   Thanks for the "thought-provoking" email.  I hadn't even considered the
case of chips containing more than one kind of gate.  One (non-optimal)
solution would be to make the symbol itself contain both parts.  Another
solution just for the 74LS51 would be to use a 3-input AND for both parts,
but name the middle connection "N/C" or something;  for PCB netlists, if
this pin is an isolated node, it will not be connected.  However, I think
that generally, the proper way to deal with it is to extend the parameter
substitutions to include entire substitutions of different objects.  So
one instance would call "and2" and one instance would call "and3".

>  The other possible soloution would to allow multiple gate definitions 
> within the object definition.  This could perhaps use the 
> "begingate...endgate" tags for the main object and then add 
> "beginvirtualgate..endvirtualgate" for each instance where the gates are 
> dissimilar in each IC package.

Object substitution would effectively do the same thing as your proposed
"beginvirtualgate..endvirtualgate".  At least, I think so.

   The chip numbering system was written before I came up with the
"libinst" idea, and I was already aware of problems with the auto-numbering,
which fails to work correctly under a number of situations.  The condition
which you related, in which you got "U1-1-" and "U2-2-", highlights one of
these problems.  The auto-numbering routine doesn't understand that the two
parts are supposed to be the same chip.  On the whole, though, there is no
way to know which instances are supposed to go with which chip.  If you
had two 7473 chips in a circuit, it would not be clear which instances
belong together.  If you're doing a netlist compare or autorouting, they
should permute as necessary.  Otherwise, if you know which instance belongs
to which chip, you can set the numbering by hand.  Regardless, the
auto-numbering routine needs work.  This shouldn't stop you from going
ahead with the 7400-series library.

>  One possible soloution would be to include the "libinst" inside the "{}" of 
> the library object and if there is the concept of variables and scope the  
> variable "?" would be the same within each object definition.  This would 
> solve #2.

   This would still not solve the problem of determining which instances
belong to which chips, for which the auto-numbering routine either needs to
be told what to do, or needs to do a better job of guessing (assuming that
any autorouter or netlist comparator downstream will deal with any
permutations as necessary).

   I'll be looking forward to a 7400-series library!  If you need any help,
please let me know.

  						Regards,
						Tim

P.S.---There's still the issue of Vdd/GND pin connections.  Apparently some
schematic capture systems put Vdd and GND pins on each instance.  At least
one of the instances per chip should have explicit connections to Vdd and
GND in the schematic.  A PCB netlist requires these pins, to be correct.
At present, connecting multiple instances to Vdd and GND will generate
redundant entries in the PCB netlist, but I can get rid of that behavior.
If you can think of a better method for Vdd/GND connections, though, please
let me know.

[Xcircuit-dev] Multiple-gate chips in PCB netlists

[Stephen H. <hon...@li...>]

Hello,

  I would like to thank all responsible for "XCircuit" and "PCB".

  I have taken on the challenge of creating an xcircuit library containing 
the entire "unique" 7400 series of ICs.  Please inform me if this task has 
already been started by another.

  While working on the library I have come across a few peculiarities I 
thought would be of some interest.  These are in reference to multiple gate 
chips available in xcircuit-2.5.2 and above.

1)  Consider the case of the 74LS51 Dual 2-Wide 2-Input, 2-Wide 3-Input 
AND-OR-INVERT Gates.  If you do not have your data book handy :

U1-1: Two, 2-Input AND with outputs connected to a 2-Input NOR
U1-2: Two, 3-Input AND with outputs connected to a  2-Input NOR

I am curious as to a possible soloution to this problem.  Clearly a "libinst" 
placed in the library file would only duplicate one of the gates.  If each 
half of this device were created as an individual library part we would have 
the situation which I will describe next.

2)  I placed multiple instances of the 7473 component from my 7400 library 
onto a page with no connections between the gates and selected "Netlist -> 
Write Pcb".  The output was similar to that described in the tutorial:

ext1        U2-2-7
ext2        U2-2-8
ext3        U2-2-9
ext4        U2-2-10
ext5        U2-2-6
ext6        U2-2-5
ext7        U1-1-14
ext8        U1-1-13
ext9        U1-1-12
ext10       U1-1-3
ext11       U1-1-2
ext12       U1-1-1

The Info pin on the device is "pcb:U parameter(1)<?>-parameter(2)<1>".  As 
expected the parameters were updated with an assigned value for "?" and with 
and index value beginning with "1".  

Unfortunately, the netlist clearly shows two unique devices, much the same as 
if I had created two parts in the library with Info pins "pcb:U 
parameter(1)<?>-1" and "pcb:U parameter(1)<?>-2".  This ties in with the case 
of multiple but differing gates in a single IC package as in #1 above. I  am 
assuming the ICs in this example should be labled as U1-1-"pin" and 
U1-2-"pin".  Is the above netlist format a condition of the "PCB" program?

  One possible soloution would be to include the "libinst" inside the "{}" of 
the library object and if there is the concept of variables and scope the  
variable "?" would be the same within each object definition.  This would 
solve #2.

  The other possible soloution would to allow multiple gate definitions 
within the object definition.  This could perhaps use the 
"begingate...endgate" tags for the main object and then add 
"beginvirtualgate..endvirtualgate" for each instance where the gates are 
dissimilar in each IC package.

  I hope this message was informative and thought provoking.  I will submit 
the 7400 series library file in the near future.

Sincerely,

Stephen Hughes,
Honeycomb Electronics, Audio and Research, Inc.

[Xcircuit-dev] XCircuit version 2.5.2

[R. T. E. <ti...@st...>]

Dear Al,
   As version 2.5.2 is "beta", it is entirely possible that some error
crept into the save process, which is supposed to find all subcircuits
associated with a schematic and save them.  At the top of the window
of "PostScript output properties" should be a checkbox labeled with
the number of pages being saved.  This should have the same number of
pages as schematic pages in your design.  If not, then something is
wrong.
   Using "m" to make an object copies the result into the User Library,
which is a space in memory, not in a disk file (the "L" key shows you
all the libraries, including the User Library).  Again, inclusion of
user library objects into the output file should be automatic.
   I will try to investigate further to see if anything is wrong.  You
might consider not being "bleeding edge" and sticking with xcircuit
version 2.3.3, as it is probably a little less error-prone.

					Regards,
					Tim

[Xcircuit-dev] question about saving files

[Al A. <ex...@au...>]

Hello,

I am using version 2.5.2 (1) on a linux machine. I use it primarily for
spice netlist generation and I am having some difficulties.I create a
file with all of my subcircuit definitions and match them to symbols.
However I cannot seem to figure out how to keep ALL of my work when I
exit. It seems that even if I save each page individually to the same
file name *and* save the library, I lose several of my subcircuits. Is
it possible to have a "Save All" button so this does not keep happening? 

Also, I cannot seem to figure out *where* the new devices I create (from
selections using 'm'  to copy them) are going. The docs say it copies
them to the User library but I never see a file of that name. So when I
exit and restart xcircuit, nothing is ever left from my previous
session.

Thanks for your help.

Regards,
-Al Arduengo
------------
"Actual courtroom exchange:  Q: Do you recall the time that you
 examined the body?  A: The autopsy started around 8:30 p.m.  Q: And
 Mr. Dennington was dead at the time?  A: No, he was sitting on the
 table wondering why I was doing  an autopsy."

[Xcircuit-dev] XCircuit Schematic capture

[Al A. <ex...@au...>]

Hi Tim,

Wow! Thanks very much for the quick response. I'm extremely excited about 
having a decent scat capture program for Linux! If there is some way I can 
contribute please let me know.

Regards,
-Al Arduengo
-- 
"I don't think so" said Rene Descartes.
Just then he vanished.

[Xcircuit-dev] XCircuit schematic capture

[R. T. E. <ti...@st...>]

Dear Al,
   Sorry!  Looks like I messed up something in the schematic capture when
working on the 2.5.2 code.  I will get a bug fix for you right away.
Thanks for sending in the bug report.
						Regards,
						Tim

[Xcircuit-dev] unable to get heirchical netlist output

[Al A. <ex...@au...>]

I have followed the tutorial to the letter as well as attempted to do my own 
heirchical design and I cannot for the life of me get the spice netlist to 
also make the proper .subckt declarations. For instance I make a schematic of 
a pmos/nmos invertor, attach the in/out pins, vdd and gnd. Then I associate 
it with the invertor symbol in the builtin library. Next I create a top level 
schematic using the invertor and when the netlist gets written, I have this:

* some title
.global Vdd
.global Gnd

X1 in out invert
.end


There is no .subckt declaration for the instance invert. I also followed the 
tutorial for the integrator and it does the same thing. It makes the X# 
statement but provides not associated .subckt statement. I have installed as 
root and as user. No difference.

I am running Slackware 7.1, Xcircuit 2.5.2 and I have Python 2.1 installed. I 
used the following for configuring/installing as of the last try:

./configure --prefix=/apps/circuits --with-python=/apps/python
make
make install

all as root.

What else might I check? Is there something I am missing in the install 
process?

I appreciate anything in the way of assistance. Please feel free to e-mail me 
is you need more info than I have provided here.

Regards,
-Al Arduengo
-- 
"I don't think so" said Rene Descartes.
Just then he vanished.

[Xcircuit-dev] Answers to questions (!)

[R. T. E. <ti...@st...>]

Dear Klaus,

> But i never heard something again....

Not a lost email.  I *am* still working on the XCircuit-to-PCB toolchain,
but as usual the real reason I didn't send another message was that I got
buried in email (mostly from my Homeowners' Association) and forgot about
it.  Sometimes I need occasional reminders.  :)

Most of what you want to do can be done in xcircuit already, but it will
require some writing of Python scripts.  One thing I did in response to
your questions (and others') was to spend a couple of days writing up a
lot of information about the XCircuit Python interface and posting it
to the XCircuit website.  I'm hoping someone will pick up on this and
help with the script writing, which I don't have much time to do myself.
Otherwise, I would have moved all the netlist output functions to Python
by now.  Well, no, that's not really true;  I have been working on a
couple of concepts for XCircuit (especially for use with PCB) that
require working on the C source code.  One of them is to parameterize
properties other than string values (mostly done).  The other is to
allow pin label strings to be parameterized (currently the effect of
doing that is unpredictable).  This will allow a simple way to define
"quad parts", such as 1 of 4 NAND gates in a 7400 chip.  One NAND gate
object would have 4 instances, each with its own pin numbers.

This doesn't really address your questions, but these methods have to
be coded and working if xcircuit is going to be considered seriously
for a schematic-to-PCB toolchain.

> First i think it is the easiest way to give an aditional output. there
> is spice, pcb and so on, make here an new output "to filter". I have no
> good name today :-). The output to filter should be something like the
> replaced language from part library.

The current implementation is to run the command "netlist()" from the
Python prompt.  This dumps a "generic" form of the netlist in a big,
ugly Python dictionary variable.  Python can then work through the
generic netlist and create whatever output is required.  New output
formats only require a new Python script based on one of the existing
scripts, and doesn't require modifying the XCircuit source (less work
for me!).

Personally, I prefer that all the "filters" be written as Python modules.
If done properly, they could be written such that they can run either as
part of xcircuit (as I intended) or as a true standalone filter (as you
intended).

> BTW: Can you organise it to replace all the libraries with different
> implementaions of same parts (D, R, C) with one more complete library?
> It should not be so confusing .... Let analoglib2 as a startpoint of
> improvement and remove analog at all for example.

It "evolved" to the organization it has now.  The changes I mentioned
are going to require more reorganization.  I already have a new version
of "analoglib2" with xcircuit version 2.5.0.  I agree that the
original symbols should probably be considered "obsolete" and removed
at some point.  For now, I will consider at least to move duplicated
parts into a library file separate from the unique objects, so it is
easy to remove them from the startup script.

> To make xcircuit and pcb a complete toolchain there must be a better
> input for pcb, but that's not your part, but i think it will be a
> good idea that you talk with the pcb developers to make more than a
> netlist input from xcircuit to pcb.

Well, actually, I have done some hacking on PCB, so there's no reason
why it shouldn't be "my part".

						Regards,
						Tim

Re: [Xcircuit-dev] Re: xcircuit netlist->pcb

[Bryce D. <br...@tl...>]

On Tue, 23 Oct 2001, R. Timothy Edwards wrote:

> > Between xcircuit and pcb, we are really close to having a schematic+layout
> > flow for circuit boards.
>  
> That was the intention.  With me and Harry Eaton working at the same place,
> it was my hope that regardless of which program needed a change for the
> sake of compatibility, we could easily work something out.

Cool.  I didn't realize you two knew each other.


> > All the transistor models in generic and analoglib2 have letter-named pins,
> > such as B for base and E for emitter
> 
> I'm not going to apologize for being a VLSI designer.  It's what I do.  
> But it means that my netlists don't really look like your netlists, so
> you have to get used to the fact that libraries like "analoglib2" were
> really designed for VLSI work, not PCB work.  What is really called
> for here is a separate library (I should probably make it default,
> too, since more people seem to use xcircuit for PCB netlisting than
> for VLSI netlisting).  In particular, such a library would have
> symbols for TO-packaged transistors, where pins "1", "2", and "3" make
> sense (maybe with a circle around the transistor symbol, which seems
> to be more standard for PCB schematics than for VLSI schematics).  
> Such a library would also be the proper place for transformers,
> crystals, voltage regulators, and such, and MOSFETs and other mainly
> VLSI components could be moved to a different page.  What do you
> think?

That's funny because I do VLSI designs at work.  But I'm using xcircuit
for smaller-scale, smaller-budget hobby circuits where ICs and discrete
components are what I can afford to play with.  

> > Pcb's netlist reader is very picky about pin numbers and node names.
> 
> However, PCB itself seems to be very liberal about pin naming conventions.
> I will ask Harry if he thinks the netlist reader syntax can be extended to
> include arbitrary names for pins, or whether that would break stuff right
> and left.  If there's a file format standard he's following, we might have
> to go back to that to make changes.

PCB keeps trace of both pin numbers and pin names.  The names can be
anything you want, but they are just for display purposes.  Only the pin
numbers can be used to specify a netlist.  If the PCB netlist reader would
allow pin names, then calling them E B C in a pcb library would be fine.  
IMHO, better than 1,2,3, since you don't have to look up which is which.

> > Another issue that's minor but confusing is that it's possible to get two
> > Vdd nodes in the netlist.
> 
> To a point, that's intentional.  If you want a Vdd pin which gets merged
> with the rest of the Vdd network, it should be declared "Global"
> (menu "Netlist->Make Global Pin").  It's really the same problem as
> declaring the scope of a variable in software.  It prevents bad things
> from happening such as declaring a global name "E" and having it suddenly
> connect together every emitter of every bipolar transistor in your
> schematic.

Ok.  I can definitely see the point of having local names, but when you
write out a flattened netlist, if these names collide you have an illegal
netlist.  When flattening, you may need a function that turns duplicate
names into unique strings so that some other tool doesn't 1) fail to parse
the two nodes with the same name, or 2) short them together.


Regards,
Bryce

Re: [Xcircuit-dev] 74xx library

[Bob P. <bpa...@cs...>]

>  I haven't
> learned how to add parts to libraries yet in xcircuit (other than user),
> so there are some steps I would need help on.

This is what I found worked for me:

If you want to edit any library you start up a version of XCircuit then 
File/'Read XCircuit File' in the library.lps file.

It ends up in the 'user library'.  Edit it any way that you want, then save 
it out under a new name.  You have a new library that you can read in with 
File/'Load New Library', the next time you start up XCircuit (so that it is 
not in the User section any more).
 
Myself I see adding/changing parts to the libraries that come with XCircuit 
as bad form.  It makes upgrading to future versions harder, and it makes 
version control almost impossible.  So I always copy them off to other 
libraries before I change them.

Re: [Xcircuit-dev] Re: xcircuit netlist->pcb

[Bob P. <bpa...@cs...>]

> > All the transistor models in generic and analoglib2 have letter-named
> > pins, such as B for base and E for emitter

> What is really called for here is a
> separate library (I should probably make it default, too, since more people
> seem to use xcircuit for PCB netlisting than for VLSI netlisting).  In
> particular, such a library would have symbols for TO-packaged transistors,
> where pins "1", "2", and "3" make sense (maybe with a circle around the
> transistor symbol, which seems to be more standard for PCB schematics than
> for VLSI schematics). 

I've made several libraries specific to PCB netlists, you can get the ones 
for resisters and capacitors here: 
http://www.csonline.net/bpaddock/xcircuit/default.htm
I'll add others when I think I'm done changing them.
If some one wants me to post theirs there as well, I'd be happy to.
Hopefully at some point they will make the official XCircuit web page.

> Such a library would also be the proper place for
> transformers, crystals, voltage regulators, and such, and MOSFETs and other
> mainly VLSI components could be moved to a different page.  What do you
> think?

I would not lump them all into one library, but I agree that they should be 
separate from the VLSI libraries.

[Xcircuit-dev] Re: xcircuit netlist->pcb

[R. T. E. <ti...@st...>]

Dear Bryce,

Sorry about the lateness of this reply.  I was under the impression
that I was actually signed up on my own mailing list, but this appears
to not have been the case.  I have corrected that problem, and now I
should get these posts sent directly to me so I don't have to keep
visiting the SourceForge website to see what's going on.

> Between xcircuit and pcb, we are really close to having a schematic+layout
> flow for circuit boards.
 
That was the intention.  With me and Harry Eaton working at the same place,
it was my hope that regardless of which program needed a change for the
sake of compatibility, we could easily work something out.

> All the transistor models in generic and analoglib2 have letter-named pins,
> such as B for base and E for emitter

I'm not going to apologize for being a VLSI designer.  It's what I do.  But
it means that my netlists don't really look like your netlists, so you have
to get used to the fact that libraries like "analoglib2" were really designed
for VLSI work, not PCB work.  What is really called for here is a separate
library (I should probably make it default, too, since more people seem to
use xcircuit for PCB netlisting than for VLSI netlisting).  In particular,
such a library would have symbols for TO-packaged transistors, where pins
"1", "2", and "3" make sense (maybe with a circle around the transistor
symbol, which seems to be more standard for PCB schematics than for VLSI
schematics).  Such a library would also be the proper place for transformers,
crystals, voltage regulators, and such, and MOSFETs and other mainly VLSI
components could be moved to a different page.  What do you think?

> Pcb's netlist reader is very picky about pin numbers and node names.

However, PCB itself seems to be very liberal about pin naming conventions.
I will ask Harry if he thinks the netlist reader syntax can be extended to
include arbitrary names for pins, or whether that would break stuff right
and left.  If there's a file format standard he's following, we might have
to go back to that to make changes.

> Another issue that's minor but confusing is that it's possible to get two
> Vdd nodes in the netlist.

To a point, that's intentional.  If you want a Vdd pin which gets merged
with the rest of the Vdd network, it should be declared "Global"
(menu "Netlist->Make Global Pin").  It's really the same problem as
declaring the scope of a variable in software.  It prevents bad things
from happening such as declaring a global name "E" and having it suddenly
connect together every emitter of every bipolar transistor in your
schematic.

						Regards,
						Tim

[Xcircuit-dev] 74xx library

[Bryce D. <bry...@ya...>]

I notice that the pcb distribution has a definition of every kind of 74xx
gate in a very simple form.

define(`Description_7400_dil', ``4 dual-NAND'')
define(`Param1_7400_dil', 14)
define(`Param2_7400_dil', 300)
define(`PinList_7400_dil',
``1A',`1B',`1Y',`2A',`2B',`2Y',`Gnd',`3Y',`3B',`3A',`4Y',`4B',`4A',`Vcc'')

If we can settle on a preferred schematic symbol for each size of 74xx
chip, I can probably convince perl to parse their 74xx definitions and
write out xcircuit gates.  Do you think the IC templates look exactly the
way you want them to, or should we edit them a little first?  I haven't
learned how to add parts to libraries yet in xcircuit (other than user),
so there are some steps I would need help on.

-Bryce

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

[Xcircuit-dev] netlist bug

[Bryce D. <bry...@ya...>]

I posted another bug report on source forge:
  [ #473739 ] netlist: pin below a wire not connected
along with a sample .ps file that shows the bug.  Basically, if a pin is
not on top of a wire, the netlister doesn't notice that they are touching.

Other than the pins bug, it's working very well to create nice-looking
schematics and PCB netlist input.

I also sent two little feature requests
  [ #473399 ] zoom should recenter first
  [ #473400 ] after move, objects could stay selected

-Bryce

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

[Xcircuit-dev] xcircuit netlist -> pcb

[Bryce D. <br...@tl...>]

Between xcircuit and pcb, we are really close to having a schematic+layout
flow for circuit boards.  With some hacking, I've been able to make it
work for a sample schematic.

Pcb's netlist reader is very picky about pin numbers and node names.  It
refers to all pins by number, and ignores lowercase letters in some
circumstances.  All the transistor models in generic and analoglib2 have
letter-named pins, such as B for base and E for emitter, so I had to
rename these pins to 1,2,3 to make the netlist valid.  You might want the
pcb netlister to print a warning about letter-named pins, since pcb itself
will choke when it tries to read them in.  This is really a pcb limitation
(I can't believe they can't handle pin names) but that's how it is at the
moment.

For reference, here's what the pcb manual says about the netlist format
that it expects.

  "The netlist received by pcb must have this simple text form: netname
NAME-PINNUM NAME2-PINNUM2 NAME3-PINNUM3 ... [\] where "netname" is the
name of the net (currently its value is ignored but it must be present
nonetheless), NAME is the layout-name given to an element, and PINNUM is
the (usually numeric) pin number of the element that is part of the net
(see section Elements for details on pin numbering). Spaces or tabs
separate the fields. If the line ends with a "\" the net continues on the
next line and the "\" is treated exactly as if it were a space. If the
NAME ends with a lower-case letter, all lower-case letters are stripped
from end of the NAME to determine the matching name-on-board name. For
example: Data U1-3 U2abc-4 FLOP1a-7 Uabc3-A9 would specifiy that pin 3 of
U1 be connected to pin 4 of U2, to pin 7 of FLOP1 and to pin A9 of Uabc3."

Another issue that's minor but confusing is that it's possible to get two
Vdd nodes in the netlist.  Draw a Vdd symbol and also name a pin Vdd in
the diagram.  If you forget to connect them, the netlist writer prints one
Vdd from the "Vdd module" and a different one for the pin called Vdd.

Thanks,
Bryce

[Xcircuit-dev] Xcircuit-dev -- confirmation of subscription -- request 706885

[R. T. E. <ti...@st...>]

confirm 706885