[Jim Thompson]

On Mon, 03 Aug 2009 20:05:25 -0500,

I'm missing someting. Why is the power on the A gate? That just
leads to problems like this.

I'd expect it to be on a separate symbol or "gate" or whatever
you call them. Another option is that power is connected automagically,
but then you need a way to override that when you are doing fancy
things.

Simulators often use $G_VDD and $G_GND... global power, hidden pins...
makes it rough for layout people. Just going thru such an episode
myself with a library connived (by a PhD with crossed eyes and his
head up his ass) with pin order not following the standard for digital
subcircuits :-(

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |

Obama: A criminal reincarnation of Nixon, disguised in black-face.

 

[krw]

On Mon, 03 Aug 2009 20:05:25 -0500,

I'm missing someting. Why is the power on the A gate? That just
leads to problems like this.

Way back up there somewhere, we were discussing different ways of
instantiating power on schematics. My preference was to have a
heterogeneous gate with only power and other(s) with the part's
function(s). That way I can hide all the power pins on a separate
page and still "show" decoupling where it belongs. The instances then
can be swapped at leisure.

Joerg prefers show the power on the 'A' instance, which I contend
looks ugly and causes grief later.

I'd expect it to be on a separate symbol or "gate" or whatever
you call them. Another option is that power is connected automagically,
but then you need a way to override that when you are doing fancy
things.

That's my preference, though I'm a little less happy about anything
done "automatically". Too often it isn't.

 

[krw]

Simulators often use $G_VDD and $G_GND... global power, hidden pins...
makes it rough for layout people. Just going thru such an episode
myself with a library connived (by a PhD with crossed eyes and his
head up his ass) with pin order not following the standard for digital
subcircuits :-(

For board schematics there are other ways of doing globals, though all
bring some danger along with them. I tend to like global power
symbols attached to heterogeneous power-only instances.

 

[Joerg]

I'm missing someting. ...

^

Caribbean accent? SCNR

... Why is the power on the A gate? That just
leads to problems like this.

I'd expect it to be on a separate symbol or "gate" or whatever
you call them. Another option is that power is connected automagically,
but then you need a way to override that when you are doing fancy
things.

In my case there are mainly two reasons:

a. The device must have its personal regulator/filter/whatever and other
engineers and also technicians need to understand that. This is much
easier when present at the symbol. Otherwise they might draw the wrong
conclusions like "Oops, +12V is missing, lets take the main power supply
apart" while in reality the local regulator was gated off for some reason.

b. I often have situations where, say, an opamp or comparator switches
the supply of another. This can become next to impossible to understand
by other engineers, especially younger ones.

Cadsoft Eagle allows a very nice flexibility here: You can call up the
power pins via the "invoke" command. The CAD symbol is usually drawn so
it slides over the A-device (or another if you wish) and fits as if it
was part of the symbol. You can also place it near the group in the
schematic, or down at the bottom for simpler architectures. That's how
it ought to be, gives the designer all the freedom.

 

[krw]

^

Caribbean accent? SCNR



In my case there are mainly two reasons:

a. The device must have its personal regulator/filter/whatever and other
engineers and also technicians need to understand that. This is much
easier when present at the symbol. Otherwise they might draw the wrong
conclusions like "Oops, +12V is missing, lets take the main power supply
apart" while in reality the local regulator was gated off for some reason.

That's a special case and I'd agree a more "local" power distribution
would help. OTOH, in our designs the regulators are "globally" (on
the board) controlled.

b. I often have situations where, say, an opamp or comparator switches
the supply of another. This can become next to impossible to understand
by other engineers, especially younger ones.

In our case there is always a PIC in the middle. I don't know how to
show the power control code on the schematic. ;-)

Cadsoft Eagle allows a very nice flexibility here: You can call up the
power pins via the "invoke" command. The CAD symbol is usually drawn so
it slides over the A-device (or another if you wish) and fits as if it
was part of the symbol. You can also place it near the group in the
schematic, or down at the bottom for simpler architectures. That's how
it ought to be, gives the designer all the freedom.

That sounds like it solves all the problems.

 

[Joerg]

Hal Murray wrote:

[...]

In my case there are mainly two reasons:

a. The device must have its personal regulator/filter/whatever and other
engineers and also technicians need to understand that. This is much
easier when present at the symbol. Otherwise they might draw the wrong
conclusions like "Oops, +12V is missing, lets take the main power supply
apart" while in reality the local regulator was gated off for some reason.

That's a special case and I'd agree a more "local" power distribution
would help. OTOH, in our designs the regulators are "globally" (on
the board) controlled.

Ok, then 80% of my designs are special cases

In our case there is always a PIC in the middle. I don't know how to
show the power control code on the schematic. ;-)

