New CAD design questions.

[Jamie]

I'm building a new Electrical/Electronic type Project CAD program
that will combine Drawings of several types, Board lay outs with foot
prints, cabinet lays and drilling templates etc.. a
This will all be in a single IDE tool with tab pages and properties
settings etc...
What I would like to know its this..
The Library database storage methods..

Create Symbol/Foot prints database as:

(1). Binary formats // Faster and more compact.

(2). Binary formats with optional Script generation.

(3). Script format all the way. // much slower to process but can be
manually edited if need be..

Would like to know what would be the best format ?

P.S.
the IDE will also include all the tools to create the symbol library.


--
"I'm never wrong, once i thought i was, but was mistaken"
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5

 

[qrk]

On Sun, 01 Jul 2007 12:36:07 -0400, Jamie
<jamie_ka1lpa_not_valid_after_ka1lpa_@charter.net> wrote:

I'm building a new Electrical/Electronic type Project CAD program
that will combine Drawings of several types, Board lay outs with foot
prints, cabinet lays and drilling templates etc.. a
This will all be in a single IDE tool with tab pages and properties
settings etc...
What I would like to know its this..
The Library database storage methods..

Create Symbol/Foot prints database as:

(1). Binary formats // Faster and more compact.

(2). Binary formats with optional Script generation.

(3). Script format all the way. // much slower to process but can be
manually edited if need be..

Would like to know what would be the best format ?

P.S.
the IDE will also include all the tools to create the symbol library.

Store it in whatever format works for you. However, being able to
convert to and from ASCII format is really nice as it allows one to
create their own library generator, perform scripted editing of the
libraries (you gotta love SED!), and create many-pin symbols with a
text editor. Xilinx is one company that supplies ASCII files of FPGA
pinouts. Allows one to make a 700-pin FPGA schematic symbol in less
than 20 minutes. GUI tools to generate symbols are fine for a few
pins, but when the pin count gets into the tens or hundreds, ASCII is
the way to go.

Look at the old DOS Orcad tools. Everything was editable in ASCII
form. Even the intermediate netlist format was ASCII which allows one
to create their own net list formatter. One guy just recently wrote a
program that generates thousands of IPC footprints to the old DOS
Orcad PCB program because Orcad PCB can import ASCII descriptions.

Your PCB and Schematic files should also be convertable to and from
ASCII format. I often find myself making changes via a text editor to
my schematics or creating multichannel schematics by editing ASCII
representations. It really saves time.

Don't forget about macros and user definable hot keys.

If your project is open source, you may be interested in joining up
with a new project that is looking into creating a schematic and PCB
program suite. The primary focus is productivity, unlike most of the
other programs out there. If you're interested, I can send you details
on joining the group.

---
Mark

 

[Hal Murray]

Store it in whatever format works for you. However, being able to
convert to and from ASCII format is really nice as it allows one to
create their own library generator, perform scripted editing of the
libraries (you gotta love SED!), and create many-pin symbols with a
text editor. Xilinx is one company that supplies ASCII files of FPGA
pinouts. Allows one to make a 700-pin FPGA schematic symbol in less
than 20 minutes. GUI tools to generate symbols are fine for a few
pins, but when the pin count gets into the tens or hundreds, ASCII is
the way to go.

For things like Xilinx, I suggest a 2 step approach.

One file describes the chip. Which pins are power? Which
signal pins are input, output, tri-state...

A second file describes the design and the mapping of signal
names to pin numbers. Maybe this file has hints about
how to draw the pictures.


--
These are my opinions, not necessarily my employer's. I hate spam.

 

[Jamie]

Hal Murray wrote:

Store it in whatever format works for you. However, being able to
convert to and from ASCII format is really nice as it allows one to
create their own library generator, perform scripted editing of the
libraries (you gotta love SED!), and create many-pin symbols with a
text editor. Xilinx is one company that supplies ASCII files of FPGA
pinouts. Allows one to make a 700-pin FPGA schematic symbol in less
than 20 minutes. GUI tools to generate symbols are fine for a few
pins, but when the pin count gets into the tens or hundreds, ASCII is
the way to go.


