| ??? 08/21/10 14:32 Read: times |
#178176 - It's just not worth the bother ... Responding to: ???'s previous message |
Andy Peters said:
Richard Erlacher said:
My issue with the first portion of the work, aside from the utterly terrible library management, is that you must provide a specific component outline (footprint) for each symbol in your schematic, which, first of all, means that if you have to adapt your footprint to the specifics of a particular board house, you then have to alter all of the parts in your repertoire that use that package outline, else you'll never again know which ones are "correct" and which are not. Moreover, it's poorly suited to team usage, since, generally speaking, the circuit designer doesn't care about the component outline as much as the guy handling the mechanical (including airflow) factors and the guy actually doing the board layout.
Unfortunately, a new library member has to be produced, including a new footprint, for each schematic in which the package is changed. A "real" software package would allow one to refer to a global package outline library so that the package outline would only have to be entered once, and corrected only once, rather than 1500 times because you now buy the TQFP rather than the PLCC. My own experience with bEAGLE required me to change dozens of components in TQFP and PQFP packages because someone entered the package outline incorrectly, leaving far too much pad under the component, where it couldn't be inspected properly, therefore requiring that each and every component in TQFP208 (consider how many pads have to be changed ... manually ...in order to effect that change) in a series of boards with a dozen of them on it. I guess I gave up on EAGLE because its schematic capture sucks and its layout isn't much better, and you're right, its library manager is stupid, but I'm not sure what your complaint is. Is it: a) the fact that the schematic symbol and footprint libraries are completely unrelated, so every time you place a symbol on a schematic, you must also choose the PCB footprint, or b) the schematic symbol DOES have embedded footprint information, so when you place a symbol on the schematic it also embeds footprint information in the layout netlist? My problem with this bEAGLE stuff is that the footprint has to be created along with every new schematic symbol and embedded with it. Since the library management is so stupidly done, I have to create a new symbol for nearly every part newer than 1990 and many that are older than that, and, as you know, programmable parts can have lots of pins ... <sigh> ... Now, if I have the same package, I still have to attach it to the schematic symbol. Since my programmables are treated as a specific device, with signal names relevant to the application, it's often in a package that I've already ensured is suitable, but ... since it has different signals on different pins, a new symbol is needed, and, therefore, a new footprint is needed as well. Sometimes I can cut and paste, but that, IIRC, doesn't always work. Now, understand that I normally don't involve myself in PCB production, and the guy who chooses the part based on price might be 5k miles away, and the guy doing the layout may be, as well. I like the approach that OrCAD uses, i.e. assigning the package when the device symbol is entered. Yes, you can make an error, but it's no different saying it's a 208PQFP20 on the schematic than saying it's an XC2S200PQFP when the schematic symbol is instantiated. If you call up the TQFP144, it's wrong. The procurement guy certainly doesn't like using differently packaged versions of the same part, but the layout guy certainly doesn't like using the 208PQFP where the 144TQFP would fit better. I prefer to let them work that out. The problem for me is that the layout editor demands that I modify the schematic symbol file for every identical programmable device just because I want to have the nets named so some human can understand who's who and what's what. The reason, of course, is that, sometimes, I'm that human. a) above sucks and leads to all kinds of errors. I'm not sure I agree ... There's only one footprint on which a particular CPLD package fits, so having that footprint correctly specified once, and linked to the schematic symbol through a database makes sense to me, as opposed to me having to redraw the %$#@! thing each time I use it. IIRC, bEAGLE likes to have signal names rather than pin numbers associated with the routes, so a new footprint has to be created for each and every application of XC2C256 in TQFP144, no matter what. Moreover, if the layout guy likes the TSOP-II, or the purchasing guy likes the price of the TSOP, I could be required to change my schematic symbol for their convenience, possibly when I'm no longer engaged in the work. b) is the right way to go.
From where I sit, the circuit designer chooses the device, but it's up to the purchasing, mechanical, and layout guys to choose the package. It works fine if I'm wearing all of these hats, but if someone is waiting for a schematic and I first have to create the package outlines for components I can't find in the libraries, I find it burdensome, since I, as the circuit designer, don't care about the package or, generally, about the pinout of a CPLD where it's just a back-annotation matter. I do care about the two-hour search for the component and the hour it takes to create a new "component" despite the fact there are already ten versions of the same device in the libraries. Sadly, it's seldom possible to use copy-and-paste because the schematic needs the signal names to match the device signal assignments. From where I sit (with the layout guy ten steps away), the choice of package is mine, but it IS based on input from purchasing (as in, "can we actually buy them in SOT-23?") and of course it's driven by layout requirements ("gotta use MSOP8, SOIC8 won't fit"). So, yes, this means that we have library symbols for AD8138-SOIC and AD8138-MSOP (or something similar) because we were using the SOIC version until we had to do itty bitty boards. We use Altium Designer, which has the concept of an "Integrated Library" which combines schematic symbols (there can be multiple symbol libraries) and PCB footprints (there can be multiple footprint libraries, too) all into one library. Our symbols call out a company part number, too, so in that sense having everything all in one library with all footprint and BOM information built into the schematic symbol makes EVERYTHING easier. Now note that I said that AD allows multiple symbol libraries and multiple footprint libraries. Again the libraries are compiled into one integrated library which everyone uses (it's maintained by the layout guy). So if we need to add a new op-amp to our library, he copies an op-amp symbol (in our analog-part symbol library, I think), renames it to the new part name, and then changes the footprint field and the company part-number field to the right values. If a new footprint is required, it's built in the footprint library, but most parts use the standard footprints so that part is already done. Then the library is recompiled and put in the standard location for everyone's use. NB that it took longer to describe how to create a new op-amp symbol than it takes to actually do the work. As for the CPLD (or FPGA) pinout, I absolutely DO care about this, as it's more than a simple back-annotation issue. You must make sure that your clocks are on the special clock input pins. With FPGAs that have multiple banks with different rails, you have to make sure that all of the 3.3V outputs are on a bank with a 3.3V rail, and all of the 2.5V outputs are on a 2.5V rail. And you have to make sure that LVDS outputs are NOT on pins called "LC" because they don't have LVDS outputs. And so on. I give the layout guy a list of layout rules for each design, indicating which signals can go in which banks, which cannot be swapped at all, and so forth. And before the board is released for fab, the FPGA tools are run on it to ensure that the chosen pins actually work. -a This last bit is something for which no provision was made in bEAGLE, or, for that matte rin most other schematic/layout software, but which is a simple housekeeping matter. Yes, it's drudgery, and yes, it's error prone, but it's part of the job. Then, too, it's often beneficial to tie unused pins to GND, and to space the signal pins around GND, just for signal quality. The extra GND connections don't hurt anything, and can help balance currents within the FPGA. I obtained and attempted to use the full-up bEAGLE, and, while I found the 2-layer "freebie" version adequate and worth its price, I didn't feel the same way about the "whole magilla". That schematic entry portion is slow to operate and awkward, clearly having been written by people who were interested in the problem of autorouting, but not experienced in drawing and interpreting schematics, as is evidenced by the way in which they handle creation and management of their libraries. I've concluded that bEAGLE is suitable for the one-man-shop operation wherein the package choice is made by the one man wearing the layout hat, and accommodated by the one man wearing circuit designer hat only because he knows no one else will do it. I find it a terrible nuissance, however, and, since the auto-router output requires considerable post-processing, I don't find that particularly desirable either. I freely admit that bEAGLE is adequate for those small two-layer boards that the "free" version handles, if one tolerates the bungled library handling, poor schematic editing features, and utterly awful-looking schematics it produces, AND if one is using only metric- or only imperial-dimensioned components. That's seldom the case, nowadays, and I believe that the impression made by the freebie version under those conditions is what sells their product. If only the full-up auto-router were worth the hassle ... RE |
