however, it also saysThe resultant ‘A’ will drive the IN signal in non-smart-pin modes.
but does that mean the filtering is not present in Smart-Pin case, or just that filtering is also available in Non-smart pin (direct SW read) ?

b) Quad reset is not in HW, as that would need a 3rd pin path, but the P2 has interrupts, and the docs sayThe quadrature encoder can be “zeroed” by pulsing DIR low at any time. There is no need to do another WXPIN.
During reset (DIR=0), IN is low and Z is set to the adder value (0/1/-1)

So it looks like an interrupt from the Reset (Z) pin can SW reset ? - at up to ?? MHz speeds ?

c) The all-edges Quad mode is supported, but missing seems to be CLOCK and DIRECTION encoder support ?
It is common for Steppers to use CLK & DIRN, so an ability to 'clip onto' that control interface to extract position accumulate, is useful.

Using the nearby-mux feature, it should be possible to have a Stepper.CLK generated by NCO hardware or SW, and Stepper.DIRN by SW, and an attached smart pin, reading the (assumed) position.
Unclear if that could pack into 2 pin cells, issues are mainly around OUT.IN ? I think yes ?

( There is another mode that is Clock UP, Clock DN signals, and some gated (clock enable) modes )
To add CLK & DIRN looks trivial, but should that be a unique mode, or a sub-mode of Quadrature ?

Comments

b) is a non-issue. Setting the hardware counter is the wrong solution. Treat it as a read-only counter. Any use of quadrature counters is via software, so software can keep a copy of the "zero" positions to be used as needed.

c) would need a new mode. Although it could be merged with the plain A-input count-up mode, %MMMMM = 01101. The difficulty with making them a single mode is the B-input becomes active and has to be muted somehow if not wanting to use it. The best I came up with was to set the B-input selector config to %BBBB = 1100, and do an OUTH to that smartpin so that the forced high is treated as a steady low at the smartpin B input.

c) would need a new mode. Although it could be merged with the plain A-input count-up mode, %MMMMM = 01101. The difficulty with making them a single mode is the B-input becomes active and has to be muted somehow if not wanting to use it. The best I came up with was to set the B-input selector config to %BBBB = 1100, and do an OUTH to that smartpin so that the forced high is treated as a steady low at the smartpin B input.

Yes, that could give a means to disable & force, if the OUT bit is spare and available ?
That would allow CLK.DIRN as well as UP and DOWN counters, in the one mode.
It may simplify overall modes, as it gives a means to remove the B condition.

Another means to 'disable B' could be to test for (BBBB==AAAA,) as it makes little/no sense to map the SAME pin to a dual-pin use.
With that, you could add CLK and CLKENABLE modes to the COUNT A modes.

That said, I've not got my head around the differing descriptions in the later, more complex, counter modes. For example, %10111 = For periods in X+ clock cycles, count periods, might do the job ...

Not quite - those modes are for whole-entity counting, for higher precision measurements.
The >= X sets a minimum capture time, but that time rounds up to the next whole cycle of Fin

FWIR, this commentKnowing how many clock cycles some number of complete periods took, and what the duty was, affords a very time-efficient and precise means of determining frequency and duty cycle. At least two of these measurements must be made concurrently to get useful results. means there is a single capture destination, so if you want Time and Periods, you need two Pin cells working closely sync'd.
Likewise, if you want precise duty cycle, you need both LOW and HIGH time captures (of one, or many, whole cycles), that's also 2 Pin cells.

[/i] means there is a single capture destination, so if you want Time and Periods, you need two Pin cells working closely sync'd.
Likewise, if you want precise duty cycle, you need both LOW and HIGH time captures (of one, or many, whole cycles), that's also 2 Pin cells.

I'm guessing but the important part here is that B input can control A rise counting.

What I'm thinking is maybe the timeout can be set way high and effectively ignored. Then use two Smartpins, one counts up on A rises with B low say, and the other Smartpin counts up on A rises and B high. Then software subtracts the second Z from the first Z to get the total count.

"There's no huge amount of massive material
hidden in the rings that we can't see,
the rings are almost pure ice."

...
Another means to 'disable B' could be to test for (BBBB==AAAA,) as it makes little/no sense to map the SAME pin to a dual-pin use.
With that, you could add CLK and CLKENABLE modes to the COUNT A modes.

I also note X[] is used in other modes for control, so here X[31] could be used for Control-Via-B Enable , where B is CTR DIRN or CLK ENABLE, depending on mode, and that leaves X[30..0] as SysCLKs to measure over. That's still 13 seconds, at 160MHz so should be enough, more is easily managed in software as needed.

Here the Z pulse is synced with A/B and with direct reset/preset guaranty that, during the further rotation/movement , A/B signals are not lost

