BJT totem pole questions

[MK14]

Adding 470p caps in parallel with R2 and R3 improves the rise/fall times of the output a bit even if I add a 75 ohm resistor in series with the input to simulate the limitations of the microcontroller drive capabilities.

Mines working reasonably well, now. I tried some of your changes, stage by stage. Amazingly, simply changing from the 2n3904's which were behaving badly/slowly on the simulator. The 2n2222's, have fixed it, and 500KHz, at least works now.

How did you export the pictures/diagrams from LTSPICE ?
I can't quickly see how to do it.

Googling it seems to say I need to create printed PDFs. This would take some time for me to set up.

[Zero999]

It looks like I've been beaten to it. Yes, it's the storage time which was causing the problem.

Regarding base resistor bypass capacitors: perhaps 470pF is too big? Did you try 100pF?

[matseng]

I use OSX so I just do a cmd-shift-4 to create a partial screenshot.  I'm not aware of any other way of doing that - and the OSX LTspice is two orders of magnitude suckier than the Windows version...

For me the 3904's perform about the same as 2n2222, but the old standby BC547B is quite bad here.

[matseng]

It looks like I've been beaten to it. Yes, it's the storage time which was causing the problem.

Regarding base resistor bypass capacitors: perhaps 470pF is too big? Did you try 100pF?

Mmmm...  The Miller capacitance effect strikes again. Putting the transistors in deep saturation is a bad thing when it comes to rapid switching.  To be fair I've been simulating and building circuits like this for a while now deigning a computer out of DTL-style discrete parts.  Running at 2.4 volts and not really caring about having a low power consumption it's quite easy to reach quite good speeds.

Yes, I swept the caps from 50p up to 1n without any joy here...   They do make quite a difference in my logic gate designs though...

[MK14]

The "slow" ones, had the pulse slowed to 250KHz. The fast ones are full 500KHz.

[MK14]

It looks like I've been beaten to it. Yes, it's the storage time which was causing the problem.

Regarding base resistor bypass capacitors: perhaps 470pF is too big? Did you try 100pF?

Sorry for initially criticizing your circuit, when my choice of general purpose transistor, tended to spoil it.

At a quick glance of the datasheets, the 2N3904 and 2N2222, don't seem too different.

I've NOT got the inclination, to try it for real. But it would be interesting to know EXACTLY what the difference(s) is, that is causing the effect.

The datasheet does seem to say that the 2N2222, is somewhat suited for fast circuits, whereas the 2N3904, does NOT sound suitable for such circuits.

Maybe there is an oscillation/ringing (I vaguely remember seeing it), which is slowing things down.

The ringing could be fooling the simulator, as it could be unsettling the calculations (guess, on my part). Or if real, it still makes sense, that it slows the response time down.

But as you both mentioned earlier. Maybe it is just due to the slowdown effects of some transistors. Miller effect etc etc.

[Jay_Diddy_B]

Hi,

Here is an idea for you:



These are the results, 500 kHz square wave:



The circuit is inverting, logic low turns on the MOSFET.

I have attached the model.

Regards,

Jay_Diddy_B

[MK14]

Hi,

Here is an idea for you:



These are the results, 500 kHz square wave:


I have attached the model

Regards,

Jay_Diddy_B

Your results are beginning to look quite good!

Maybe we should use this OP's problem, as the next competition to win a big prize. The best LTSPICE IV simulation results, WINS! (Joke, and I would come last!).

[danadak]

An interesting ap note -

http://www.irf.com/technical-info/appnotes/an-937.pdf

Regards, Dana.

[Simon]

I've been on this merry go round for a couple of days and have opted for a mosfet gate driver. They exist for a reason, sadly often more expensive than the mosfet itself.

[nour]

I've been on this merry go round for a couple of days and have opted for a mosfet gate driver. They exist for a reason, sadly often more expensive than the mosfet itself.

I have been for a couple of weeks 
if you are going to switch one or two mosfet I think integrated driver would be cheap and quick solution to go
but if you are going to driver 10+ mosfet, you will need to consider the cost
currently I am working on something that require switching 30+ mosfet (stepper drivers  ) so go figure 

[MK14]

I've been on this merry go round for a couple of days and have opted for a mosfet gate driver. They exist for a reason, sadly often more expensive than the mosfet itself.

I have been for a couple of weeks 
if you are going to switch one or two mosfet I think integrated driver would be cheap and quick solution to go
but if you are going to driver 10+ mosfet, you will need to consider the cost
currently I am working on something that require switching 30+ mosfet (stepper drivers  ) so go figure 

I'm rather surprised you can't just drive them all from your (presumably) digital signals ?
MCU or whatever.
There are plenty available (MCUs) with partly higher drive current pins, and can be further speeded up with low cost (suitable) logic gates/buffers whatever. Even doubling up or more the gates, to achieve even higher speeds.

Is it some kind of severe microstepping scheme (high accuracy), or VERY powerful steppers or something ?

Typically I would expect them to be driven directly from the MCU (or logic as just described).