So far I never had a PIC in the middle ...

That sounds like it solves all the problems.

Sure does. That CAD program is very close to perfect. With one major
deficiency and that makes it IMHO useless for any larger design: No
hierarchical sheet structure :-(

 

[krw]

Hal Murray wrote:

[...]

... Why is the power on the A gate? That just
leads to problems like this.

I'd expect it to be on a separate symbol or "gate" or whatever
you call them. Another option is that power is connected automagically,
but then you need a way to override that when you are doing fancy
things.

In my case there are mainly two reasons:

a. The device must have its personal regulator/filter/whatever and other
engineers and also technicians need to understand that. This is much
easier when present at the symbol. Otherwise they might draw the wrong
conclusions like "Oops, +12V is missing, lets take the main power supply
apart" while in reality the local regulator was gated off for some reason.

That's a special case and I'd agree a more "local" power distribution
would help. OTOH, in our designs the regulators are "globally" (on
the board) controlled.

Ok, then 80% of my designs are special cases

I don't think anyone here would argue that. ;-)

So far I never had a PIC in the middle ...

When I first wrote "PIC" I was kidding; the answer to every question
is "PIC". The fact is that we do have a PIC in the middle, on top of
a DSP.

Sure does. That CAD program is very close to perfect. With one major
deficiency and that makes it IMHO useless for any larger design: No
hierarchical sheet structure :-(

Monday we had the design review for the widget I'm working on. My
boss really liked the hierarchical (turtles all the way down)
organization. I'm not so sure about the other hardware engineer
though. ;-) I'm still not to where I can easily determine where to
add a hierarchical block or another sheet though. More than one block
for a component (FPGA) just seems wrong.

 

[Joerg]

[...]

So far I never had a PIC in the middle ...

When I first wrote "PIC" I was kidding; the answer to every question
is "PIC". The fact is that we do have a PIC in the middle, on top of
a DSP.

Dead-bugged on top of it with liquid nails glue ...?

Monday we had the design review for the widget I'm working on. My
boss really liked the hierarchical (turtles all the way down)
organization. I'm not so sure about the other hardware engineer
though. ;-) I'm still not to where I can easily determine where to
add a hierarchical block or another sheet though. More than one block
for a component (FPGA) just seems wrong.

Yes, I would never, ever, split a component across several sheets or
even just blocks. That makes a royal mess out of a schematic.

 

[John Larkin]

krw wrote:

[...]

b. I often have situations where, say, an opamp or comparator switches
the supply of another. This can become next to impossible to understand
by other engineers, especially younger ones.
In our case there is always a PIC in the middle. I don't know how to
show the power control code on the schematic. ;-)

So far I never had a PIC in the middle ...

When I first wrote "PIC" I was kidding; the answer to every question
is "PIC". The fact is that we do have a PIC in the middle, on top of
a DSP.

Dead-bugged on top of it with liquid nails glue ...?

Monday we had the design review for the widget I'm working on. My
boss really liked the hierarchical (turtles all the way down)
organization. I'm not so sure about the other hardware engineer
though. ;-) I'm still not to where I can easily determine where to
add a hierarchical block or another sheet though. More than one block
for a component (FPGA) just seems wrong.

Yes, I would never, ever, split a component across several sheets or
even just blocks. That makes a royal mess out of a schematic.