For things like Xilinx, I suggest a 2 step approach.

One file describes the chip. Which pins are power? Which
signal pins are input, output, tri-state...

A second file describes the design and the mapping of signal
names to pin numbers. Maybe this file has hints about
how to draw the pictures.


Basically what I am doing is creating what I call an

inherited database of symbols. these would be the most
primitive types like circles, boxes etc. that are in a vector
type so that size can be adjusted when applied to another
symbol design etc.. the final end will be a vector type
graphic to be used
the final graphic will have magnetic connection points to
make it easy for you to lay it out. each project will be
storing the drawings in a vector type system that encompasses the
symbol drawings and the node map to draw on the display..
I suppose I could dump this out in an ASCII format also.
By including all of the required symbol data in a section of
the files, one could open this schematic for example and be able
to view even if they don't have the symbols on board but could
grab a copy of the symbol and add it to their own lib.

It will make for a larger set of schematic files how ever, the
danger lye's in one day you may want to open the file that may have
used older foot prints that you no longer have maybe due to a crash
or what ever.
Also a simple viewer could be created just for viewing much like the
PDF system..

--
"I'm never wrong, once i thought i was, but was mistaken"
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5

 

[Marra]

I have written a PCB CAD program over the last 12 years and I opted
for the binary approach.
This allows the data to be more compact than scripting.
It was originally written for DOS hence the compact data system.

Having said that there is no reason why a converter could not be
written to edit the binary data.

As for editing I just wrote a good symbol editor that was very easy
for the user.
Instead of just allowing the user to plonk pads everywhere I asked for
some parameters upfront and got the software to place everything. You
still had the option to edit it afterwards if need be.

www.ckp-railways.talktalk.net/pcbcad21.htm
www.ckp-railways.talktalk.net/pcbcad28.htm

 

[qrk]

On Sun, 01 Jul 2007 19:40:23 -0400, Jamie
<jamie_ka1lpa_not_valid_after_ka1lpa_@charter.net> wrote:

Hal Murray wrote:

Store it in whatever format works for you. However, being able to
convert to and from ASCII format is really nice as it allows one to
create their own library generator, perform scripted editing of the
libraries (you gotta love SED!), and create many-pin symbols with a
text editor. Xilinx is one company that supplies ASCII files of FPGA
pinouts. Allows one to make a 700-pin FPGA schematic symbol in less
than 20 minutes. GUI tools to generate symbols are fine for a few
pins, but when the pin count gets into the tens or hundreds, ASCII is
the way to go.


For things like Xilinx, I suggest a 2 step approach.

One file describes the chip. Which pins are power? Which
signal pins are input, output, tri-state...

A second file describes the design and the mapping of signal
names to pin numbers. Maybe this file has hints about
how to draw the pictures.


Basically what I am doing is creating what I call an
inherited database of symbols. these would be the most
primitive types like circles, boxes etc. that are in a vector
type so that size can be adjusted when applied to another
symbol design etc.. the final end will be a vector type
graphic to be used
the final graphic will have magnetic connection points to
make it easy for you to lay it out. each project will be
storing the drawings in a vector type system that encompasses the
symbol drawings and the node map to draw on the display..
I suppose I could dump this out in an ASCII format also.
By including all of the required symbol data in a section of
the files, one could open this schematic for example and be able
to view even if they don't have the symbols on board but could
grab a copy of the symbol and add it to their own lib.

It will make for a larger set of schematic files how ever, the
danger lye's in one day you may want to open the file that may have
used older foot prints that you no longer have maybe due to a crash
or what ever.
Also a simple viewer could be created just for viewing much like the
PDF system..

Embedding the parts in the schematic file is a good thing as it makes
the project portable and self-archivable.

For the PCB program, it's also a good idea to have a DXF import/export
function. This allows you to draw up complex footprint or board
outlines in a drawing CAD package then import to the PCB program.

 

[Jim Thompson]