@evanh: b) is an issue. Because normal counter modules the counter increases and decreases AND (P)RESETS without user action, autonomously.
You can handle it via sw, but it will slow the bandwidth and/ore lose adjacent a/b pulses/edges
Having an internal/sw relative zero will force math operations between the real-time counter and internal zero memory. This math is not simple add/sub but also take in account the hw counter roll-over.

Pulse&Dir:
In this mode the rising-edge of A increase/decrease the counter based on state of B. This can be used with the same A/B/Z encoder (where also B pulses with 90° phase shift) but can be also used with any clock source on A and stable state on B.

An other thing I would like to understand is if there is an differential input mode (ed with adjacent pin) that beside for normal input can be also used in quadrature mode as many encoders provide differential outputs (so a total of 6 signals for A/B/Z).

How do you understand the floath output?
Is it open collector/drain with selectable stable/driven high/low state?
Using this will be enough to drive the out or, as P1, you will still need to drive DIR and preset OUT?
The former (driving OUT in any case) will make the code more compact in case of configurable drivers as it will be enough to setup it at the beginning and non continuously switch betbeen OUT and DIR instructions in the code.

You can handle it via sw, but it will slow the bandwidth and/ore lose adjacent a/b pulses/edges

Just don't go re-zeroing at speed. If there is concern for on-the-fly lost position then it's time to fix the faulty equipment.

Having an internal/sw relative zero will force math operations between the real-time counter and internal zero memory. This math is not simple add/sub but also take in account the hw counter roll-over.

Smartpin Z counter is 32 bit, the same as Cog natural integers. The maths is as simple as a single subtract.

"There's no huge amount of massive material
hidden in the rings that we can't see,
the rings are almost pure ice."

An other thing I would like to understand is if there is an differential input mode (ed with adjacent pin) that beside for normal input can be also used in quadrature mode as many encoders provide differential outputs (so a total of 6 signals for A/B/Z).

Nope. The closest is the USB modes but that's a special case with non-differential states as well.

It wouldn't be desirable anyway as it doubles the pin count requirement. Use cheap line receivers and save the Prop pins for something more useful.

"There's no huge amount of massive material
hidden in the rings that we can't see,
the rings are almost pure ice."

This is an answer of the person that only knows linear axis. There is also rotating axis where the the position are degrees.

Don't worry, using an offset as the zero reference makes no difference to the overall effort of managing rotating machinery. I've done my fair share in that department. Modulo'ing became almost invisible to me back in the day. I learnt pretty quickly that (x - limit > 0) was far superior to (x > limit). ie: everything becomes relative calculations even though the numbers are representing absolute positions.

An other thing I would like to understand is if there is an differential input mode (ed with adjacent pin) that beside for normal input can be also used in quadrature mode as many encoders provide differential outputs (so a total of 6 signals for A/B/Z).

USB modes have some form of Differential IP, not sure is that is true differential, or the common mode range it will have.
That may be limited to USB only, the DOCs are sparse on this detail.

You can still usefully use differential sensors, for the better EMC specs, just with single ended RX.

Keep in mind proper differential buffers have a much wider common mode tolerance than a CMOS logic process can give, so if you really need differential signals because everything is very noisy, you are best to put in proper RS485 like buffers.

I have a dumb question, what features from smart pins are available in the current FPGA images ? I'd assume anything ADC/DAC related is out, isn't it ?

Everything except the P's are done. I think the documented part below is correct for the FPGA. There is four external flash DACs routed to these config bits on the Prop123 boards and maybe some on the other boards too. The meaning of the P's will change for the final silicon.

It might be possible to get a whole megabyte of hub RAM with fewer cogs, but I doubt it. To get more RAM, we just need a smaller process. That is what would really do the trick.

How granular and layout-time-flexible, is the RAM sizing ?
It seems LSB of 4 is one constraint, a larger constraint is likely memory matrix size ?
eg if the cells are 128x256x16 bytes, ~ 15% of spare equivalent memory area could result in ~600,000 bytes, ~17% spare would allow a '600k' tag.

If I recall, the current 512KB of RAM takes over half of the space within the pad frame.

Yes, but the memory-footprint is a large XY matrix, so it is possible to change the size in other than 1:2:4 steps.
You should be able to 'fill with memory' as part of the design flow ? (my % examples were for spare-room increments, not the memory die-space usage estimates)

Jmg, I suppose that is possible. I've never asked OnSemi about any weird memory sizes, though.

I guess it depends on how well their memory compilers are written
I could understand needing to keep a rectangular array, and whole X or Y additions, but it should be practical (in theory) to allow intermediate RAM sizes