Shop Learn
New P2 Silicon Observations - Page 9 — Parallax Forums

New P2 Silicon Observations

1679111223

Comments

  • jmgjmg Posts: 14,665
    edited 2018-10-04 04:45
    cgracey wrote: »
    Peter, Ray, instead of doing a FLTL, try a DIRL.
    I already do a DIRL.
    ' F - float pin
    F               _ret_   dirl    pinreg
    
    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)


  • cgraceycgracey Posts: 13,588
    edited 2018-10-04 05:00
    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:
    assign rx2_x = ra1[7] ? rx1 + $signed(ry1[11:1]) : rx1 - $signed(ry1[11:1]);
    

    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.
  • cgraceycgracey Posts: 13,588
    edited 2018-10-04 05:42
    Regarding this drive-to-float glitch on P59...

    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.
  • cgracey wrote: »

    Well, I can't seem to get the .gif to work. Any ideas?

    Maybe the forum code is modifying your image because first I can see 1MB and downloaded only 174KB.

    It only contains 1 frame.
  • jmgjmg Posts: 14,665
    edited 2018-10-04 05:16
    cgracey wrote: »
    .. 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.
    cgracey wrote: »
    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 ?

  • cgraceycgracey Posts: 13,588
    edited 2018-10-04 07:47
    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.
  • yeah that could make sense
  • jmgjmg Posts: 14,665
    cgracey wrote: »
    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 ?
  • evanhevanh Posts: 10,951
    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.

  • cgraceycgracey Posts: 13,588
    edited 2018-10-04 08:42
    Jmg,

    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.
  • ErNaErNa Posts: 1,579
    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?
  • cgraceycgracey Posts: 13,588
    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.
  • cgraceycgracey Posts: 13,588
    edited 2018-10-04 09:24
    ErNa wrote: »
    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.


    2048 x 1152 - 720K
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-10-04 09:24
    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
    
  • evanhevanh Posts: 10,951
    I suppose it is only async drives that this applies to. OUT and DIR will be the only cases of this type.
  • cgraceycgracey Posts: 13,588
    edited 2018-10-04 09:57
    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:
    dat	org
    
    .loop	mov	outa,#0
    	mov	outb,#0
    	neg	dira,#1
    	neg	dirb,#1
    	waitx	#10
    	neg	outa,#1
    	neg	outb,#1
    	waitx	#10
    	mov	dira,#0
    	mov	dirb,#0
    	waitx	#10
    	jmp	#.loop
    
    clkena	long	%0000_0000_000_0000100000000_00_00000_0
    

    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.
  • cgraceycgracey Posts: 13,588
    evanh wrote: »
    I suppose it is only async drives that this applies to. OUT and DIR will be the only cases of this type.

    Right, and you can always enable OUT registering within the pad. That really perfects timing.
  • RaymanRayman Posts: 11,988
    Is this P59 glitch somehow related to the need for a pullup there to boot?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-10-04 14:15
    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
    300MHZ 782ma FAIL
    290MHZ 760ma
    270MHZ 712ma
    228MHZ 637ma
    200MHZ 542ma
    180MHZ 492ma
    114MHZ 333ma
    RCFAST = 70ma
    
  • . 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.
  • evanhevanh Posts: 10,951
    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.
  • RaymanRayman Posts: 11,988
    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?
  • BTW - this is the 1.8V current I measured at different clock frequencies.
    1.8V supply current
    300MHZ 782ma FAIL
    290MHZ 760ma
    270MHZ 712ma
    228MHZ 637ma
    200MHZ 542ma
    180MHZ 492ma
    114MHZ 333ma
    RCFAST = 70ma
    

    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
  • 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:
    12 M OSCILLATOR 180 M CLOCK 
    
    or
    12,000,000 OSCILLATOR 
    180,000,000 CLOCK
    
  • jmgjmg Posts: 14,665
    cgracey wrote: »
    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 ?
  • RaymanRayman Posts: 11,988
    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
    
  • potatoheadpotatohead Posts: 10,179
    edited 2018-10-04 16:37
    evanh wrote: »
    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.

    I see Peter did a more proper post. Good.

  • tonyp12tonyp12 Posts: 1,950
    edited 2018-10-04 17:23
    270MHz 712ma
    228MHz 637ma

    A tmds rate of 250MHz is needed for hdmi 480P (848x480 visual pixels)
    How likely would it be to officially support 250MHz?




  • Cluso99Cluso99 Posts: 17,731
    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.
  • cgraceycgracey Posts: 13,588
    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:

Sign In or Register to comment.