On Mon, 02 Jul 2007 18:17:31 GMT, qrk <SpamTrap@spam.net> wrote:

[snip]

Embedding the parts in the schematic file is a good thing as it makes
the project portable and self-archivable.

[snip]

The old original MicroSim (PSpice) Schematics is all ASCII and has an
archiving method that pulls only those symbols used in that particular
schematic.

Which is a good deal... I literally have THOUSANDS of home-brew
symbols.

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice480)460-2350 | |
| E-mail Address at Website Fax480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |

America: Land of the Free, Because of the Brave

 

[Joel Kolstad]

"Jamie" <jamie_ka1lpa_not_valid_after_ka1lpa_@charter.net> wrote in message
news:iyQhi.16$qF2.14@newsfe02.lga...

The Library database storage methods..

Create Symbol/Foot prints database as:

(3). Script format all the way. // much slower to process but can be
manually edited if need be..

Do it this way using, say, XML. Sure, it's slower than binary, but on a
modern PC in all likelihood you'll still be waiting on the hard drive for the
actual data, so there probably won't be any difference in *actual* execution
time based on the binary/ASCII choice.

 

[Joel Kolstad]

"Marra" <cresswellavenue@talktalk.net> wrote in message
news:1183397460.153263.35550@k29g2000hsd.googlegroups.com...

I have written a PCB CAD program over the last 12 years and I opted
for the binary approach.
This allows the data to be more compact than scripting.
It was originally written for DOS hence the compact data system.

12 years ago, this made plenty of sense. Today, with 500GB hard drives
selling for $100 and file systems that support on-the-fly compression, I think
the ASCII/XML approach makes much more sense.

Having said that there is no reason why a converter could not be
written to edit the binary data.

The usual problem here is that if you have a corrupted library file, most
converters use the exact same code to read the library as the regular program
does, and therefore will die a horrible death as well, preventing a (manual)
fix.

 

[Hal Murray]

Embedding the parts in the schematic file is a good thing as it makes
the project portable and self-archivable.

The downside is that it's harder to fix a bug in a library part
and or share library info with other designs.

The original question was ascii or binary. You tossed in another
interesting consideration: archiving.

My preference is lots of small tools rather than one big GUI mess.
A major advantage is that I can often do something that the
one-big-package doesn't do.

What I really want is something like make and the tools to generate
a makefile so I can easily be sure that I have done all the steps
I need to do when making gerbers and archiving everything.

Lots of small tools generally work better with ascii than binary.

If the performance hit is serious, I'm happy using binary
files as long as there is a simple way to translate beetween
them. I'd be surprised if that happens at the board layout
level - maybe for large boards.

--
These are my opinions, not necessarily my employer's. I hate spam.

 

[Bob Woodward]

qrk wrote:

On Sun, 01 Jul 2007 19:40:23 -0400, Jamie
jamie_ka1lpa_not_valid_after_ka1lpa_@charter.net> wrote:

Hal Murray wrote:

Store it in whatever format works for you. However, being able to


Embedding the parts in the schematic file is a good thing as it makes
the project portable and self-archivable.

Another good thing is that a schematic file can be used as library.
Removing wires, Sorting the parts, write their names alongside and
print it for easy lookup. Same for board-lay out.

For me, even with available libs containing thousands of parts I need
to edit a part right in the first project.

Andre

 

[qrk]

On Tue, 03 Jul 2007 00:00:58 -0500,
hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote:

Embedding the parts in the schematic file is a good thing as it makes
the project portable and self-archivable.

The downside is that it's harder to fix a bug in a library part
and or share library info with other designs.

The original question was ascii or binary. You tossed in another
interesting consideration: archiving.

My preference is lots of small tools rather than one big GUI mess.
A major advantage is that I can often do something that the
one-big-package doesn't do.

This is one of the reasons I still use the old DOS Orcad schematic
tool, SDT. Over the years, people have written apps and drivers to
modernize aspects of SDT. I cringe when I see customers fighting with
Capture.

What I really want is something like make and the tools to generate
a makefile so I can easily be sure that I have done all the steps
I need to do when making gerbers and archiving everything.

