Mail Archives: geda-user/2015/10/19/14:51:06
> >> And you need a way to distinguish them.
> >
> > I think we're underestimating the importance (and complexity) of that.
>
> I think you want something foolproof. That desire will drive a great
> deal of complexity, and I don't think it's possible without
> seriously getting in the way of user needs.
I'm not trying to make things complex, I'm trying to figure out how to
solve a seemingly easy problem in a useful way. The users have been
asking for this for a while now, so it's not a case of "getting in the
way of user needs" but "meeting user needs". What kind of solution
can we offer? Are there pitfalls to this solution? Is there a better
way? Just saying "I don't think it's possible" doesn't help.
> > So... what if we dumped slotting?
>
> A lot of current projects would break.
True, I meant "as a way of solving this problem".
> > What would schematics look like then? Do we assume/require that
> > the user will create a schematic with a separate refdes for each
> > gate in a package?
>
> Unless you make a kit which is fundamentally alien to the way that
> geda-gaf works, I think this is necessary.
What "kit"? Why would a valid use of a toolkit be "alien" to how it
works? Why is it that every time I propose something different than
the way you use geda, you tell me "that's now how geda works" ?
> > That, of course means we need to set some expectation of what
> > <downstream>'s package refdes would look like,
>
> We're talking about abstract schematics, right? Consider a generic Sallen-Key filter as given at: https://en.wikipedia.org/wiki/Sallen%E2%80%93Key_topology#/media/File:Sallen-Key_Lowpass_General.svg. You have R1, R2, C1, C2. Do you expect those to carry over into the final as-built design?
Of course not, but you're not answering the question. What would the
refdes look like in <downstream> ? This is the same as flattening a
heirarchy, just because it says "R1" on the schematic doesn't mean we
should have N components in the layout called R1. How do we expand
this solution to include multiple symbols that are part of one
component? Or, if we can't come up with a solution, how do we make
sure the user works within the limitations needed by what we do come
up with?
> > Are there cases where a package contains two identical copies of
> > something complex enough to each be broken into separate symbols?
>
> Microcontroller I/O ports, FPGA I/O banks. Probably other things. I don't trust the limits of my imagination, and you shouldn't either.
None of those use slotting, though. Made up example: two MCUs in one
chip, each MCU has a symbol for the control logic and a separate
symbol for the I/O banks. The design would end up mixing slotting and
mutli-symbols, yet must make sure the right control logic goes with
the right I/O bank :-)
- Raw text -