EDIT: On reflection, I usually let off the shelf ICs, perform microstepping for me.
Maybe if you have a sophisticated microstepping scheme, you need to turn the mosfets on/off VERY quickly.
EDIT2:
SORRY!
I've been a bit foolish.

I'm use to relatively slow steppers, with on-off control operation and/or microstepping via off the shelf ICs.

Presumably you have got a sophisticated, high (freq) PWM scheme, hence the fast on/off mosfet requirements.
Sorry again!

[Simon]

The problem is charging and discharhing the gate capacitance quickly. Also if you have a long trace to your mosfet gate the inductance will cause oscilation. One microchip driver actually comes in 2 pin out versions so that whichever side of the mosfet your on or it's pinout you can straddle the driver right across the mosfet with minimal trace and inductance.

[MK14]

The problem is charging and discharhing the gate capacitance quickly. Also if you have a long trace to your mosfet gate the inductance will cause oscilation. One microchip driver actually comes in 2 pin out versions so that whichever side of the mosfet your on or it's pinout you can straddle the driver right across the mosfet with minimal trace and inductance.

The bit that I still can't quite get my head round. Is WHY are mosfet drivers, so so expensive ?

It's somewhat crazy, you can get a full micro controller from Microchip, with somewhat hefty capabilities for say $0.39
Yet their quad fet drivers are about four times ($1.39/$1.67) that value, in quantities of 5K.

A long time ago, MCUs were quite expensive, but transistors and stuff, were considerably cheaper, in general.

I wonder why mosfet drivers are so expensive.

Presumably they are a major electronics engineering marvel in their own right. Needing lots of IC process steps, to make them.

Even so, one would have thought that they can sell so many (at the right price), that they can sell them cheaply.

Another possible factor, is that I think it needs P channel mosfets, so that it can rapidly switch the fet, BOTH on and off. That probably is making it rather expensive.

[Simon]

Yes they do need some really good output mosfets of both polarities. Thing is while they on average can handle mA continuously they are expected to handles amps in small peaks.

[MK14]

Yes they do need some really good output mosfets of both polarities. Thing is while they on average can handle mA continuously they are expected to handles amps in small peaks.

Thanks for the explanation.

Which probably means large (relatively speaking) die area.

Hence EXPENSIVE production costs.

One often encounters various weirdly (apparently way over priced) components and stuff in Electronics. But I guess it helps make it fun and interesting.

E.g. I initially found it strange that when a component is beginning to be withdrawn (phasing out/stopping production), the prices can immediately go very high for it. I think I know why now (manufacturers getting scared their PCB layouts will need changing etc, so they buy up all available stock).

Supply and demand, can sometimes do odd things as well.

[ali6x944]

use an open collecter drive with a schottkey from the gate to the emitter.

[ali6x944]

or use a tri-state buffer array. like SN74LS541
or use an inverter like 74ls04.

[dom0]

Smart power logic (smart switches, FET drivers) need complicated layouts to combine high performance FETs and logic on the same die, i.e. lots of processing. A textbook I have claims that these are way more complicated to make than old MOS logic (2+ V).

[matseng]

Yes they do need some really good output mosfets of both polarities. Thing is while they on average can handle mA continuously they are expected to handles amps in small peaks.

Is really a P-channel required? With a charge pump and level shifters N-channel fets can be used at high side as well. In an integrated solution that might give more bang for the bucks compares to trying to make good-performing P fets.

[MK14]

Smart power logic (smart switches, FET drivers) need complicated layouts to combine high performance FETs and logic on the same die, i.e. lots of processing. A textbook I have claims that these are way more complicated to make than old MOS logic (2+ V).

I can WELL believe it!

Some things are extremely complicated to do. But almost everyone else outside of that particular industry or sector, or even very narrow field, is completely oblivious as to how much of a nightmare it actually is.

For example, three clever people, are famous for inventing the first transistor, around 1947/8.

BUT the really massively difficult part, was finding out/inventing how to mass produce reliable/cheap and useful transistors.

This took another decode or so, and effectively (just about), also involved inventing the first early integrated circuits. As the "shaping", of transistors and IC masks, are VERY similar concepts. Or even identical.

Funnily enough, Edison was one of the early inventors of electronic valves/tubes. BUT he did not realize their importance, so just patented it and moved on.

A lot of early history has some amazing stories associated with it.

[MK14]

Yes they do need some really good output mosfets of both polarities. Thing is while they on average can handle mA continuously they are expected to handles amps in small peaks.

Is really a P-channel required? With a charge pump and level shifters N-channel fets can be used at high side as well. In an integrated solution that might give more bang for the bucks compares to trying to make good-performing P fets.

I'm going to take a wild guess here. So feel free to throw a heavy lump hammer, made out of hand crafted, discrete transistors, into a DTL Flip-flop, so it continually flops me over the head, until I FLIP over into submission.

Maybe the extreme gate transitions that chip (FET driver) needs, would consume too much of the charge pumped capacitor charge (being an IC capacitor, it would have a limited capacity, and use up tons of space, if bigger valued), and/or the complementary N and P channel method, may allow balancing stuff to minimize self oscillation (ringing) etc, while the huge and immensely fast, transitions takes place.

