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

18182848687160

Comments

  • jmgjmg Posts: 13,928
    cgracey wrote: »
    I've got the two new modes integrated into the smart pins. The net increase amounted to about three 2-input gates per smart pin. Almost nothing.

    Just reading the new v19 Docs I see

    %01100 = Count A-input positive edges when B-input is high

    That good, sounds like a Gated Counter , but ideally, this transfers/captures when B goes low, to act as a useful gated counter. That detail I'm not seeing yet ?
    (If B is very narrow low, you do not have time to respond on B and read, so some capture on B =\_ is tolerant of any duty cycle.)

    The text says : "If a non-zero value is used for the period, events will be counted for that many clock cycles and then the result will be placed in Z, while the accumulator will be set to the 0/1 value that would have otherwise been added into it, beginning a new measurement." - but that seems to be old-mode description ?

    %01101 = Accumulate A-input positive edges with B-input supplying increment (=1) or decrement (=0)

    That looks like a Up/Dn counter, and capture of that is less important, so I think that one is OK.
  • evanhevanh Posts: 7,919
    edited 2017-05-21 - 10:20:43
    Oops, Chip's changed that function ...
     
    Old mode   New Mode   Description
    ===================================================================
               %01100     Count A-input positive edges when B-input is high
               %01101     Accumulate A-input positive edges with B-input supplying increment (=1) or decrement (=0)
    %01100     %01111     Count, !Y[0], A-input highs
    %01101     %01110     Count, !Y[0], A-input positive edges
    %01110     %01111     Count, Y[0], A-input highs increment and B-input highs decrement
    %01111     %01110     Count, Y[0], A-input positive edges increment and B-input positive edges decrement
    
    "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."
  • jmg wrote: »
    (If B is very narrow low, you do not have time to respond on B and read, so some capture on B =\_ is tolerant of any duty cycle.)
    I don't think B-input controls capture at all, it only controls accumulation. Z will capture the accumulator on a RDPIN or when X expires.
    "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."
  • We could use the Y[0] bit to enable capture on A-rise when B-low for the 'inc on A-rise when B-high' mode. Right now it just captures on every N clock cycles.
  • cgracey wrote: »
    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.
    The only smartpin modes used are USB host and async serial TX. With my current issue, the USB smartpins haven't yet been configured.
    garryj
  • cgracey wrote: »
    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.
    This affects just the TESTB* instruction group? I have a few TESTB* cases that WZ, but that code isn't related to the LUT write issue.
    garryj
  • cgraceycgracey Posts: 11,711
    edited 2017-05-21 - 16:54:54
    garryj wrote: »
    cgracey wrote: »
    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.
    This affects just the TESTB* instruction group? I have a few TESTB* cases that WZ, but that code isn't related to the LUT write issue.

    It affects TESTB/TESTBN and TESTP/TESTPN (which replaced TESTIN/TESTNIN). If you want to read a bit/pin into !Z, use TESTBN/TESTPN WZ.
  • cgracey wrote: »
    It affects TESTB/TESTBN and TESTP/TESTPN (which replaced TESTIN/TESTNIN). If you want to read a bit/pin into !Z, use TESTBN/TESTPN WZ.
    Yep, I've got some TESTP* WZ cases too. Should be able to make the edits and retest soon.
    garryj
  • garryj wrote: »
    cgracey wrote: »
    It affects TESTB/TESTBN and TESTP/TESTPN (which replaced TESTIN/TESTNIN). If you want to read a bit/pin into !Z, use TESTBN/TESTPN WZ.
    Yep, I've got some TESTP* WZ cases too. Should be able to make the edits and retest soon.

    The ROM_Booter.spin2 program did a lot of TESTB WZ instructions. I just changed the TESTB to TESTBN and that solved the problem, getting the bit into !Z.
  • Hi Chip,

    Regarding TESTB/TESTBN and TESTP/TESTPN, I found useful the following way to explain:

    TESTB/TESTBN and TESTP/TESTPN use either C or Z flag as accumulator for bit operations (Write / AND / OR / XOR).

    Write operation copies the selected bit into the accumulator (C or Z).
    This means that Z flag's value will be the opposite of the expected value for other instructions:
    WZ when the selected bit is zero results in Z=0 (instead of the usual Z=1).

    Maybe you will find this useful for documentation.
  • jmgjmg Posts: 13,928
    cgracey wrote: »
    Right now it just captures on every N clock cycles.
    That made sense for SysCLKs in N-Cycles, but it makes less sense to define capture after 100 N edges, as you will always just get 100... ?
    cgracey wrote: »
    We could use the Y[0] bit to enable capture on A-rise when B-low for the 'inc on A-rise when B-high' mode.
    I think some minor tweak may be needed.

    What you describe for Y[0] would require an A-rise present, after B-low, which may not be present, and is an unusual capture scheme to users.

    Perhaps more useful would be, if A Clock swaps in for SysCLK, and B becomes what increments X, and N for capture ?
    Here, X=0 is a one-shot next edge, and 1.. (re)capture after every N B edges.
    ie treat this as an external-clock version of other modes.
    (you may want to just allow a config bit in most CTR modes for Internal SysCLK, or PinCLK, as that is very easy to explain and understand)

    Can you improve the Smart Pin DOCs with timing handshake diagrams, as it is not easy to spot the blindspots from many words.
  • Anyone on v19 using POLLCT* events?

    The USB demo host and driver cogs use multiple POLLCT* events, and for some, the timer event doesn't ever trigger. This code has been unchanged over the last several FPGA image updates, and doesn't use any of the v19 opcodes. I haven't had the time yet to investigate further, but so far it appears to happen with the P2 clock at both 60 and 120Mhz. If any of these events malfunction, the mouse/keyboard can't ever get fully configured.

    Chip, is there a CLKSET value for 80Mhz? It might be useful to have an 80Mhz image around if potential issues arise that could be related to pushing the P2 clock a bit too much?
    garryj
  • cgraceycgracey Posts: 11,711
    edited 2017-05-22 - 23:08:49
    garryj wrote: »
    Anyone on v19 using POLLCT* events?

    The USB demo host and driver cogs use multiple POLLCT* events, and for some, the timer event doesn't ever trigger. This code has been unchanged over the last several FPGA image updates, and doesn't use any of the v19 opcodes. I haven't had the time yet to investigate further, but so far it appears to happen with the P2 clock at both 60 and 120Mhz. If any of these events malfunction, the mouse/keyboard can't ever get fully configured.

    Chip, is there a CLKSET value for 80Mhz? It might be useful to have an 80Mhz image around if potential issues arise that could be related to pushing the P2 clock a bit too much?

    120MHz/16 = 7.5MHz per step. So, you could get 75MHz or 82.5MHz, but not 80MHz.

    I'm going to.... I see a problem! I had made the result mux two-stage for things that could be resolved in the 'get' cycle. The POLLx instructions used this early mux, but I didn't realize that the event mux wasn't updated until after 'get'. So, POLLx instructions should not work. I need to recompile. Garryj, what FPGA board are you using? False alarm there.
  • ozpropdevozpropdev Posts: 2,567
    edited 2017-05-22 - 22:56:08
    I can't get the debug interrupt to work on V19 either, might be related?

    Never mind.
    Melbourne, Australia
  • jmgjmg Posts: 13,928
    garryj wrote: »
    The USB demo host and driver cogs use multiple POLLCT* events, and for some, the timer event doesn't ever trigger..
    Not even on the next go-around (~36 seconds later) ?
    garryj wrote: »
    Chip, is there a CLKSET value for 80Mhz? It might be useful to have an 80Mhz image around if potential issues arise that could be related to pushing the P2 clock a bit too much?
    96MHz (USB, no jitter) and 100MHz (ethernet tests?) would also be nice to have, but I think run-time logic-fabric access to the FPGA PLL tree is quite limited.
    (ie it is a build-time choice)

    It might be possible to FPGA-PLL to 240MHz and then /2/3/4 will cover 120/80/60MHz (tho 80M is not 50:50 duty)
    480MHz PLL would cover 120/96/80/68.57/60 with /4/5/6/7/8 as valid divide values

  • jmg wrote: »
    cgracey wrote: »
    Right now it just captures on every N clock cycles.
    That made sense for SysCLKs in N-Cycles, but it makes less sense to define capture after 100 N edges, as you will always just get 100... ?
    cgracey wrote: »
    We could use the Y[0] bit to enable capture on A-rise when B-low for the 'inc on A-rise when B-high' mode.
    I think some minor tweak may be needed.

    What you describe for Y[0] would require an A-rise present, after B-low, which may not be present, and is an unusual capture scheme to users.

    Perhaps more useful would be, if A Clock swaps in for SysCLK, and B becomes what increments X, and N for capture ?
    Here, X=0 is a one-shot next edge, and 1.. (re)capture after every N B edges.
    ie treat this as an external-clock version of other modes.
    (you may want to just allow a config bit in most CTR modes for Internal SysCLK, or PinCLK, as that is very easy to explain and understand)

    Can you improve the Smart Pin DOCs with timing handshake diagrams, as it is not easy to spot the blindspots from many words.

    Jmg, should the A-rise + B-enable work like this:

    - Increment counter on every A-rise when B-high
    - Capture counter on B-fall, and raise IN to signal event
    - Clear counter on B-low
  • False alarm on the POLLx instructions. I was misreading the Verilog. I ran a test and it works fine:
    dat
    	org
    
    	getct	c1
    	getct	c2
    	getct	c3
    
    	addct1	c1,c1_
    	addct2	c2,c2_
    	addct3	c3,c3_
    .lp
    	pollct1	wc
    if_c	addct1	c1,c1_
    if_c	drvnot	#32
    
    	pollct2	wc
    if_c	addct2	c2,c2_
    if_c	drvnot	#33
    
    	pollct3	wc
    if_c	addct3	c3,c3_
    if_c	drvnot	#34
    
    	jmp	#.lp
    
    
    c1	long	0
    c1_	long	60_000_000/3
    
    c2	long	0
    c2_	long	60_000_000/4
    
    c3	long	0
    c3_	long	60_000_000/5
    
  • cgraceycgracey Posts: 11,711
    edited 2017-05-22 - 23:09:46
    The trouble with the Altera PLL is that you can't just wire in multiply and divide values. It's a compile-time-only deal, unless you want a reconfigurable one which you shift new settings into, including some magic numbers for the filter loop. Not practical for what we want. I made an NCO and used the MSB as our clock. It's ugly, but gives us some variance.
  • evanhevanh Posts: 7,919
    edited 2017-05-22 - 23:52:06
    cgracey wrote: »
    Jmg, should the A-rise + B-enable work like this:

    - Increment counter on every A-rise when B-high
    - Capture counter on B-fall, and raise IN to signal event
    - Clear counter on B-low
    Those are extra submodes really - extra config. We don't want to remove the basic count on enable that you've got now.

    There is cases in the other counter types that could gain many extra submodes too ... I'm a tad hesitant to encourage any more tinkering though.
    "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,928
    edited 2017-05-23 - 00:06:48
    cgracey wrote: »
    Jmg, should the A-rise + B-enable work like this:

    - Increment counter on every A-rise when B-high
    - Capture counter on B-fall, and raise IN to signal event
    - Clear counter on B-low

    Yes, that is more practically usable, but leaves open the question of what controls X (or X controls?)

    Given you are counting A-edges, it makes more sense to compare X on B edges ?
    In the other modes, the faster sysclk can total over a number of slower whole periods, so X related to B follows that model.

    In this "Gated & external Clock" (A-rise + B-enable) mode, A is really an external version of SysCLK (with usual sampling caveats) & some slower B (also external).

    The whole-period detail is nice for highest precision (no software interaction), but I think that does dictate two edges are needed ?
    In some designs, a pulse goes out on one pin, and a single echo comes in on another.
    You can make those pins close, and use the A-B relative timing modes, but someone porting code from another MCU might want to just pulse a pin in Sw, Arm the smart pins, and wait until the echo is captured.
    This simpler use, needs a single-edge capability. Is that in the smart pins currently ?

    This sort of detail is why I asked for Smart Pin DOCs to add timing handshake diagrams.
  • cgraceycgracey Posts: 11,711
    edited 2017-05-23 - 00:58:01
    Evanh and Jmg,

    There seem to be many counting modes that could use one or two pins.

    The steering circuitry to realize these modes is just a few gates, each, and these modes are trivial to implement. If you want to come up with a set of requirements for a bunch of these modes, I could look into implementing them. These are outside of the hub and cogs and may not have any effect on ongoing software development.

    It's going to be a few months, probably, before we start spending the money to fabricate, so there's time to make sure the smart pins have what they ought to.

    If you could express each mode in simple terms like these, it would make things very easy:
    COUNT POSITIVE EDGES WITH ENABLE AND CAPTURE
    - Clear counter on B-low
    - Increment counter on every A-rise when B-high
    - Capture counter on B-fall, and raise IN to signal event
    
  • jmg wrote: »
    In some designs, a pulse goes out on one pin, and a single echo comes in on another.
    You can make those pins close, and use the A-B relative timing modes, but someone porting code from another MCU might want to just pulse a pin in Sw, Arm the smart pins, and wait until the echo is captured.
    This simpler use, needs a single-edge capability. Is that in the smart pins currently ?
    A pin pattern event (SETPAT) will do that.
    "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,928
    cgracey wrote: »
    Evanh and Jmg,

    There seem to be many counting modes that could use one or two pins.

    The steering circuitry to realize these modes is just a few gates, each, and these modes are trivial to implement. If you want to come up with a set of requirements for a bunch of these modes, I could look into implementing them. These are outside of the hub and cogs and may not have any effect on ongoing software development.

    It's going to be a few months, probably, before we start spending the money to fabricate, so there's time to make sure the smart pins have what they ought to.

    If you could express each mode in simple terms like these, it would make things very easy:
    - Clear counter on B-low
    - Increment counter on every A-rise when B-high
    - Capture counter on B-fall, and raise IN to signal event
    

    Can you expand the DOCs to include timing handshake diagrams on the modes that are already there ?
    99% of the coverage is there I think, just needs a pass to check for simpler subsets being ok.





  • jmgjmg Posts: 13,928
    evanh wrote: »
    A pin pattern event (SETPAT) will do that.
    ... but does that capture the hardware counter value ? Based on external CLK edges ?
  • jmgjmg Posts: 13,928
    edited 2017-05-23 - 05:00:33
    cgracey wrote: »
    If you could express each mode in simple terms like these, it would make things very easy:

    Moved to the other thread ....
  • TonyBTonyB Posts: 73
    edited 2017-05-23 - 22:40:19
    A couple of quick points ...

    Renaming XORO32 to RANDOM would make it so much easier to remember! Instructions mention name of algorithm.

    I think Instructions not quite right for RCZR & RCZL and should be written as:
    RCZR	D	WCZ
    RCZL	D	WCZ
    
  • jmgjmg Posts: 13,928
    TonyB wrote: »
    A couple of quick points ...

    Renaming XORO32 to RANDOM would make it so much easier to remember! Instructions mention name of algorithm.
    However, there is more than one Random in P2 ..
    TonyB wrote: »
    I think Instructions not quite right for RCZR & RCZL and should be written as:
    RCZR	D	WCZ
    RCZL	D	WCZ
    
    ? The V19 docs seem to say exactly that ?
  • The XORO32 instruction iterates the state, but to actually get the random number out, you need to add the low and high 16-bit fields and use bits 15..1 of the sum, ignoring bit 0. So, just calling it RANDOM would be too simplistic.
  • jmg wrote: »
    TonyB wrote: »
    I think Instructions not quite right for RCZR & RCZL and should be written as:
    RCZR	D	WCZ
    RCZL	D	WCZ
    
    ? The V19 docs seem to say exactly that ?

    Instructions v19 say {WC/WZ/WCZ} but C and Z are part of the rotates.
  • cgracey wrote: »
    The XORO32 instruction iterates the state, but to actually get the random number out, you need to add the low and high 16-bit fields and use bits 15..1 of the sum, ignoring bit 0. So, just calling it RANDOM would be too simplistic.

    Well, XORO32 will mean nothing to newbies, like me, especially when they find out that XORO16+16 would be more accurate.
Sign In or Register to comment.