Dick Hollenbeck a écrit :
Jean-Pierre,
<snipped>
What is the most number of layers for a PCB board that you have ever
heard of? I cannot tell if you are being humorous above or not.
I was humorous, but the most number of layers for a PCB board that we
must consider is a very important question.
The professional board designer who work with me made recently a 10
layers board (and many 8 layers board) with Pcbnew.
I saw a lot of 16 layers board, an my board manufacturer said me (last
year) he made some 20 layers boards.
A friend of mine saw a 40 layers board, but such a board uses a specific
technology:
This is *really* a printed board (a layer of conductive ink covered by a
layer of non conductive ink, repeated 40 times)
This specific technology handle very easily blind vias.
For now, 16 layers seems enough for Pcbnew, but I believe in few years,
more than 16 layers will be needed.
A reason could be due to the high frequencies of logic signals in
designs using recent fpga.
The bandwidth of these signals is more than 2 GHz, and therefore boards
must be designed like microwave applications:
each critical track is a strip line on a ground plane.
(this problem is the reason why i recently added the the track length
display in Pcbnew, because my board designer needs to route a lot of
tracks with a given length and impedance between a connector and an
integrated circuit)
And to reduce EMI problems some designers use the top and bottom layers
a ground planes (no tracks to reduce EMI)
So such boards could need an active layer between 2 ground planes.
In these caes, 7 active layers (a very reasonable amount of layers) need
9 ground planes, and therefore the full capacity of Pcbnew.
So handle 32 copper layers could be mandatory tomorrow.
And be able to handle 64 or more copper layers in Pcbnew code is not stupid.
Of course no need to handle many non copper layers.
I think if we introduce a new class (hierarchy?) called LAYERSET we can
hide the details of how the IsOnLayer() method is done, along with the
hiding the data that is used in that test. So BOARD_ITEM:: IsOnLayer(
aLayerNumber ) would then call LAYERSET::IsOnLayer () to do its work, and
the LAYERSET data would be hidden inside itself. This way we can
support a number of different types of layerset specifications,
including but not limited to: list, range, and all copper layers. The
problem with using "list of layers" to also indicate "all layers" is
that this becomes a layer count dependent test. Same for range.
Whereas if we have a special flag for the "all copper layers" case in
the encapsulated data of LAYERSET, then we can handle both situations.
A LAYERSET element would become part of a D_PAD element. And would have
its own textual representation when being serialized to a file. The
textual representation could be dropped into the current location for
layermask for D_PADs in your existing *.brd file format.
Examples of a textual representations for LAYERSET specs (range, list,
and all) would be:
(layers 0-14) # a range
(layers 0 1 2) # a layer list of arbitrary length
(layers all) # all layers
(layers front back) # a list, but with special layer names
(layers front) # front only
(layers back) # back only
As said, these textual representations could be placed anywhere you are
currently using a layer mask or multiple layers in the current format.
A wholesale board file format change is not needed, but I am not
expressing resistance to said wholesale change.
I suggest that we add a parameter to the xxx::IsOnLayer( ) test in
addition to aLayerNumber, that being the BOARD*. This way we can query
the layer counts without walking up a datatree from a D_PAD to the BOARD
for example.
Seems good.
As an implementation detail, I probably would still go with a bitmap of
enabled layers, but expand it to the necessary number of bits required
to support all our desired layers. It is a simple matter to create a
bitmap mask from aLayerNumber. This is a direction of conversion, from
index to mask, that is no problem. It is the other way around that is a
problem, mask to index, and we should not use or need any conversion in
this direction. The important thing is that the file format change does
not limit us in any way, and the details of how we represent LAYERSETs
should be encapsulated, and only exposed through sensible member
functions which aid in the data hiding. You probably need to forget
what I said before about byte arrays being useful internally. It think
a bitmap is still superior to a byte array. (But a bitmap can be done
in the future or now with a byte array. Until we exceed 64, I would use
a uint64_t to hold the bitmap.)
Yes, the important thing is the file format must not depend on the
internal representation of the pcbnew data.
So using a bitmap or a byte array is not critical.
So we would swap the direction of the layer numbers, and start at 0 for
FRONT. The question I still have is what value would we use for BACK?
This is important only internally, since the new file format never
exposes the numerical value of BACK!
We should probably add a Save() or Format() type function to LAYESET to
maintain the data hiding duties and understanding within the class itself.
If you want to take on more and redo the entire board file format, then
I suggest the specctra format, and starting with a sample using a text
editor. See if you can create a board file using a simple text editor
according to your heart's desire.
Out of this will fall out the new format, and the format of all nested
objects.
Or we can dissect out the layer specs and layermasks that he have now in
the current format, and replace them with the LAYERSET textual
representation, and mark the new file format revision in the header.
Then we have to decide on whether we keep all the board legacy
conversion code in PCBNEW or put it into an external conversion program,
so that PCBNEW can be leaner.
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.)
