Decoded PHI2

Building your first 6502-based project? We'll help you get started here.
Post Reply
sburrow
Posts: 833
Joined: 09 Oct 2021
Location: Texas

Decoded PHI2

Post by sburrow »

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
Attachments
ScreenshotDecodedPHI2.png
User avatar
BigEd
Posts: 11463
Joined: 11 Dec 2008
Location: England
Contact:

Re: Decoded PHI2

Post by BigEd »

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...
John West
Posts: 383
Joined: 03 Sep 2002

Re: Decoded PHI2

Post by John West »

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.
kernelthread
Posts: 166
Joined: 23 Jun 2021

Re: Decoded PHI2

Post by kernelthread »

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.
sburrow
Posts: 833
Joined: 09 Oct 2021
Location: Texas

Re: Decoded PHI2

Post by sburrow »

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.
Wow! Leave it to the math teacher to not divide correctly :) Sorry, good catch on that, I meant eighth :)

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
User avatar
AndrewP
Posts: 368
Joined: 30 Aug 2021
Location: South Africa

Re: Decoded PHI2

Post by AndrewP »

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.
CounterDecoder.png
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.
User avatar
AndrewP
Posts: 368
Joined: 30 Aug 2021
Location: South Africa

Re: Decoded PHI2

Post by AndrewP »

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.
3 Input Or Gare - Source 5V.png
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.
3 Input Or Gare - Source 3V.png
Still surprisingly flat.
sburrow
Posts: 833
Joined: 09 Oct 2021
Location: Texas

Re: Decoded PHI2

Post by sburrow »

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.
3 Input Or Gare - Source 5V.png
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.
3 Input Or Gare - Source 3V.png
Still surprisingly flat.
Hm! Very nice to see.

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
User avatar
AndrewP
Posts: 368
Joined: 30 Aug 2021
Location: South Africa

Re: Decoded PHI2

Post by AndrewP »

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.
I had a bit of learning moment thinking about this.

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.
User avatar
BigEd
Posts: 11463
Joined: 11 Dec 2008
Location: England
Contact:

Re: Decoded PHI2

Post by BigEd »

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.
Paganini
Posts: 516
Joined: 18 Mar 2022

Re: Decoded PHI2

Post by Paganini »

I don't quite understand the point of this arrangement, so I made a truth table.

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
<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. :lol:

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
sburrow
Posts: 833
Joined: 09 Oct 2021
Location: Texas

Re: Decoded PHI2

Post by sburrow »

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. :lol:

So, I redid the truth table, and now I think it's correct. Phi2 seems even less useful now. What's this for?
Attached is my modified timing chart. It does not use the original setup, instead I use a 74HC74 to flip-flop PHI2 based on /LATCH and /TRANS.

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
TimingChart.png (7.99 KiB) Viewed 4996 times
Paganini
Posts: 516
Joined: 18 Mar 2022

Re: Decoded PHI2

Post by Paganini »

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.
sburrow wrote:
Paganini wrote:
It's been a while since you've been online Paganini, glad to see you back!
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. :D
"The key is not to let the hardware sense any fear." - Radical Brad
Post Reply