← Back to team overview

kicad-developers team mailing list archive

Re: PCB Layer Stackup UI


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 best choice:
- 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 format itself, 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.

(header .....)
(layer name1 )
(layer name2 )
(edges (line sx sy endx endy) (line sx sy endx endy) (arc ...) )
(nets ..... )
(netclasses .....)
(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.


Follow ups