kicad-developers team mailing list archive
Mailing list archive
Re: PCB Layer Stackup UI
Dick Hollenbeck <dick@...>
Wed, 09 Dec 2009 10:12:02 -0600
Thunderbird 184.108.40.206 (X11/20090817)
I must study the specctra format (220 pages cannot be read in 5 minutes).
And know how to save some specific pcbnew data.
(for instance data relative to zones like the list of filled sub areas
in a given zone outline)
I agree with you for this point:
We can modify (with minimal modifications) the current pcb file format
to support these modifications.
Or use an other format, and in this case the .dsn file format is the
- a lot of work is already done (thanks, Dick)
- This will solve import/export problems with others EDA tools.
The main problem when using the specctra format is not the the specctra
but the stupid and very restrictive copyright of the specctra
specifications documentation, that just allows to print one hard copy.
(therefore, we cannot put this doc on Kicad servers).
(I expect just we can use an other color than white ink to print this
*one* hard copy. This is not specified in the copyright.)
I meant to say specctra syntax, not specctra format. There is no
specctra format that can fully describe a board. Briefly, there is the
DSN format and the SES format. The DSN describes the copper layers
only, no technical layers. No text. The SES format describes a subset
of the copper layers and has less information in it.
By specctra syntax, I mean using tokens in a way that the existing lexer
can still work without any changes other than a new token table. You
could chose to adopt some elements of the DSN format, or very few and
keep the grammar similar to the existing board format.
You/we can fully define our own grammar, since the grammar can be
handled by recursive descent with new code. You can even simply do a
one for one change of the *.BRD format keeping the same higher level
grammar, just like I said you could put in LAYERSET (layers ....) you
could put in anything.
(layer name1 )
(layer name2 )
(edges (line sx sy endx endy) (line sx sy endx endy) (arc ...) )
(nets ..... )
(components (part name (position (side back) (orientation 0) x y)
(outline (drawing...) ) (pads....) )
(wires (trace layer width start end)(trace layer width start end)...)
(vias (via size hole x y )...)
(zones (zone (net 23).....) .... )
) # end board
the grammar could be exactly the same, so that the BOARD internal data
structures do not have to change. Of course you would want to use
floating point coordinates, but probably stick with the existing
internal usage of units for now. Later without file format change, you
could go to a finer internal unit.
The syntax does not use commas. It uses spaces and parenthesis. This
syntax controls what the lexer needs to do, and if you stick with simple
syntax, you can define your own grammar and use the existing lexer with
a new token table.
Notice that above, I allowed every via to define itself. A better
alternative is to define all the unique vias by name using a padstack
like element, then simply reference that via type by name and position
later for each instance.