Odd Counter Behaviour
pjv
Posts: 1,903
Hi Chip;
I wonder if you can check the logic in the counters for me.
I'm using counterA in duty cycle mode (%00110), so I'm generating 12.5 nSec pulses out on·its pinA bit every 100 nSec.
I'm using counterB in the same cog in the LOGIC AND mode (%11000) using the pulse from counterA (above) into pinB, and a steady high level into pinA.
As counterA pulses, I get double the number of counts input into pinB registering in the PHASB accumulator.
When I reverse the inputs, that is the steady high level into pinB, and the 12.5 nSec pulses into pinA, the count in the accumulator is correct.
Furthermore, in the case of·the errant count set-up, the counted number will actually vary somewhat (not linearly) with the phase of the 12.5 nSec pulse relative to an instruction epoch.
This phasing adjustment·appears to have no effect when the connection is "proper".
Since the logic function of this block is simply an AND, reversing the pins ought not have any effect.
Any comments??
Cheers,
Peter (pjv)
·
I wonder if you can check the logic in the counters for me.
I'm using counterA in duty cycle mode (%00110), so I'm generating 12.5 nSec pulses out on·its pinA bit every 100 nSec.
I'm using counterB in the same cog in the LOGIC AND mode (%11000) using the pulse from counterA (above) into pinB, and a steady high level into pinA.
As counterA pulses, I get double the number of counts input into pinB registering in the PHASB accumulator.
When I reverse the inputs, that is the steady high level into pinB, and the 12.5 nSec pulses into pinA, the count in the accumulator is correct.
Furthermore, in the case of·the errant count set-up, the counted number will actually vary somewhat (not linearly) with the phase of the 12.5 nSec pulse relative to an instruction epoch.
This phasing adjustment·appears to have no effect when the connection is "proper".
Since the logic function of this block is simply an AND, reversing the pins ought not have any effect.
Any comments??
Cheers,
Peter (pjv)
·
Comments
We had such a problem here, and it turned out that there was extra junk attached to the I/O pin that was ringing with each transition (a peizo speaker, in our case). There might be a race condition around the I/O pins, too. See if it goes away at 40 or 20 MHz. Also, try it on different COGs which are different distances away from the I/O pins. Also, try it on different I/Os. When doing this fast stuff, I noticed that it makes a huge difference to be CLOSE to the I/O pin, and preferably using an LQFP part, as opposed to a PDIP.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Thanks, I'll keep messing with it as you appear not to have an answer regarding differences in logic. All I have connected on is my scope probes and an inch or so of wire, so pretty short.
Good suggestion to try the different frequencies..... that had not yet occurred to me.
The race condition possibility scares me a little........ shades of the old SX consecutive port accesses reading back un-settled data!
Thanks,
Peter (pjv)
Very interesting........
Slowing the clock down from 80 MHz to 40 (pllx8 vs pllx16) makes the problem disappear, but of course this won't serve my purpose.
Also, back at 80 MHz, putting a capacitor on the 12.5 nSec pulsing line also makes the problem go away. In fact I can totally obliterate the pulse with a large (0.1) cap, and it still works !! Clearly the signal is being "read" by the logic circuit before the output driver.
Nifty..... have to experiment using the "B" port bits.......... Hmmmmmmmmm.....
Cheers,
Peter (pjv)
All reads are from the input buffer, which is after the output buffer. To see an echoed signal, you have to go out the output and into the input. In other words, the actual pin·must transition for·any change to be seen. There are certainly a few nanoseconds lost during all this through the internal combinatorial pin logic, output buffer, and input buffer, so a 12.5ns signal is cutting it very close.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
The only difference that exists in logic is the number of combiner gates (like ORs) that a pin output (from a COG)·must travel through before getting to the actual I/O pad. For pins 0 to 15, output signals propogate from COG7 through COG0, then to the I/O pad (pin). For pins 16 to 31, signals propogate from COG0 through COG7, and then to the pin. Inputs, on the other hand,·are received simultaneously by every COG.
Let's say you're using pins 8 and 9. COG0 is closest to them logic-wise, and physically, too. COG7 is farthest from them, so that 7 subsequent combiners handle COG7's control signals for pins 8 and 9. They must travel through COG6, COG5, COG4, etc., all the way through COG0. These combiners are very optimized high-speed OR gates which complement the signal as it propogates towards the I/O pins, insuring equal high-low and low-high prop times. Their latency is probably about 150ps each. 7 of those only add up to ~1ns. The I/O pad driver takes maybe 1.5ns to get its signal out, since it must be amped up quite a bit to drive the final PMOS and NMOS transistors. Coming back in through the input buffer takes maybe 1ns, too. So, you've got potentially ~3.5ns of echo time. Oh, maybe add another nanosecond for internal COG propogation delays. ~4.5ns. Things had better to able to slew outside the chip very quickly, too, to make all this work in 12.5ns.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Thanks for the info, I think I know what it means. Especially the sequential issue makes it all more interesting. So now I will go and mess with using different I/O pins, further and closer as well as other cogs, to see what the impact of all of that is.
Just at this moment, I'm receiving 10 Mb/s Manchester rock-solid, and of course 20 Mb/s UART. I seem to have at least a plus/minus 1 clock phase margin in my sample time before errors occur.
Real sweet.
By the way, I just might have figured a way to crank this up to 160 Mb/s using synced multiple cogs, and if I can the video generator to co-operate. Although this might be a stretch...... we'll see at some future date.
I'm havin' the time of my life !!!!!
Thanks for your ever-available assistance.
Cheers,
Peter (pjv)
A Somewhat confused KK
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
I only know the name myself. Hope this helps.
http://www.maxim-ic.com/appnotes.cfm/appnote_number/3435
-Parsko
In communication it is frequently desirable to have evenly distributed high and low levels on the "data" line.
The reasons for this can be manyfold, but often it is an issue for coupling transformers that don't like to "see" long periods of either high or low, as that starts to look like D.C., and hence upsets the neutral magnetic balance in their cores. Depending on the duration of these continuous high or low periods, the transformers can actually saturate, and hence distort the signal that will later pass through them and cause data errors.
A similar situation can be found in simple R.F. receivers where the level of the data slicer is parked at some point, and an unbalanced data stream arriving will "average" itself around the data slices depending again on the duration of contiguous one or zero bits.
So a balanced code was devised which for every bit has a high period and an equal low period, hence a net zero as far as transformers and data slicers are concerned. The information contained in the code as to whether a "one" or a "zero" is represented is determined by the sequence of these levels. That is, for example, a low followed by a high would be called a zero, and a high followed by a low would be a one. The further benefit of this is that by definition, there is a clock edge, either rising or falling, in every bit, and one can extract that event to assist in tracking the data sampler clock.
This coding mechanism of a hi/low or a low/high for each bit is called Manchester coding. Among many other applications, it is also used in 10 Mb/s Ethernet, and with some further modifications in 100 Mb/s Ethernet.
For these benefits, one sacrifices a factor of two in speed as Manchester coding needs to send a high and a low for every bit.
Although I have not tried, perhaps there is a better explanation to be found through "wikipedia" or Google.
Cheers,
Peter (pjv)
Post Edited (pjv) : 4/13/2006 4:25:53 PM GMT
Cheers,
Chris
Parsko:
Thanks for the link, I did read the page, and it did help.
Peter:
Your reply made it very clear, and understandable.
Again, thanks to both.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
I did reply, but I didn't know why or the details of how. I had read about it before (manchester stuff) but didn't quite get it. Peter did a perfect job of "laymen"izing all the nerd stuff. I'm a mech. eng, so I don't quite grasp all the EE stuff very quickly or thoroughly.
-Parsko
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·