I need a sanity check on a memory copy circuit.

[MarkS]

Is the Q output of the 74LVC1G79 guaranteed to be low on power on? I don't see anything in the datasheet about that.

That is the purpose of the pull down resistor R1, although ignore it's value. I copied another resistor and didn't change the value.

You've tied OE of the as7c256 low... This means the RAM's data buss lines will be outputs whenever WR goes high. This will cause buss contention with the EPROM chip during the copy phase.

Oh, good catch! I totally missed that! That would have been a nasty bug to find and fix!

You'll also need pullup resistors on the data buss lines once you tie the OE pin of the as7c256 high.

Why exactly?

I can't see any value in commenting further on the present design, because it is incomplete.  The design has to provide a means of external access for normal operation.  Trying to work out the detail timing of this circuit is pointless, since the other interface will greatly impact both the design and the timing.

The OP needs to recognize this and learn how to do design work, rather than just sticking chips together. 

This is what I was talking about in a previous post.  What he is doing right now, is painting himself into a corner, again, and again, starting over each time.

You're not wrong, but that is also not helpful. You're trying to figure out the timing of the whole VGA circuit, and while I can understand that, once the copy is complete the SRAM is disconnected from this circuit and connected to the VGA circuit. While this is running, the VGA circuit will be disabled. Point being, we can focus on the timing requirements of this circuit separately from the entire VGA circuit. Yes, the SRAM will need timing and interfacing done. But not here. If you don't want to help, that is your prerogative. Perhaps you can better explain to me your concerns. It's obvious I'm a novice. Maybe I'm not understanding your concerns?

[Kim Christensen]

Is the Q output of the 74LVC1G79 guaranteed to be low on power on? I don't see anything in the datasheet about that.

That is the purpose of the pull down resistor R1, although ignore it's value. I copied another resistor and didn't change the value.

That won't work. The Q output of the 74LVC1G79 will override the pull down resistor upon power on. Q will be undefined. But don't take it from me: Read this TI guru FAQ/forum post.

You'll also need pullup resistors on the data buss lines once you tie the OE pin of the as7c256 high.

Why exactly?

Because when the RAM's CE & OE pins go high, it's data lines change to high impedance mode (floating). Your EPROM data outputs will also be high impedance at the end of copy when it's OE & CE go high. Then the data buss lines will be floating hi-Z. This is because you can have multiple devices on a bidirectional data buss and can only have one talker (outputs) at a time. Kind of a normal old-school data buss configuration to have pull ups.

[gnuarm]

I can't see any value in commenting further on the present design, because it is incomplete.  The design has to provide a means of external access for normal operation.  Trying to work out the detail timing of this circuit is pointless, since the other interface will greatly impact both the design and the timing.

The OP needs to recognize this and learn how to do design work, rather than just sticking chips together. 

This is what I was talking about in a previous post.  What he is doing right now, is painting himself into a corner, again, and again, starting over each time.

You're not wrong, but that is also not helpful.

It's not helpful, because you don't understand the implications.  When you try to attach this circuit to the rest of the design, this circuit will need to change significantly. 

I would suggest that you design the VGA circuit, with the knowledge that you will need to initialize this small portion of the RAM.  It is very likely, that you can find a way to initialize the RAM with little interference.  In fact, I have an idea in mind, that might involve nearly no additional logic at all.  But that can't be determined, until the rest of the circuit is known. 

In essence, I think you are putting the cart before the horse.  Or maybe you should at least design the cart and horse together.

You're trying to figure out the timing of the whole VGA circuit, and while I can understand that, once the copy is complete the SRAM is disconnected from this circuit and connected to the VGA circuit. While this is running, the VGA circuit will be disabled. Point being, we can focus on the timing requirements of this circuit separately from the entire VGA circuit. Yes, the SRAM will need timing and interfacing done. But not here. If you don't want to help, that is your prerogative. Perhaps you can better explain to me your concerns. It's obvious I'm a novice. Maybe I'm not understanding your concerns?

I know what you are doing.  Keep in mind that you are looking at the building one brick at a time.  I have designed similar circuits and can see the entire building at once, because I already know the pieces.  I can't say just which pieces you plan to use, but I'm very familiar with them all. 

To be honest, seeing what you are doing, no, I'm not very inclined to help.  I would be interested in helping you design something, but not when you choose to make things much more difficult than they need to be.  Look at the circuit you started with, and what you have now.  This is such an improvement. 

When you try to integrate this with the VGA circuit, you will be in a position to see similar improvements to the design as a whole.  Why help you do it the hard way now, when it will mostly be tossed out later?

