On 2018-03-14 09:05, John Larkin wrote:> On Wed, 14 Mar 2018 08:00:27 -0700, Joerg <news@analogconsultants.com> > wrote: > >> On 2018-03-13 17:16, krw@notreal.com wrote: >>> On Tue, 13 Mar 2018 16:03:57 -0700, Joerg <news@analogconsultants.com> >>> wrote: >>> >>>> On 2018-03-13 15:11, Lasse Langwadt Christensen wrote: >>>>> Den tirsdag den 13. marts 2018 kl. 22.38.37 UTC+1 skrev Joerg: >>>>>> On 2018-03-13 08:43, John Larkin wrote: >>>>>>> On Mon, 12 Mar 2018 17:43:07 -0700 (PDT), whit3rd <whit3rd@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> On Sunday, March 11, 2018 at 1:59:26 PM UTC-7, John Larkin wrote: >>>>>>>> >>>>>>>>> The original justification was that decimal points were somehow >>>>>>>>> fragile and got lost on drawings, so the wrong parts values got >>>>>>>>> installed. It was nonsense of course. >>>>>>>> >>>>>>>> Too young to recall thermal fax machines? >>>>>>>> Lines that crossed got rather fat at the intersection, >>>>>>>> and the images faded over time. >>>>>>> >>>>>>> I started with hand-drawn schematics on vellum, and blueprint >>>>>>> machines. And I still use both. And I never lose or mistake decimal >>>>>>> points or tie points. Maybe that's because I had two semisters of >>>>>>> engineering drawing in college. >>>>>>> >>>>>>> I don't think that a D-size schematic could be FAXd, then or now. >>>>>>> >>>>>>> A lot of current "wisdom" is left over from olden days, and especially >>>>>>> bad, amateur habits of olden days. We have computers now. Parts lists >>>>>>> are generated automatically from our schematics, and computers don't >>>>>>> mistake decimal points for coffee stains. Software gets the net lists >>>>>>> right even when two wires cross. >>>>>>> >>>>>> >>>>>> I have found bugs in netlists. Mostly where wires looked like they >>>>>> connected to a component but didn't. I check every schematic on all my >>>>>> designs against the netlist by hand. Doing one right now. It's tedious >>>>>> grunt work but better safe that sorry. >>>>> >>>>> missing connections to a component should be caught by ERC >>>>> >>>> >>>> Not if, for example, the pin is declared as output in the symbol because >>>> leaving outputs unconnected is perfectly ok. Same for I/O or passive. >>> >>> These pins should (have to) be marked as not connected. >>> >> >> The x's like Lasse showed aren't very customary anymore these days. Some >> CAD systems could even choke on those if you placed some. > > There is a strong tendency among tekkies to automate things that they > should just do themselves. Why do the grunt work of checking your > design or code when you can buy some fancy tools/toys to do it for > you? >Until some day it doesn't. Or does it except for a few spots.> Problem is, the fancy tools can't understand your parts, requirements, > or intent. > > Some tools, like PCB clearance and connectivity checks are great and > don't (much) encourage bad habits. Some tools switch off thinking. > > But you *can* blame the tools/toys when the board doesn't work. >It's like with cars, for example anti-lock brakes. People think they can now just stomp on it and it'll be alright. Until that not so sunny day when the road is slick and the fancy system prevents their car from stopping. -- Regards, Joerg http://www.analogconsultants.com/
Dot allowed as characters allowed in netlist?
Started by ●March 11, 2018
Reply by ●March 14, 20182018-03-14
Reply by ●March 14, 20182018-03-14
On Wed, 14 Mar 2018 07:57:41 -0700, Joerg <news@analogconsultants.com> wrote:>On 2018-03-13 17:11, krw@notreal.com wrote: >> On Tue, 13 Mar 2018 14:38:35 -0700, Joerg <news@analogconsultants.com> >> wrote: >> >>> On 2018-03-13 08:43, John Larkin wrote: > >[...] > > >>>> Scientific notation and SI units are correct. The 4K7 thing is amateur >>>> audio nonsense. >>>> >>> >>> It was worse in the old days. Often a schematic said .001 with no units >>> whatsoever and you had to guess from the function of the circuit what >>> that meant. Not a problem for us seasoned guys but that could throw >>> freshly minted engineers a curve. >> >> There was usually a note that said something like "all capacitance >> values in microfarads and all resistance values in k-ohms, unless >> otherwise noted). >> > >A group of engineers from Europe joined a US team. A prototype had to be >made in the machine shop. A few days and $800 cross-charged Dollars >later ... "This is way off in size!" ... "No, it's accurate. For >example, you said this side should be 342 mils and it is" (holding >caliper to it) ... "But, but, no, with mil I meant millimeters".How does that relate to electronics. I suggest they should be fired anyway (or more accurately, shouldn't have been hired).
Reply by ●March 14, 20182018-03-14
On Wed, 14 Mar 2018 10:03:59 -0700, Joerg <news@analogconsultants.com> wrote:>On 2018-03-14 09:05, John Larkin wrote: >> On Wed, 14 Mar 2018 08:00:27 -0700, Joerg <news@analogconsultants.com> >> wrote: >> >>> On 2018-03-13 17:16, krw@notreal.com wrote: >>>> On Tue, 13 Mar 2018 16:03:57 -0700, Joerg <news@analogconsultants.com> >>>> wrote: >>>> >>>>> On 2018-03-13 15:11, Lasse Langwadt Christensen wrote: >>>>>> Den tirsdag den 13. marts 2018 kl. 22.38.37 UTC+1 skrev Joerg: >>>>>>> On 2018-03-13 08:43, John Larkin wrote: >>>>>>>> On Mon, 12 Mar 2018 17:43:07 -0700 (PDT), whit3rd <whit3rd@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Sunday, March 11, 2018 at 1:59:26 PM UTC-7, John Larkin wrote: >>>>>>>>> >>>>>>>>>> The original justification was that decimal points were somehow >>>>>>>>>> fragile and got lost on drawings, so the wrong parts values got >>>>>>>>>> installed. It was nonsense of course. >>>>>>>>> >>>>>>>>> Too young to recall thermal fax machines? >>>>>>>>> Lines that crossed got rather fat at the intersection, >>>>>>>>> and the images faded over time. >>>>>>>> >>>>>>>> I started with hand-drawn schematics on vellum, and blueprint >>>>>>>> machines. And I still use both. And I never lose or mistake decimal >>>>>>>> points or tie points. Maybe that's because I had two semisters of >>>>>>>> engineering drawing in college. >>>>>>>> >>>>>>>> I don't think that a D-size schematic could be FAXd, then or now. >>>>>>>> >>>>>>>> A lot of current "wisdom" is left over from olden days, and especially >>>>>>>> bad, amateur habits of olden days. We have computers now. Parts lists >>>>>>>> are generated automatically from our schematics, and computers don't >>>>>>>> mistake decimal points for coffee stains. Software gets the net lists >>>>>>>> right even when two wires cross. >>>>>>>> >>>>>>> >>>>>>> I have found bugs in netlists. Mostly where wires looked like they >>>>>>> connected to a component but didn't. I check every schematic on all my >>>>>>> designs against the netlist by hand. Doing one right now. It's tedious >>>>>>> grunt work but better safe that sorry. >>>>>> >>>>>> missing connections to a component should be caught by ERC >>>>>> >>>>> >>>>> Not if, for example, the pin is declared as output in the symbol because >>>>> leaving outputs unconnected is perfectly ok. Same for I/O or passive. >>>> >>>> These pins should (have to) be marked as not connected. >>>> >>> >>> The x's like Lasse showed aren't very customary anymore these days. Some >>> CAD systems could even choke on those if you placed some. >> >> There is a strong tendency among tekkies to automate things that they >> should just do themselves. Why do the grunt work of checking your >> design or code when you can buy some fancy tools/toys to do it for >> you? >> > >Until some day it doesn't. Or does it except for a few spots. > > >> Problem is, the fancy tools can't understand your parts, requirements, >> or intent. >> >> Some tools, like PCB clearance and connectivity checks are great and >> don't (much) encourage bad habits. Some tools switch off thinking. >> >> But you *can* blame the tools/toys when the board doesn't work. >> > >It's like with cars, for example anti-lock brakes. People think they can >now just stomp on it and it'll be alright. Until that not so sunny day >when the road is slick and the fancy system prevents their car from >stopping.I'm thinking about the pin use rules on uPs or FPGAs or, worse, SOCs. In an SOC, some pins can be clocks, or not. There are bank voltages that determine the logic levels and rules of clumps of pins. Some pins have multiple programmable functions, like ADC or GPIO. Some pins have hard-defined functions during configuration but become IOs later; some never become i/o. Some pins are available only to the uP and some only to the fabric. Some pins are single-ended or can be one of a differential pair. Things like logic levels and drive strengths are programmable. How do you explain all that to an automated checker? -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●March 14, 20182018-03-14
On 2018-03-13 19:37, John Larkin wrote:> On Tue, 13 Mar 2018 17:24:54 -0700 (PDT), Lasse Langwadt Christensen > <langwadt@fonz.dk> wrote: > >> Den onsdag den 14. marts 2018 kl. 01.17.03 UTC+1 skrev John Larkin: >>> On Tue, 13 Mar 2018 20:15:03 -0400, krw@notreal.com wrote: >>> >>>> On Tue, 13 Mar 2018 15:33:12 -0700, John Larkin >>>> <jjlarkin@highland_snip_technology.com> wrote: >>>> >>>>> On Tue, 13 Mar 2018 15:11:04 -0700 (PDT), Lasse Langwadt Christensen >>>>> <langwadt@fonz.dk> wrote: >>>>> >>>>>> Den tirsdag den 13. marts 2018 kl. 22.38.37 UTC+1 skrev Joerg: >>>>>>> On 2018-03-13 08:43, John Larkin wrote: >>>>>>>> On Mon, 12 Mar 2018 17:43:07 -0700 (PDT), whit3rd <whit3rd@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Sunday, March 11, 2018 at 1:59:26 PM UTC-7, John Larkin wrote: >>>>>>>>> >>>>>>>>>> The original justification was that decimal points were somehow >>>>>>>>>> fragile and got lost on drawings, so the wrong parts values got >>>>>>>>>> installed. It was nonsense of course. >>>>>>>>> >>>>>>>>> Too young to recall thermal fax machines? >>>>>>>>> Lines that crossed got rather fat at the intersection, >>>>>>>>> and the images faded over time. >>>>>>>> >>>>>>>> I started with hand-drawn schematics on vellum, and blueprint >>>>>>>> machines. And I still use both. And I never lose or mistake decimal >>>>>>>> points or tie points. Maybe that's because I had two semisters of >>>>>>>> engineering drawing in college. >>>>>>>> >>>>>>>> I don't think that a D-size schematic could be FAXd, then or now. >>>>>>>> >>>>>>>> A lot of current "wisdom" is left over from olden days, and especially >>>>>>>> bad, amateur habits of olden days. We have computers now. Parts lists >>>>>>>> are generated automatically from our schematics, and computers don't >>>>>>>> mistake decimal points for coffee stains. Software gets the net lists >>>>>>>> right even when two wires cross. >>>>>>>> >>>>>>> >>>>>>> I have found bugs in netlists. Mostly where wires looked like they >>>>>>> connected to a component but didn't. I check every schematic on all my >>>>>>> designs against the netlist by hand. Doing one right now. It's tedious >>>>>>> grunt work but better safe that sorry. >>>>>> >>>>>> missing connections to a component should be caught by ERC >>>>> >>>>> How does that work? >>>> >>>> Nothing connected to the pin, maybe? >>> >>> I meant, what is ERC? >>> >> >> electric rule check >> > > OK, one more level of indirection: > > what is that? >It checks for potential show-stoppers by flagging unconnected inputs, two outputs tied together, an output connected to the rail, rails shorted to each other, missing junction dots, and so on. Some of that may be deliberate and ok in which case a good CAD system should offer an "allow" check box for each flagged observation. In Eagle that remains stored so if I continue work on a schematic it won't flag the same observations again after I clicked "allow". Some ERC functions are a bit nonsensical. For example, I get a lot of false positives like "VCC connected to V+" or "+5V connected to V+" because a component symbol happened to call the pin V+ and not VCC or +5V. So I have to click all those off on the ERC list. It's ok, I'd rather it errs on the cautious side than discovering an "Oh dang!" after the boards come back. Same with the design rule checks on layouts. I remember a guy who didn't run it and then had umpteen via shorts to the ground plane. All those had to be drilled out and lots of air wires were needed. -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●March 14, 20182018-03-14
"Gerhard Hoffmann" wrote in message news:fgqunhFg0bcU1@mid.individual.net... Am 13.03.2018 um 22:20 schrieb Joerg:>> It's worse. LTSpice cannot distinguish between milli and mega if you use >> m and M. It'll always see that as milli. You have to write MEG or e6, >> else it'll go wrong.>That is the correct behavior.Not at all.> Changing that would break old decks >that used to work for 40 years.Like, who cares a f*uk? -- Kevin Aylward http://www.anasoft.co.uk - SuperSpice http://www.kevinaylward.co.uk/ee/index.html
Reply by ●March 14, 20182018-03-14
"Joerg" wrote in message news:fgqtkqFfk28U2@mid.individual.net...> >> Yes, I know. The 1u notation can be troublesome if LTspice is configured >> to >> convert it to the symbol. If you try to send it via SED, the client may >> convert it to an unknown symbol. This wrecks the file so it cannot be >> read >> until the symbol is converted back. Using 1e-6 solves the problem. > >> There are other cases in LTspice where it makes more sense to use >> exponential >> notation to avoid confusion rather than scientific notation. >>It's worse. LTSpice cannot distinguish between milli and mega if you use m >and M. It'll always see that as milli. You have to write MEG or e6, else >it'll go wrong.And of Of course...SS don't have that problem. I pre-process all M, Meg, m, 4k7 to what Spice expects. This includes all string numbers for subckt parameters. -- Kevin Aylward http://www.anasoft.co.uk - SuperSpice http://www.kevinaylward.co.uk/ee/index.html
Reply by ●March 14, 20182018-03-14
On 2018-03-14 10:39, John Larkin wrote:> On Wed, 14 Mar 2018 10:03:59 -0700, Joerg <news@analogconsultants.com> > wrote: > >> On 2018-03-14 09:05, John Larkin wrote:[...]>>> Problem is, the fancy tools can't understand your parts, requirements, >>> or intent. >>> >>> Some tools, like PCB clearance and connectivity checks are great and >>> don't (much) encourage bad habits. Some tools switch off thinking. >>> >>> But you *can* blame the tools/toys when the board doesn't work. >>> >> >> It's like with cars, for example anti-lock brakes. People think they can >> now just stomp on it and it'll be alright. Until that not so sunny day >> when the road is slick and the fancy system prevents their car from >> stopping. > > I'm thinking about the pin use rules on uPs or FPGAs or, worse, SOCs. > > In an SOC, some pins can be clocks, or not. There are bank voltages > that determine the logic levels and rules of clumps of pins. Some pins > have multiple programmable functions, like ADC or GPIO. Some pins have > hard-defined functions during configuration but become IOs later; some > never become i/o. Some pins are available only to the uP and some only > to the fabric. Some pins are single-ended or can be one of a > differential pair. Things like logic levels and drive strengths are > programmable. > > How do you explain all that to an automated checker? >Sometimes I just declare them PAS for passive and nothing gets flagged there. The CAD can't know about the port declarations in a uC or FPGA. IOW you have to be able to switch it off in some way. On a decent CAD system you can, in a car you mostly can't and there you are at the mercy of whatever the design engineers have decided. -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●March 14, 20182018-03-14
On 2018-03-14 09:53, krw@notreal.com wrote:> On Tue, 13 Mar 2018 19:44:19 -0700, John Larkin > <jjlarkin@highlandtechnology.com> wrote: > >> On Tue, 13 Mar 2018 16:14:52 -0700, Joerg <news@analogconsultants.com> >> wrote: >> >>> On 2018-03-13 15:31, John Larkin wrote: >>>> On Tue, 13 Mar 2018 14:38:35 -0700, Joerg <news@analogconsultants.com> >>>> wrote: >>>> >>>>> On 2018-03-13 08:43, John Larkin wrote: >>>>>> On Mon, 12 Mar 2018 17:43:07 -0700 (PDT), whit3rd <whit3rd@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> On Sunday, March 11, 2018 at 1:59:26 PM UTC-7, John Larkin wrote: >>>>>>> >>>>>>>> The original justification was that decimal points were somehow >>>>>>>> fragile and got lost on drawings, so the wrong parts values got >>>>>>>> installed. It was nonsense of course. >>>>>>> >>>>>>> Too young to recall thermal fax machines? >>>>>>> Lines that crossed got rather fat at the intersection, >>>>>>> and the images faded over time. >>>>>> >>>>>> I started with hand-drawn schematics on vellum, and blueprint >>>>>> machines. And I still use both. And I never lose or mistake decimal >>>>>> points or tie points. Maybe that's because I had two semisters of >>>>>> engineering drawing in college. >>>>>> >>>>>> I don't think that a D-size schematic could be FAXd, then or now. >>>>>> >>>>>> A lot of current "wisdom" is left over from olden days, and especially >>>>>> bad, amateur habits of olden days. We have computers now. Parts lists >>>>>> are generated automatically from our schematics, and computers don't >>>>>> mistake decimal points for coffee stains. Software gets the net lists >>>>>> right even when two wires cross. >>>>>> >>>>> >>>>> I have found bugs in netlists. Mostly where wires looked like they >>>>> connected to a component but didn't. I check every schematic on all my >>>>> designs against the netlist by hand. Doing one right now. It's tedious >>>>> grunt work but better safe that sorry. >>>> >>>> Some bad schematic software, like OrCad, allowed one to miss a >>>> connection by a single pixel, and get an open circuit. LT Spice can do >>>> things like that. PADS does not allow a wire to terminate into free >>>> space; every wire end must terminate connected to a part pin, or a big >>>> fat dot to another wire. It's impossible to create an open end or a >>>> free-floating wire segment. >>>> >>> >>> That's how it should be. Even Eagle misses that at times so the drill is >>> to move all the parts at the end and see if everything rubber-bands >>> along. Other than that it is fairly good though I won't make the >>> transition to the new owner's "license tax model". >>> >>> >>>> I don't manually check PCB netlists for connectivity; it's never >>>> wrong. I do sometimes read a netlist to make sure I haven't mis-named >>>> nets, like CLOCK12 on one sheet and CLK12 on another. >>>> >>> >>> That's another error that can happen. Then there is the run of a wire >>> into the wrong net and it got overlooked because the schematic is very >>> busy. When tracing off the netlist in the schematic it's "Hey, wait a >>> minute, why does this connect to the 7th line and not the 8th?". >> >> I don't like busses. One of my guys once named a bus ADDR[15:0] on one >> sheet and ADDR[0:15] on another. So we had to write a program to >> shuffle the programming file for an EPROM. > > ...and you didn't check that in your design review? Tsk. Tsk. >Stuff happens. What is surprising though is that the ERC in the CAD didn't alert. Assuming that one of the notations was a mistake and happened only on one sheet that bus would have to be flagged as orphaned. -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●March 14, 20182018-03-14
On 2018-03-14 11:00, Kevin Aylward wrote:> "Joerg" wrote in message news:fgqtkqFfk28U2@mid.individual.net... > >> >>> Yes, I know. The 1u notation can be troublesome if LTspice is >>> configured to >>> convert it to the symbol. If you try to send it via SED, the client may >>> convert it to an unknown symbol. This wrecks the file so it cannot be >>> read >>> until the symbol is converted back. Using 1e-6 solves the problem. >> >>> There are other cases in LTspice where it makes more sense to use >>> exponential >>> notation to avoid confusion rather than scientific notation. >> > >> It's worse. LTSpice cannot distinguish between milli and mega if you >> use m and M. It'll always see that as milli. You have to write MEG or >> e6, else it'll go wrong. > > > And of Of course...SS don't have that problem. I pre-process all M, Meg, > m, 4k7 to what Spice expects. > > This includes all string numbers for subckt parameters. >That's the smart way of doing it, where the schematic entry is a separate layer and acts as a "scrubber" between operator and netlist. -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●March 14, 20182018-03-14
On Wed, 14 Mar 2018 13:03:30 -0400, krw@notreal.com wrote:>On Wed, 14 Mar 2018 07:51:56 -0700, Joerg <news@analogconsultants.com> >wrote: > >>On 2018-03-13 19:44, John Larkin wrote: >>> On Tue, 13 Mar 2018 16:14:52 -0700, Joerg <news@analogconsultants.com> >>> wrote: >>> >>>> On 2018-03-13 15:31, John Larkin wrote: >> >>[...] >> >>>>> I don't manually check PCB netlists for connectivity; it's never >>>>> wrong. I do sometimes read a netlist to make sure I haven't mis-named >>>>> nets, like CLOCK12 on one sheet and CLK12 on another. >>>>> >>>> >>>> That's another error that can happen. Then there is the run of a wire >>>> into the wrong net and it got overlooked because the schematic is very >>>> busy. When tracing off the netlist in the schematic it's "Hey, wait a >>>> minute, why does this connect to the 7th line and not the 8th?". >>> >>> I don't like busses. One of my guys once named a bus ADDR[15:0] on one >>> sheet and ADDR[0:15] on another. So we had to write a program to >>> shuffle the programming file for an EPROM. >>> >> >>Can be worse. Designing an ultrasound machine a 32-bit analog bus >>between boards became mangled that way. So a cable had to be made that >>had sort of a Moebius loop in it. Since this was all coaxes it was quite >>stiff, meaning shield and bezel could not be locked in place anymore. > >That's the _one_ thing I like about our schematic entry system. Busses >are really just a collection of wires. The individual strands in the >bundle can be named anything. They make the schematics more readable >but there is no implied order (though that should never be a problem - >you should know big-endian from little-endian). So, I'll have an I2C >bus, for instance, named "UC_DACS_I2C" (UC owns the bus, it used for >the DACs, and its type is I2C). The strands of the bundle might be >named "UC_DACS_SDA", "UC_DACS_SCL", "UC_DACS_DAC0IRQ", and >"UC_DACS_DAC1IRQ".We just assign a net name to every offpage. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
