Prop2 FPGA files!!! - Updated 31 May 2017 - Version 19a

18081838586

Comments

  • Getting the speed up should be a big bonus for real silicon ;)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • I've seen P1 do 160 MHz as long as there was only one cog running.
    If you tried to start a second cog, it'd go belly up.

    Wonder if P2 will be like that...
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    I've seen P1 do 160 MHz as long as there was only one cog running.
    If you tried to start a second cog, it'd go belly up.

    Wonder if P2 will be like that...

    When overclocked by 2x? Yeah, that seems a certainty. Actually, I wonder if you'll even be able to overclock that much in the first place. The layout of the P2 die is bound to be significantly different from what we saw with the P1 (i.e., I don't expect clearly defined cog regions, for instance). I have to imagine that, in order to hit the desired "safe" frequency that Chip wants, the clocking tolerances are going to be fairly tight.
  • jmgjmg Posts: 10,077
    edited May 17 Vote Up0Vote Down
    cgracey wrote: »
    Would CLK+RESET be of any use?
    ..... Maybe if it would capture on reset, but that's still not useful, it seems.

    I think there is already an external Capture, but what I'd call a higher precision model ?
    Those high-precision, whole period ones, may be harder to explain and use, than a simple Capture & Reset, so yes, CLK+RESET(capture) sounds useful to me, as a 'spare mode filler'
    With Capture & reset, you need only one edge, whilst the higher precision modes need at least two edges.

    Addit : examples of simple one-edge echo style uses would be any sonar system, from the low precision Ping units (air), and there are linear probes that use speed of sound in metals & Magnetostrictive pulses.


    I found more info on the pulse choices for Magnetostrictive Pulse Linear sensors.
    Magnetostrictive Pulse  -  4 Choices of Pulse type order code 
    (PWM is strictly Pulse High Width Modulation, L is ignored)
    a) Control Pulse: Interrogate Pulse (IP)~1us   Output Pulse (OP)  ~1us Tp is probe delay k*mm 
    IP ___/==\___________________________________________________
    OP _________________________________________________/==\_____
    Tp    |<--------------------- Tp ------------------>|
    
    
    b) Start/Stop: Interrogate Pulse (IP)  Output Pulse (OP)
    IP ___/==\___________________________________________________
    OP ____/==\_________________________________________/==\_____
    Tp     |<-------------------- Tp ------------------>|
    
    c) PWM, External trigger Interrogate Pulse (IP)  Output Pulse (OP)PWM
    IP ___/==\___________________________________________________
    OP ____/============================================\________
    Tp     |<-------------------- Tp ------------------>|
    
    d) PWM, internal interrogation (one less wire, self retriggers)
    IP  nc
    OP ____/============================================\_____/============================================\_____
    Tp     |<-------------------- Tp ------------------>|  L  |<-------------------- Tp ------------------>|
    Data: "LOW OUTPUT VARIES DEPENDING ON LENGTH PROGRAMMED VIA DIP SW2 SWITCHES 1-6"
    
    e) Choice of TTL and RS422 signaling.
    
    

    Next step is to match P2 Smart Pin modes, to each of the above ?
    Smart pin DOCs are very terse, but let's try anyway....
    It is also not clear what rise or edge means, usually edge means change in level, does it mean either rise or fall ?
    is %01 = A-input rise to B-input edge
    == %01 = A-input rise to B-input change
    == %01 = A-input rise to B-input rise or fall

    'Count states' - what is a state ?


    c) I think can use this one
    %10001 = Time A-input high states Continuous high states are counted in clock cycles.
    Upon each high-to-low transition, the previous high duration count is placed in Z, and IN is raised.

    d) can use above, or the smarter
    %10011 = For X periods, count time
    - unclear which sub-mode for LEVEL gating ? or is this mode purely edges-only ?
    %00 = A-input rise to B-input rise, where B = !A, would be A _/= to A =\_ which is HIGH time.

    where X can accumulate whole pulse widths, over 10,16 or 100 (etc) echos to allow lower SysCLK speeds for same precision LSB

    or, d) could use
    %10010 = Time X A-input highs Time is measured until X highs are accumulated.


    b) can use A=B mapping, for
    %10011 = For X periods, count time
    %00 = A-input rise to B-input rise

    a) is trickier, provided IP pin is close to OP pin, It can use the same as b), but if IP is a distant pin ??
    If the P2 'clips onto' an existing system, both Start and End are IP, so they can be close-by ?

    However, if a P2 as master design wanted a common trigger for a dozen probes, that's outside A-B reach, so maybe

    %10000 = Time A-input states ? - this seems to need 2 edges ?

    Perhaps inverted version of :
    %10001 = Time A-input high states
    Upon each high-to-low transition, the previous high duration count is placed in Z, and IN is raised.

    Using !A, combined with software clear/start, that may work as Capture ?
    !A means _/= captures TimeL -> Z, which is what is needed.

  • evanhevanh Posts: 3,899
    I gather IP and OP are both digital inputs. And Tp is the time we want to measure/calculate, right?

    In both b) and c), IP seems to be irrelevant.
    $50,000 buys you a discrediting of a journalist
  • evanhevanh Posts: 3,899
    jmg wrote: »
    It is also not clear what rise or edge means, usually edge means change in level, does it mean either rise or fall ?
    is %01 = A-input rise to B-input edge
    == %01 = A-input rise to B-input change
    == %01 = A-input rise to B-input rise or fall

    'Count states' - what is a state ?
    Yeah, that's about my understanding too. "States" is both high and low. "Edge" is both rise and fall. Some of the earlier modes say rising edge where the later modes just say rise.
    $50,000 buys you a discrediting of a journalist
  • jmgjmg Posts: 10,077
    evanh wrote: »
    I gather IP and OP are both digital inputs. And Tp is the time we want to measure/calculate, right?

    In both b) and c), IP seems to be irrelevant.
    IP and OP are probe-relative, & from the probe-end the Interrogate Pulse (IP)~1us is required for all modes, except D (as per the nc)
    Where the P2 is master, it will generate the ~1us Interrogate Pulse (IP).
    Where P2 is attached to some other system, it can passively read both IP and OP

    From a measurement-angle, b) c) d) need no knowledge of the timing of IP, and those modes are more tolerant of cable length.
    Mode a) includes any cable & driver delay in the Tp.
  • cgraceycgracey Posts: 7,697
    edited May 19 Vote Up1Vote Down
    Okay. New v19 is done. See the first post in this thread.

    I'll get the documentation updated in the next several hours. Just a few things to change there. The Google sheet for instruction encodings is done, already.
  • Great Chip! Thank you. :D
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • RaymanRayman Posts: 8,200
    edited May 20 Vote Up0Vote Down
    Looks like we lost 2 smart pins with P123 since last time I updated...

    had to change all my wc,wz to wcz
    need to change outn to DRVNOT
    change SETLUT to LUTSON
    change max to FLE (or FGE?) one of those anyway
    bitn to bitnot
    testin to testb ina,
    setcz #0 to modcz _CLR,_CLR wcz
    JNP to testp #DP wc then if_nc JMP?

    Got a video driver working.
    USB doesn't work though...
    Might need Garryj's help...

    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    need to change outn to DRVNOT
    If you've already set the pin as output there's
    OUTNOT #PIN {WCZ}
    testin to testb ina,
    And I think to replace TESTIN, you can also use:
    TESTP #PIN WC/WZ
    garryj
  • I'm guess the problem is that there are other commands like JNP, that don't exist anymore.

    Assembler now sees them as labels and not errors...

    Think I'll just wait and hope garryj posts new version...
    Prop Info and Apps: http://www.rayslogic.com/
  • cgraceycgracey Posts: 7,697
    edited May 21 Vote Up0Vote Down
    I think Rayman hit most every snag. Here is a complete list, based on his post and what else I remember:
    CHANGE		TO
    --------------------------------------------
    WC,WZ		WCZ
    MAX		FLE
    MIN		FGE
    MAXS		FLES
    MINS		FGES
    BITN		BITNOT
    DIRN		DIRNOT
    OUTN		OUTNOT
    FLTN		FLTNOT
    DRVN		DRVNOT
    SETLUT		SETLUTS -or- LUTSON/LUTSOFF
    TESTIN		TESTP
    TESTNIN		TESTPN
    SETCZ		MODCZ _CLR/_SET,_CLR/_SET
    JNP		TESTP pin WC + IF_NC JMP addr
    JP		TESTP pin WC + IF_C  JMP addr
    
    For WMLONG, the no-write byte value has been changed from $FF to $00.
    

    Getting rid of JNP/JP allowed things to run quite a bit faster. Most other changes were to harmonize mnemonics and flag effects (TESTB/TESTP).
  • evanhevanh Posts: 3,899
    Note to anyone that might be using Wine. With the release of Wine 2.8 the developers saw fit to mess around with how the comports assignment system works ...

    Wine now automatically overwrites the old symbolic links, that one used to hand craft, with a predefined mapping of COM1 to COM32 for ISA mapped ports so that USB mapped ports then start at COM33 ... !!!

    What the bloody hell were they thinking?!

    Anyway, the new instruction on how to override, using regedit, this new behaviour with preset assignments again are provided here - https://wiki.winehq.org/index.php?title=Wine_User's_Guide&oldid=2519#Serial_and_Parallel_Ports
    $50,000 buys you a discrediting of a journalist
  • evanhevanh Posts: 3,899
    edited May 21 Vote Up0Vote Down
    Chip,
    I can't get any of the sample programs to run on the v19 image. Not even all_cogs_blink. Has the Prop2 download protocol changed from v18a to v19?

    With v19 the behaviour of loadp2 now appears similar to PNut.exe. loadp2 still works fine if I put v18a back in the FPGA.

    EDIT: Ah, I see Dave's loadp2 first downloads a small piece of built-in binary code labelled "mainloader", that'll need updated ... I presume I can use PNut to build the official MainLoader.spin2 file ...
    $50,000 buys you a discrediting of a journalist
  • Rayman wrote: »
    Got a video driver working.
    USB doesn't work though...
    Might need Garryj's help...
    Yep, there's definitely something amiss on the USB side, and my only guess right now is that it may be associated with LUT sharing. During startup, the host and driver cogs (host is cog0, driver is cog1) are getting started OK, the P2 clock gets set to 120Mhz OK, and the serial output, which is handled by the driver cog, gets started OK, as I'm getting splash banner text output to the terminal at 3Mbaud.

    Both cogs are using SETLUTS #1 as both host and driver have several LUT locations in the "other" cog that they write to. But when the host cog tries to initialize a LUT location of the driver cog that it *should* have permission to write to, it appears to go off the rails at the WRLUT instruction. If I comment out this instruction, the host cog goes into its "idle" loop as it should. I've got things short-circuited to keep both cogs in their idle loops, if they get that far, and the only smart pin in use is serial TX.

    So far, this is the only info I have. I've run out of time to play today, but I'll try to get back to it to tomorrow to dig further.
    garryj
  • evanh wrote: »
    Chip,
    I can't get any of the sample programs to run on the v19 image. Not even all_cogs_blink. Has the Prop2 download protocol changed from v18a to v19?

    With v19 the behaviour of loadp2 now appears similar to PNut.exe. loadp2 still works fine if I put v18a back in the FPGA.

    EDIT: Ah, I see Dave's loadp2 first downloads a small piece of built-in binary code labelled "mainloader", that'll need updated ... I presume I can use PNut to build the official MainLoader.spin2 file ...
    The MainLoader.spin2 used with loadp2 is slightly different than Chip's version. However, it may not need to be recompiled as long as the codepoints haven't changed for the instructions it uses. There are two lines that need to be changed in loadp2.c. They are the following two lines
        txval(3*80000000/LOADER_BAUD/2-6);
        txval(80000000/LOADER_BAUD-6);
    
    These assume a clock rate of 80MHz. With v19 the clock rate will be 120MHz, so those two lines should be changed to
        txval(3*120000000/LOADER_BAUD/2-6);
        txval(120000000/LOADER_BAUD-6);
    
    This may be all that needs to be changed.

    I'm away from home right now, so I won't be able to test this until I get back on Thursday.
  • evanh wrote: »
    Chip,
    I can't get any of the sample programs to run on the v19 image. Not even all_cogs_blink. Has the Prop2 download protocol changed from v18a to v19?

    With v19 the behaviour of loadp2 now appears similar to PNut.exe. loadp2 still works fine if I put v18a back in the FPGA.

    EDIT: Ah, I see Dave's loadp2 first downloads a small piece of built-in binary code labelled "mainloader", that'll need updated ... I presume I can use PNut to build the official MainLoader.spin2 file ...

    Yes, PNut will compile the MainLoader.spin2 file. The error is due to now running at 120MHz. The WAITX values need adjusting. Also, MainLoader sets the clock to just 60MHz via 'CLKSET #$7F'.
  • Garryj, I made some changes around the LUT read and write for interrupt purposes. I'm going to go test them to see if everything still works properly.
  • cgraceycgracey Posts: 7,697
    edited May 21 Vote Up0Vote Down
    deleted
  • One other change in V19 is WMLONg from $ff to $00 as the "transparent" byte.

    Made all the changes to all my stuff, with some still not working.
    I'll keep digging....

    Melbourne, Australia
  • ozpropdev wrote: »
    One other change in V19 is WMLONg from $ff to $00 as the "transparent" byte.

    Made all the changes to all my stuff, with some still not working.
    I'll keep digging....

    I just updated the WMLONG description in the Google Doc to reflect this change. Thanks for pointing this out. Sorry I forgot about that.
  • Dave HeinDave Hein Posts: 5,179
    edited May 21 Vote Up0Vote Down
    I tried compiling the MainLoader.spin2 file used by loadp2, and it fails on the testin instruction. This needs to be changed to testp. I should change the name of the file I use so there's no confusion with Chip's version. After compiling with v19 there is one byte that is different in the generated binary as compared to v18. So in loadp2.c the hex code "4f" should be changed to "40" in the MainLoader string. This hex code is located in the middle of the MainLoader string. Just search for "4f" to find it.

    So that change plus the other two lines should fix loadp2 for v19. That's assuming that everything works OK at 120MHz. If not, the clkset instruction should use $7F, and 60MHz should be used in the delay computations. Also, the third hex code in the MainLoader string would need to be changed from "65" to "64".
  • It looks to me like LUT sharing is working okay. I'll test the LUT events next.
  • evanhevanh Posts: 3,899
    edited May 21 Vote Up0Vote Down
    Thanks Dave. You got it spot on with just changing that one byte to $40. I was trying all sorts of other combinations but wasn't hitting it by myself.

    I then successfully changed over to 60 MHz as per your second description.

    PS: I note the examples like all_cogs_blink.spin2 cycle at different speeds a result of the different clock rates.
    $50,000 buys you a discrediting of a journalist
  • I just tested all the LUT events and they work okay.

    The only difference from the last release is that the LUT r/w events are now sensed one clock later than they were before. I had to use some flops to capture the ENA, WR, and ADDR, in order to make sense of them in the next cycle, as there was insufficient time to do it all in one clock. So, the LUT events are sensed one clock later than they used to be, causing events/interrupts to trigger one clock later. It seems unlikely that anyone's code would be so sensitive to such a small change.
  • cgracey wrote: »
    It looks to me like LUT sharing is working okay. I'll test the LUT events next.
    Ah. Both cogs set up SE1 events to catch when the partner cog has written to their LUT.
    garryj
  • garryj wrote: »
    cgracey wrote: »
    It looks to me like LUT sharing is working okay. I'll test the LUT events next.
    Ah. Both cogs set up SE1 events to catch when the partner cog has written to their LUT.

    Garryj, smart pin modes %011xx have changed and have been remapped, somewhat. Are you using any of those modes? The latest Google Doc explains the new modes.
  • ozpropdevozpropdev Posts: 1,819
    edited May 21 Vote Up0Vote Down
    Ok I'm made some progress with the V19 update changes.
    This one took a while to pin down.

    The result from a TESTB D,#S WZ is inverted compared to V18.
    dat	org
    
    'v18 led is off
    'v19 led is on
    
    	testb	oz,#1 wz
    	drvz	#32
    	jmp	#$
    
    oz	long	2
    

    I changed some IF_Z's to IF_NZ and things started working.
    Still digging....
    Melbourne, Australia
  • ozpropdev wrote: »
    Ok I'm made some progress with the V19 update changes.
    This one took a while to pin down.

    The result from a TESTB D,#S WZ is inverted compared to V19.
    dat	org
    
    'v18 led is off
    'v19 led is on
    
    	testb	oz,#1 wz
    	drvz	#32
    	jmp	#$
    
    oz	long	2
    

    I changed some IF_Z's to IF_NZ and things started working.
    Still digging....

    Ah, yes, I forgot about that. With all the flag-logic instructions, it seemed to me that we had better get rid of flag inversion on WZ. I hope garryj's problems are related to this change.
Sign In or Register to comment.