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

1132133135137138160

Comments

  • ozpropdevozpropdev Posts: 2,564
    edited 2018-04-19 - 10:33:48
    @Cluso99
    Can you use RCZR D or maybe a SKIP D instead?
    	_ret_	rczr	myreg wcz
    
    Melbourne, Australia
  • Cluso99 wrote: »
    Anyone know what happened to the setcz instruction?
    I found modcz but I don't understand the required operands.

    This is how I use it:
    modcz	0,0 wc		' clear C for some operations that use this to determine behaviour
    
    The 0,0 are the states for C and Z while wz wc specify which ones to set. So therefore, to set the carry:
    modcz	1,0 wc		' Set C
    
    MODCZ   c,z      {WC/WZ/WCZ}	Modify C and Z according to cccc and zzzz. C = cccc[{C,Z}], Z = zzzz[{C,Z}].
    

    '0' does happen to clear, but %1111 is needed to set. These MODCZ values that Ozpropdev listed are what work. Everything is a function of current flag states, except set and clear (%1111 and %0000).
  • cgraceycgracey Posts: 11,705
    edited 2018-04-25 - 12:25:22
    OnSemi was running into delays from long routes associated with the DIR and OUT signals coming from the cogs and going to the smart pins. I added an extra layer of flops to cut the routing distance down. This will speed things up.

    This means that the DIR and OUT signals from the cogs will take one more clock to get to the I/O pins, which nobody will like. To get the speed up to where it could otherwise be, this was necessary.

    I'm compiling new FPGA images now, first for the BeMicro-A9 board. I'll have it posted in several hours. Then, I'll compile the Prop123-A9 board image.

    If you guys could check these out (after I post them) and see that your code still runs, that would be good. It all seems to work on my end.

    Thanks.
  • I wonder if OUT routing is the primary cause of the I/O timing issue in the FPGA. I'll be running my Smartpin based I/O response measuring program for sure.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • jmgjmg Posts: 13,912
    cgracey wrote: »
    This means that the DIR and OUT signals from the cogs will take one more clock to get to the I/O pins, which nobody will like. To get the speed up to where it could otherwise be, this was necessary.
    Extra delays are never nice, but fixed known delays are far better than SysCLK dependent delays, and having any situation where delays are right on some cusp.

    Does this extra delay affect any part of the smart pin operation ?
    I guess it affects SW trigger, but not any of the pin-related signals ? ( ie Counting, Serial, Streamer all have the same top speeds ? )
  • evanh wrote: »
    I wonder if OUT routing is the primary cause of the I/O timing issue in the FPGA. I'll be running my Smartpin based I/O response measuring program for sure.

    It was. I had jiggered things around to make them faster on the ASIC without adding another flop stage, but now we're back to what is better on the FPGA, too.

    The FPGA pretty well tracks ASIC timing, but the ASIC is much finer grain and more can be done by the ASIC tools to tighten timing on critical paths than can be done by the FPGA tools.
  • jmg wrote: »
    cgracey wrote: »
    This means that the DIR and OUT signals from the cogs will take one more clock to get to the I/O pins, which nobody will like. To get the speed up to where it could otherwise be, this was necessary.
    Extra delays are never nice, but fixed known delays are far better than SysCLK dependent delays, and having any situation where delays are right on some cusp.

    Does this extra delay affect any part of the smart pin operation ?
    I guess it affects SW trigger, but not any of the pin-related signals ? ( ie Counting, Serial, Streamer all have the same top speeds ? )

    The smart pins are unaffected by this. It's just the DIR and OUT signals coming from the cogs that are now delayed by another clock cycle.
  • cgraceycgracey Posts: 11,705
    edited 2018-04-26 - 05:59:43
    Okay. Here are new files for the BeMicro-A9 and the Prop123-A9 boards. This is v32c:

    https://drive.google.com/file/d/10nhZYSZ3wGYi2JiVmayUFNyGzWhsrpn_/view?usp=sharing

    Could you guys please try these out for a sanity check? The only difference should be that the OUT and DIR signals emanating from the cogs are delayed by one more clock cycle. This may have implications to your software. Signals will take one more clock to get from the cogs to the pins, which also means that they will echo back one clock later, as well. The pin-to-IN timing is the same. Just the DIR/OUT-to-pin timing has increased by one clock.

    Thanks.
  • px.exe wants a .rbf file.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • BeMicro_A9 V32c seems to be working fine.
    Just need a RBF format file for the P123_A9 as evanh pointed out.
    Melbourne, Australia
  • cgraceycgracey Posts: 11,705
    edited 2018-04-26 - 00:00:21
    ozpropdev wrote: »
    BeMicro_A9 V32c seems to be working fine.
    Just need a RBF format file for the P123_A9 as evanh pointed out.

    WHOOPS!!!!!

    Change that Prop123-A9 .jic to .rbf. When copying the file, I put the wrong extension on it.

  • cgracey wrote: »
    ozpropdev wrote: »
    BeMicro_A9 V32c seems to be working fine.
    Just need a RBF format file for the P123_A9 as evanh pointed out.

    WHOOPS!!!!!

    Change that Prop123-A9 .jic to .rbf. When copying the file, I put the wrong extension on it.
    Ok Thanks Chip.
    P123-A9 V32c flashed Ok.
    I've run everything I have here and it all seems to be running Ok.



    Melbourne, Australia
  • cgracey wrote: »
    Okay. Here are new files for the BeMicro-A9 and the Prop123-A9 boards. This is v32c:

    https://drive.google.com/file/d/1zjwzv1ZsdinWMBBOsTm3pEXf-4p8i9jf/view?usp=sharing

    Could you guys please try these out for a sanity check? The only difference should be that the OUT and DIR signals emanating from the cogs are delayed by one more clock cycle. This may have implications to your software. Signals will take one more clock to get from the cogs to the pins, which also means that they will echo back one clock later, as well. The pin-to-IN timing is the same. Just the DIR/OUT-to-pin timing has increased by one clock.

    Thanks.
    For some reason I get an error when I try to download this zip file.


    672 x 232 - 78K
  • SD and monitor working fine on BeMicroCV-A9

    Chip, BTW back home for the day now.
    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)
  • David Betz wrote: »
    cgracey wrote: »
    Okay. Here are new files for the BeMicro-A9 and the Prop123-A9 boards. This is v32c:

    https://drive.google.com/file/d/1zjwzv1ZsdinWMBBOsTm3pEXf-4p8i9jf/view?usp=sharing

    Could you guys please try these out for a sanity check? The only difference should be that the OUT and DIR signals emanating from the cogs are delayed by one more clock cycle. This may have implications to your software. Signals will take one more clock to get from the cogs to the pins, which also means that they will echo back one clock later, as well. The pin-to-IN timing is the same. Just the DIR/OUT-to-pin timing has increased by one clock.

    Thanks.
    For some reason I get an error when I try to download this zip file.

    Direct link to the zip file:
    https://drive.google.com/uc?export=download&id=1zjwzv1ZsdinWMBBOsTm3pEXf-4p8i9jf
    Formerly known as TonyB
  • David BetzDavid Betz Posts: 13,480
    edited 2018-04-26 - 02:23:04
    TonyB_ wrote: »
    David Betz wrote: »
    cgracey wrote: »
    Okay. Here are new files for the BeMicro-A9 and the Prop123-A9 boards. This is v32c:

    https://drive.google.com/file/d/1zjwzv1ZsdinWMBBOsTm3pEXf-4p8i9jf/view?usp=sharing

    Could you guys please try these out for a sanity check? The only difference should be that the OUT and DIR signals emanating from the cogs are delayed by one more clock cycle. This may have implications to your software. Signals will take one more clock to get from the cogs to the pins, which also means that they will echo back one clock later, as well. The pin-to-IN timing is the same. Just the DIR/OUT-to-pin timing has increased by one clock.

    Thanks.
    For some reason I get an error when I try to download this zip file.

    Direct link to the zip file:
    https://drive.google.com/uc?export=download&id=1zjwzv1ZsdinWMBBOsTm3pEXf-4p8i9jf
    Oddly, that gives me the same error. Maybe I'll try downloading it on my Linux or Windows machine. Might be some issue with my Mac.

    Edit: Downloaded fine under Windows. Not sure what went wrong on the Mac. I even tried Chrome as well as Safari.
  • Hmm, not consistent yet on the OUT to IN times. Here's the usual 80 MHz results:
    SmartPin mode = %01111, Count highs
    pin# reset     pause     high......later     low.......later
     19  00000000  00000000  00000000  00000001  00000001  00000003
     18  00000000  00000000  00000000  00000001  00000001  00000002
     17  00000000  00000000  00000000  00000002  00000002  00000004
     16  00000000  00000000  00000000  00000002  00000002  00000004
     15  00000000  00000000  00000000  00000002  00000002  00000004
     14  00000000  00000000  00000000  00000001  00000001  00000003
     13  00000000  00000000  00000000  00000001  00000001  00000003
     12  00000000  00000000  00000000  00000001  00000001  00000003
     11  00000000  00000000  00000000  00000001  00000001  00000003
     10  00000000  00000000  00000000  00000001  00000001  00000002
     09  00000000  00000000  00000000  00000002  00000002  00000004
     08  00000000  00000000  00000000  00000001  00000001  00000003
     07  00000000  00000000  00000000  00000001  00000001  00000002
     06  00000000  00000000  00000000  00000001  00000001  00000003
     05  00000000  00000000  00000000  00000001  00000001  00000003
     04  00000000  00000000  00000000  00000001  00000001  00000002
     03  00000000  00000000  00000000  00000002  00000002  00000004
     02  00000000  00000000  00000000  00000002  00000002  00000004
     01  00000000  00000000  00000000  00000002  00000002  00000004
     00  00000000  00000000  00000000  00000002  00000002  00000004
    

    And, as expected, the ideal 20 MHz results:
    SmartPin mode = %01111, Count highs
    pin# reset     pause     high......later     low.......later
     19  00000000  00000000  00000000  00000001  00000001  00000002
     18  00000000  00000000  00000000  00000001  00000001  00000002
     17  00000000  00000000  00000000  00000001  00000001  00000002
     16  00000000  00000000  00000000  00000001  00000001  00000002
     15  00000000  00000000  00000000  00000001  00000001  00000002
     14  00000000  00000000  00000000  00000001  00000001  00000002
     13  00000000  00000000  00000000  00000001  00000001  00000002
     12  00000000  00000000  00000000  00000001  00000001  00000002
     11  00000000  00000000  00000000  00000001  00000001  00000002
     10  00000000  00000000  00000000  00000001  00000001  00000002
     09  00000000  00000000  00000000  00000001  00000001  00000002
     08  00000000  00000000  00000000  00000001  00000001  00000002
     07  00000000  00000000  00000000  00000001  00000001  00000002
     06  00000000  00000000  00000000  00000001  00000001  00000002
     05  00000000  00000000  00000000  00000001  00000001  00000002
     04  00000000  00000000  00000000  00000001  00000001  00000002
     03  00000000  00000000  00000000  00000001  00000001  00000002
     02  00000000  00000000  00000000  00000001  00000001  00000002
     01  00000000  00000000  00000000  00000001  00000001  00000002
     00  00000000  00000000  00000000  00000001  00000001  00000002
    
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • I flashed the Prop123_A9_Prop2_8cogs_v32c.rbf file a second time and re-ran the tests to make sure I had the right one.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • Are you saying there's no difference between v32b and v32c?
  • correct.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • jmgjmg Posts: 13,912
    evanh wrote: »
    Hmm, not consistent yet on the OUT to IN times. Here's the usual 80 MHz results:
    And, as expected, the ideal 20 MHz results:
    Has v32c improved over v32b ? ie less jitter or less range of values ?
    Are there other valid test frequencies between 20MHz and 80MHz you can try ?
    V32c should have pushed up the point where the variations start to show ?

  • USB demo looks OK on v32c.
    garryj
  • Exactly the same range of 1 to 2 clocks. Not identical pin pattern to historical v31 tests though. 40 MHz is the same as 20 MHz - no change there.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • jmgjmg Posts: 13,912
    evanh wrote: »
    Exactly the same range of 1 to 2 clocks. Not identical pin pattern to historical v31 tests though. 40 MHz is the same as 20 MHz - no change there.
    I guess the pins delays always 'wobble around' a little with each P&R, and maybe P&R does not place the registers as carefully, delay-wise, as the OnSemi scripts do.... ?

  • evanhevanh Posts: 7,872
    edited 2018-04-27 - 04:01:41
    I just tested with v32a FPGA image and the pin pattern differs slightly from v32c.

    With repeated runs of the same there is also some unstable jitter effects on some pins as well. No surprise really.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • Hi evanh

    Could you please point me to the post where I can find the routine you've been using, to measure the pin-to-pin timings you've been commenting about?

    Sorry, but I'm having a hard time, trying to find it among that many posts this thread now has.

    Thanks in advance.

    Henrique
  • "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • Cluso99Cluso99 Posts: 15,397
    edited 2018-04-28 - 03:51:39
    ALTS instruction

    While technically not a bug, these are the results of some testing I did with the ALTS instruction.

    I was kind of hoping that ALTS allowed me to use a full address for the base address so that I could feed it into a following RDxxxx/WRxxxx instruction.
     addr-  0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
     -----------------------------------------------------
      080- 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F  initial values for all tests below
      084- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
           -----x----- -----y----- -----z----- -----a-----
     -----------------------------------------------------
                                                            mov  y, ##$00000144 
                                                            alts y, ##$11223344 
                                                            mov  a, #0
      084- 00 00 00 00 5D 00 00 00 00 00 00 00 88 32 22 11
                       ^^                         ^^
     -----------------------------------------------------
                                                           mov  y, ##$00000144
                                                           alts y, ##$11223344
                                                           mov  a, 0          
      084- 00 00 00 00 5D 00 00 00 00 00 00 00 3D 3D 3D 3D
                       ^^                      ???????????   
     -----------------------------------------------------
                                                            mov  y, ##$00000014 
                                                            alts y, ##$11223344 
                                                            mov  a, #0          
      084- 00 00 00 00 2D FF FF FF 00 00 00 00 58 33 22 11
                       ^^ ^^ ^^ ^^              
     -----------------------------------------------------
                                                           mov  y, ##$00000002 
                                                           alts y, ##$00000080 
                                                           mov  a, #0          
      084- 00 00 00 00 02 00 00 00 00 00 00 00 82 00 00 00
                                              
     -----------------------------------------------------
                                                           mov  y, ##$00000002 
                                                           alts y, ##$00000080 
                                                           mov  a, 0           
      084- 00 00 00 00 02 00 00 00 00 00 00 00 48 49 4A 4B
                                              
     -----------------------------------------------------
                                                           mov  y, ##$00000144 
                                                           alts y, ##$00000144 
                                                           mov  a, #0          
      084- 00 00 00 00 44 01 00 00 00 00 00 00 88 00 00 00
                       ^^ ^^                      ^^
     -----------------------------------------------------
                                                           mov  y, ##$00000014 
                                                           alts y, ##$00000144 
                                                           mov  a, #0          
      084- 00 00 00 00 14 00 00 00 00 00 00 00 58 01 00 00
    
     -----------------------------------------------------
                                                           mov  y, ##$00000014 
                                                           alts y, ##$00000344 
                                                           mov  a, #0          
      084- 00 00 00 00 15 00 00 00 00 00 00 00 58 03 00 00
                       ^^
     -----------------------------------------------------
    
    From these results, I deduced a few things that I think are correct...
    1. The ALTS instruction writes a result back into its' D register.
    2. The ALTS D register must be =< $1F (5bits max) or D is overwritten with an incorrect value
    3. The ALTS S register must be =< $1FF (9 bits max) or D is overwritten with an incorrect value
    4. If the ALTS D register is > $1FF then the S value passed to the following instruction is incorrect
    5. If the ALTS D register is =< $1F and the S value is > $1FF then while D is overwritten, the correct value of S is passed to the following instruction
    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)
  • Re: ALTD,ALTS
    See "Register Indirection" in the V32 P2 Documentation in the first post.
    Melbourne, Australia
Sign In or Register to comment.