Differential versions for WAITPX, WAITPR and WAITPF
Ramon
Posts: 484
Chip,
The new IC pinout distribution is very smart and efficient. Did you inserted power pins every two pins just only for even thermal dissipation? or did you do that also because you were thinking to add differential signals in the future?
I think that this configuration with pins grouped in pairs and around a Vdd pin is great for differential signaling. The instruccions needed will look somewhat like this:
But I don't know if this is possible because there are only 2 instruction opcodes left:
Also because there is a Vdd pin every two pins, I wonder if the pin pair can be configured with other voltage different from 3.3V. Maybe this would allow LVDS with 2.5V. Or any other voltage or mode. But even if this is not possible, I think that the differential instructions are useful.
The new IC pinout distribution is very smart and efficient. Did you inserted power pins every two pins just only for even thermal dissipation? or did you do that also because you were thinking to add differential signals in the future?
I think that this configuration with pins grouped in pairs and around a Vdd pin is great for differential signaling. The instruccions needed will look somewhat like this:
WAITPPX = Wait for Pin Pair change WAITPPR = Wait for main Pin in Pair to Rise (*) WAITPPF = Wait for main Pin in Pair to Fall (*) WAITPP0 = Wait for both Pins in Pair to be 0 WAITPP1 = Wait for both Pins in Pair to be 1 (*) main pin in pair is always the lowest numbered pin. E.g. For (P0, P1), pair P0 is main pin
But I don't know if this is possible because there are only 2 instruction opcodes left:
--L- 1111111 00 L CCCC DDDDDDDDD xxxx00000 WAIT D/# (wait for some number of clocks, 0 same as 1) --L- 1111111 00 L CCCC DDDDDDDDD xxxx00001 WAITPX D/# (wait for any edge on pin D/#) --L- 1111111 00 L CCCC DDDDDDDDD xxxx00010 WAITPR D/# (wait for pos edge on pin D/#) --L- 1111111 00 L CCCC DDDDDDDDD xxxx00011 WAITPF D/# (wait for neg edge on pin D/#) --L- 1111111 00 L CCCC DDDDDDDDD xxxx00100 PUSH D/# (push D/# into 4-level stack) --L- 1111111 00 L CCCC DDDDDDDDD xxxx00101 SETVID D/# (set video mode) [b]--L- 1111111 00 L CCCC DDDDDDDDD xxxx00110 - D/# --L- 1111111 00 L CCCC DDDDDDDDD xxxx00111 - D/# [/b]
Also because there is a Vdd pin every two pins, I wonder if the pin pair can be configured with other voltage different from 3.3V. Maybe this would allow LVDS with 2.5V. Or any other voltage or mode. But even if this is not possible, I think that the differential instructions are useful.
Comments
- so that means no changes to existing opcodes are needed
The 5 instructions that I posted above cover all cases. So at least there is a need for two new opcodes. If single-ended an differential can be handled with the same opcode then there is a way to fit all 5 instructions in the current instruction set.
The pinout is for low noise in general rather than for differential signalling specifically. All I/O pins are analogue capable after all.
EDIT: I think I read somewhere they are grouped as 4 I/O pins per VIO pin. That may mean that each VIO can be it's own supply voltage in the 1.8 - 3.3 volt range, ie: The VIOs possibly aren't bonded together internally.
That's my recollection too. They were in groups of 8, now looks like groups of 4.
From an Analog performance point of view, I'm not sure whether we'll be better served by having a single big ground pad carrying all digital+analog currents, vs having vio grounds per set of 8 gpio. It'll be very low impedance, so probably...
(Bill, the x chips are using 65nm and 90nm. We cannot expect such miracle from 180nm.)
Cluso99 did request a USB helper Opcode, IIRC that used Z and C to get results of (M XOR P) and ( !M & !P)
With the new PinOpcodes, the pin-logic can do whatever simple pair-logic mapping was needed, to two pin outputs.
(ie one becomes SE0 and one is the data, or, one is NotDifferential and the other is LogicValue).
Cluso99 would probably need to revisit his USB code, to comment on what the issues are on this variant.
One of the problems with using WAITPP0/1 for differential is that the switching of the differential pins may not be quite symmetric (for a number of reasons). So a wait of this kind could give a false result due to transition errors. The idea with my USB is that I would be sampling close to the centre of the bit cycle and this would give a proper result. Otherewise, you need to re-verify the reading which takes valuable time.
but the first edge detect will always be non-centre - once you have that reference, others can be better centred - but the ideal is to check sync so it does not creep on Data.
If the Pin Cell can take two pins, and give
* NotDifferential
* LogicValue
On two Read paths, and maybe
* LogicOut
* Tristate enable
on two OUT paths for Send
What else do you need ?
Clock tolerance is 480.00 Mbit/s ±500 ppm, 12.000 Mbit/s ±2500 ppm, 1.50 Mbit/s ±15000 ppm
- and I think my PC here is ~ 200ppm high @ 12Mb, so that 2500 is not typical, but it is the spec limit
At that spec limit, it takes just 200 bit times to creep Half a bit off, at 12Mb, and just 33.3 bit times at 1.5Mb
Taking a measured typical of 250ppm is 2000 bit times, still well under a USB frame.
A USB frame at 12MHz is able to resolve to 83ppm, and @ 48MHz is 21ppm
Perhaps a P1+ can run a Frame based NCO digital Lock loop ?
( Other chips self-calibrate off the USB data fields.)
There, it could be better supported if the COG Counters were accessible to WAITP_ opcodes - ie map to virtual pins.