By the way, what are you using or planing to use as memory for your discrete transistor DTL computer ?
I'm curious.

[matseng]

I was only thinking aloud about the n vs p fets for an integrated fet driver. I haven't actually looked into that at all....

Well, for my discrete computer I plan to have four kinds of memory - why be limited to just one when you can make life harder.  Since it's a Harvard architecture  (I.E separate data & code memories)  it makes kinda sense.

1) The Data RAM (8 bits wide) will be with discrete edge triggered D-style flipflops.  They require a lot of parts for each bit to have good read and write speeds.

There will bi a metric shitton of pcb's for any reasonable amount of memory.  I most def need a pick n' place machine. Just populating a few hundred pcbs in China will cost almost as much as a Neoden machine.  And with SOT's and 0603's any neoden machine should be good enough even without vision.

The code memories (11 bits wide) I plan three different versions of:

2) Code RAM A two transistor memory cell with some diode overriding logic to force it to set itself into 1 or 0. This is rather slow for writing, but can give full read speed.

3) Code "EPROM". A less compact diode matrix with jumpers for each diode to set the bits.

4) Code "ROM". A compact diode matrix type memory with diodes soldered into a grid on the pcb. So when the monitor and commin library functions is done and debugged I can just transfer the code from the EPROM or RAM boards into the ROM boards.

[MK14]

I was only thinking aloud about the n vs p fets for an integrated fet driver. I haven't actually looked into that at all....

Well, for my discrete computer I plan to have four kinds of memory - why be limited to just one when you can make life harder.  Since it's a Harvard architecture  (I.E separate data & code memories)  it makes kinda sense.

1) The Data RAM (8 bits wide) will be with discrete edge triggered D-style flipflops.  They require a lot of parts for each bit to have good read and write speeds.

There will bi a metric shitton of pcb's for any reasonable amount of memory.  I most def need a pick n' place machine. Just populating a few hundred pcbs in China will cost almost as much as a Neoden machine.  And with SOT's and 0603's any neoden machine should be good enough even without vision.

The code memories (11 bits wide) I plan three different versions of:

2) Code RAM A two transistor memory cell with some diode overriding logic to force it to set itself into 1 or 0. This is rather slow for writing, but can give full read speed.

3) Code "EPROM". A less compact diode matrix with jumpers for each diode to set the bits.

4) Code "ROM". A compact diode matrix type memory with diodes soldered into a grid on the pcb. So when the monitor and commin library functions is done and debugged I can just transfer the code from the EPROM or RAM boards into the ROM boards.

WOW! and thanks for the information.

That's a VERY big commitment, to do all that.

How are you solving the following problem ?

The microcode decoding "ROM" ?

Possible solutions are:

(1)...There is NONE, you are using a different type of cpu model, such as "severe" RISC design. (severe is NOT the right technical term, but to differentiate between that and something which still might have a microcode ROM in it).

(2)...It will be hard wired diodes etc, like your EPROMs etc. But my concern is that it would be a REAL PAIN to debug it!

(3)...It will initially be "ram", so you can change it like crazy, for test/debug/development reasons. Then later either always initialize that ram, or replace the final code with ROM/EPROM

(4)...{Cheat} Use standard SRAM initially. Then when code is ready/complete/stable, you make another ROM/EPROM board, with the final debugged microcode.

(5)...Determine microcode via FPGA and/or simulator and/or emulator. So you can set the microcode in stone, early on.

My best guess now that I have typed all this stuff, is that there isn't any ?
I'm convinced 4 is NOT the right answer, and consider 5 unlikely.

Pity you aren't hand winding individual core memory elements. Then RAM/ROM/EPROM/MICROCODE etc, would all be one and the same.

Also I know where you live now. I just need to borrow a thermal camera (from the other thread), go approximately to your location, then when your computer is finished and on, I'll search for the place, emitting HUGE amounts of heat.

Or just ask the locals, whose place has the slowest computer, possible.

Then enjoy seeing and discussing your new, self build/design computer. As I love stuff like that.

[matseng]

It's a helluva big project :-)  That currently are put a bit on hold when it comes to any practical tests since I'm in the middle of a move from Malaysia back to Dubai...

Well, the compete plans are not drawn out yet, I'm building/planning the major blocks first and then time will tell how to glue them together. It's a bottom up version. I could of course have done it the other way, started with all my blocks in standard TTL ICs and then made the glue in discrete, followed by replacing the chips with insane amounts of PCBs of discretes...

I currently hope to make it a single cycle processor (https://en.wikibooks.org/wiki/Microprocessor_Design/Single_Cycle_Processors) where all info required by one instruction is already there in the 11 bits of code.  Then microcode is basically not really necessary and can be replaced by a simple lookup table to enable the correct muxes and other bits and bobs in the modules.  At least this is what I hope :-)

The machine will use quite a lot of power when fully operational.  For instance the 16 bit program counter module (with an integrated single level stack) is pulling about 4 amps at 2.5 volts....  The Code ram modules (16 words each with two pcs of 4-to-16 decoders) are about 3 amps. And I plan to have 128 of them