Since we know a supposed one-term opcode has apparent crosstalk issues, what is the result if you do try a two term opcode ?
Is this effect even worse ?
ie try FLTH, which should be the same logic-time-changes as DIRL, (OUT unchanged when DIR changes) and also
try FLTL, which adds a further possible break-before-make skew issue. (both flip in one opcode)
Some of you had asked about what the source code errors looked like, regarding the $signed() problem.
Here is a line that caused a problem. Note that it uses $signed() to sign-extend an ry1 bitfield, but because rx1 was not also a signed type, it didn't do any sign extension on the ry1 bitfield. Well, the Altera Verilog compiler did, but the ASIC Verilog compiler did not:
All these $signed() problems have been remedied and the circuits re-tested on the FPGA to make sure I didn't break anything. The ASIC compiler will not demote what need to be signed operations, next time, because I've followed the rules of EVERY term on the right-hand side of the equation being of a signed type, in order to ensure a signed operation is recognized and compiled.
I looked at my Verilog source and my synthesized logic outputs both OUT and DIR signals directly from flip-flops, so there is no way this glitch should be happening. The only thing I can figure is that ON Semi's test logic, which goes in-between my flop outputs and the I/O pad inputs is mixing OUT and DIR in some logical fashion and glitching OUT when DIR changes. I will ask Wendy about this tomorrow. They met the setup and hold requirements for the OUT flop in the I/O pin, but the OUT glitches when DIR goes low. There will be some way to fix this, I'm sure, by changing the way the on-chip test circuitry is organized. This is totally unexpected.
I just discovered, as Peter pointed out, that VDD has something to do with the negative-glitch voltage. This is strange.
.. The only thing I can figure is that ON Semi's test logic, which goes in-between my flop outputs and the I/O pad inputs is mixing OUT and DIR in some logical fashion and glitching OUT when DIR changes. I will ask Wendy about this tomorrow.
That would need quite broken test insertion, as it should vanish logically when not in test mode.
They met the setup and hold requirements for the OUT flop in the I/O pin, but the OUT glitches when DIR goes low. There will be some way to fix this, I'm sure, by changing the way the on-chip test circuitry is organized. This is totally unexpected.
The key bit is OUT glitches when DIR goes low - it's not proven the cause of this crosstalk is test-modes related yet.
- can you confirm the test pad chip does not do this ?
I think I understand what is happening with the glitch. Indeed, the relationship between VDD and VIO does have an effect on the glitch. The greater the delta between VDD and VIO, the longer the glitch lasts, resulting in a lower voltage.
This doesn't have anything to do with test logic, after all. It seems to just be simple crosstalk between DIR and OUT. When they are both high and DIR is switched low, DIR induces a brief negative pulse on OUT which recovers to high before the setup/hold window for the OUT flop inside the pad.
I looked at our pad layout and the DIR and OUT signals are far apart. It must be coming from the synthesized logic and its long wire runs. I did not observe this phenomenon on the test chip.
I think I understand what is happening with the glitch. Indeed, the relationship between VDD and VIO does have an effect on the glitch. The greater the delta between VDD and VIO, the longer the glitch lasts, resulting in a lower voltage.
This doesn't have anything to do with test logic, after all. It seems to just be simple crosstalk between DIR and OUT. When they are both high and DIR is switched low, DIR induces a brief negative pulse on OUT which recovers to high before the setup/hold window for the OUT flop inside the pad.
I looked at our pad layout and the DIR and OUT signals are far apart. It must be coming from the synthesized logic and its long wire runs. I did not observe this phenomenon on the test chip.
How many pins show this effect, or how does it vary across all the pins ?
Where is the Core<->Vio level shift done - is that in synthesized logic, or in the PAD Ring ?
What are the switching points of that level translator ?
Ouch, that's a problem. It's a problem for any long run parallel signals. I hope that rules can be applied to keep long parallel runs a certain distance apart. Ideally, the minimum spacing be proportional to parallel length.
It seems that all pins exhibit this issue to some extent, but P59 is particularly bad. This variance points to the synthesized logic.
The level shifters are in the pad circuits. They are built from weak back-to-back inverters that hold state and must be tripped to change state. 3.3V NMOS's, with their Vgs only reaching VDD (1.8V), are used to trip the 3.3V back-to-back inverters with weak PMOS devices in them.
If it is related to the internal logic voltage, couldn't it be, that the level translators have a threshold, that is independent of the voltage, so that variations of the voltage shift the switching time?
Looking at many different pins, some of these glitches are almost non-existent, while P59 is really bad. Next time around, the router will have to be given some special instruction on shielding the OUT signals.
If it is related to the internal logic voltage, couldn't it be, that the level translators have a threshold, that is independent of the voltage, so that variations of the voltage shift the switching time?
Exactly. Those voltage variations effect all the pins together, while each pin also has a unique/fixed personality.
Here are two pins, P59 (top) and P58 (bottom), being driven high, then floated. These pins are right next to each other, but P59 has much more of a glitch than P58. This is due solely to auto-generated layout differences between the pins' OUT and DIR signals.
I emailed Wendy about this. We could skew-band the OUT signals to make sure that they transition in near-unison, and then we could shield them to prevent glitches. Might as well do the same thing with the DIR signals.
I will try all the I/O pins later although P0 did exhibit the same characteristics so perhaps that might vary chip to chip. At present I have a shunt and probe pins installed in the 1.8V line (between the vias to the right of the crystal) and I am taking some measurements.
Another question regarding the PLL, is it 100 to 400MHZ or 200MHZ range? I have clock control words but I'm also adding a layer on top of that so that we can specify the input frequency and target frequency and have the correct values calculated.
I will try all the I/O pins later although P0 did exhibit the same characteristics so perhaps that might vary chip to chip. At present I have a shunt and probe pins installed in the 1.8V line (between the vias to the right of the crystal) and I am taking some measurements.
Another question regarding the PLL, is it 100 to 400MHZ or 200MHZ range? I have clock control words but I'm also adding a layer on top of that so that we can specify the input frequency and target frequency and have the correct values calculated.
12 M OSCILLATOR 180 M P2CLOCK
Here is my all-pin glitch test program. Just run it and you can check all 64 pins:
The VCO should run from 100MHz...200MHz, or overclocked. If you are running the chip at 100MHz+, you should be using the direct VCO output (PPPP = %1111), instead of dividing it.
Many of my I/O pins show the glitch. In fact where lsio shows a pulldown, then they are the same pins that glitch.
TAQOZ# lsio
P:00000000001111111111222222222233333333334444444444555555555566
P:01234567890123456789012345678901234567890123456789012345678901
=:ddd~d~~~~~~ddd~ddd~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~hhh ok
TAQOZ#
Chip, what does your lsio command show? Some of the pins had partial glitches that didn't quite pull down as much so these aren't showing up as pulldowns.
@Rayman -nothing at all do with a pullup or the fact that we happen to use it for boot detect. We had to put a pullup on it because P59 floating is for a normal startup and P59 pulled down would inhibit all serial boot operations which is the case if we leave it "floating" but the glitch makes it appear that it has a pulldown.
BTW - this is the 1.8V current I measured at different clock frequencies.
1.8V supply current
. While reading with interest, I can't help but notice Peter how effective forth is. This stage is perfect for it. I'm glad to see this in action. It's going to help a lot of us. Nice work.
Is it possibly to use the smartpin modes to do simple things like DRVH, DRVL, FLTH?
I see things in the docs that make me think you could.
It's been so long since I looked that that stuff...
Anyway, would this glitch show up if doing this via smartpin?
In order to do a fair compare with data already gathered by Chip, shown at the spreadsheet attached to the following linked post (September 28), how many Cogs were active, during your readings?
This glitch would probably never really affect anything other than checking for a floating pin. Other than the fact that it stuffed up our boot detection, I wouldn't worry about it otherwise. Usually when we use a pin as an output, it stays that way, but even if we did float it back to an input it would still work.
Smartpins don't flip from output to input so this "glitch" would not show up. The only reason we investigated the glitch is because you may remember that when Chip first tried to get the P2 to talk via serial, it wouldn't talk. After he found he had to add a pullup on P59 Chip thought that the boot firmware had been changed but that definitely wasn't the case. Now we know that P59 was glitching and making it appear that it had a pulldown which is why we added the pullup to compensate.
BTW - Forth is extremely useful for debugging hardware and while I use "one liners" they are not meant to be verbose multi-line commented code although you can do that. I just like to show what can be accomplished in one line plus it makes sense only when you stop thinking in the language you know that is so different to the one that you don't know. But once you do know it, it seems simple.
A one-liner we may know:
Peter Piper picked a peck of pickled peppers.
How some programmers may write it:
Peter \ some guy
Piper \ oh, that guy
picked \ the action
a peck \ the amount
of \ set peck attributes
pickled peppers \ what was picked
A one-liner in Forth to configure individual clock mode parameters:
30PF PLLEN 12 XIDIV 228 VCOMUL 1 PLLDIV USEPLL
How I could write it:
30PF \ select 30PF loading with XI active
PLLEN \ enable the PLL
12 XIDIV \ Set the XI divider to 12 ( 12MHZ OSC )
228 VCOMUL \ configure the VCO to multiply by 228
1 PLLDIV \ don't divide the output of the PLL
USEPLL \ Apply configuration and then use PLL as the P2 CLOCK source
But of course from these "components" I create other components so that I can end up saying:
Looking at many different pins, some of these glitches are almost non-existent, while P59 is really bad. Next time around, the router will have to be given some special instruction on shielding the OUT signals.
Hmm... there is another variant test for this effect, which is to test all pins at the same time.
Now, you have all DIR nodes changing, which would be expected to show worse cross talk effects. (Varying with routing, of course)
A spice run on the layout could confirm this?
Differential signals have less crosstalk, but that’s more routes & it’s not clear how the pad-ring would connect ?
This section seems to imply that you can float or drive pins:
%P..P: low-level pin control (needs final silicon to fully operate)
%0000CIOHHHLLL = digital mode (default = %0000000000000)
%C: 1 = clocked I/O (extra clock for IN and OUT)
%I: 1 = invert IN output
%O: 1 = invert OUT input
%HHH: 000 = drive high, other = float when driven high
%LLL: 000 = drive low, other = float when driven low
What boggles me with forth is the erratic order of parameters and lack of formatting to say what relates to what. I could be looking at machine code.
Arguments first, then words. That is what makes Forth so darn small. A parser happens as an artifact of building the words needed.
Toggle Pin 1 @ 50 Mhz for 1 second becomes:
1 pin 50 mhz 1 toggle
(Depending on how words were defined)
1 goes onto the stack
Pin is a word and executes consuming whatever is on top of stack
50 goes on top of stack
Word
Argument
Etc...
With just that, most of what Peter put here so far can be understood.
Some words need more. So it all goes on the stack before the word hits, so the word can get what it needs. Or, words leave stuff other words, or you need.
So a bigger word could be togglepin
1 50 2 togglepin = toggle pin 1 at 50 mhz for 2 seconds.
Peter,
Can you try the worst pins using just the DIR, IN and OUT registers via MOV instructions rather than using the special DRVx instructions?
The P2 1v8 core current is much higher overall than I was expecting/hoping. Do you have all cogs running? I forget if you changed the TAQOZ ROM to start only one cog.
Did you have time to test the P2D2 board with the P2 chip before you shipped to Lachlan? Will be nice to see results from those guys too.
Bump got rid of the .mp4 restriction and upped the attachment size to 10MB, to boot.
Here is that .mp4 file of the Goertzel circuit taking 10us measurements, looking for 10.0MHz, while my function generator swept from 9.5MHz to 10.5MHz over 1ms. The P2 was running at 200MHz:
Comments
Is this effect even worse ?
ie try FLTH, which should be the same logic-time-changes as DIRL, (OUT unchanged when DIR changes) and also
try FLTL, which adds a further possible break-before-make skew issue. (both flip in one opcode)
Here is a line that caused a problem. Note that it uses $signed() to sign-extend an ry1 bitfield, but because rx1 was not also a signed type, it didn't do any sign extension on the ry1 bitfield. Well, the Altera Verilog compiler did, but the ASIC Verilog compiler did not:
Wherever possible, I got rid of $signed() and did things the discrete, unmistakable way. That line above got rewritten into this:
wire [11:0] rx2_x = ra1[7] ? rx1 + {ry1[11], ry1[11:1]} : rx1 - {ry1[11], ry1[11:1]};All these $signed() problems have been remedied and the circuits re-tested on the FPGA to make sure I didn't break anything. The ASIC compiler will not demote what need to be signed operations, next time, because I've followed the rules of EVERY term on the right-hand side of the equation being of a signed type, in order to ensure a signed operation is recognized and compiled.
I looked at my Verilog source and my synthesized logic outputs both OUT and DIR signals directly from flip-flops, so there is no way this glitch should be happening. The only thing I can figure is that ON Semi's test logic, which goes in-between my flop outputs and the I/O pad inputs is mixing OUT and DIR in some logical fashion and glitching OUT when DIR changes. I will ask Wendy about this tomorrow. They met the setup and hold requirements for the OUT flop in the I/O pin, but the OUT glitches when DIR goes low. There will be some way to fix this, I'm sure, by changing the way the on-chip test circuitry is organized. This is totally unexpected.
I just discovered, as Peter pointed out, that VDD has something to do with the negative-glitch voltage. This is strange.
Maybe the forum code is modifying your image because first I can see 1MB and downloaded only 174KB.
It only contains 1 frame.
The key bit is OUT glitches when DIR goes low - it's not proven the cause of this crosstalk is test-modes related yet.
- can you confirm the test pad chip does not do this ?
This doesn't have anything to do with test logic, after all. It seems to just be simple crosstalk between DIR and OUT. When they are both high and DIR is switched low, DIR induces a brief negative pulse on OUT which recovers to high before the setup/hold window for the OUT flop inside the pad.
I looked at our pad layout and the DIR and OUT signals are far apart. It must be coming from the synthesized logic and its long wire runs. I did not observe this phenomenon on the test chip.
How many pins show this effect, or how does it vary across all the pins ?
Where is the Core<->Vio level shift done - is that in synthesized logic, or in the PAD Ring ?
What are the switching points of that level translator ?
It seems that all pins exhibit this issue to some extent, but P59 is particularly bad. This variance points to the synthesized logic.
The level shifters are in the pad circuits. They are built from weak back-to-back inverters that hold state and must be tripped to change state. 3.3V NMOS's, with their Vgs only reaching VDD (1.8V), are used to trip the 3.3V back-to-back inverters with weak PMOS devices in them.
Exactly. Those voltage variations effect all the pins together, while each pin also has a unique/fixed personality.
Here are two pins, P59 (top) and P58 (bottom), being driven high, then floated. These pins are right next to each other, but P59 has much more of a glitch than P58. This is due solely to auto-generated layout differences between the pins' OUT and DIR signals.
I emailed Wendy about this. We could skew-band the OUT signals to make sure that they transition in near-unison, and then we could shield them to prevent glitches. Might as well do the same thing with the DIR signals.
Another question regarding the PLL, is it 100 to 400MHZ or 200MHZ range? I have clock control words but I'm also adding a layer on top of that so that we can specify the input frequency and target frequency and have the correct values calculated.
Here is my all-pin glitch test program. Just run it and you can check all 64 pins:
The VCO should run from 100MHz...200MHz, or overclocked. If you are running the chip at 100MHz+, you should be using the direct VCO output (PPPP = %1111), instead of dividing it.
Right, and you can always enable OUT registering within the pad. That really perfects timing.
@Rayman -nothing at all do with a pullup or the fact that we happen to use it for boot detect. We had to put a pullup on it because P59 floating is for a normal startup and P59 pulled down would inhibit all serial boot operations which is the case if we leave it "floating" but the glitch makes it appear that it has a pulldown.
BTW - this is the 1.8V current I measured at different clock frequencies.
1.8V supply current
I see things in the docs that make me think you could.
It's been so long since I looked that that stuff...
Anyway, would this glitch show up if doing this via smartpin?
Hi Peter Jakacki
In order to do a fair compare with data already gathered by Chip, shown at the spreadsheet attached to the following linked post (September 28), how many Cogs were active, during your readings?
https://forums.parallax.com/discussion/comment/1446960/#Comment_1446960
Henrique
Smartpins don't flip from output to input so this "glitch" would not show up. The only reason we investigated the glitch is because you may remember that when Chip first tried to get the P2 to talk via serial, it wouldn't talk. After he found he had to add a pullup on P59 Chip thought that the boot firmware had been changed but that definitely wasn't the case. Now we know that P59 was glitching and making it appear that it had a pulldown which is why we added the pullup to compensate.
BTW - Forth is extremely useful for debugging hardware and while I use "one liners" they are not meant to be verbose multi-line commented code although you can do that. I just like to show what can be accomplished in one line plus it makes sense only when you stop thinking in the language you know that is so different to the one that you don't know. But once you do know it, it seems simple.
A one-liner we may know:
How some programmers may write it:
A one-liner in Forth to configure individual clock mode parameters:
How I could write it:
But of course from these "components" I create other components so that I can end up saying: or
Hmm... there is another variant test for this effect, which is to test all pins at the same time.
Now, you have all DIR nodes changing, which would be expected to show worse cross talk effects. (Varying with routing, of course)
A spice run on the layout could confirm this?
Differential signals have less crosstalk, but that’s more routes & it’s not clear how the pad-ring would connect ?
%P..P: low-level pin control (needs final silicon to fully operate) %0000CIOHHHLLL = digital mode (default = %0000000000000) %C: 1 = clocked I/O (extra clock for IN and OUT) %I: 1 = invert IN output %O: 1 = invert OUT input %HHH: 000 = drive high, other = float when driven high %LLL: 000 = drive low, other = float when driven lowArguments first, then words. That is what makes Forth so darn small. A parser happens as an artifact of building the words needed.
Toggle Pin 1 @ 50 Mhz for 1 second becomes:
1 pin 50 mhz 1 toggle
(Depending on how words were defined)
1 goes onto the stack
Pin is a word and executes consuming whatever is on top of stack
50 goes on top of stack
Word
Argument
Etc...
With just that, most of what Peter put here so far can be understood.
Some words need more. So it all goes on the stack before the word hits, so the word can get what it needs. Or, words leave stuff other words, or you need.
So a bigger word could be togglepin
1 50 2 togglepin = toggle pin 1 at 50 mhz for 2 seconds.
I see Peter did a more proper post. Good.
228MHz 637ma
A tmds rate of 250MHz is needed for hdmi 480P (848x480 visual pixels)
How likely would it be to officially support 250MHz?
Can you try the worst pins using just the DIR, IN and OUT registers via MOV instructions rather than using the special DRVx instructions?
The P2 1v8 core current is much higher overall than I was expecting/hoping. Do you have all cogs running? I forget if you changed the TAQOZ ROM to start only one cog.
Did you have time to test the P2D2 board with the P2 chip before you shipped to Lachlan? Will be nice to see results from those guys too.
Here is that .mp4 file of the Goertzel circuit taking 10us measurements, looking for 10.0MHz, while my function generator swept from 9.5MHz to 10.5MHz over 1ms. The P2 was running at 200MHz: