Maker Pro
Maker Pro

Schematic preferences

K

krw

Jan 1, 1970
0
But I have. On complex chips like the first Garmin GPS chip, I sat
there in Burlington with the IBM test guys correlating test data to
the test plan, and creating a final probe test procedure.

You're still not probing the circuits so don't need all of the
information contained in the schematic. The logic guys haven't even
used schematics for thirty years. Before VHDL they used flow charts.
Rare now-a-days, everything always comes up working ;-)

Even when it works we have to prove it. It's not like chips where we
throw it over the wall to the test guys and forget it (until they come
back with failing patterns our simulation didn't catch ;-).
 
D

D Yuniskis

Jan 1, 1970
0
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.
 
F

Fred Abse

Jan 1, 1970
0
I was trained at Tektronix for drafting electronics, so my
preferences come from there.

Do you do cowboys and tombstones?

;-)
 
F

Fred Bartoli

Jan 1, 1970
0
Fred Abse a écrit :
Do you do cowboys and tombstones?

Don't know for the cowboys, but aren't tombstones a production thing :-?
 
N

Nico Coesel

Jan 1, 1970
0
D Yuniskis said:
Hi Nico,



I think, nowadays, its relatively easy to get 300 dpi. 600 dpi
will quickly replace that. I never need to turn on 1200 dpi to
get a quality drawing -- even on A size paper.

My 15 year old printer already does 600dpi!
Inkjet printers are probably *not* a good idea for schematics
as they tend to have larger dot sizes. IMO, inkjet only makes
sense for really low power and/or "color" (neither of which
seem to be necessary -- IMO -- for producing schematics).

Inkjet is crap indeed. Although the colors have some added value.
 
N

Nico Coesel

Jan 1, 1970
0
krw said:
You rarely have to sit down in the lab, in front of a scope and debug
the design. ;-)

I always print diagrams. First to place the PCB secondly to probe the
prototype. I always draw components like their actual footprint. That
makes it much easier to find the proper pin.
 
T

Tim Williams

Jan 1, 1970
0
Nico Coesel said:
Inkjet is crap indeed. Although the colors have some added value.

My Canon PIXMA iP6000D prints at fair quality. The main problem is regular
paper wicks a little bit, so you get "hairy" pixels. If you want photo
quality, print on photo paper -- does an excellent job.

It also depends how you print. "Normal" quality doesn't look too good (it
prints in color with typical resolution, but it doesn't seem to pay
particular attention), while "high" quality looks okay, at the expense of
going quite slow. It also does duplex printing automatically (it has a page
flip roller), but it takes an extremely long time (it just sits there -- the
driver claims "Drying Paper").

Tim
 
K

krw

Jan 1, 1970
0
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" :>

It still takes time. Management usually has other things to do with
my time. ;-)
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? It's not rocket-surgery. OrCrap comes close but botches the net
names completely. VHDL/Verilog is all hierarchical and it seems to
work pretty well. Even the graphics tools drill into the hierarchy
fine.
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.

Power supplies are globals.
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.

Not buying it.
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! :>

Ever see a processor design? It is *exactly* the same thing.
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)

Which file documents the instruction that gets executed in a VHDL
design? ;-)

Just name the main file ProjectName_Main.c or Project_Start.c. It is
*exactly* the same thing.
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 use both paper and the screen together. Each has its strengths. I
have to support manufacturing, too.
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! ;-)

I just lost about half my desk space. We moved downstairs to bigger
digs so we have more wasted space and less office space. Well, the
other engineer and the lead firmware guy ended up with a huge offices.
I'm not "supposed" to use my office as a lab anymore. :-(
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" :>

Double ick. I'd throw that schematic away without reading. :)
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"?
Yes!

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*!

If they're individual GPIOs leave them separate because they are. If
it's a bus, draw it as a bus, because it is. It's not a difficult
concept to draw things as they're used.
[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)

I don't generally put 100 pins on a device. FPGAs and processors get
homogeneous symbols spread where they make sense. The address/data
bus may end up on the memory page. Power on the decoupling page
(often with more than one large component).
Cramming more onto a single page doesn't make things any easier
for me to read.

It's not necessarily more. It's simpler.
Who said *one* ROM or *one* RAM? Note they each have s's on
them!

I don't think we have a board with more than one RAM or Flash. In
particular, memory should be crammed together with busses. These
sheets rarely have problems that need troubleshooting. When they do
it's easier to have everything on one sheet; the whole bloomin' bus.
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.

They never get "published", but no, I often print segments in B&W. All
the information is still there, just not as obvious without color
queues.
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! :> )

Silly analogy. This stuff is *not* safety critical, nor is any
critical information lost without color.
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 :> )

Our "client" isn't about to get *any* schematics. ;-)
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 was the only way a large system could be managed. Laser printers
soon replaced the chain printers but they were still character based.
Of course everyone else was still hand drafting stuff when we were
auto-routing. As a lifeline to Intel, they got the system (and had
put a usable front end on it so their engineers would use it ;).
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 didn't say one had to be stupid. Some here are advocating that too.
(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!


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? :<

That was certainly dumb. Even 35 years ago we had 32 characters for
signal names, before the hierarchy.
How is my choice of name *not* indicating polarity?

Seven lines up:
"So, I will often label signals ignoring any "negated" convention."
RUN indicates that the system is RUNning when it is
HIGH.

That is a positive active signal, so has no "_n".
When the STOP signal is high (RUN_n in your parlance),
then the system is STOPped.

Again, a positive signal. That's exactly how you match signal name
polarity with component "dot" polarity and DeMorgan correct symbols.
You *are* using proper polarity conventions; they're all positive
active.
I do a design. Later, someone decides how to make it real.

I do it the other way around. I want control over the product, as
much as possible. I'll often move connectors around so they make more
sense and I want my schematics to resemble reality.
I don't see anything "leftist" about it! Rather, I don't want
people screwing up my work.

It *is* targeting the lowest common denominator. Dumbing everything
down because some are dumb, i.e. typical leftist.
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).

Sounds like Augat. Loved their stuff.
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.

He couldn't count either? I was assigned a dumb technician once too.
It was the last time he worked for me.
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!

So they got rid of all color codes? The green wire in your world
isn't ground? Get real.
That's part of the signal name. ROM_Enable, RAM_Enable, ADC_Enable,
etc.

Sure, but I still draw a table with the decode table so it's clear
which address range activates each enable.
 
K

krw

Jan 1, 1970
0
krw said:
How do you define "MH" and it's connections?

It's just a regular part that has one connection on it that -- on the
schematic -- you connect to a ground symbol. All Pulsonix is doing is taking
your part, replicating it six times, and connecting them all in parallel.

Besides mounting holes, the common use for this is bypass caps... for the ones
I want sprinkled around the board, I hook up a capacitor to +3.3V and ground
(or whatever) and name the part C[1:20] -- poof!, 20 bypass caps.

It's a small little feature, but I do prefer C[1:20] to 20 bypass caps all in
a big string taking up mondo page real estate.

Ooooh, I don't like parts that aren't drawn.
 
K

krw

Jan 1, 1970
0
(cough) Um, I knew a number of digital designers back in the '90s who used
Xilinx's schematic capture tools to define their logic. Even in the '00s
people still were, although by then I think there was a sense that you were a
bit of a fossil if you hadn't switched over to VHDL, Verilog, or similar.

