Here's logic diagram of the output logic (T-block). A lot more guessing for this one. I've renamed the OUT that goes to the input selectors, called it "OUTin"
And edited the block diagram to fit the new "OUTin" name and also put the inverter back on "Other". This is needed so that the T-block is then identical for both even and odd pins.
I think the big inverter is actually a good idea because it highlights what is really the main difference between even and odd pins in the pair...
Orange might help too...
Ah, now I remember, the final OUT from the cogs is already AND'ed with the final DIR. That was something that was highlighted with the pin glitch issue that OnSemi refined for Chip.
So, my T-block AND'ing is extraneous ... although it does do a good job of showing what happens a little further back towards the cogs.
Probably best to follow Chip's naming though. That means another change to show OUT routed, as per Chip's naming, direct to the F-block inputs ...
So OUTin is back to OUT again in the block diagram. And Instead of shuffling a whole lot to make room for the route I've just passed it through the T-block untouched.
Done the DAC bus mux'ing (P-block) too now. It involves a four mode control links back to T-block. Not too surprisingly, these two blocks are somewhat intertwined. So I've updated the internals of T-block to suit.
I won't change the block diagram though, since control/config wasn't intended to be part of it.
I could use M[7:0] naming in place of the DACbus label. When operating in DAC mode, M[7:0] bits are the data path for the DAC network.
The M bits have two modes of their own: The upper bits are primarily just encoded control lines. But the lower eight bits, in particular, swap between being config bits and being a data flow bus depending on the upper control bits.
PS: Interestingly, this helps highlight that there is a distinction between the P field of WRPIN and the low level M bits of the pad ring. WRPIN fills a register in the synthesised logic for the pin. The M bits are not a register at all. These P field register bits don't always map directly to the M bits.
Question..
Does the "Smart B" input to the USB D- (USB Brain) and the "Smart B" input to the USB D+ (USB Passive) come via the "Logic Input %A_B_F" block?
The reason I ask is that I thought the pin came direct, not via the mux.
IIRC from my USB playing years ago, effectively the D- and D+ pins are swapped (from a software point of view) when changing from USB LS to USB FS. This was a trick to utilise the same software routines for LS and FS. I wasn't sure it was possible to swap the input pins in the P2 USB implementation???
Question..
Does the "Smart B" input to the USB D- (USB Brain) and the "Smart B" input to the USB D+ (USB Passive) come via the "Logic Input %A_B_F" block?
The reason I ask is that I thought the pin came direct, not via the mux.
IIRC from my USB playing years ago, effectively the D- and D+ pins are swapped (from a software point of view) when changing from USB LS to USB FS. This was a trick to utilise the same software routines for LS and FS. I wasn't sure it was possible to swap the input pins in the P2 USB implementation???
On RevB+ the DM/DP pins only need to be configured once by pin# via DIRL WRPIN DIRH to set host/device and driven/sniffer modes. FS/LS signaling is determined when the NCO is configured via WXPIN, which can be done "on the fly". Very cool.
Given that Chip has added special control logic just so the USB smartpins can dynamically manage the config of the pin pair it's hard to guess in detail how it works.
In an even/odd pair, all the USB smart pin logic is in the even pin. The odd pin just has conduit for control from the even pin. The even pin controls HHH and LLL modes for both pins in the pair.
My take is he's got it directly twiddling the low level pad ring M bits for pin input modes too - Which bypasses the P field of WRPIN. Chances are the actual USB incoming data bits are still flowing via the F-block though. It'll just be in default pass-through mode because the trickery is being done with the pad ring.
EDIT: Ten edits later, I think I've fixed all the typos and messaging mishaps. Getting way too tired.
Go for it. I had left it there because that bit looks like spare for more smartpin modes, but also because AKPIN is an alias of WRPIN with that bit set. Neither really matters.
For digital output, the streamers are wired same as the cogs are - In a big chain of OR gates. All sources are equal. Any one cog or streamer can set an OUT high.
I don't know what pin modes are associated the TDMS encoding but I'd guess OUTs rather than DACs.
Huh, you know, I'd assumed the DAC buses are all mux'd, but it's possible that at least some sources could be OR'd like the OUTs.
Nice Rayman! I actually find your table format much easier to read. There's something very daunting about that original picture (too dense for me). You might need another small legend at the right for the "O" bit, i.e. the output being inverted or not. That was missing.
They do map 1:1 but there is an operational difference between the P field and M control bits. There are times when parts of the P field are overridden, DAC mode in particular. USB smartpin modes too.
Comments
Orange might help too...
So, my T-block AND'ing is extraneous ... although it does do a good job of showing what happens a little further back towards the cogs.
Probably best to follow Chip's naming though. That means another change to show OUT routed, as per Chip's naming, direct to the F-block inputs ...
So OUTin is back to OUT again in the block diagram. And Instead of shuffling a whole lot to make room for the route I've just passed it through the T-block untouched.
If you have a tidy way to show OUT routed to the F-block directly then I'll be keen to use it.
I won't change the block diagram though, since control/config wasn't intended to be part of it.
EDIT: Fixed an error with logic of cogDACmode.
The M bits have two modes of their own: The upper bits are primarily just encoded control lines. But the lower eight bits, in particular, swap between being config bits and being a data flow bus depending on the upper control bits.
PS: Interestingly, this helps highlight that there is a distinction between the P field of WRPIN and the low level M bits of the pad ring. WRPIN fills a register in the synthesised logic for the pin. The M bits are not a register at all. These P field register bits don't always map directly to the M bits.
Does the "Smart B" input to the USB D- (USB Brain) and the "Smart B" input to the USB D+ (USB Passive) come via the "Logic Input %A_B_F" block?
The reason I ask is that I thought the pin came direct, not via the mux.
IIRC from my USB playing years ago, effectively the D- and D+ pins are swapped (from a software point of view) when changing from USB LS to USB FS. This was a trick to utilise the same software routines for LS and FS. I wasn't sure it was possible to swap the input pins in the P2 USB implementation???
On RevB+ the DM/DP pins only need to be configured once by pin# via DIRL WRPIN DIRH to set host/device and driven/sniffer modes. FS/LS signaling is determined when the NCO is configured via WXPIN, which can be done "on the fly". Very cool.
My take is he's got it directly twiddling the low level pad ring M bits for pin input modes too - Which bypasses the P field of WRPIN. Chances are the actual USB incoming data bits are still flowing via the F-block though. It'll just be in default pass-through mode because the trickery is being done with the pad ring.
EDIT: Ten edits later, I think I've fixed all the typos and messaging mishaps. Getting way too tired.
Is there a reason to leave it?
I think it has to come from the streamer inputs, right?
But, I think it goes to logic drive and not to DAC...
I don't know what pin modes are associated the TDMS encoding but I'd guess OUTs rather than DACs.
Huh, you know, I'd assumed the DAC buses are all mux'd, but it's possible that at least some sources could be OR'd like the OUTs.
EDIT: Remove incorrect reference to wired-OR.
This thing in the Docs is pretty bad... Not least of all because it says %M..M instead of %P..P.
I changed Input to IN for consistency, but it might not be correct...
Update: See revision below...
See revised version below...
PS: I made a text version of that table for the same reason - https://forums.parallax.com/discussion/comment/1452036/#Comment_1452036