3
\$\begingroup\$

I have attached a circuit which includes three counters which are the IC 74163. This specific IC is a 4 bit counter. I want to make a bigger counter which will be able to count 752 steps with an input frequency of 20 MHz. The fact is that my counter does not work at all and I would like to know what do I make a wrong. Is there something that I do not see? In this case the preset is 4095 - 1 - 752 (steps) = 110100001110. Unfortunately the system does not count correctly and I am sure that there something wrong with my design. Could please someone give me advice?

The input signal is 26.6 kHz and the frequency of the system is 20 MHz. Also the reason for doing something like that is because I am trying to use an external PLL in cooperation with my FPGA design and the circuit below is used to make the division which is needed fout = N * fin and theoretically I want to make a division of 752 so I need 752 steps. The system does not work well but with another preset value it worked. Despite the fact that I get the 20 MHz I need digitally I want to understand completely why the counter that I have designed does not work properly.

The reason for which I do not get a bigger counter is that I have to simulate the system using parts available from my FPGA's software library. Is there a possibility of overflow or something like that, which I cannot see?

Schematic

\$\endgroup\$
  • 1
    \$\begingroup\$ Have you started by doing sims on ONE counter, and just getting it to upcount, not worrying about the start count and stop count? In general, simplifying your problems is the right way to debug, and it helps to simplify your question before asking it. \$\endgroup\$ – Scott Seidman Jun 6 '14 at 13:13
  • \$\begingroup\$ Hi!I have tested the System and the Counter sends the pulses but it does not cooperate well with the pll. And that is quite strange... \$\endgroup\$ – George.K Jun 10 '14 at 6:40
2
\$\begingroup\$

Doh! Facepalm time. I completely missed the fact that your circuit is an FPGA, so ALL or my timing analysis was wrong. Well, OK. Scratch the timing. What remains is correct, so here is the new, improved, and maybe to the point version.

The simplest answer is that this is not going to work as you think. The first problem is that your preset is wrong. Instead of calculating 4095 - 1 - 752, you should have calculated 4095 + 1 - 752. You had the right idea (essentially recognizing that 0 is a state), but you got the sign wrong. That is, you were trying to calculate 4095 - (752 - 1).

Another problem is that you are using the last ripple carry to reset your counters. This is wrong on 2 counts. First, what you want to do is to load the presets which you calculated. Second, the counter will reset anyways, since the next count after FFF is 000. The most elegant way to load your preset is to change your preset to 1000 1000 1011, and use the QC output to drive your preset pins. Essentially you are presetting your counter to one count more than previously, then letting the rollover from FFF to 000 provide the active low signal you need to preset the counters. This eliminates the inverter you used.

In the absence of activity on the load lines, what will happen with this circuit is that it will produce on phase_three a 50 nsec pulse at a 4.88 KHz (20 MHz / 4096) frequency. That this is apparently not the case, since you say you're getting good outputs for a different preload, seems clear. If you are not sending pulses on the preload line, I have no faint idea why the preload setting would make a difference.

Also, be aware that RCOs are not clean. They will show spikes at intermediate counts. This is true for discrete logic, and in some respects even more so for FPGA logic.

Finally, a note of caution, if you are going to use an external preload as shown, you will occasionally get weird results. This is caused by the preset releasing too close to the rising clock edge, so that some counters will (occasianally) respond in a flakey manner. The term for this is metastability, and if you are going to synchronise any sort of clocked logic to external events, you need to do a little studying.

\$\endgroup\$
  • \$\begingroup\$ Hi! Thanks a lot for your answer. I will try to apply some changes regarding everything you have already written to me. Metastability is also something that i will have to work with, in order to understand it and then solve the Problems that metastability causes. \$\endgroup\$ – George.K Jun 10 '14 at 7:16
0
\$\begingroup\$

Since the counters want to be PRESET to d0fH before the start of a count, their CLEARs should all be wired high and not invoked by 1111 of the hex MSD.

Also, since the count starts at 3343 and ends 752 clocks later with all the counters at 1111, that's when all the RCOs will be hot, so they should be NANDed and used to inhibit the first counter by pulling ENT and ENP low, which will stop all the counters until their LOADs are pulled low and then allowed to go high again, starting a new cycle

This seems to work: enter image description here

\$\endgroup\$
  • \$\begingroup\$ The problem is, the RC of the top counter is already the anding of the other two, plus its internal count. So this is functionally identical to the original circuit. \$\endgroup\$ – WhatRoughBeast Jun 6 '14 at 14:01
  • \$\begingroup\$ No, the ripple carry only goes true when the local count gets to 1111 and it stays there for one clock cycle. That way, when a lower-order counter gets to its maximum count it enables the next higher counter in the chain and when the clock next goes positive it increments that counter and rolls the lower order from 1111 over to 0000. Pretty much the same way we count when 09 goes to 10 when we count past 9. \$\endgroup\$ – EM Fields Jun 6 '14 at 14:19
  • \$\begingroup\$ First, I was wrong about the equivalence claim. However, the circuit will not work as you think. The ripple carry goes true when the local counter reaches 1111 AND the CET input is high. So in your circuit, because you feed the NAND back to the CET, you will get a race condition at 1111 1111 1111. When U1 TC goes low, the NAND output will go high, TC will go high, NAND goes low, etc. Not to mention the effects on the TCs of U2 and U3. Your NAND should only drive U1 CEP. \$\endgroup\$ – WhatRoughBeast Jun 6 '14 at 19:48
  • \$\begingroup\$ Since counting will be disabled unless CET and CEP are both high, the race condition won't be cured by driving only CEP with CET wired high. Interestingly, the low out of U4 wont ripple through the counter chain quickly enough to keep U1 and maybe U2 from responding to the next clock, so at least one of them will roll over to 0001 when that clock edge comes along. That'll force the output of U4 high, allowing all of the counters to run, but they'll never all get to 1111 at the same time again unless PEbar is asserted, so U4 will only output that single pulse once per load cycle. \$\endgroup\$ – EM Fields Jun 7 '14 at 3:11
  • \$\begingroup\$ Huh? Sure it will be cured. If U1 is at 1111, and CET is wired high, TC will be high regardless of the state of CEP. So if U4 only drives CEP, there will be no race. That said, I did make an error. Instead of U4 driving U1 CEP, it should drive all 3 CEPs, with U1 CET wired high. Then, at FFF, all 3 TCs will be high, but with each CEP held low, none of the counters will advance, and the counters will hold at FFF until reset or loaded. \$\endgroup\$ – WhatRoughBeast Jun 7 '14 at 4:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.