krw said:
That's a good idea, but management rarely thinks such things are worth
the effort, particularly on small projects (OTOH, when >200 engineers
are involved in one design things change fast). It would be nice to
be able to tie them together.
I prepare the documents mostly for myself. I may have to revisit
a design years later. I don't want to have to waste the time
*then* trying to figure out what I did previously. Clients
frown on you billing them for "time to remember what I did" :>
If that's the case a block diagram doesn't work cleanly either.
Hierarchical design has so many other benefits. Apparently board
designers don't see the importance because the CAD companies have
blown it so badly.
The problem is, you (I) want a block diagram that gives
folks a general feel for what is where in the design.
But, hierarchical tools have to account for *everything*.
So, if you have tucked a voltage regulator on a sheet in
"Block A" that is also used in "Block C", the block diagram
wants to show that signal connecting the too. Even though it
isn't significant enough to elevate to the level of
prominence that you would typically embody in a block diagram.
I.e., block diagrams should deliberately hide details.
Yet, this "niggling detail" gains a place of prominence
on a par with major signal flow, etc.
That's easy. My main (VHDL) module is ProjectName_Top.vhd.
Testbenches (the highest level in a hierarchy, actually) are *_TB, so
the top level testbench would be ProjectName_TB.vhd.
Different scale entirely. Imagine hundreds (thousands?) of
files of code. Probably hundreds of lines of code in each.
With descriptive names on the files -- at least in terms of the
guys who named them! :>
CPU comes out of reset. Which file documents the first instruction
that it will execute? (assuming I can figure out which *other*
files it will eventually wander into or through)
Binders keep all the pages together. ;-) I keep the entire project
in one binder. I can look at any component quickly. Well, as long as
someone hasn't borrowed my binder (happens constantly).
I try to work off the screen as much as possible. Printed copies
while I am creating the schematic. And, as part of the deliverables.
Most of my time spent with a design is consulting it while writing
software (to make it do its thing). My designs themselves tend to
work "out of the box" (unless a defective part gets stuffed, etc.)
so I don't need to spend much time fretting over the hardware
itself.
I just don't have much desktop space free for paper, binders, etc.
Too much equipment in too little space :> And I'd rather have
the equipment than space for paper! ;-)
Just highlight the bus breakout. I have no interest in seeing 64 (or
double or triple that) off-page connectors or the wires crossing every
page. This makes me ill just thinking about it.
Using small pages limits the number of signals that can be on a page.
E.g., I just drew a page with an SoC which, by its very nature,
has *lots* of things that will want to head off to other pages
(peripherals, etc.). So, there are ~80 signals that leave the
page bound for "parts unknown" :>
Seldom does an individual wire of a bus go to a unique place.
Quite common for SoC designs! E.g., this chip has 6 or 8
ports on it. Should I bundle each 8 bit port into a little
"bus"? In which case, I doubt all 8 signals in *any* of
those busses will end up on the same *page* -- let alone
the same *chip*!
[I vacillate between preferring B or C size drawings. C is nice
in that it reduces to A nicely (i.e., with the same aspect ratio)
OTOH, B is nice because reducing to A leaves room along the
binding edge -- which must be located "above" the drawing! -- for
three hole punch *or* more professional binding. And, B size
can always be reproduced full size with "fold outs". (frown) B
size (reduced or otherwise) is currently en vogue -- perhaps a
consequence of my aging eyes? :> ]
Get glasses. ;-) Bifocal reading glasses (two strengths, both for
close work) work for me.
I have several pair around the house but rarely need them
for paperwork -- if I avoid C reduced to A, that is! :>
Just wait. ;-)
Too late. :>
I don't like one component per sheet. I see a lot of that in vendor's
examples. I can't see what's going on at all. I'd do better with a
netlist.
The only time I end up with a single component per sheet is
for things like SoC's. It's just too hard to get devices
with 100+ pins to *fit* on a small (B) size sheet with much of
anything else (besides a handful of discretes)
Exactly. Bundling signals that are naturally bundled makes schematics
*easier* to read. That's the whole point.
Cramming more onto a single page doesn't make things any easier
for me to read.
Ick. One component per page is *ugly*. It doesn't give any
information about how things work.
Who said *one* ROM or *one* RAM? Note they each have s's on
them!
I don't believe in dumbing anything down to the least common
denominator. Color is a useful tool. Use it. This is like saying
that a painter should only use black and white. Nonsense!
Do your drawings *always* get rendered in color? Are they
*published* in color? I.e., if they are ever going to be
rendered in black and white, then any information conveyed
by color is going to disappear.
There are industries in which I work where this is actually
part of their "best practices". Because they acknowledge
that there is a huge portion of the population that has
some sort of color impairment in the vision. Likewise,
restrictions on what frequencies to use in audible
annunciators (e.g., if the "Evacuate the building" signal
is at 20KHz, you're pretty sure most of the elderly employees
aren't going to make it out! :> )
I can either adopt two different standards for work done
in those industries vs. work done elsewhere; or, adopt
a standard that works well in *both* places. (I've never
had a client ask for a *color* version of a schematic
from me :> )
LOL! Our schematics *were* all boxes. AND gates, OR gates, DFFs were
all the same sized as resistors, transistors, and capacitors. They
had to be printed on chain printers. Rockets and bullets are a major
move up. ;-) Oh, and full schematics were more like several thousand
C-sized pages (a rack about 2'Wx5'Hx6'L. ;-)
Yes, I've worked out of "books" of such schematics. I
wonder if anyone has ever *studied* the practice to be
able to quantify how *unproductive* it is?
It does. As long as the clocks and active levels are marked, labels
tell pretty much everything you need. At some complexity there isn't
room on the schematic for details anyway.
This ignores a huge class of components! E.g., I was just looking
at a PoE controller. Drawn by the manufacturer as a "box".
With pins on all four sides AS IF it was the actual chip itself!
(i.e., pins were numbered sequentially around the "box").
Told me absolutely nothing about what was going on in the
circuit. And, I'd wager it would be just as hard for the
chip's *designer* to sort out the behavior in that circuit!
Use the "_n" suffix. This is allowed in every system I know (even
VHDL) and maintains the sort order.
I worked with a system that restricted names to 8 characters.
(or, maybe it was 6?). So, I have to keep my signal names at
6 (or 4?) characters just so I can add "_n" and still fit
in the 8 (6) allowed? :<
NEVER! The signals polarity *must* be noted using some convention.
Not doing so is just asking for disaster.
How is my choice of name *not* indicating polarity?
RUN indicates that the system is RUNning when it is
HIGH. When the STOP signal is high (RUN_n in your parlance),
then the system is STOPped.
External connectors are usually chosen before the design starts. It's
part of the project description. Internal connectors should look
sorta like what they represent to aid in debugging.
I do a design. Later, someone decides how to make it real.
<frown> "leftist targeting the lowest common denominator"
I don't see anything "leftist" about it! Rather, I don't want
people screwing up my work.
I had a technician prototype a design of mine some 30 years
ago (when we still used to wirewrap things). I pulled the
wirewrap sockets from stock and set them on his desk in a bag.
Sockets were color coded (Augat, IIRC): red and green for
14 and 16 pin devices (I can't recall the colors for the
other sizes).
I came back an hour later to see how he was doing and found
him patiently *unwrapping* his work. I assumed he had just
made a mistake on *that* wrap and kidded him about it:
"Wrong pin?" He replied "Wrong socket." I assumed he
meant he had wrapped pin X on socket Y and it should have
been pin X on socket Z. No. He couldn't differentiate
red from green and had used the WRONG SOCKET for that device.
I've similarly found problems where technicians got wire
colors wrong in harnesses. This can be really annoying if
you're talking about *big* harnesses!
Yeah, with more of a description than that. What fields of the
address bus are being decoded and for what purpose?
That's part of the signal name. ROM_Enable, RAM_Enable, ADC_Enable,
etc.