??? 04/17/06 23:16 Read: times |
#114420 - I've just got to disagree Responding to: ???'s previous message |
I've recently been evaluating the new schematic capture module in the XILINX programmable logic package, which, sadly, I'm forced to use nearly every day.
With release 8, and over the past three months there have been three patch sets (service packs), there are a number of giant steps backward that have been taken, some in the look-and-feel, which then divorces us users from what we've learned to tolerate, and some in the functionality, which may eventually be fixed. This, of course, brings to mind all the struggles with Protel, PCAD, EAGLE, OrCAD Capture, and a bunch more that I can't remember at this moment. With the libraries, the problem is that it's too common that the schematic symbols are bound to a package type. This is a particular problem with EAGLE, which, in the free (limited to 2 layers) isn't a bad PCB router/editor, but which has a terrible system design obviously intended to be used by a single designer and not a team. There's no way to split apart the design of PCB footprints from the design of schematic symbols, since they're bound together at their inception. That means an entire new component has to be built for every version of a part. Now, that's not a BIG issue for me, but it's a Pain In The *ss (PITA) because the guy who handles PCB layout doesn't have to be a circuit designer, given proper instructions, and the circuit designer doesn't have to concern himself with whether a part is in TSSOP or DIP package. He just wants the signals to be handled properly, and the PCB guy is generally quite happy to do that, provided he's told what "properly" means. That in turn, means that for each of 100 similar RJ45's, with a different part number, there has to be a new component symbol. Look at BEagle's library set and you'll see what I mean. I once had a job with a small company that was pinching pennies, and they said, "look at this!" referring to the Eagle free software package and its routing capabilities for small circuits. I told 'em, "yep, it's cute, but we'll need more than two layers." They bought the 4-layer package. <sigh> Then I told 'em well, we'll need three ground plane layers, and four layers for supplies, plus four for signals. They bought the "full-up" package, which handles 16 layers, I guess, but still has that ultra-lame schematic front-end. The thing takes days to route a circuit that other packages do in minutes, and it does it so badly, it would take at least a week to hand-edit its output into reasonably useable form. Unfortunately, the guy who did the routing (I had to build all the symbols and footprints, which I didn't like) thought he was done after it was 100% routed. It leaves wide spaces between tracks, yet leaves traces witihin a tenth of a millimeter of a via if you let it. It can't resolve both metric and imperial pin spacing, so you have to "fix" everything by hand. The whole thing stank! I have a 15 year-old DOS OrCAD package that is smart enough not to put routes too close to vias, and that autoroutes at about 20x the speed of Eagle. It's also limited to 16 layers, but I've not found that to be a problem. Yes, some Windows software vendors have figured out that "mode" editors are not very handy. Now they allow keyboard macros and other devices that enable you to skip hunting for the one of 50 icons in the toolbar that you need, but, once you're there, you still have to deal with the next 11 levels of menus and mouse-clicks before it finally places that component, or junction dot, or whatever, and woe unto you if you want to change a line weight on a component outline or something, or maybe use more than one font in a drawing. The vendors have forgotten that the purpose of a schematic is to communicate the designer's meaning to the multitude who have to work with it later, often adding or modifying what can't be implemented because of requirement changes, or supplier buyouts, component end-of-life, etc. I often just draw a schematic to show someone how things work. If I had to do that with Windows, I'd never have time. A few weeks ago, a fellow on this forum asked about decoding memory space in very general terms. He emailed me privately and I've sent him a couple of schematics. If I'd had to use Windows tools, I'd never have managed to find the time. It took about 10 minutes with the old DOS tools to generate a complete schematic of a microprocessor based memory subsystem including the decoding and the timing logic. That's not a big job, but if it had required half an hour, I might not have gotten it done. Yes, this stuff is a sore point with me ... I've struggled with schematic packages for decades, but I've encountered none that even begin to approach the old DOS-based OrCAD stuff. Not even OrCAD's current offering is close. RE |