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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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
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
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.
- 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.
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
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 ?
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.
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.
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.
Comments
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.
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 decrementIt affects TESTB/TESTBN and TESTP/TESTPN (which replaced TESTIN/TESTNIN). If you want to read a bit/pin into !Z, use TESTBN/TESTPN WZ.
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.
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.
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.
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.
Never mind.
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, 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
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.
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.
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:
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.
Moved to the other thread ....
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:
? The V19 docs seem to say exactly that ?
Instructions v19 say {WC/WZ/WCZ} but C and Z are part of the rotates.
Well, XORO32 will mean nothing to newbies, like me, especially when they find out that XORO16+16 would be more accurate.