kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

> 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.


(board
(header .....)
(layers
(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.

Dick