Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 157 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

1154155157159160

Comments

  • Cluso99 wrote: »
    Now if someone could do that on a P2-ES chip (P2D2 or P2-EVAL board) with three different resistor values please :)

    If only I had a scope!
  • I could do that now. Could you confirm the steps and any source code ?

    Pulldown on P58
    <insert SD card, FAT32, file content?> ?
    <run code> ?
    Trigger on P58 ?


    Also, bearing in mind P2-EVAL has 47pF on that pin... do you want that removed or reduced first?
    I think P2D2 had 10-12pf there, but I don't have one of those to test.

  • evanhevanh Posts: 15,126
    edited 2019-02-07 10:58
    Here's my complete source. EDIT: You'll need to add in the clock setting for real silicon.
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-02-07 11:03
    VonSzarvas wrote: »
    I could do that now. Could you confirm the steps and any source code ?

    Pulldown on P58
    <insert SD card, FAT32, file content?> ?
    <run code> ?
    Trigger on P58 ?


    Also, bearing in mind P2-EVAL has 47pF on that pin... do you want that removed or reduced first?
    I think P2D2 had 10-12pf there, but I don't have one of those to test.
    This would be great thanks vonszarvas.
    Just use another close pin such as P56 ( dont think anything is on this pin).

    Place a pulldown and do this for the 3 values ie 3 traces
    Trigger on the pin
    Run a simple program to
    DRVH #56 ‘trigger here on high
    WAITX #30
    FLTH #56
    JMP #$

    Repeat the above with pullups ie 3 traces using the program
    DRVL #56. ‘trigger here on low
    WAITX #30
    FLTL #56
    JMP #$

    This would be fantastic thanks. I know this wouldbe slightly different with an sd card present but will be good enough to see what is happening.
    Ray
  • Ray are all these pin glitch captures any use for what you want? They are Drive High - Float
    http://forums.parallax.com/discussion/comment/1447922/#Comment_1447922

    However most of the time we were looking at the jtag pins. I take it you are primarily interested in the boot select pins.

    Note from those previous captures, the depth of the negative going pulse varies by pin (perhaps, hypothetically, by jtag loading?).

    Also I am not sure where the switching threshold is on the P2. On the P1 it was somewhere around 1.42v, ie its not simply vcc/2.

  • Cluso99Cluso99 Posts: 18,066
    Yes, its only the 4 boot pins that are of interest P58-61.
    Because i found a problem, i want to understand the timing because it could potentially affect the ROM Boot code.
    From the trace i should be able to ensure i read in the correct eindow. The small hysterisis where the chip sees the change should not matter if ive chosen the timing correctly.
  • With this code and 10K pulldown I get the attached.

    Is this the right setup for the detail you need?


    I'll install the scope software on this PC, then grab the rest right now.

    dat     org
    
    	' set up clock
            hubset  ##%1_000000_0000001100_1111_10_00    'enable crystal+PLL, stay in 20MHz+ mode
            waitx   ##20_000_000/100            	     'wait ~10ms for crystal+PLL to stabilize
            'hubset  ##%1_000000_0000001100_1111_10_11   'now switch to PLL
    
    
    
    loop    
    	DRVH #56 'trigger here on high
    	WAITX #30
    	FLTH #56
    	WAITX #30
    	jmp #loop
    
    853 x 480 - 132K
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-02-07 13:04
    Yes, that will do nicely with just the waitx changes so i can see that we got to gnd. So just tweek them as follows please
    dat     org
    
    	' set up clock
            hubset  ##%1_000000_0000001100_1111_10_00    'enable crystal+PLL, stay in 20MHz+ mode
            waitx   ##20_000_000/100            	     'wait ~10ms for crystal+PLL to stabilize
            'hubset  ##%1_000000_0000001100_1111_10_11   'now switch to PLL
    
    
    
    loop    
    	DRVH #56 'trigger here on high
    	WAITX #15
    	FLTH #56
    	WAITX #45
    	jmp #loop
    

  • VonSzarvasVonSzarvas Posts: 3,272
    edited 2019-02-07 14:04
    Vertical offset at -1,8V

    4K7, 10K and 22K.

    Is 15K crucial ? Could construct the value....

    1018 x 557 - 39K
    1018 x 557 - 39K
    1018 x 557 - 37K
    1018 x 557 - 40K
    1018 x 557 - 38K
    1018 x 557 - 36K
  • VonSzarvasVonSzarvas Posts: 3,272
    edited 2019-02-07 14:22
    Just trying P58 for comparison...

    Edit:

    Scope results the same for P58, except that with 22K the pulse frequency starts to vary slightly as the cap influences.

    Freq. was locked on 320 KHz for all except P58 22K, which rolls ~312 to 320 KHz.
  • jmgjmg Posts: 15,140
    edited 2019-02-07 19:30
    VonSzarvas wrote: »
    Vertical offset at -1,8V

    4K7, 10K and 22K.

    Is 15K crucial ? Could construct the value....

    There is no need to do more than a single capture, as from there you can derive the PCB capacitance, either from formula, or from Spice.

    Note: SCH shows C108.C109.C110 of 47pF added to Pins 59.60.61, plus I think a few traces run much further than others. ( I think P56 is not one ?)
    VonSzarvas wrote: »
    Just trying P58 for comparison...
    Scope results the same for P58, except that with 22K the pulse frequency starts to vary slightly as the cap influences.
    It would be interesting to see separate captures for CAP added pins, 59.60.61, vs no-cap pins. (I have no R's or soldering iron on this station)
    Expected to be ~ 38% slower again.

    Your capture of Pin 56 ? maps to a rather high 125pF P2-Eval loading value. (sounds much higher than P2D2 would be )

    Attached image shows the Spice Timing match for your 10k captures.
    Cluso99 wrote: »
    Yes, its only the 4 boot pins that are of interest P58-61.

    Those 4 will not be the same, as Pins 59.60.61 show additional added loading C of 47pF, on the P2-Eval.
    Seems that is totally unnecessary, if the P2-Eval loading is already ~125pF ? (as indicated by P56,P58 ?)

    Addit: Pin61 looks to be the worst trace, length wise. Pin59,Pin60 are shorter and roughly equal paths.
  • That "125pF" seems high and is probably half due to the CRO probe and input capacitance of the scope.

    Screen caps show x1 probe mode, could you repeat a test at x10 @VonSzarvas and see if that 125pF drops?
  • Here's 10k pulldowns on P59,60,61

    And an extra P56 at x10

    1018 x 557 - 37K
    1018 x 557 - 37K
    1018 x 557 - 37K
    1018 x 557 - 36K
  • Oops, that's x10 scale is off.
    Try again...
    1018 x 557 - 40K
  • jmgjmg Posts: 15,140
    VonSzarvas wrote: »
    Oops, that's x10 scale is off.
    Try again...
    Pin 56 ?
    re-run the spice gives ~54pf (includes scope CL)
    So expect Pin61 to be about 2x that ?
    961 x 941 - 49K
  • Cluso99Cluso99 Posts: 18,066
    @VonSzarvas
    Many thanks for doing this. Nothing looks amiss here. I'll look at the timing either tonight or over the w/e to ensure my software meets the timing shown. 22K is fine. BTW I was using P2D2 so the extra caps were not present in my tests.

    @jmg
    Shouldn't the 10k be across the capacitance, not in series, and this will be for the external parts. Then the internal will be a small 22R? in series with some small capacitance, which would be across that. ???
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    @jmg
    Shouldn't the 10k be across the capacitance, not in series,

    Here you go, 10k across the cap.
    Notice the risetimes are identical, as the RC time constant is what matters here.

    958 x 940 - 48K
  • evanhevanh Posts: 15,126
    Chip,
    I've noticed what seems to be a hub like timing to the event generation of COGATN/WAITATN. I haven't come up with another explanation ... although COGATN execution doesn't stall like other hub types do.

    I wouldn't have thought it needed such arbitration. I was expecting something as simple as an OR function, like what OUT uses.

    Have I got this wrong?

  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    Chip,
    I've noticed what seems to be a hub like timing to the event generation of COGATN/WAITATN. I haven't come up with another explanation ... although COGATN execution doesn't stall like other hub types do.

    I wouldn't have thought it needed such arbitration. I was expecting something as simple as an OR function, like what OUT uses.

    Have I got this wrong?

    There's no hub timing relationship. It is an OR function. What are you seeing?
  • evanhevanh Posts: 15,126
    Hmm, you've prompted me to try cleaning up the code, namely clean out all the lutRAM sharing parts, and funnily the artefact has gone away. I'll see if I can identify if it was just a bug ...
  • evanhevanh Posts: 15,126
    edited 2019-03-12 05:56
    Chip,
    Thanks for the info, btw.

    I found the culprit finally - COGID. I had assumed it was a 2-clock instruction. So a bug, yes. It was added for the testing of coinciding lutRAM writes, just yesterday.
  • RaymanRayman Posts: 13,797
    Cogid is not 2 clocks? I’m surprised too... what is it? 1 ... 3?
  • cgraceycgracey Posts: 14,133
    Rayman wrote: »
    Cogid is not 2 clocks? I’m surprised too... what is it? 1 ... 3?

    It's a hub instruction.
  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    Chip,
    Thanks for the info, btw.

    I found the culprit finally - COGID. I had assumed it was a 2-clock instruction. So a bug, yes. It was added for the testing of coinciding lutRAM writes, just yesterday.

    I'm glad you're turning every rock over.
  • evanhevanh Posts: 15,126
    Hehe, it does have that feel of chasing after each distant yelp coming from yonder on the beach.

    I remember back when I first joined the forums and was reading old posts of others finding the latest discoveries on the Prop1. I so wanted to do that. I guess I've got there for the Prop2. :)
  • RaymanRayman Posts: 13,797
    Ok, cogid is hub instruction. A little strange that a cog has to ask which one it is...
    But, it's not like you'd be using this instruction very often...
    Having deja vu… Sure this came up in P1 thread before...
  • cgracey wrote: »
    Rayman wrote: »
    Cogid is not 2 clocks? I’m surprised too... what is it? 1 ... 3?

    It's a hub instruction.
    That seems kind of odd. Why would the COG have to wait for the hub to determine its COG ID? Not a big deal I guess but kind of surprising.

  • RaymanRayman Posts: 13,797
    I guess if the cogs are truly identical, then it has to be this way... Or, does it?
  • cgraceycgracey Posts: 14,133
    edited 2019-03-12 17:28
    Rayman wrote: »
    I guess if the cogs are truly identical, then it has to be this way... Or, does it?

    It could have easily been made into a 2-clock instruction, but it's a little more economical to keep it in the hub. Its implementation is mainly a carryover from the first Propeller chip.
  • evanhevanh Posts: 15,126
    cgracey wrote: »
    ... it's a little more economical to keep it in the hub.
    That's something I bet wasn't tested in terms of used routing space. The bigger the cogs are the longer the linking routes become.
Sign In or Register to comment.