home .. forth .. misc mail list archive ..

Re: F21 Network Coprocessor


Hi Dave,

Dave Lowry wrote:
> 
> There's a detail about the network coprocessor that confuses me.
> If I understand what Jeff wrote on the UT website, there is a counter
> that shifts bits in whenever it reaches zero.  The counter is reset
> to its start value when it reaches zero and when there's a transition
> on the input.  

The timing of the analog and serial/network coprocessors are
determined by the input clock and a count down value in an
11 bit register, values 1-2047 are valid.  The counter is reset
whenever it reaches zero.  It is decremented on each external
clock.  So there are two frequencies, Ci (clock in), and a
sample rate which is Ci/n.  If n=1 then Ci is the sample
rate, otherwise it is some fraction of Ci.

> What confuses me is it seems that sometimes you'd
> want the counter to count down from one full bit time, and sometimes
> count down from one half bit time.  

The unit was designed to send and recieve data packets and provide
a mechanism for remote CPU interupts.  The idea is that it does this
with little CPU intervention and no more memory bandwidth than
needed for DMA of messages that go into or out of a node's memory.

The unit was not designed to allow one to alter the bit rate
halfway through a bit cell sample time.  It could be done
however.  There is a bit in the parallel port that shows the
state of Ci, so the CPU can monitor the external input
clock and bit bang on the network port totally under CPU
control.  It could not run as fast as when the network
coprocessor hardware does the data clocking and routing
in hardware because it would require a bunch of CPU memory
accesses to transfer a bit.

"one half bit time" means halfing the count down register
value to half the delay and double the bit rate.  The CPU
can adjust the bit rate over a range of about 2000 for a
given Ci.  However the idea of the CPU trying to reconfigure
the network processor on every bit is pretty strange.  It
would problably be easier to use the CPU to do things 
that the network coprocessor was not designed to do,
like encodeing the transmitted and received bit patterns
in a different way.

> After a transition, you'd want to
> sample the input 1/2 bit time later, then at 1 bit time intervals
> from then on, until the next transition.

The F21 uses a self-synchonized scheme that is compatible with
fiber-channel encoding.  It requires that there be bit transitions
in at least every five bits in any transmitted pattern.  This
means a table lookup or other computation is needed to process
data transmitted over the network.

It sounds like you want a different encoding scheme, one
that is clocked in a different way.  I think you can do it
up to a few megabits per second on any pport pin but it
might get tricky if you have the cpu monitoring Ci and
trying to reconfigure the coprocessor on bit timings.

> --------!________!________!________!--------!________
>             ^        ^        ^        ^        ^
>         R   r        r        r    R   r    R   r
> 
> ^ = sample bit
> R = counter reset from transition
> r = counter reset from reaching zero
> 
> Could someone educate me?  Thanks.
> 
> -Dave

I don't know if that answers your question or not.
Perhaps these diagrams will help.

ci |---|   |---|   |---|   |---|   |---|     input clock on Ci
   |   |---|   |---|   |---|   |---|

n1 |-------|   0   |-------|   0   |---  /1  1 input clock per
   |   1   |-------|   1   |-------|         encoded bit

n2 |---------------|       0       |---  /2  2 input clocks per
   |       1       |---------------|         encoded bit

n3 |------------------------|            /3  3 input clocks
   |           1            |----------   

n4 |-------------------------------|     /4  4 input clocks
   |               1               |---

n5 |-----------------------------------| /5  5 input clocks
   |                    1              |

n6 |-----------------------------------> /n  5 < n < 2048
   |                           1

Changing the configuration register on individual bits
to adjust the timing on individual bits is a pretty odd
idea as far as I can see.  I would guess the CPU might
just as easily do the job if it isn't what the serial/
network coprocessor hardware is going to do by itself.

Of course if you are trying to encode a signal in a
different way you may find that you can simply encode and
decode some bits twice in software to make some of the
bit times twice as large as some of the other bit times....

Jeff Fox