| ??? 10/06/10 01:36 Read: times |
#178934 - Read up on phase detectors and separate from lgic detect Responding to: ???'s previous message |
The XOR thing has only (O.N.L.Y.) meaning after the chip and chip pins have been identified. And only as an optional step to measure propagation delays.
Do you get it? Propagation delays? Not detecting inputs. Not detecting outputs. Not detecting schmitt-trigger. Not detecting open collector. Not detecting tristate. Just measuring the delay from an already known input to an already known output. If you wouldn't use an XOR to detect a tristate output, why are you so busy assuming anyone else in this thread have suggested that. Wouldn't it be better, if something sounds too wrong, to take one step back and recheck your facts. The normal case is that you have lost the thread many posts earlier. So recover the path instead of pushing further and further into no-mans land. I reverse the question. Have you really tried to play with an XOR gate and change the delay of one of the signals? I really do think you did not do the googling I suggested. I really do not think you have ever looked at an XOR discriminator. They have been used for a very long time to measure delays with very good result. My example mentioned 0 to 500ns measurement range with 1MHz square wave. Are you not aware then that a 10ns change in the delay of one of the signals do change the output quotient with 10/500 or 2% - something that is possible to measure. The rise and fall times of the signals, and the voltage levels where the XOR inputs reacts does affect the result by a fixed error. The capacitances in the inputs and traces does affect the result by a fixed error. But even with these errors, you can still get very nice measurement results. Iol and Ioh? Yes, they affect how large capacitance I can accept. But measuring them with an XOR? Have you seen me write that somewhere? Please post a quote and from what post. Richard said:
I don't see how that's relevant either, since the PC isn't capable of making observations at a rate high enough to detect differences in propagation delay, rise time, etc. If I had a PC capable of measuring the time delay difference between two signals with 10ns or better, I would not need any XOR or anything else. But why are you spending time arguing something you do not now anything about. Wouldn't it be so many times better if you did google around and came back when you knew what a XOR phase detector is. When you know that it does not produce a pulse for a PC to measure the time of. An XOR phase detector uses an XOR to produce a pulse with varying ratio between 0 and 100% (but best when you don't need to push too close to 0 or 100%). These pulses are sent to a low-pass filter producing a voltage. So it is a delay-to-voltage converter. And you let your ADC measure this voltage to figure out the percentage of the range. Convert the reading into time based on the measurement range, i.e. based on the frequency of the square wave. Alternaively - but not applicable here - it's a circuit for measuring the frequency difference between two signals - i.e. basically a kind of multiplier. You get a trangle-wave output frequency proportional to the frequence difference of two signals. Had you googled using the terms I gave you, you wouldn't have made these random posts based on radom assumptions about what the XOR gate is used for. Richard said:
I think you should provide a schematic and at least a hint as to how you 'd make such measurements with the aid of a PC and no other costly hardware. What you are saying is: I do refuse to google - give me schematics and source code now. Need it fast. Hurry. But why can't you please just read up a bit. http://en.wikipedia.org/wiki/Phase_detector Then google around a bit and read some random links you find. The concept isn't advanced. As a matter of fact, it is covered in some of the earlier electronics courses. Richard said:
I don't see how you can do any of this with a PC and some number of XOR's. Which is because you don't know what an XOR phase detector is. No PC needs to be involved. But an ADC and XOR and a low-pass filter. Richard said:
Just how does a phase-detector fit into this? You would now after spending that little time with Google. It really is required to check up on the phase detector before continuing any discussion. Richard said:
Just how do you go about detecting a floating output? By trivial electronics way before trying to bother with any gate delays. 100kohm pull-up. Measure if signal is high or low. 100kohm pull-down. Measure if signal is high or low. If both pull-up and pull-down wins, then the signal is definitely not driven with any force. So it's an input or an output in tri-state. Potentially an open-collector output or an unused pin. Playing through the rule set, wiggling signals with weak pull-up or pull-down should manage to activate the output-enable signal in which case that tirstated output isn't tristated anymore. Just a question of making a good set of test patterns to figure out what you have. Richard said:
Well, I don't agree about that, since you wouldn't have to "walk" through 2^n input patterns. What you'd have to do is to "walk through one input vector for each known device in the repertoire. If it passes on one gate, then it's to be checked on all the gates. If it fails, that's not what it is. When you run out of test vectors, you have a junk part. You can either open it up and read what it says on the die, or you can toss it out. Exactly. No need to do a stupid tester with stupid 2^n rules. Having a totally random chip, a tester could do 2^n tests and then do karnaugh map processing to describe the logic. But such a concept would fail as soon as a there are memory elements inside the chip. Which is the reason why a tester is only meaningful to try to identify chips in the rule database. And some chips can't even be added to the rule database because the amount of internal state is so huge that any number of tests will still fail to deduce what it is. Richard said:
Since it was never unusual for one vendor to buy dice from a competitor, it's hardly important to base any decisions on what manufacturer's brand on the device says. On one hand - not an open issue since no one have claimed that. On the other hand - some chips do matter. Especially things like bilateral switches or similar. Sending analog signals through them means bandwidth, on-resistance etc also matters. Richard said:
That decision tree is an interesting concept, though I've no idea how you'd make such decisions. As far as the vector table database is concerned, I'd order them by pin count, since, with unknown parts, that's all we know. I'd appreciate a demonstration of how you'd make the decision based on what you get from 74xx365 and a 74xx161. For a real database - maybe hundreds of chips - I would use a PC to build an optimized tree. Starting by setting a probability that the different chips may be tested. Obviously figuring that 7400, 7404, ... are more probable than some of the tree or four-digit chips. Then let the PC scan all rules to decide what rules will quickly prune as large part of the tree as possible. But let's just make a trivial tree - no attemt at optimizing it by having "important" tests high up in the tree. There can be a lot of different knowledge (or lack of knowledge) about a pin of a tested chip. Such as: - is input - is not input - is not connected - unknonw But at the same time: - is output - is not output - is not connected - unknown And of course: - is totem output - is tristated output - is open-collector output - has unknown drive capability A chip like '245 have dual-direction pins - input and output sharing same pin. Anyway. '161: - always outputs are: 11, 12, 13, 14, 15. No tristate or oc or similar. - if any of the above pins are not drive low or high then it's not a '161. '163 - same as 163 because the difference is synchronous or asynchronous reset. '365 - pins 3, 5, 7, 9, 11, 13 are outputs with tristate. It is basically ridiculous to build a tree for so few chips but here is an example: Start with tree containing ('161, '163, '365): Test pin 12 as output. - If pin12 activelly driven -> go subtree with ('161 and '163) - If pin12 not driven -> go subtree with ('365) Subtree with ('161 and '163) All logic is identical between then besides reset, so synchronous/asynchronous reset is the critial test to perform. - Keep /MR high - Keep CP low - set D0..D3 high - Set /PE low - Set CP high - Set CP low - Verify Q0..Q3 high - if not fail. - Verify TC high - if not fail. - Set /MR low - If Q0 low -> go subtree with ('161) (was asynchronous reset, so got reset without caring about clock) - If Q1 high -> go subtree with ('163) (was synchronous reset, so no reset because no rising clock flank) Subtree with ('161) - Any logic table test fails -> fail (unkown or broken chip) - All logic table tests matches -> decide if advanced testing (input logic levels, output drive, propagation delay, ...) Subtree with ('163) - Any logic table test fails -> fail (unkown or broken chip) - All logic table tests matches -> decide if advanced testing (input logic levels, output drive, propagation delay, ...) Subtree with ('365) - Any logic table test fails -> fail (unknown or broken chip) - All logic table tests matches -> decides if advanced testing (input logic levels, output drive, propagation delay, ...) The separating tests for a '161 or '163 is quite long since the chip has internal memory. But most tests when pruning the possibilities can be formed using very simple tests. Measuring delays is not too hard for most chips. But it's quite hard for a '161 and '163 since there are no direct signal path from in to out that doesn't involve aynchronous pulse on the CP signal. But if really needed, it can be done. - A 2MHz signal is sent to CP. - A signal with half that frequency and delayed > one setup time is sent to Dx and to one input of XOR gate. - The output of Qx is sent to other input for XOR gate. - The signal /MR can then be held high to let Dx be copied to Qx and the propagation delay measured. But earlier posts have already covered that a chip tester/detector may fail for some chips because the complexity of adding special hardware for every possible chip is too high. It is quite easy to write a program that checks all rules and sees if there exists situatins where no rule can separate two chips. If so, the datasheet will tell if it is possible to add one more rule or if the end of the line is that the tester will say: may be A or B. Anyway - it's hard to try to describe this type of optimizations but the required software really isn't that complex. |
