A big clue to the problem is the-right-instruction-is-executing vs. it's-reporting-wrong-results. The prior is a hubexec problem while the latter is a hub-phase problem. At least, this all seems to revolve around COGID.
I'm using the CVA9 yes but I think if you had a gun loaded you might shoot me. My IDLE loop was supposed to be quite idle but because I fetched a long vector instead of a word vector it was picking up a counter byte in the msb. Oh... the humanity!
idlp
word _1,_COGID,TASK,_3,PLUS,CPLUSST ' INCREMENT task+3 to indicate Tachyon running
word _8,ms ' do nothing for a bit - saves power
word _COGID,TASK,WFETCH ' fetch cog's task variable (SHOULD ONLY BE 16-bits at present - bug had FETCH)
word QDUP,_UNTIL+13 ' until it is non-zero
word ACALL ' Execute but ignore if task address is only 8-bits
word _0,_COGID,TASK,STORE ' clear run address only if it has returned back to idle
word IDLE+ex
No problem, Peter. I think this uncovered a latent bug, anyway, in the hub instructions, where a hubexec fetch could smear hub interaction on things like COGID.
I'm recompiling now and I'll get a new version out soon.
I think this uncovered a latent bug, anyway, in the hub instructions, where a hubexec fetch could smear hub interaction on things like COGID.
This kind of statement makes me nervous. I read it as "there may or may not have been a bug that I may or may not have fixed."
Well, I remember thinking that the first hub slot after "get" should be used for hub operations, and my code comments indicated that, as well. The only thing was, the code wasn't actually doing that, but now it is.
Why do cogs need to get their ID from the hub? Yes, cogid needs to wait for the hub for flags and such, but for the actual ID part, why don't they each know their own ID?
Why do cogs need to get their ID from the hub? Yes, cogid needs to wait for the hub for flags and such, but for the actual ID part, why don't they each know their own ID?
This started out being a carry-over from Prop1, and it could have been-hardwired, but now COGID is also used to check other cogs for activity, so the hub is needed, again.
I think this uncovered a latent bug, anyway, in the hub instructions, where a hubexec fetch could smear hub interaction on things like COGID.
This kind of statement makes me nervous. I read it as "there may or may not have been a bug that I may or may not have fixed."
Well, I remember thinking that the first hub slot after "get" should be used for hub operations, and my code comments indicated that, as well. The only thing was, the code wasn't actually doing that, but now it is.
New v30 at the top of this thread. Currently, there are 8-cog images for BeMicro-A9 and Prop123-A9.
This is feeling very final and I have a calm, settled feeling about it.
Please see if this works okay. I'll be adding other FPGA images over the next day or two.
Thanks!
Great! I'll try not to come up with any "bugs". I've got a few different boards and I might leave a CVA9 running FTP and Telnet for any who'd like to check it out. I do need to write an updated interactive inline assembler to help test the instruction set.
btw, what did you change for the "latent hubexec bug"?
[...btw, what did you change for the "latent hubexec bug"?
Hubexec will refill the instruction buffer (FIFO) when it's less than full and the needed RAM slice comes around. This will pause an instruction before it even gets to the "get" cycle, which is followed by the "go" cycle for 2-clock instructions. I had to inhibit hub operations during that pre-execution time, when it occurs. Otherwise, the cog will be issuing a hub command before the instruction actually starts executing, causing phase errors when it finally releases from the FIFO filling.
My prior comment wasn't quite right about waiting until after "get" - we just need to wait until "get" before responding to the signal that it's our cog's turn to issue a hub command. I think I've got it nailed down tightly now, so we won't have any strange hiccups.
You might have been experiencing this problem, along with your software bug. From the way the Verilog code WAS, this was definitely a pitfall. It just took the circumstance of a hub operation instruction to be coincident with the FIFO stalling execution during refilling. Now that I've changed the Verilog code, that can't happen. It's weird that my code comments recognized this potential and implied it was handled, but it wasn't.
Cool, I have V30 loaded and have it running Tachyon at tachyonforth.com with FTP (ftp://tachyonforth.com) and Telnet on port 10001. While it may sometimes be temporarily unavailable for a few minutes it will nonetheless be available otherwise. In the meantime I will put together a crash-resistant version that can reload itself on one of the other boards. (says V29 but it is the latest V30)
Parallax Propeller II .:.:--TAQOZ--:.:. V10171218.0000 V29 BOOT
--------------------------------------------------------------------------------
CODE SPACE @ $00.61EC for 20,972
NAME SPACE @ $00.B34E for 10,079
DATA SPACE @ $00.E33A for 296
FREE SPACE = 20,834
MODULES LOADED:
$5424: EASYNET.fth WIZNET NETWORK SERVERS 160707.1500
$4B1C: W5500.fth WIZNET W5500 driver for TF2 171217.0000
$3A28: EASYFILE.fth P2 EASYFILE FAT32 SD FILE SYSTEM - 171212.0000
$1DC0: EXTEND.fth TACHYON FORTH EXTENSIONS for the P2 - 171212-0000
Mon, 01 Jan 2001 15:05:59 UTC
--------------------------------------------------------------------------------
Mounted C: NO NAME 7803.AA00-F84E.1690 [ SDC ] FAT32 4,119MB (32kB/cluster)
*** Tachyon Forth EASYNET Network Servers and EASYFILE File Server ***
... ready!
NETWORK STATUS:
LINK *UP*
HARDWARE: P2DEV using WIZnet W5500 V4
SRC IP 192.168.000.150
MASK 255.255.255.000
GATEWAY 192.168.000.001
MAC 02.FF.E0.76.33.5F.
SKT HH:MM:SS MODE PORT DEST TXRD TXWR RXRD RXWR RXSZ IR STATUS IP ADDR
#1 15:05:59 TCP 21 60526 . . . . . 00 14 LISTEN
#2 15:05:59 TCP . . . . . 00 14 LISTEN
#3 15:05:59 TCP 10001 56278 . . . . . 00 14 LISTEN
#4 15:05:59 TCP 81 . . . . . 00 14 LISTEN
* WEB, FTP, and TELNET servers running *
----------------------------------------------------------------
TAQOZ#
Peter, I think that errant COGID reporting was not purely related to your software bug, but was really happening because of a hardware bug. Is there any way that you can test to see if it behaves differently now? It might mean running your buggy app on v30 and seeing if that COGID failure is still there, or maybe gone.
Peter, I think that errant COGID reporting was not purely related to your software bug, but was really happening because of a hardware bug. Is there any way that you can test to see if it behaves differently now? It might mean running your buggy app on v30 and see if that COGID failure is still there, or maybe gone.
Okay, I will run through some tests straight after I find out why remote FTP isn't working correctly. Must be a very minor thing. Telnet is okay.
Huh, all my debug code is erroring on the mnemonic JP used by Dave's serial routines. That mnemonic seems to have been removed from the documentation at v19 but it's been assembling just fine until now ... well, I was using v26 prior to this so maybe not exactly at this v30.
Oops!
I think the HUB in V30 is not quite right.
Code I have that runs fine in V29 has issues in V30.
Only program change was a few DJNS to DJNF updates.
I'll keep digging....
Bugger, now I need a debug terminal ... Dave, help!
Sorry, I've been involved in other things, and I haven't had much time to keep up with all the recent changes. I have been watching the updates during the past weeks, and am a little puzzled by some of the arbitrary changes that have been made. I thought the design was frozen a few months ago. I can understand fixing known problems in the design, but it seems like a lot of the recent tweaking of the instruction set is unnecessary and unproductive at this stage in the development.
Huh, all my debug code is erroring on the mnemonic JP used by Dave's serial routines. That mnemonic seems to have been removed from the documentation at v19 but it's been assembling just fine until now ... well, I was using v26 prior to this so maybe not exactly at this v30.
It looped on itself while the pin is high:
getch0 jp #rx_pin, #getch0
My best guess of equivalent would be:
getch0 testp #rx_pin wz
if_z jmp #getch0
JP/JNP were removed from the design a long time ago because they took too long to settle, and those slots became do-nothing. However, I just now thought to remove them from the assembler. Sorry about that.
Some of these last encoding changes were to tidy things up and were not necessary, it's true.
Comments
A big clue to the problem is the-right-instruction-is-executing vs. it's-reporting-wrong-results. The prior is a hubexec problem while the latter is a hub-phase problem. At least, this all seems to revolve around COGID.
Is it okay if I exclude the CORDIC for the 8-cog compile? And I assume you need an image for the BeMicro-A9.
Oh... the humanity!
No problem, Peter. I think this uncovered a latent bug, anyway, in the hub instructions, where a hubexec fetch could smear hub interaction on things like COGID.
I'm recompiling now and I'll get a new version out soon.
This kind of statement makes me nervous. I read it as "there may or may not have been a bug that I may or may not have fixed."
Well, I remember thinking that the first hub slot after "get" should be used for hub operations, and my code comments indicated that, as well. The only thing was, the code wasn't actually doing that, but now it is.
This started out being a carry-over from Prop1, and it could have been-hardwired, but now COGID is also used to check other cogs for activity, so the hub is needed, again.
Gotcha. Now I see what you were saying. Thanks.
Are you saying the whole thing was a false positive ? - at least that's easy for Chip to fix !
Currently, there are 8-cog images for BeMicro-A9 and Prop123-A9. I'll be adding other FPGA images over the next day or two.
This is feeling very final and I have a calm, settled feeling about it.
Please see if this works okay.
Thanks!
btw, what did you change for the "latent hubexec bug"?
Hubexec will refill the instruction buffer (FIFO) when it's less than full and the needed RAM slice comes around. This will pause an instruction before it even gets to the "get" cycle, which is followed by the "go" cycle for 2-clock instructions. I had to inhibit hub operations during that pre-execution time, when it occurs. Otherwise, the cog will be issuing a hub command before the instruction actually starts executing, causing phase errors when it finally releases from the FIFO filling.
My prior comment wasn't quite right about waiting until after "get" - we just need to wait until "get" before responding to the signal that it's our cog's turn to issue a hub command. I think I've got it nailed down tightly now, so we won't have any strange hiccups.
You might have been experiencing this problem, along with your software bug. From the way the Verilog code WAS, this was definitely a pitfall. It just took the circumstance of a hub operation instruction to be coincident with the FIFO stalling execution during refilling. Now that I've changed the Verilog code, that can't happen. It's weird that my code comments recognized this potential and implied it was handled, but it wasn't.
I'm taking a wild wild guess but is that you kuroneko?
V30 running OK on both A9 boards with all my stuff.
All looking good here.
It looped on itself while the pin is high:
My best guess of equivalent would be:
Oh oh OH never mind, Smile, PNut now downloads in Wine!!!
I think the HUB in V30 is not quite right.
Code I have that runs fine in V29 has issues in V30.
Only program change was a few DJNS to DJNF updates.
I'll keep digging....
Edit: Code is targeted for P123-A9 board.
I suspect i'm losing cordic results, if that helps..
Are the two connected somehow?
When a cog issues a CORDIC instruction, it must wait for its hub slot.
JP/JNP were removed from the design a long time ago because they took too long to settle, and those slots became do-nothing. However, I just now thought to remove them from the assembler. Sorry about that.
Some of these last encoding changes were to tidy things up and were not necessary, it's true.