[gnuarm]

Is the Q output of the 74LVC1G79 guaranteed to be low on power on? I don't see anything in the datasheet about that.

That is the purpose of the pull down resistor R1, although ignore it's value. I copied another resistor and didn't change the value.

That won't work. The Q output of the 74LVC1G79 will override the pull down resistor upon power on. Q will be undefined. But don't take it from me: Read this TI guru FAQ/forum post.

You'll also need pullup resistors on the data buss lines once you tie the OE pin of the as7c256 high.

Why exactly?

Because when the RAM's CE & OE pins go high, it's data lines change to high impedance mode (floating). Your EPROM data outputs will also be high impedance at the end of copy when it's OE & CE go high. Then the data buss lines will be floating hi-Z. This is because you can have multiple devices on a bidirectional data buss and can only have one talker (outputs) at a time. Kind of a normal old-school data buss configuration to have pull ups.

In reality there is no reason to add pull up resistors.  If the bus will be used pretty constantly, the bus will not "float" to some indeterminate level.   It will remain at its previous state for some significant time.  In the old days of TTL, one needed to not let TTL inputs float, but I don't believe there is any TTL here. 

In the real design, once the initialization is complete, the VGA circuit will take over, and the data bus can be driven full time.   This, unless I don't understand the circuit, is the character generator.  It is written to once and always read after that.   So, no floating bus anyway.  Even a few microseconds of not being driven won't be sufficient time for the level to change.

[Kim Christensen]

In reality there is no reason to add pull up resistors.  If the bus will be used pretty constantly, the bus will not "float" to some indeterminate level.   It will remain at its previous state for some significant time.  In the old days of TTL, one needed to not let TTL inputs float, but I don't believe there is any TTL here.