In the '70s they used schematics. In the '80s, flow charts (VHDL
wasn't ready for prime time, though some used it), and late '90s and
'00s VHDL. I moved from schematics to VHDL in '98 or '99.
 
K

krw

Jan 1, 1970
0
I always print diagrams. First to place the PCB secondly to probe the
prototype. I always draw components like their actual footprint. That
makes it much easier to find the proper pin.

Ick! You must have small schematics.
 
K

krw

Jan 1, 1970
0
My 15 year old printer already does 600dpi!


Inkjet is crap indeed. Although the colors have some added value.

HP DesignJets are pretty good. Well, ours was until IT "fixed" it.
 
D

D Yuniskis

Jan 1, 1970
0
krw said:
Seven lines up:
"So, I will often label signals ignoring any "negated" convention."


That is a positive active signal, so has no "_n".


Again, a positive signal. That's exactly how you match signal name
polarity with component "dot" polarity and DeMorgan correct symbols.
You *are* using proper polarity conventions; they're all positive
active.

Exactly! Read my original comment:

"E.g., RUN and STOP instead of RUN and RUNN (or NRUN)."

Obviously, this refers to *two* signals. One of those is the
complement of the other (RUN -> RUNn, RUN -> STOP). The point I
was making is that I will *avoid* the "_n" in favor of choosing a
signal name that inherently implies the negation of its counterpart.
YES -> NO. RUN -> STOP. LEFT -> RIGHT.

This avoids the "negation" issue for the most part (i.e., always
name "negative" signals with their antonyms)
He couldn't count either? I was assigned a dumb technician once too.
It was the last time he worked for me.

He assumed the socket he had installed -- since it *looked* the same
(color) as the previous one he had installed -- was the same size
as that previous one.

We aren't all lucky enough to have final say over who gets
hired at the places we work (or, at the clients we work *for*).
 
K

krw

Jan 1, 1970
0
Exactly! Read my original comment:

Again, your original comment was:
"So, I will often label signals ignoring any "negated" convention."
....which is not what you're doing. Negative active signals *MUST*
have a negative notation.
"E.g., RUN and STOP instead of RUN and RUNN (or NRUN)."

Obviously, this refers to *two* signals. One of those is the
complement of the other (RUN -> RUNn, RUN -> STOP). The point I
was making is that I will *avoid* the "_n" in favor of choosing a
signal name that inherently implies the negation of its counterpart.
YES -> NO. RUN -> STOP. LEFT -> RIGHT.

This avoids the "negation" issue for the most part (i.e., always
name "negative" signals with their antonyms)

No it doesn't avoid negation. Parts still have negative inputs and
the signal names should match. Negated names for negative logic.
He assumed the socket he had installed -- since it *looked* the same
(color) as the previous one he had installed -- was the same size
as that previous one.

Any idiot can tell the difference between a 14-pin socket and a 16-pin
socket by inspection. Color isn't even involved. Nope. Not buying
it.
We aren't all lucky enough to have final say over who gets
hired at the places we work (or, at the clients we work *for*).

I (eventually) get to say who works for me. They want the work done
give me competence or at least someone smart enough to learn.
 
K

krw

Jan 1, 1970
0
In general I agree with you, but I'm OK for something as "well-known" as some
dozens of bypass caps.

I wouldn't even go there. Too many ways for things to go wrong.
 
U

Uwe Hercksen

Jan 1, 1970
0
D said:
[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? :> ]

Hallo,

in Germany we have well defined paper formats, all these have the same
aspect ratio and the next larger format has exactly the double area of
the smaller one. Perfect for reduction and magnification.

Bye
 
D

D Yuniskis

Jan 1, 1970
0
Hi Uwe,

Uwe said:
D said:
[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? :> ]

in Germany we have well defined paper formats, all these have the same
aspect ratio and the next larger format has exactly the double area of
the smaller one. Perfect for reduction and magnification.

<grin> Unfortunately, not that simple on this side of the pond.
The aspect ratio alternates with each successive paper size.
E.g., 8.5x11 -> 11x17 -> 17x22 (same aspect as 8.5x11) -> 22x34
(same aspect as 11x17).

Sometimes, it can be a win as you can deliberately chose a size
and orientation that will scale to fit something nicely (e.g.,
B scaled to fit on an A gives you a nice margin). But, it is
something that every designer stumbles over sooner or later
when they get tired of large paper formats.
 
K

krw

Jan 1, 1970
0
Exactly! Read my original comment:

"E.g., RUN and STOP instead of RUN and RUNN (or NRUN)."

Obviously, this refers to *two* signals. One of those is the
complement of the other (RUN -> RUNn, RUN -> STOP). The point I
was making is that I will *avoid* the "_n" in favor of choosing a
signal name that inherently implies the negation of its counterpart.
YES -> NO. RUN -> STOP. LEFT -> RIGHT.

This avoids the "negation" issue for the most part (i.e., always
name "negative" signals with their antonyms)

---
I don't understand what you're saying, but what works for me is to name
the signal appropriately and then to assign it the polarity which
results in the desired action being asserted.

For example: (View in Courier)

If have a signal which goes high and I want to use that signal to
trigger an RS latch which will, say, start a motor, then I'll call the
signal START and I'll wire it into a pair of positive true NORs like
this:


START>----A _
NOR Y--+
+--B |
| |
| _ A
+-----Y NOR
B

Let's also say that the signal required by the controller, which will
turn the motor on, is a momentary low-going signal. Then the signal
chain would look like this:

CONTROLLER
+--------------+
START>----A _ _____ |_____ ___|
NOR Y--+-->START>---O|START ON/OFF|--[MOTOR]
+--B | | |
| | | |
| _ A
+-----Y NOR
B
_____
Except that START and START are not complementary. In this case
_____ _______ _____________
START should be something like RUNNING or START_LATCHED
or some such.
To finish it up, let's say the either the controller or the user can
turn the motor off, and that either must generate a momentary low to do
that, with both signals staying high the rest of the time.

Then we have:

CONTROLLER
+--------------+
START>----A _ _____ |__ ___|
OR Y-----+-->START>---O|ST ON/OFF|--[MOTOR]
+--B U1 | | |
| | ____ |__ ____|
+-----------|-->STOP-----O|SP STOP|O--+
| | | | |
| _ A--+ _ +--------------+ |
+-----Y OR A----------------------------+
U2 B---Y _ OR
U3 B--+
____ |
STOP>---------------------+

Notice that all of the gates are functionally ORs but, because of the
annotation being applied to indicate function, in the real world U1 and
U2 would be something like HC02 NORs, and U3 (being its De Morgan
equivalent)something like an HC00 NAND.

YES! Thank you!
 
K

krw

Jan 1, 1970
0
Think of it as just like a hierachical block ("all your bypass caps are belong
to us") -- you just can't "push" into it explicitly. :)

It's a special case, one that likely wouldn't be used enough for it to
be obvious. No thanks.
 
K

krw

Jan 1, 1970
0
Fair argument, but the whole "let's use hierarchical" idea that you and I both
support is often dismissed for the same reason ("won't be used enough for it
to be obvious,"), don't you think? (Particular in companies that are usually
doing small designs that could fit on just a few, say, C-sized sheets.)

Not true at all. If it worked, every design I did would be
hierarchical. All of my FPGA designs are hierarchical. ;-)
 
Top