We have an NE64 connected to an FPGA for data transfer. We transfer 16-bit words from the FPGA to the NE64 via PORTAB, using our own handshaking scheme implemented in software on PORTE. When the handshaking completes, the FPGA just sends 16-bit word after word, every X clock cycles. The FPGA uses the ECLK from the NE64 for the transfer. The NE64 is in Normal Single Chip mode with NECLK = 0.
The code on the NE64 is the following (minus the handshaking):
asm
{
SEI // Disable interrupts
LDX PointerTo16bitWideBuffer // Load buffer address
LDD _PORTAB // Load 16-bit word to register
STD 0,X // Copy register to buffer
LDD _PORTAB // etc...
STD 2,X
LDD _PORTAB
STD 4,X
...
}
Given that it's just a bunch of LDD and STD instructions, I'd expect each of these instruction pairs to take a FIXED number of clock cycles. But this doesn't seem to be the case. If for example the FPGA sends (0, 1, 2, 3, 4, 5, 6, 7, etc.) leaving each unchanged for three clock cycles, the NE64 "stores" this as (0, 1, 2, 3, 4, 5, 7, etc.), with 6 missing.
If I repeat the same procedure with the FPGA leaving the data unchanged for 1, 2, 3, 4, 5, 6, 7 clock cycles, I always run into missing or duplicated codes. No constant number of cycle transfer system works!
A hack that I made which works keeps each code active for the following number of clock cycles:
3, 6, 2, 6, 6, 6, 6 Aaaaah!
So my question is: what is going on? Is the NE64 really taking a variable number of clock cycles to execute the LDD and STD pairs?
I've tried playing with the bus cycle stretching settings without success (they shouldn't do anything anyway).
Thanks!
Jeff
The code on the NE64 is the following (minus the handshaking):
asm
{
SEI // Disable interrupts
LDX PointerTo16bitWideBuffer // Load buffer address
LDD _PORTAB // Load 16-bit word to register
STD 0,X // Copy register to buffer
LDD _PORTAB // etc...
STD 2,X
LDD _PORTAB
STD 4,X
...
}
Given that it's just a bunch of LDD and STD instructions, I'd expect each of these instruction pairs to take a FIXED number of clock cycles. But this doesn't seem to be the case. If for example the FPGA sends (0, 1, 2, 3, 4, 5, 6, 7, etc.) leaving each unchanged for three clock cycles, the NE64 "stores" this as (0, 1, 2, 3, 4, 5, 7, etc.), with 6 missing.
If I repeat the same procedure with the FPGA leaving the data unchanged for 1, 2, 3, 4, 5, 6, 7 clock cycles, I always run into missing or duplicated codes. No constant number of cycle transfer system works!
A hack that I made which works keeps each code active for the following number of clock cycles:
3, 6, 2, 6, 6, 6, 6 Aaaaah!
So my question is: what is going on? Is the NE64 really taking a variable number of clock cycles to execute the LDD and STD pairs?
I've tried playing with the bus cycle stretching settings without success (they shouldn't do anything anyway).
Thanks!
Jeff
Given that it's just a bunch of LDD and STD instructions, I'd expect each of these instruction pairs to take a FIXED number of clock cycles. But this doesn't seem to be the case. If for example the FPGA sends (0, 1, 2, 3, 4, 5, 6, 7, etc.) leaving each unchanged for three clock cycles, the NE64 "stores" this as (0, 1, 2, 3, 4, 5, 7, etc.), with 6 missing.
Do you expect each LDD-STD pair taking fixed number of cycles, or each LDD and each STD taking the same fixed number of cycles? In your code LDD ext takes 3 cycles, STD idx 2 cycles. So each LDD-STD pair - 5 cycles. I don't understand how, leaving the FPGA output unchanged for just 3 cycles, you are receiving 6 good numbers from FPGA?
BTW, in your code, SEI instruction is way to late to have reliable protocol. It should be moved somewhere into the middle of handshaking procedure.
I see variable number of cycles only here:
LDX PointerTo16bitWideBuffer // Load buffer address
LDX of misalignedd pointer variable in FLASH will take 1 cycle more than LDX of pointer variable in internal RAM or word aligned var in FLASH. But that's just one cycle.
Thanks for the quick reply kef.
I was expecting every LDD-STD pair to take a fixed number of cycles. I've done a lot of debugging, and this is what I've found:
The first nine LDD-STD pairs take 5 clock cycles, and then all of those thereafter take 6 clock cycles. If I adjust my FPGA to change the data according to this standard, everything works fine.
Could it be that the STD #,X instructions take an extra cycle if the # is greater than a certain value? Different addressing mode?
Would love to know why this occurs, but at least now I can write less-hacked code for my FPGA.
Thanks again,
Jeff
I was expecting every LDD-STD pair to take a fixed number of cycles. I've done a lot of debugging, and this is what I've found:
The first nine LDD-STD pairs take 5 clock cycles, and then all of those thereafter take 6 clock cycles. If I adjust my FPGA to change the data according to this standard, everything works fine.
Could it be that the STD #,X instructions take an extra cycle if the # is greater than a certain value? Different addressing mode?
Would love to know why this occurs, but at least now I can write less-hacked code for my FPGA.
Thanks again,
Jeff
Thanks for the code kef. I tested it out and it does indeed execute at a constant 5 cycles per pair. It also makes my VHDL code much less awkward.
kef wrote:You could rewrite your code using postincrement indexed addressing mode like thisLDD _PORTAB // Load 16-bit word to register
STD 2,X+ // Copy register to buffer AND ADVANCE POINTER to the buffer in register X
LDD _PORTAB // etc...
STD 2,X+
LDD _PORTAB
STD 2,X+
...postincrement indexed STD takes the same like STD with 5bit offset. So timing of one pair should be the same 5 cycles.
I actually did have a good look through the manual last year when I wrote most of the (hacked) code, but I have to admit that I've never really warmed to this architecture. I work in parallel with all sorts of PICs and, well, it requires a lot less effort to write good assembly code for them.
For instance, I'm disappointed that on the instruction description page of the CPU manual, there's no indication of execution time relative to addressing mode (unless it is very cryptically given?).
But, I'm very happy to have better learned this architecture thanks again to this forum. Thanks again guys!
Jeff