If it was TTL, I wouldn't "worry" at all. But it's actually worse, because it's CMOS. But you're right about the busy buss. As long as it stays busy (which it will when he's done) all will be OK. But as it stands, the buss very quickly becomes idle at the end of the mem copy. I can't comment on what he might build. Only about what he has shown so far.

[gnuarm]

In reality there is no reason to add pull up resistors.  If the bus will be used pretty constantly, the bus will not "float" to some indeterminate level.   It will remain at its previous state for some significant time.  In the old days of TTL, one needed to not let TTL inputs float, but I don't believe there is any TTL here.

If it was TTL, I wouldn't "worry" at all. But it's actually worse, because it's CMOS. But you're right about the busy buss. As long as it stays busy (which it will when he's done) all will be OK. But as it stands, the buss very quickly becomes idle at the end of the mem copy. I can't comment on what he might build. Only about what he has shown so far.

TTL could get into goofy states when allowed to float.  CMOS has the issue of high shoot through current if floating to the threshold, but with so little leakage current, that takes significant time. 

As to what happens when the initialization circuit is complete, that's not my problem.  That's up to some other designer who is working on the VGA circuit. 

It's been years since I worked in this sort of environment, where specs are sliced and diced and the design fragment is thrown over the wall when complete.  It's only been in Dilbert cartoons where they do this sort of stuff.

[MarkS]

That won't work. The Q output of the 74LVC1G79 will override the pull down resistor upon power on. Q will be undefined. But don't take it from me: Read this TI guru FAQ/forum post.

This was extraordinarily helpful. I was not aware that this was an issue with flip flops. Changing this to a 74xx74, setting the PRE pin high and the CLR pin from low to high via a simple RC circuit will ensure a low output at startup.

[MarkS]

Look at the circuit you started with, and what you have now.  This is such an improvement. 

Which only came about due to the help I've received here. I've learned a lot and am grateful. This may not be the easiest or most efficient way to do this, but breaking down into parts is easier on me mentally. Regardless, right or wrong, this is what I chose for this circuit and is where I'm at. I'll tackle the challenges that pop up due to this as they come.

[tychob]

In reality there is no reason to add pull up resistors.  If the bus will be used pretty constantly, the bus will not "float" to some indeterminate level.   It will remain at its previous state for some significant time.  In the old days of TTL, one needed to not let TTL inputs float, but I don't believe there is any TTL here.

If it was TTL, I wouldn't "worry" at all. But it's actually worse, because it's CMOS. But you're right about the busy buss. As long as it stays busy (which it will when he's done) all will be OK. But as it stands, the buss very quickly becomes idle at the end of the mem copy. I can't comment on what he might build. Only about what he has shown so far.

TTL could get into goofy states when allowed to float.  CMOS has the issue of high shoot through current if floating to the threshold, but with so little leakage current, that takes significant time. 

As to what happens when the initialization circuit is complete, that's not my problem.  That's up to some other designer who is working on the VGA circuit. 

TI have an app note on this: https://www.ti.com/lit/an/scba004e/scba004e.pdf (section 4, Bus control). So long you have a reasonable sized bus and it is never idle for more than a couple of hundred ns, then you are fine without them. If you have idle periods longer than a couple of hundred nanoseconds (exact numbers and formula are in the app note), then they recommend some form of active control, such as pullups. But they also seem to assume a leakage current of 50mA, even with CMOS and I'm not sure of the timing involved here.

[Kim Christensen]

But they also seem to assume a leakage current of 50mA, even with CMOS and I'm not sure of the timing involved here.

Good document for the OP to read.
Looks like a typo. They really meant 50uA as you can see from the formula in that example:

[gnuarm]

In reality there is no reason to add pull up resistors.  If the bus will be used pretty constantly, the bus will not "float" to some indeterminate level.   It will remain at its previous state for some significant time.  In the old days of TTL, one needed to not let TTL inputs float, but I don't believe there is any TTL here.

If it was TTL, I wouldn't "worry" at all. But it's actually worse, because it's CMOS. But you're right about the busy buss. As long as it stays busy (which it will when he's done) all will be OK. But as it stands, the buss very quickly becomes idle at the end of the mem copy. I can't comment on what he might build. Only about what he has shown so far.

TTL could get into goofy states when allowed to float.  CMOS has the issue of high shoot through current if floating to the threshold, but with so little leakage current, that takes significant time. 

As to what happens when the initialization circuit is complete, that's not my problem.  That's up to some other designer who is working on the VGA circuit. 

TI have an app note on this: https://www.ti.com/lit/an/scba004e/scba004e.pdf (section 4, Bus control). So long you have a reasonable sized bus and it is never idle for more than a couple of hundred ns, then you are fine without them. If you have idle periods longer than a couple of hundred nanoseconds (exact numbers and formula are in the app note), then they recommend some form of active control, such as pullups. But they also seem to assume a leakage current of 50mA, even with CMOS and I'm not sure of the timing involved here.

Not sure what "leakage" you are talking about.  Each TTL family is different, but the input sources some amount of current, typically uA.  So to pull the input to ground takes a small amount of current.  The input is pulled up through a BE junction and resistor with other current flowing through it.  To pull the input to ground takes some mA or so.  50 mA is a huge current relative to any of these. 

With CMOS, there is virtually no input current, other than needing to charge the parasitic capacitance of the input.  The only problem I am aware of, is when the input sits at the threshold voltage, which turns on both a pull up and a pull down transistor, resulting in current flowing from power to ground.  This can be large enough that it overheats and damages the device.  Since there is no current flowing into or out of the input, the voltage on the input will not change, other than very, very slowly.  If the input is floating for some us or even ms, it should not be an issue.  Many busses have significant undriven periods. 

[tychob]

TI have an app note on this: https://www.ti.com/lit/an/scba004e/scba004e.pdf (section 4, Bus control). So long you have a reasonable sized bus and it is never idle for more than a couple of hundred ns, then you are fine without them. If you have idle periods longer than a couple of hundred nanoseconds (exact numbers and formula are in the app note), then they recommend some form of active control, such as pullups. But they also seem to assume a leakage current of 50mA, even with CMOS and I'm not sure of the timing involved here.

Not sure what "leakage" you are talking about.  Each TTL family is different, but the input sources some amount of current, typically uA.  So to pull the input to ground takes a small amount of current.  The input is pulled up through a BE junction and resistor with other current flowing through it.  To pull the input to ground takes some mA or so.  50 mA is a huge current relative to any of these. 

With CMOS, there is virtually no input current, other than needing to charge the parasitic capacitance of the input.  The only problem I am aware of, is when the input sits at the threshold voltage, which turns on both a pull up and a pull down transistor, resulting in current flowing from power to ground.  This can be large enough that it overheats and damages the device.  Since there is no current flowing into or out of the input, the voltage on the input will not change, other than very, very slowly.  If the input is floating for some us or even ms, it should not be an issue.  Many busses have significant undriven periods.

By leakage, I'm referring to the leakage of current onto the bus from the input when all transceivers are supposed to be disconnected.

Rereading it, the milliamp is a typo in the english description. They actually use 50 uA for the maths, which comes out at 320ns to charge 0.8V, because of the relatively low amount of gate capacitance. Now 50uA is probably still on the conservative side for leakage per device, but it depends how reliable you want to be. Alternatively if I pull the numbers from the 74HC299 datasheet I have open, it gives a gate capacitance of 10pF, maximum Z state leakage of 5uA and input leakage of 1uA. So ignoring the line capacitance, that gives you 1.3us that you are guaranteed to stay in a valid value, before the bus potentially floats out of being valid.

[gnuarm]

TI have an app note on this: https://www.ti.com/lit/an/scba004e/scba004e.pdf (section 4, Bus control). So long you have a reasonable sized bus and it is never idle for more than a couple of hundred ns, then you are fine without them. If you have idle periods longer than a couple of hundred nanoseconds (exact numbers and formula are in the app note), then they recommend some form of active control, such as pullups. But they also seem to assume a leakage current of 50mA, even with CMOS and I'm not sure of the timing involved here.

Not sure what "leakage" you are talking about.  Each TTL family is different, but the input sources some amount of current, typically uA.  So to pull the input to ground takes a small amount of current.  The input is pulled up through a BE junction and resistor with other current flowing through it.  To pull the input to ground takes some mA or so.  50 mA is a huge current relative to any of these. 

With CMOS, there is virtually no input current, other than needing to charge the parasitic capacitance of the input.  The only problem I am aware of, is when the input sits at the threshold voltage, which turns on both a pull up and a pull down transistor, resulting in current flowing from power to ground.  This can be large enough that it overheats and damages the device.  Since there is no current flowing into or out of the input, the voltage on the input will not change, other than very, very slowly.  If the input is floating for some us or even ms, it should not be an issue.  Many busses have significant undriven periods.

By leakage, I'm referring to the leakage of current onto the bus from the input when all transceivers are supposed to be disconnected.

Rereading it, the milliamp is a typo in the english description. They actually use 50 uA for the maths, which comes out at 320ns to charge 0.8V, because of the relatively low amount of gate capacitance. Now 50uA is probably still on the conservative side for leakage per device, but it depends how reliable you want to be. Alternatively if I pull the numbers from the 74HC299 datasheet I have open, it gives a gate capacitance of 10pF, maximum Z state leakage of 5uA and input leakage of 1uA. So ignoring the line capacitance, that gives you 1.3us that you are guaranteed to stay in a valid value, before the bus potentially floats out of being valid.

I looked at the app note and they provide no source for the 50 uA number.  That must be some TTL family or some very odd CMOS family.  I would suggest you find the data sheet for the parts you are using.  Your real world capacitance can include the traces, outputs and loads.  It's unlikely to be only 10 pF.

[tychob]

I looked at the app note and they provide no source for the 50 uA number.  That must be some TTL family or some very odd CMOS family.  I would suggest you find the data sheet for the parts you are using.  Your real world capacitance can include the traces, outputs and loads.  It's unlikely to be only 10 pF.

One of the points of the appnote is you can get a good idea of how close you are to needing active control by looking at the average ratio of capacitance to leakage. So its not 10pF for the whole bus, its 10pF per load. But the 50uA is very generous by an order of magnitude. For the 74HC299 because I have the numbers for that: 5uA/20pF for an output, 1uA/10pF for an input. add a generous 5" of bus trace at 2pF per inch per input/output and thats a best case (the bus is dominated by loads, and we can ignore output drivers) average of 1uA/20pf, for 0.05 V/us. Which gives you 16us to raise by 0.8V. Thats still 2 orders of magnitude away from ms bus idle time. Do you have a suggestion of a different part to run the numbers for?

[MarkS]

If it could even possibly help with stability and/or longevity, I have no issue adding a SIP pull up resistor. I was just wondering why it was recommended, not challenging the recommendation.

[MK14]

If it could even possibly help with stability and/or longevity, I have no issue adding a SIP pull up resistor. I was just wondering why it was recommended, not challenging the recommendation.

A quick, dirty and not 100% accurate explanation, is that logic devices (especially CMOS ones), have internal transistors which either pull the voltage up to Vcc (5V in your case) or down to ground.

But if it ever sees a voltage, approximately half-way, between the logic states (to one or more of its inputs), and stays at that voltage.  It can cause 'shoot-through' (not necessarily proper shoot through, as they may be only weakly or partly turned on), where one transistor pulls it up to Vcc/5V, the other pulls it down to ground and they electrically fight each other (a sort of short-circuit).

That can cause a fair bit of current (or lots, if you like), latch-up (in rather old devices these days), and other issues.  At best the circuit may not work as intended, or worse case, can be damaged/destroyed.

Edit: Added simple picture, of an overly simplified logic gate.  Imagine both the top and bottom transistors, have been activated, by an input voltage, half way between the power rail and ground.