kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx>]

----- Original Message -----

> From: Dick Hollenbeck <dick@xxxxxxxxxxx>
> To: kicad-developers@xxxxxxxxxxxxxxxxxxx
> Cc: 
> Sent: Friday, September 6, 2013 3:49 AM
> Subject: Re: [Kicad-developers] Experiments and considerations for more	layer
> 
> On 09/05/2013 12:03 PM, Lorenzo Marcantonio wrote:
>>  On Thu, Sep 05, 2013 at 11:02:36AM -0500, Dick Hollenbeck wrote:
>>>  Says you.   Says me:  having the the bits in the instance block matter.
>>> 
>>> 
>>>  I guess if what I have to say is going to be labelled as irrelevant 
> right out the box, I'd
>>>  be wasting my time continuing.
>> 
>>  Strange that, said by someone which a little while ago told that data
>>  could even be on the moon and it's all a question of interface... 
> I'd
>>  like you to notice that in my first message I was concerned about
>>  performance of an object vs a simple integer. These things should be a)
>>  readily copyable and b) readily passed around by value, from the common
>>  usage pattern I've seen.
>> 
>>> From a performance standpoint I'd roughly evaluate the 
> implementations (both in
>>  space and in time) in this order: int, std::bitset<>, 
> std::vector<bool>,
>>  std::set<int>. The adhoc implementation should be roughly on par with
>>  bitset. 
> 
> 
> Agreed, I estimate the same.
> 
> 
>> 
>>  However, what I meant was that there were 'bigger' proposals on the 
> list
>>  to evaluate. Something like std::bitset (i.e. something inherently
>>  configured and limited at compile time) clearly is not adequate for
>>  these proposals.
> 
> 
> 
> I think Tom's class is adequate. I don't think Brian S.'s idea about 
> dynamically
> assignable layer slots is optimal.  I think fixed layer slots are easier to 
> code, but I
> don't see why you have to limit the number of slots with Tom's 
> approach.  You can have 300
> layers if you want, but I think you need to pre-assign all of them, and chose 
> not to use
> but a subset of them on any board.
> 
> I think fixed technical layer names are important, both to KiCad branding and to 
> board
> merging like JP mentioned.  Because these names are being indexed by google.
> 
> KiCad branding comes about via help with google and propagation of opensource 
> boards and
> pretty footprint libraries.
> 
> This is part of why I don't want to mess with the technical layer names that 
> are in place
> already and why I yanked the international language translations for them.  
> *Adding* to
> that established list with concise English names is not a problem for me.  The 
> footprint
> format, at least pretty, should not be viewed as forever fixed.  However the 
> keywords we
> have already chosen should not be changed, while remaining open to significant 
> additions
> to it.
> 
> 
> Some observations:
> 
> a) specctra numbers copper layers from front to back, starting from zero.
> 
> 
> b) in contrast, my most recent conversations with bare board houses in China had 
> them
> numbering layers from back to front, starting at 1 on the back.
> 
> 
> c) The internal copper bit masks for layers has always bothered me, the sequence 
> that is.
> 
> 
> d) Existing problematic code fragments should be identified early in the 
> planning phase,
> and any design change should be evaluated on its ability to handle the 
> problematic code
> collection.  Please start that problematic list with where I output the pretty 
> layers, and
> extend it by adding to it.
> 
> 
> It seems to me we could go with a conceptual enumeration embodied in Tom's 
> FLAG_SET
> template, where the enumeration starts at zero and goes on up forever if need 
> be.
> Although you pick the end of the range with a compiled in number, that is 
> pertinent until
> it is inadequate.
> 
> If the result of the first implementation is that you do not depend on layer 
> numbers
> (much), but rather on names or range checking, then you can shift that 
> enumeration at any
> time in the future without causing the source code or existing data files any 
> grief.
> 
> 
> For for the sake of discussion, I propose as one possibility:
> 
> 0 - 31 are cu layers
> 
> 32 - MAX_LAYER   are technical layers.
> 
> 
> These LAYERs and LAYER_SET are done using "Tom's 20 minute solution 
> plus augmentation, as
> needed".
> 
> 
> If you have based your files on concise English names for all but the Cu layers, 
> but those
> cu layers are also named, then I don't see any large grief to shift this 
> conceptual
> enumeration which runs from 0 - MAX_LAYER.  Not only can you make MAX_LAYER 
> higher, but
> you can also shift regions of interest within it without radically impact code 
> or data
> files later.
> 
> 
> Dick
> 
> 
> 
>> 
>>  std::set<int> (usually a balanced tree) is the bigger and slower and
>>  IMHO only would have a meaning if we allowed arbitrarily large and
>>  sparse layer numbers. std::vector feels a good compromise. An
>>  std::bitset<> or a int64_t would be useful if we put a cap of maximum 
> 64
>>  or whatever number of simultaneous layers. With an 'adequate' 
> layerset
>>  structure that could be arranged.
>> 
>> 
> 
> 


This sounds good, and 32 copper layers should suit all but the most exotic cases in the future.  This is a major break with the past though, but I think a necessary one - however, so long as we know the version number of the file format, older files can be seamlessly imported and the general user shouldn't have any problems. Being able to add on technical layers without having to worry about a layer size limit as features are implemented is a Good Thing.

- Cirilo