Thing I'm doing now, the PLX PCIe chip is three "gate sections" (pcie,
backside bus, power) across two sheets. The FPGA is 8 sections (one
for each bank, 450 pins or so total) across three sheets. This one
board is a 22 sheet schematic... B size sheets.

You never split gate or opamp sections between sheets?

I never do hierarchical schematics. Everything's flat.

John

 

[Fred Abse]

I remember a high-tech place near Munich, Germany, where we had some die
bonding done. In the hallway there was a vending machine. No cans but
bottles like in the old days. Five columns to choose from:

1: Clear lemonade
2: Orange lemonade
3: Beer
4: Beer
5: Beer

Isn't it illegal to drink anything other than beer in Munich?

;-)

 

[Jim Thompson]

On Thu, 06 Aug 2009 07:42:46 -0700, John Larkin

[snip]

I never do hierarchical schematics. Everything's flat.

John

I _always_ do hierarchical schematics! Each block is a functional
cell, making it easier for my layout guy to sort out signal and power
routing. And for me to simulate pieces before combining into the
total chip.

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |

I love to cook with wine Sometimes I even put it in the food

 

[Joerg]

krw wrote:
[...]


b. I often have situations where, say, an opamp or comparator switches
the supply of another. This can become next to impossible to understand
by other engineers, especially younger ones.
In our case there is always a PIC in the middle. I don't know how to
show the power control code on the schematic. ;-)

So far I never had a PIC in the middle ...
When I first wrote "PIC" I was kidding; the answer to every question
is "PIC". The fact is that we do have a PIC in the middle, on top of
a DSP.

Dead-bugged on top of it with liquid nails glue ...?

Cadsoft Eagle allows a very nice flexibility here: You can call up the
power pins via the "invoke" command. The CAD symbol is usually drawn so
it slides over the A-device (or another if you wish) and fits as if it
was part of the symbol. You can also place it near the group in the
schematic, or down at the bottom for simpler architectures. That's how
it ought to be, gives the designer all the freedom.
That sounds like it solves all the problems.
Sure does. That CAD program is very close to perfect. With one major
deficiency and that makes it IMHO useless for any larger design: No
hierarchical sheet structure :-(
Monday we had the design review for the widget I'm working on. My
boss really liked the hierarchical (turtles all the way down)
organization. I'm not so sure about the other hardware engineer
though. ;-) I'm still not to where I can easily determine where to
add a hierarchical block or another sheet though. More than one block
for a component (FPGA) just seems wrong.

Yes, I would never, ever, split a component across several sheets or
even just blocks. That makes a royal mess out of a schematic.

Thing I'm doing now, the PLX PCIe chip is three "gate sections" (pcie,
backside bus, power) across two sheets. The FPGA is 8 sections (one
for each bank, 450 pins or so total) across three sheets. This one
board is a 22 sheet schematic... B size sheets.

You never split gate or opamp sections between sheets?

Nope. Only exception is simple logic gates but even then you'd almost
have to twist my arm.

I never do hierarchical schematics. Everything's flat.

Then we have almost opposite CAD habits. But at least we have similar
beer taste, only the good stuff

 

[Joerg]

On Thu, 06 Aug 2009 07:42:46 -0700, John Larkin

[snip]

I never do hierarchical schematics. Everything's flat.

John

I _always_ do hierarchical schematics! Each block is a functional
cell, making it easier for my layout guy to sort out signal and power
routing. And for me to simulate pieces before combining into the
total chip.

T'is how it ought to be. Just MHO.

 

[TheJoker]

In Bavaria beer is considered basic nutrition

The same is true at the Sam Addams Breweries.

 

[krw]

krw wrote:

[...]

b. I often have situations where, say, an opamp or comparator switches
the supply of another. This can become next to impossible to understand
by other engineers, especially younger ones.
In our case there is always a PIC in the middle. I don't know how to
show the power control code on the schematic. ;-)

So far I never had a PIC in the middle ...

When I first wrote "PIC" I was kidding; the answer to every question
is "PIC". The fact is that we do have a PIC in the middle, on top of
a DSP.

