really weird PADS problem

This is PADS-PowerLogic version 5.0.

I have a clock net SCKB that runs here and there. I decided to add a termination resistor to ground, so I did that, and did a forward ECO file to the PCB. The resistor is added, but the reference designators of two unrelated ICs are swapped in the ECO file too, and this rips out their nice PCB routing.

If I add the resistor, and ground one end, but don't touch SCKB, the ECO is OK.

If I add any new part to the SCKB net, it messes up.

Except that if I run an unused pin from a nearby uP chip to SCKB, the resulting ECO is ok.

THEN I can add the terminator, OK!

Then if I leave the terminator and remove the uP connection, the problem is back!

The other problem we're having with this design is that if we export a schematic netlist, PCB refuses to do a netlist compare. It complains about an end-of-file or something. The schematic output ascii netlist looks OK to us, no weird control characters or anything.

So it looks like the schematic is corrupted somehow. An ascii in-out cycle doesn't help.

PADS is usually stone-cold reliable. This is weird.

Any suggestions?

John

Reply to
John Larkin
Loading thread data ...

The traditional explanation for this kind of lunacy is a "non-printing character". You need a specialised editor to inspect the files to find them - people who write and debug assembler code have such programs. Lesser mortals try localise find the offending data string, then fix it by deleting the offending string and replacing it by typing in the deleted character string as reported by a regular editor.

-- Bill Sloman, Nijmegen

Reply to
Bill Sloman

We thought of that. One of my guys whipped up a C program to search for control characters in the exported netlist, and in fact histogram all characters. Nothing looks unusual.

John

Reply to
John Larkin

Old programs - like PADS - seem to allow specific key-combinations (like control-C and alt-control-delete) to be used an alternative to mouse-button combinations.

Inadvertent key-strokes can havre unexpected consequences. My mother used to make her version Eudora unusable in this way from time to time.

-- Bill Sloman, Nijmegen

Reply to
Bill Sloman

"John Larkin" wrote in message news: snipped-for-privacy@4ax.com...

I've been caught by trailing spaces before, not easy to see. Cutting and pasting Unicode also has interesting implications.

Cheers

Reply to
Martin Riddle

I stayed up until 11:30 last night writing my own PADS netlist comparator program. It can't find any problem in the schematic or the PCB netlists, and they match exactly; or at least after some dreadful parsing and culling and sorting. But the schematic file still does weird things, and PCB refuses to compare netlists.

The thing we suspect is that a new part has lots of square brackets in its pin names, and PADS probably uses square brackets as part of its part syntax, somewhere internally. It may invoke some bus stuff.

John

Reply to
John Larkin

Did you try doing an ascii out and then ascii in to a new database? Works for pcb, don't know if it is available for the schematic.

-- Vic

perl -le "print scalar reverse qq/moc.liamg\100837465bciv/"

Reply to
me at

Yes, both the schematic and the PCB. That usually cleans things up, but didn't in our case. I suspect that a library part, specifically a new ARM processor, upsets PCB when it imports it from the library.

I wrote my own netlist compare program, and the board and the schematic seem to agree, and the schematic and PCB look OK to the naked eye. I added a spurious do-not-stuff resistor to the bad net, and that somehow allowed us to move on, so we Gerbered the sucker.

Weird. PADS is usually very solid.

John

Reply to
John Larkin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.