On Wed, 14 Mar 2018 18:00:23 -0000, "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> wrote:>"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? > >Changing Spice would also break things that worked last week. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.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 2018-03-14 11:33, John Larkin wrote:> On Wed, 14 Mar 2018 18:00:23 -0000, "Kevin Aylward" > <kevinRemovAT@kevinaylward.co.uk> wrote: > >> "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? >> >> > > Changing Spice would also break things that worked last week. >That just happened to me with LTSpice. When it updates it seems to hose off custom symbols. -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●March 14, 20182018-03-14
Am 14.03.2018 um 19:00 schrieb Kevin Aylward:> "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?Those who do regression tests as part of their software qualification process, for example. I worked on the 10 million line operating software of a mixed signal wafer tester system and customers would have been quite upset when it started to make things "better" than the old HP from decades ago. That what has worked before must continue to do so. If not, it belongs into the bug list. I admit that in the case of your hobbyist SuperSpice really no one would care a f*k. And, what defines correct behavior: that's the brownish book from Berkeley. Other than in JT's phantasies there are no non- "Berkeley-related spice variants". The tail is wiggling the dog. Gerhard
Reply by ●March 14, 20182018-03-14
On 2018-03-14 12:15, Gerhard Hoffmann wrote:> Am 14.03.2018 um 19:00 schrieb Kevin Aylward: >> "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? > > > Those who do regression tests as part of their software qualification > process, for example. I worked on the 10 million line operating > software of a mixed signal wafer tester system and customers would > have been quite upset when it started to make things "better" than > the old HP from decades ago. That what has worked before must > continue to do so. If not, it belongs into the bug list. > > I admit that in the case of your hobbyist SuperSpice really no one > would care a f*k. > > And, what defines correct behavior: that's the brownish book > from Berkeley. Other than in JT's phantasies there are no non- > "Berkeley-related spice variants". > The tail is wiggling the dog. >http://www.linear.com/solutions/5739 Quote "Robustness of Newton iteration depends on (1) having all circuit element I-V curves being continuous in value and slope and (2) all nonlinear elements being bypassed with capacitance so that the previous time step solution is a good starting point for the Newton iteration of the current time point. Conditions (1) and (2) are met by any physical circuit, but SPICE programs usually don't get this right because the semiconductive devices in Berkeley SPICE have discontinuities and these implementation errors have spilled over to pay-for SPICE implementations. These discontinuities do not occur in LTspice." -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●March 14, 20182018-03-14
On Wed, 14 Mar 2018 11:35:42 -0700, Joerg <news@analogconsultants.com> wrote:>On 2018-03-14 11:33, John Larkin wrote: >> On Wed, 14 Mar 2018 18:00:23 -0000, "Kevin Aylward" >> <kevinRemovAT@kevinaylward.co.uk> wrote: >> >>> "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? >>> >>> >> >> Changing Spice would also break things that worked last week. >> > >That just happened to me with LTSpice. When it updates it seems to hose >off custom symbols.I haven't noticed that, but the XVII version has its own libraries and everything. It's a completely different thing from IV. -- 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-14 13:10, John Larkin wrote:> On Wed, 14 Mar 2018 11:35:42 -0700, Joerg <news@analogconsultants.com> > wrote: > >> On 2018-03-14 11:33, John Larkin wrote: >>> On Wed, 14 Mar 2018 18:00:23 -0000, "Kevin Aylward" >>> <kevinRemovAT@kevinaylward.co.uk> wrote: >>> >>>> "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? >>>> >>>> >>> >>> Changing Spice would also break things that worked last week. >>> >> >> That just happened to me with LTSpice. When it updates it seems to hose >> off custom symbols. > > I haven't noticed that, but the XVII version has its own libraries and > everything. It's a completely different thing from IV. >I am not going to upgrade anymore for a long time because when something like this breaks it creates a lot of unnecessary work. I can't see any reason why an update has to over-write a complete library file instead of just adding in the new stuff. -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●March 14, 20182018-03-14
"Joerg" <news@analogconsultants.com> wrote in message news:fgt6cgFr5hU1@mid.individual.net...> 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. >Unless it can. Altium toyed with that for a long time, of course nobody used it because their FPGA tools weren't useful compared to the manufacturer's. No idea if there are higher priced tools with tighter integration. Tim -- Seven Transistor Labs, LLC Electrical Engineering Consultation and Contract Design Website: https://www.seventransistorlabs.com/
Reply by ●March 14, 20182018-03-14
On Wed, 14 Mar 2018 11:17:33 -0700, John Larkin <jjlarkin@highland_snip_technology.com> wrote:>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.That gets ugly when you have SDRAM busses.
Reply by ●March 14, 20182018-03-14
On Wed, 14 Mar 2018 11:05:57 -0700, Joerg <news@analogconsultants.com> wrote:>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.I was just tweaking JL because he claims a perfect design review process. Apparently he doesn't use ERC.
Reply by ●March 14, 20182018-03-14
On Wed, 14 Mar 2018 20:21:03 -0400, krw@notreal.com wrote:>On Wed, 14 Mar 2018 11:17:33 -0700, John Larkin ><jjlarkin@highland_snip_technology.com> wrote: > >>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. > >That gets ugly when you have SDRAM busses.How would adding fat black lines improve this? https://www.dropbox.com/s/b9vim9g36p2qt7l/DDR_DRAM.jpg?raw=1 -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
