Do you think what I called “smart cell” as “smartpin”?
Yes, it's easy to think of that one block as a processor in its own right.
Also, the whole custom ring side is entirely separate both geographically and development wise. The smartpin feature set didn't evolve until quite late and there was substantial change in the verilog over that time.
Geographically, there is a long route out from the cluster of synthesised logic around the smartpins to the physical pad ring. I'd bet they are right in the centre of the die.
The first three smartpin modes, DAC noise, DAC 16-bit dither(noise) and 16-bit dither(PWM) are feed the DAC. They need a way to get 8-bit data to the DAC network.
Do you think what I called “smart cell” as “smartpin”?
Yes, it's easy to think of that one block as a processor in its own right.
It is actually the main reason I made the first ascii drawing. I wanted to point out how the pin modes have quite some independence of the smartpin modes.
Is there an M where OUT goes directly to SMART_OUT? If so, maybe show in same way as IN...
I did have it like that in first drawing but OUT is not used as an input by the smartpin processor in any way. So I've got the T block (Logic Output) handling all the OUT spaghetti routing.
PS: And you'll note I've got DIR going to both, because DIR is used to reset the smartpin processor as well as pin output enable.
Do you think what I called “smart cell” as “smartpin”?
Yes, it's easy to think of that one block as a processor in its own right.
It is actually the main reason I made the first ascii drawing. I wanted to point out how the pin modes have quite some independence of the smartpin modes.
This solidified for me after I got a streamer outputting to a smartpin and that smartpin outputting to its pin all in the one WRPIN config, ie: OUT was being used as an input (Via the F block importantly) to the smartpin while simultaneously the smartpin could still drive the output!
EDIT: When I say importantly, this is because it needed an A/B selection of OUT to be made. So the smartpin processor only sees it as A and B inputs.
Okay, I could have OUT going directly to the F block instead going via the T block ... I might have to separate OUT into two to prevent clutter though.
EDIT: Okay, certainly easier to do it that way.
EDIT2: Err, no, retesting it finds that's wrong. DIR definitely plays a part at that point. OUT has to go through the T block first.
PS: Exploding the T block would be most useful next thing to attempt.
Chip,
Thought I start with the easy block and tried to get my head around the de-glitch wiring in the F block. Turns out I haven't got a handle on that at all.
The principle of it is easy enough but I'm struggling to sort out how the global part of it works. Each instance has to take L samples at T interval with unanimous state changes. Problem I'm struggling with is how these two parameters become effective, via the four global filt, at the F blocks? It can't just be a bit line for each global filt.
Chip,
Thought I start with the easy block and tried to get my head around the de-glitch wiring in the F block. Turns out I haven't got a handle on that at all.
The principle of it is easy enough but I'm struggling to sort out how the global part of it works. Each instance has to take L samples at T interval with unanimous state changes. Problem I'm struggling with is how these two parameters become effective, via the four global filt, at the F blocks? It can't just be a bit line for each global filt.
Using the HUBSET instruction, you can set each of the four global filter settings. On a per-pin basis, you can select one of those four filter settings. If I recall, the hub outputs the four sets of 1-bit enables and 2-bit filter sizes (12 bits, in all), while the pin muxes the specific enable and filter-size signals, using local flops to realize the actual filter.
Rayman,
OUT does not go to the smartpin processor. The only way OUT reaches there is via A/B input selection in the F block.
Whicker,
I'm not sure how informative those would be. There is also other places where staging flops exist other than just the extra for distance/fanout.
Wuerfel_21,
The GETSCP scope feature uses the RDPIN data buses to gather it's data I believe.
Chip's diagram stops at the dotted line. It only covers the custom pad ring. It was very helpful for nailing down exactly what should be drawn on each side of that line though. It also confirmed a number of things like output+enable rather than driveH+driveL.
Definitely not! It just goes to two DACs is all. The main one is low impedance, the comparator one is high impedance.
EDIT: Actually, it's not specifically just a DAC bus at that stage. It's actaully M[7:0], as per the old Pad I/O Modes sheet, and gets used for config too. At any rate there is no bidirectional signals crossing the dotted line between the custom ring and the synthesised core.
EDIT: PI is the only input signal crossing the dotted line. This is what goes into the F block in my diagrams and eventually becomes IN at the cogs. PO is what I've called Output. DIR I've called Enable because DIR from a cog is not always what is controlling it.
One interesting trivia to come from examining Chip's diagram is that "Input" within the pad ring is slightly different to the PI that crosses the dotted line. Practically, they are the same signal though. I don't see any mode, namely with ADC operating, that uses them separately.
What I've called SmartOUT, Chip has just called SMART in the %TT section in the main doc. So there is three possible sources (OUT/Other/SmartOUT) for both Output and BitDAC.
DAC_MODE in Chip's docs is not a specific data path so I've dropped its use. DAC mode is a setting to switch over to using the DAC network instead of the logic drive circuit. You could say the two blocks across the top of my diagram is DAC mode.
Comments
Also, the whole custom ring side is entirely separate both geographically and development wise. The smartpin feature set didn't evolve until quite late and there was substantial change in the verilog over that time.
Geographically, there is a long route out from the cluster of synthesised logic around the smartpins to the physical pad ring. I'd bet they are right in the centre of the die.
I'll think about "Smart Cell" name... Maybe "Smart Pin" is better...
PS: And you'll note I've got DIR going to both, because DIR is used to reset the smartpin processor as well as pin output enable.
EDIT2: Drawing reinstated
EDIT: When I say importantly, this is because it needed an A/B selection of OUT to be made. So the smartpin processor only sees it as A and B inputs.
EDIT: Okay, certainly easier to do it that way.
EDIT2: Err, no, retesting it finds that's wrong. DIR definitely plays a part at that point. OUT has to go through the T block first.
PS: Exploding the T block would be most useful next thing to attempt.
Thought I start with the easy block and tried to get my head around the de-glitch wiring in the F block. Turns out I haven't got a handle on that at all.
The principle of it is easy enough but I'm struggling to sort out how the global part of it works. Each instance has to take L samples at T interval with unanimous state changes. Problem I'm struggling with is how these two parameters become effective, via the four global filt, at the F blocks? It can't just be a bit line for each global filt.
Using the HUBSET instruction, you can set each of the four global filter settings. On a per-pin basis, you can select one of those four filter settings. If I recall, the hub outputs the four sets of 1-bit enables and 2-bit filter sizes (12 bits, in all), while the pin muxes the specific enable and filter-size signals, using local flops to realize the actual filter.
@Evanh: Chip said Out should go to "Smart Cell" (or whatever we should call it). You have it just going to Logic Output... Should it go to both?
Edit: Also changed COMP_DAC to Comp&DAC...
Like this:
That's right.
Plus it takes even more clocks to get to and from each cog. I'm hoping someone could shed some light where the clock delays are in the diagram.
OUT does not go to the smartpin processor. The only way OUT reaches there is via A/B input selection in the F block.
Whicker,
I'm not sure how informative those would be. There is also other places where staging flops exist other than just the extra for distance/fanout.
Wuerfel_21,
The GETSCP scope feature uses the RDPIN data buses to gather it's data I believe.
Definitely not! It just goes to two DACs is all. The main one is low impedance, the comparator one is high impedance.
EDIT: Actually, it's not specifically just a DAC bus at that stage. It's actaully M[7:0], as per the old Pad I/O Modes sheet, and gets used for config too. At any rate there is no bidirectional signals crossing the dotted line between the custom ring and the synthesised core.
EDIT: PI is the only input signal crossing the dotted line. This is what goes into the F block in my diagrams and eventually becomes IN at the cogs. PO is what I've called Output. DIR I've called Enable because DIR from a cog is not always what is controlling it.
Is this better?
DAC_MODE in Chip's docs is not a specific data path so I've dropped its use. DAC mode is a setting to switch over to using the DAC network instead of the logic drive circuit. You could say the two blocks across the top of my diagram is DAC mode.