With Layout/GerbTool, I have written a macro for GerbTool that moves
the fab files to other directories. Sure reduces the headache of
moving those files by hand.

Lots of small tools generally work better with ascii than binary.

If the performance hit is serious, I'm happy using binary
files as long as there is a simple way to translate beetween
them. I'd be surprised if that happens at the board layout
level - maybe for large boards.

---
Mark

 

[Marra]

On 2 Jul, 22:57, "Joel Kolstad" <JKolstad71HatesS...@yahoo.com> wrote:

"Marra" <cresswellave...@talktalk.net> wrote in message

news:1183397460.153263.35550@k29g2000hsd.googlegroups.com...

I have written a PCB CAD program over the last 12 years and I opted
for the binary approach.
This allows the data to be more compact than scripting.
It was originally written for DOS hence the compact data system.

12 years ago, this made plenty of sense. Today, with 500GB hard drives
selling for $100 and file systems that support on-the-fly compression, I think
the ASCII/XML approach makes much more sense.

Having said that there is no reason why a converter could not be
written to edit the binary data.

The usual problem here is that if you have a corrupted library file, most
converters use the exact same code to read the library as the regular program
does, and therefore will die a horrible death as well, preventing a (manual)
fix.

Why would the file ever get corrupted?
I have yet since I wrote the first version in 1990 to get a corrupt
library file !
It shouldnt happen unless there are bugs in the software or someone is
extremely stupid like switching the PC off by mains instead of logging
off.

The binary method means the data can be held in simple arrays in
memory instead of on the hard disc, making reading and writing very
very fast. Even with modest amounts of memory massive pin loadings can
be used with binary.
I also fit strings exactly into memory without allocating something
silly like 64K to a string each time. It makes for very careful
programming but I find if I do make a mistake it goes horribly wrong
which is better than missing something.

PC's do have massive storage and power now but I still find .NET V3
graphics slow even on a dual core PC.
Having moved on to ORCAS it is even worse still.
It doesnt matter how much power PC's have it is never enough to keep
up with the demands of the latest OS.




I also embed the library parts used into the schematic.

 

[Joel Kolstad]

"Marra" <cresswellavenue@talktalk.net> wrote in message
news:1183506252.681464.62020@57g2000hsv.googlegroups.com...

Why would the file ever get corrupted?

Most likely reason: Bugs in the software. I've used various EDA tools over
the years, and I can specifically recall all of ORCAD, PCAD, Protel, and
Pulsonix corrupting files at some point. (ORCAD Capture is bad enough that I
can *almost* get it to do so consistently... not that I think being able to
demonstrate such a problem would actually cause Cadence to *fix* it, of
course.)

I have yet since I wrote the first version in 1990 to get a corrupt
library file !

Yes, but your software is nowhere near as sophisticated as most contemporary
EDA tools. More sophistication unfortunately often correlates with more
bugs...

I also fit strings exactly into memory without allocating something
silly like 64K to a string each time

Most string libraries today use aliasing/copy on write to reduce memory
requirements along with some heuristical approach to memory allocation (e.g.,
start all strings at, say, 16 bytes, grow the memory allocated to them by a
factor of 2 whenever they hit the current size limit) to keep performance up.
I'd be surprised if any commercial products were so bad as to allocate 64K to
each and every string.

It doesnt matter how much power PC's have it is never enough to keep
up with the demands of the latest OS.

Very true.

I also embed the library parts used into the schematic.

That's my preference as well, although I don't have anything against EDA tools
that merely reference library parts in their design files so long as there's a
function to create a standalone library file that contains all the reference
parts (PCAD did it this way).

---Joel

 

[xray]

On Sun, 01 Jul 2007 19:40:23 -0400, Jamie
<jamie_ka1lpa_not_valid_after_ka1lpa_@charter.net> wrote:

the danger lye's in

Indeed. Red Devil, I suppose.

I guess that's why you can't easily buy it anymore
http://candleandsoap.about.com/b/a/203763.htm