Shop Learn
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 112 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

1109110112114115160

Comments

  • cgraceycgracey Posts: 13,631
    edited 2017-12-18 23:52
    Sorry about this, I'm still not sure but I don't think it is getting confused about the cogid. Look at this test which displays a symptom:
    INITCOG
    		cogid	X
    		mov	r1,X
    		add	r1,#$F0
    		wrbyte	r1,R1
    		loc	PTRA,#@IDLE		' default startup into Instruction Pointer
    		tjnz	X,#INITSTKS
    		drvh	#tx_pin			'set tx output high
    		loc	PTRA,#@TERMINAL
    		wrpin	#$7C,#tx_pin		' asynchronous transmit
    		wxpin	##baudval+7,#tx_pin	' baud 8 data
    

    It reports correctly for all cogs not including cog#1 which is a serial cog.
    TAQOZ$ $F0 $10 DUMP 
    00.00F0: F0 00 F2 F3 F4 F5 F6 F7 00 00 00 00 00 00 00 00    ................ ok
    

    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.
  • cgraceycgracey Posts: 13,631
    edited 2017-12-18 23:55
    I'm doing a small sanity-check compile before I do the 8-cog compile.

    Is it okay if I exclude the CORDIC for the 8-cog compile? And I assume you need an image for the BeMicro-A9.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-12-19 00:04
    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
    
  • cgraceycgracey Posts: 13,631
    Ha, ha!!

    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.
  • cgracey wrote: »
    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."
  • cgraceycgracey Posts: 13,631
    Seairth wrote: »
    cgracey wrote: »
    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.
  • cgraceycgracey Posts: 13,631
    Peter, does the RDLONG mistake explain why you were getting funny COGID results? I know that was a problem, but was it the whole issue, do you think?
  • I wouldn't worry about the results at all now as the background execution/restart was playing havoc with my system.
  • 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?
  • cgraceycgracey Posts: 13,631
    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.
  • cgracey wrote: »
    Seairth wrote: »
    cgracey wrote: »
    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.

    Gotcha. Now I see what you were saying. Thanks.
  • jmgjmg Posts: 14,853
    I wouldn't worry about the results at all now as the background execution/restart was playing havoc with my system.


    Are you saying the whole thing was a false positive ? - at least that's easy for Chip to fix ! ;)

  • cgraceycgracey Posts: 13,631
    edited 2017-12-19 08:29
    New v30 at the top of this thread.

    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!
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-12-19 08:32
    cgracey wrote: »
    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"?

  • cgraceycgracey Posts: 13,631
    edited 2017-12-19 08:52
    [...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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-12-19 08:49
    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# 
    
  • cgraceycgracey Posts: 13,631
    edited 2017-12-19 08:55
    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 JakackiPeter Jakacki Posts: 10,193
    edited 2017-12-19 08:56
    cgracey wrote: »
    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.
  • ikemschn wrote: »
    Being an "old" Prop1-fan and following the progress of your work for years, here a question a bit apart from the ongoing context in this thread:

    Are there any Prop123-A9-boards left for sale?
    (and if yes: how to get one to germany?)

    Would be great !

    I'm taking a wild wild guess but is that you kuroneko?
  • Chip
    V30 running OK on both A9 boards with all my stuff.
    All looking good here. :)
  • evanhevanh Posts: 12,032
    edited 2017-12-19 11:15
    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
    
  • evanhevanh Posts: 12,032
    What has changed since v26? The loader doesn't seem to work now. Sysclock default? CLKSET changes/defaults? ....

    Oh oh OH never mind, crap, PNut now downloads in Wine!!! :D

  • evanhevanh Posts: 12,032
    edited 2017-12-19 11:36
    Bugger, now I need a debug terminal ... Dave, help!
  • ozpropdevozpropdev Posts: 2,776
    edited 2017-12-19 12:19
    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....

    Edit: Code is targeted for P123-A9 board.
  • Chip
    I suspect i'm losing cordic results, if that helps..
  • Dave HeinDave Hein Posts: 6,347
    edited 2017-12-19 12:59
    evanh wrote: »
    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.
  • cgracey wrote: »
    I'm doing a small sanity-check compile before I do the 8-cog compile.

    Is it okay if I exclude the CORDIC for the 8-cog compile? And I assume you need an image for the BeMicro-A9.
    ozpropdev wrote: »
    Chip
    I suspect i'm losing cordic results, if that helps..

    Are the two connected somehow?
  • TonyB_ wrote: »
    cgracey wrote: »
    I'm doing a small sanity-check compile before I do the 8-cog compile.

    Is it okay if I exclude the CORDIC for the 8-cog compile? And I assume you need an image for the BeMicro-A9.
    ozpropdev wrote: »
    Chip
    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.


  • How soon can we expect an FPGA image with Tachyon in ROM?
  • cgraceycgracey Posts: 13,631
    evanh wrote: »
    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.
Sign In or Register to comment.