Decoded PHI2
Decoded PHI2
Hey everyone,
This is a newbie type question, but I want your opinion.
Attached is my mini-schematic. I'm decoding PHI2 to be part of a sixteenth of a clock cycle.
I'm not asking if this is silly (it is), but rather would the '138 and '10 hold the PHI2 high and/or low for the desired length of time? Between switching '138 outputs, would there be the possibility of changing PHI2 for a few nanoseconds, or would PHI2 be constant and solid for that section of the decoder?
Thank you everyone.
Chad
This is a newbie type question, but I want your opinion.
Attached is my mini-schematic. I'm decoding PHI2 to be part of a sixteenth of a clock cycle.
I'm not asking if this is silly (it is), but rather would the '138 and '10 hold the PHI2 high and/or low for the desired length of time? Between switching '138 outputs, would there be the possibility of changing PHI2 for a few nanoseconds, or would PHI2 be constant and solid for that section of the decoder?
Thank you everyone.
Chad
Re: Decoded PHI2
I think you're looking for some kind of glitch-free decode, and I think that probably isn't safe.
You might be better off with a shift register, and ORing together some consecutive taps.
Or possibly some kind of SR latch, which you set once and then reset, to make a pulse.
But probably there are standard ways and clever ways which I don't know about...
You might be better off with a shift register, and ORing together some consecutive taps.
Or possibly some kind of SR latch, which you set once and then reset, to make a pulse.
But probably there are standard ways and clever ways which I don't know about...
Re: Decoded PHI2
Or just a shift register on its own. The '165 should be suitable. Connect the parallel inputs to 00000111 (or whatever pattern you want it to generate), SH/LD to /RESET, and SER to QH.
Although the '138 makes no guarantees about what happens to its outputs as the inputs change, it is still usable. You just need to pass the output of the NAND gate through a flip-flop, clocked on the clock edge that the counter isn't (that's the counter that's feeding the '138). It doesn't matter what the flip-flop's input is doing in between. But that ends up a lot of chips.
Although the '138 makes no guarantees about what happens to its outputs as the inputs change, it is still usable. You just need to pass the output of the NAND gate through a flip-flop, clocked on the clock edge that the counter isn't (that's the counter that's feeding the '138). It doesn't matter what the flip-flop's input is doing in between. But that ends up a lot of chips.
-
kernelthread
- Posts: 166
- Joined: 23 Jun 2021
Re: Decoded PHI2
Even disregarding potential glitches, I don't think the circuit you've drawn does what you want, because you've missed out the EIGHTH signal from the decode. PHI2 is low for counts from 0-7; for counts 8-15:
1000 O4 low PHI2=1
1001 O5 low PHI2=1
1010 O4 low PHI2=1
1011 O5 low PHI2=1
1100 O6 low PHI2=1
1101 O7 low PHI2=0
1110 O6 low PHI2=1
1111 O7 low PHI2=0
So you end up with two PHI2 pulses for each 16 cycle period of the counter.
You could get the effect you want by using a JK flip flop clocked on the same edge as the main counter.
Decode J = (count == 4'b0111)
Decode K = (count == 4'b1110)
Then the JK output will go high on the same edge which counts to 8 and low on the same edge which counts to 15. All other counts have J=K=0 which leaves the state unchanged.
1000 O4 low PHI2=1
1001 O5 low PHI2=1
1010 O4 low PHI2=1
1011 O5 low PHI2=1
1100 O6 low PHI2=1
1101 O7 low PHI2=0
1110 O6 low PHI2=1
1111 O7 low PHI2=0
So you end up with two PHI2 pulses for each 16 cycle period of the counter.
You could get the effect you want by using a JK flip flop clocked on the same edge as the main counter.
Decode J = (count == 4'b0111)
Decode K = (count == 4'b1110)
Then the JK output will go high on the same edge which counts to 8 and low on the same edge which counts to 15. All other counts have J=K=0 which leaves the state unchanged.
Re: Decoded PHI2
kernelthread wrote:
Even disregarding potential glitches, I don't think the circuit you've drawn does what you want, because you've missed out the EIGHTH signal from the decode.
Everyone else, thank you for the input. The SR-Latch or JK flip-flop seem like the best idea for sure. I do like the shift register idea as well, that's handy! And yes, a lot of chips. I just want to do this thing right. Thank you all, good input!
Chad
Re: Decoded PHI2
I think this might work (with a bunch of caveats) because, well, I tried.
What you see below is a 40MHz signal fed into a 74VHC161 counter into a 74VHC238 decoder finally into a 74LVC332 OR gate. You can ignore everything at the bottom. The flip-flip is the clock so you can ignore it too. The final output of the 3 input OR gate is absolutely flat and glitch free.
The big difference is that I'm driving a 3.3V LVC chip with 5V tolerant inputs with a 5V signal and that might be enough to "pave over" the glitches. I'm also not using HC chips and I would not swear that different manufactures and different families have the same behaviour.
I recommend just building it and see what happens. Unfotunately I've lost my 'scope picture of the inputs and the outputs but if you want I can hook it up again. It was a bit more effort than just quickly posting this is all.
What you see below is a 40MHz signal fed into a 74VHC161 counter into a 74VHC238 decoder finally into a 74LVC332 OR gate. You can ignore everything at the bottom. The flip-flip is the clock so you can ignore it too. The final output of the 3 input OR gate is absolutely flat and glitch free.
The big difference is that I'm driving a 3.3V LVC chip with 5V tolerant inputs with a 5V signal and that might be enough to "pave over" the glitches. I'm also not using HC chips and I would not swear that different manufactures and different families have the same behaviour.
I recommend just building it and see what happens. Unfotunately I've lost my 'scope picture of the inputs and the outputs but if you want I can hook it up again. It was a bit more effort than just quickly posting this is all.
Re: Decoded PHI2
So I did connect it and here's what the signal looks like. The inputs yellow, cyan and purple taken from the left hand half-circle pins and the output green on the right hand full circle pin.
And just to be sure it isn't the 5V VHC chips managing to hold the 3.3V LVC OR gate high rather than having little downwards spikes here is the same with everything running at 3.3V.Still surprisingly flat.
Re: Decoded PHI2
AndrewP wrote:
So I did connect it and here's what the signal looks like. The inputs yellow, cyan and purple taken from the left hand half-circle pins and the output green on the right hand full circle pin.
And just to be sure it isn't the 5V VHC chips managing to hold the 3.3V LVC OR gate high rather than having little downwards spikes here is the same with everything running at 3.3V.Still surprisingly flat.
I'm guessing you noticed the propagation delay of the OR logic? It's shifted by some nanoseconds. Perhaps because of that, the input signals change faster than it can propagate, thus it remains high. Interesting.
This would of course assume signals that would hit the OR gate at the same time, thus allowing for that to work like that. Still, good to know and good to see. Thank you!
Chad
Re: Decoded PHI2
sburrow wrote:
I'm guessing you noticed the propagation delay of the OR logic? It's shifted by some nanoseconds. Perhaps because of that, the input signals change faster than it can propagate, thus it remains high.
Full disclosure, I haven't been doing hardware stuff for very long and I really dislike analogue signals.
What I think is happening here is that the transistors in chip can be viewed as little amplifiers. For LVC (being TTL 3.3V) anything above 2.0V is going to swing to a logic high within the data sheets specs and the same for anything below 0.8V swinging to a low. But the zone in between is not undefined it's just out of spec for the given propagation times. An input signal is still going to cause the transistor to swing high or low. But slowly (where slow is very relative with LVC).
I assume manufacturers are going to tune - is that even the word? - their ICs to amplify up or down around some given voltage. Digging through Nexperia's datasheets didn't turn up anything but looking at the datasheet for Texas Instruments' SN74LVC245 it looks like the threshold voltage is 1.5V for a VCC of 3.3V. So anything above 1.5V is going register as high output for that OR gate. And in my example the OR gate was already driven high by the previous signal so the output doesn't need to swing at all to remain high. And even though the input dips are quite large none drop below 1.5V.
But also as you mentioned there is a propagation delay (about 2ns) before the OR gate starts responding at all and by the time it would start responding the next input is already within the spec'ed 2.0V.
I'm glad you asked this question because I built that circuit last year to test if I could use a counter, a decoder and some OR gates to generate PHI2, but never really thought about why it worked.
Re: Decoded PHI2
Indeed, sometimes it's useful to think of digital gates as very high gain analogue amplifiers.
And indeed, it's important to see specs as what they are: if you reach a certain voltage by a certain time, then you'll be OK. It doesn't say anything about whether or not you're OK in other circumstances.
Even if this circuit seems empirically glitch-free, I'd say it's a bit of a risky choice: different parts, different temperatures, different supply voltages, and it might glitch. We've particularly seen trouble with high speed devices, which can detect glitches which slower ones can't - and by detect glitches, I mean react to edges with misbehaviour.
It might be OK for hobby use, of course. But things which just about work most of the time are the hardest to debug, so watch out for that.
And indeed, it's important to see specs as what they are: if you reach a certain voltage by a certain time, then you'll be OK. It doesn't say anything about whether or not you're OK in other circumstances.
Even if this circuit seems empirically glitch-free, I'd say it's a bit of a risky choice: different parts, different temperatures, different supply voltages, and it might glitch. We've particularly seen trouble with high speed devices, which can detect glitches which slower ones can't - and by detect glitches, I mean react to edges with misbehaviour.
It might be OK for hobby use, of course. But things which just about work most of the time are the hardest to debug, so watch out for that.
Re: Decoded PHI2
I don't quite understand the point of this arrangement, so I made a truth table.
<strike>Assuming your input signals are coming off of a *161 or *163 counter or similar, Phi2 will be high for 3 out of 8 strobes, and low for 5 out of 8 strobes. Is that useful for something? What am I missing?</strike>
Edit: Hah! Thanks to the 100% reliable gremlins of internet posting, I immediately saw what I was missing (at least in part). Also I numbered the signals backwards.
So, I redid the truth table, and now I think it's correct. Phi2 seems even less useful now. What's this for?
Code: Select all
| 1/16|(1/8)| 1/4| 1/2 | Phi2 | Count (decoded)
0 0 0 0 0 0
0 0 0 1 0 1
0 0 1 0 0 2
0 0 1 1 0 3
0 1 0 0 0 0
0 1 0 1 0 1
0 1 1 0 0 2
0 1 1 1 0 3
1 0 0 0 1 4
1 0 0 1 1 5
1 0 1 0 1 6
1 0 1 1 0 7
1 1 0 0 1 4
1 1 0 1 1 5
1 1 1 0 1 6
1 1 1 1 0 7
Edit: Hah! Thanks to the 100% reliable gremlins of internet posting, I immediately saw what I was missing (at least in part). Also I numbered the signals backwards.
So, I redid the truth table, and now I think it's correct. Phi2 seems even less useful now. What's this for?
"The key is not to let the hardware sense any fear." - Radical Brad
Re: Decoded PHI2
Paganini wrote:
<strike>Assuming your input signals are coming off of a *161 or *163 counter or similar, Phi2 will be high for 3 out of 8 strobes, and low for 5 out of 8 strobes. Is that useful for something? What am I missing?</strike>
Edit: Hah! Thanks to the 100% reliable gremlins of internet posting, I immediately saw what I was missing (at least in part). Also I numbered the signals backwards.
So, I redid the truth table, and now I think it's correct. Phi2 seems even less useful now. What's this for?
Edit: Hah! Thanks to the 100% reliable gremlins of internet posting, I immediately saw what I was missing (at least in part). Also I numbered the signals backwards.
So, I redid the truth table, and now I think it's correct. Phi2 seems even less useful now. What's this for?
Originally I was wanting to lengthen the time of PHI2-low because I was running a faster clock and wanted to access some slower ROM during that time. But all in all I was really wanting to a way to control PHI2 outside of a simple '161 or '163 like I have been forevers.
It's been a while since you've been online Paganini, glad to see you back!
Chad
- Attachments
-
- TimingChart.png (7.99 KiB) Viewed 5002 times
Re: Decoded PHI2
Iiiinteresting. So the 6502 doesn't care how long it is between edges as long as it's "long enough?" If I'm reading your chart right, you've got 3 parts for 6502 to work, and 4 parts for interleaved RAM/ROM access. Slick.
Thanks! I've been here! Just been quiet for a while, partly because I got busy with work, and also partly because I had to take the electronics workshop apart and put the wood workshop in (and now the car workshop... yeep). I have upgraded my breadboarding area. I'll put up some pictures on the project thread in a few days. 
sburrow wrote:
Paganini wrote:
It's been a while since you've been online Paganini, glad to see you back!
"The key is not to let the hardware sense any fear." - Radical Brad