Dead-bugged on top of it with liquid nails glue ...?

If I had my way, yes. My plan is to replace the PIC, and a pile of
other stuff, with an FPGA. The DSP is sorta the heart of the widget.
Replacing it would be *hard*.

Yes, I would never, ever, split a component across several sheets or
even just blocks. That makes a royal mess out of a schematic.

Here I disagree 100%. I always use heterogeneous "gates" to make high
pincount/programmable devices more understandable. Depending on the
situation, I may separate them into FPGA banks, or into functional
blocks (usually close to the same thing). Just wrapping them in
another hierarchical layer just seems icky.

 

[krw]

On Thu, 06 Aug 2009 07:42:46 -0700, John Larkin

[snip]

I never do hierarchical schematics. Everything's flat.

John

I _always_ do hierarchical schematics! Each block is a functional
cell, making it easier for my layout guy to sort out signal and power
routing. And for me to simulate pieces before combining into the
total chip.

It's not surprising that JL would like flat schematics. He does his
programming that way. I went to hierarchical programming *long*
before I seriously contemplated doing it for schematics.

 

[krw]

On Thu, 06 Aug 2009 07:42:46 -0700, John Larkin

[snip]

I never do hierarchical schematics. Everything's flat.

John

I _always_ do hierarchical schematics! Each block is a functional
cell, making it easier for my layout guy to sort out signal and power
routing. And for me to simulate pieces before combining into the
total chip.

T'is how it ought to be. Just MHO.

Yes, and I think it'll reduce our errors significantly. However, I've
just run into another OrCad gotcha. Named signals get ruined when
buried in a hierarchy. The first instance keeps its name, everything
else has its net number appended. It's impossible (without
investigating each net) to tell which signal goes with which block.

 

[krw]

Jim Thompson wrote:
On Thu, 06 Aug 2009 07:42:46 -0700, John Larkin

[snip]
I never do hierarchical schematics. Everything's flat.

John
I _always_ do hierarchical schematics! Each block is a functional
cell, making it easier for my layout guy to sort out signal and power
routing. And for me to simulate pieces before combining into the
total chip.

T'is how it ought to be. Just MHO.

Yes, and I think it'll reduce our errors significantly. However, I've
just run into another OrCad gotcha. Named signals get ruined when
buried in a hierarchy. The first instance keeps its name, everything
else has its net number appended. It's impossible (without
investigating each net) to tell which signal goes with which block.

I hung up on OrCad many years ago. Too many crashes for my taste.
Although to be fair, I am known to be brutal on computers. But Eagle
doesn't crash. IMHO the last good OrCad was the DOS version, that was
absolutely perfect. I never found a bug in it.

Yes, OrCad crashes constantly but they've "fixed" it by doing a save
during the crash - sorta. I'm not convinced (less so every day) that
it saves everything. Ive noticed that things are disappearing from
the schematics. :-(

 

[Jim Thompson]

On Thu, 06 Aug 2009 07:42:46 -0700, John Larkin

[snip]
I never do hierarchical schematics. Everything's flat.

John

I _always_ do hierarchical schematics! Each block is a functional
cell, making it easier for my layout guy to sort out signal and power
routing. And for me to simulate pieces before combining into the
total chip.

T'is how it ought to be. Just MHO.

Yes, and I think it'll reduce our errors significantly. However, I've
just run into another OrCad gotcha. Named signals get ruined when
buried in a hierarchy.

In PSpice Schematics "appending" a page number is an option. But
you're probably using Crapture :-(

The first instance keeps its name, everything
else has its net number appended. It's impossible (without
investigating each net) to tell which signal goes with which block.

HB34:N_6 ???

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |

I love to cook with wine Sometimes I even put it in the food

 

[FatBytestard]

I hung up on OrCad many years ago. Too many crashes for my taste.
Although to be fair, I am known to be brutal on computers. But Eagle
doesn't crash. IMHO the last good OrCad was the DOS version, that was
absolutely perfect. I never found a bug in it.

Sounds more like you were using shitty computers. On a decent box, I
have seen entire seasons pass without such things happening.