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

Comments

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 ?

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).

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.

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.

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.

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 ?

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.