This must be very recognizable by a lot of us folks: Yet another CAD company trying to sell us 'tools' that create schematic symbols from an FPGA pin list. You get these 'square blobs' full of 'pins' having absolutely no relation to the schematics that you currently are creating.
No thank you, not my cup of tea. To my opinion: Schematics are artwork and are as important as the PCB design itself: FPGA's should be represented in banks, just as they are internally organized.
For example, this I find an absolute shame: CAD companies selling their toolchains with schematic entry tools that really are from the '80's. Horrible. I used PCAD until a couple of years ago. I used it until they were invaded by the Chinese. Now -fully into Chinese hands- they force you to go to work 'in the cloud'. Well, I followed StarTrek for years and I know how unpredictable 'clouds' can be, so thank you, I miss another cup of tea.
[COMPUTING IN THE CLOUD IS NOT A WISE IDEA] (c) Rob Gongrijp, a former Dutch hacker
Then, Cadence... what ??? !!! Orcad schematics? From the 80's indeed. They should be ashamed of themselves. You cannot even recognize LVDS pairs besides to couple them inside a 'spread sheet'. Helpful indeed, those spreadsheets, but the schematics *should* tell you the full story as a lot of people here already mentioned. And you have to know that they *have* proper schematic entry tools. Even PCAD is more modern looking than Orcad. People tend to make these 'label schematics', unreadable, I hate those.
I have the feeling that 2D CAD just is a big money maker and they don't care a ^#$%@^ of our struggle to get something properly on paper. Beeing in the industry for more than 25 years this is one of my frustration points. So, thanks for bringing this up.
At one place I used to work all logic gates were drawn as boxes. No sense of the logic function, the only intent of the schematic was to create a netlist to create a PCB. The idea was that no competitor could use the schematic to figure out the logic. Nor could anyone else within that company.
That, of course, is what happens when the lawyers are let out of their cages.
betajet, I disagree. Clear documentation makes it that much easier to handoff to another engineer. I personally ttry to make my documentation clear, especially firmware by adding tons of comments on the intent of the code. However, I have seen folks manage to stay in a job way longer than management desired, by purposefully writting obscure code. Schematics aren't so difficult to clean up, no matter how bad the original authors intentions were.
My first engineering job had a requirement, from the military customer I beleive, that schematics not have dots. If lines cross, they do not connect nets. If a connection is desired, the vertical line must be offset and split into two Ts. They said the dots would get lost in mutliple photocopies. It made sense to me and I have adopted it for use over the last 30 years. I don't why, but when I see a schematic with little hoops where nets cross and don't connect, it makes me think of hobbyist versus professional.
"The worst as you say are MCU diagrams where the tendency seems to be to put ICs in isolation with a funny shaped box on each pin with a cryptic signal name in each. Somewhere on the rest of the diagram is another box, going into another IC, with the same signal name"
One of the things I like about Altium Designer is the 'Harness' device. Similar to a bus, but allows a free-form mix of signals, including busses and other harnesses, to bu grouped together as a single line.
These days my typical circuit has a top level with a bunch of subsheets connected by harnesses with suitable names. The CPU subsheet has harnesses with the IO conditioning subsheets, keypad subsheet, display subsheet, etc.
Of course the CPU sheet itself still has many labelled wire stubs, but at least I can collect many nets directly into harmesses, and can often position the others so the connections are not too hard to find. I thought to add some screen-shots, but anything useful is a bit big.
@JohnMMoore, I've heard it said that poor documentaion, especially code with little or no comments, is done for job protection. The designer wants to be the only person in the company who knows how the thing works. It's all about unique knowledge.
A Book For All Reasons Bernard Cole3 comments Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...