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

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

1151152154156157160

Comments

  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    PS: IN is not raising upon WXPIN either. I've been using COGATN to notify of update instead.


    Ok. Good to know. I will fix this.
  • cgracey wrote: »
    evanh wrote: »
    PS: IN is not raising upon WXPIN either. I've been using COGATN to notify of update instead.


    Ok. Good to know. I will fix this.

    You shouldn't need to set the TT bits.
    You do have to allow 4 lcoks though for a valid IN status.
    	wxpin	#1,#0
    	nop
    	nop		'allow 4 clocks before reading IN
    	testp	#0 wc
    	drvc	#32
    
  • This seems to work OK
    Cog #1 writes to repository and Cog #0 reacts to IN raise.
    dat		org
    
    		hubset	#$ff
    		loc	ptra,#\@blink
    		coginit	#16,ptra
    
    		wrpin	#%00001_0,#0
    		dirh	#0
    
    loop		testp	#0 wc
    	if_c	rdpin	pa,#0
    	if_c	drvnot	#32
    		jmp	#loop
    
    		org
    blink		rep	#3,#0
    		wxpin	#1,#0
    		waitx	##20_000_000
    
    
  • cgraceycgracey Posts: 14,133
    Evanh, can you confirm this? Maybe you just needed to wait a few more clocks before looking at the IN pin.
  • evanhevanh Posts: 15,126
    Doh! That was a silly slip-up of mine. I didn't issue a DIRH for it. I was managing operate the smartpin with it disabled, lol.

    Tested and working as documented now. Thanks for the example Brian. :)

  • evanhevanh Posts: 15,126
    edited 2018-12-19 01:54
    In hindsight, it makes sense. The repository mode is just making use of the config space, and that has be settable with DIR low.

    I guess the only question mark is why does, with DIR low, RDPIN work when TT=1 but not when TT=0.

  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    In hindsight, it makes sense. The repository mode is just making use of the config space, and that has be settable with DIR low.

    I guess the only question mark is why does, with DIR low, RDPIN work when TT=1 but not when TT=0.

    I need to look into that. It shouldn't matter.
  • cgracey wrote: »
    evanh wrote: »
    In hindsight, it makes sense. The repository mode is just making use of the config space, and that has be settable with DIR low.

    I guess the only question mark is why does, with DIR low, RDPIN work when TT=1 but not when TT=0.

    I need to look into that. It shouldn't matter.

    I haven't been able to replicate this behaviour.
    All combinations of TT has same result.
    The only way I can get RDPIN to work is when DIRx = 1
    dat	org
    
    	bmask	dirb,#15
    	wrpin	#%01_00001_0,#0
    
    '	dirh	#0
    
    	mov	pa,#$5a
    	wxpin	pa,#0
    	nop		'2 clock delay before rdpin
    	rdpin	outb,#0	'show on P123-A9 leds
    	jmp	#$
    
    
    
  • evanhevanh Posts: 15,126
    Hmm, my code is too big and messy. Thanks again Brian. Looks like this was a total wild goose.

    I can't remember the exact details of when what happened now. I ended up with that pin dual purposed. There is a DRVNOT instruction for pulsing the scope trigger, the scope probe had been on there for days. Obviously this is setting DIR high.

    Feeling sheepish now.

  • Don't feel too bad Evan.
    It's not as bad as me BBQ'ing my P2 chip! <:(
  • jmgjmg Posts: 15,140
    evanh wrote: »
    Hmm, my code is too big and messy. Thanks again Brian. Looks like this was a total wild goose.

    I can't remember the exact details of when what happened now. I ended up with that pin dual purposed. There is a DRVNOT instruction for pulsing the scope trigger, the scope probe had been on there for days. Obviously this is setting DIR high.

    Feeling sheepish now.

    Is there still an issue with erratic exit on a conditional jump ? (not the last line, special case, which is not erratic)
    Is there code to prove that on a real P2 ?
  • evanhevanh Posts: 15,126
    JMG,
    I'm certainly still dealing with it. See comments at end of source:
    'monitor loop
    '==============
    		rep     @.monend, #0          'loop forever (REP reduces monitor loop by two instructions)
    .monl
    		waitx   delay                 '2    WAITX reduces monitor loop by one instruction
    		jse1    #.keyboard            '4    branch on event reduces monitor loop by one instruction
    
    'decimator
    		rdlut   samp, #(monitor & $1ff) '7
    		sub     samp, diff1           '9
    		add     diff1, samp           '11
    		sub     samp, diff2           '13
    		add     diff2, samp           '15
    		sub     samp, diff3           '17
    		add     diff3, samp           '19
    		sub     samp, diff4           '21
    		add     diff4, samp           '23
    'spit to DAC for scope
    		add     samp, offset          '25   offset centring
    		wypin   samp, #1              '27   smartpin 16-bit dither into DAC1
    .monend
    
    'This code is workaround for intermittent problem with event branching out from REP loops
    'occasionly it just drops the JSE1 branch and falls out the bottom of the REP
    		add     dbg, #1
    		wxpin   dbg, #dpin            'mailbox for reporting occurances
    		jmp     #\.keyboard
    		jmp     #\.keyboard           'needs double JMP to recover
    		cogstop cid
    
    
  • @evanh
    Did you try it without the JSE1 instruction?
    		jse1	#.keyboard
    'replace with
    		pollse1	wc
    	if_c	jmp	#.keyboard
    
  • evanhevanh Posts: 15,126
    Yeah, that works fine but I wanted to minimise the loop size and the workaround is reliably achieving this. Also, just experimenting with the flaw for fun.

    There's no lasting effect from any spurious extra instructions so the recovery is as good as no flaw. The main thing is having an exact loop length to calculate WAITX amount with.
    		mov     delay, period
    		sub     delay, #27
    
  • jmgjmg Posts: 15,140
    evanh wrote: »
    Yeah, that works fine but I wanted to minimise the loop size and the workaround is reliably achieving this. Also, just experimenting with the flaw for fun.

    There's no lasting effect from any spurious extra instructions so the recovery is as good as no flaw. The main thing is having an exact loop length to calculate WAITX amount with.
    		mov     delay, period
    		sub     delay, #27
    

    hmm.. what is the failure rate, and does that vary with time or temperature ?
    If you remove the WAIT, does that change the failure rate at all ?
  • evanhevanh Posts: 15,126
    Well, the event trigger is only the key repeat rate of my desktop PC. But even a single key press has fluked it already.

    Period is always an even number sysclocks. So far, multiples of either 10 or 8 with shortest down at 30. So that's a WAITX of only 3 (30 - 27). Now you mention it, fault occurrences are more common when period is below 100.

  • evanhevanh Posts: 15,126
    Switching to 40 MHz sysclock is identical. Actually, I've done most of the testing at 40 MHz.

  • PublisonPublison Posts: 12,366
    edited 2018-12-19 19:36
    Anyone running Quartus 18 for A9 ? I am getting ready to set up a new 123 A9 board since I gave up my Eval board. Hard to go back through 155 pages. :smile: )
  • jmgjmg Posts: 15,140
    evanh wrote: »
    Period is always an even number sysclocks. So far, multiples of either 10 or 8 with shortest down at 30. So that's a WAITX of only 3 (30 - 27). Now you mention it, fault occurrences are more common when period is below 100.
    If you remove the waitx, is the effect still there ? Any difference for even/odd delay values ?
    What about for other test-&-jump opcodes, do they all have the same issue ?


  • Publison wrote: »
    Anyone running Quartus 18 for A9 ? I am getting ready to set up a new 123 A9 board since I gave up my Eval board. Hard to go back through 155 pages. :smile: )
    You don't need Quartus to program the A9 board with a P2 image.
    Use PX.EXE to program the board.
    1. Set switch to "prog"
    2. Run PX.exe (e.g. COM7)
        px Prop123_A9_Prop2_v32i.rbf /7 /p
    3. Switch to "run" when done.
    

  • PublisonPublison Posts: 12,366
    edited 2018-12-19 22:02
    ozpropdev wrote: »
    Publison wrote: »
    Anyone running Quartus 18 for A9 ? I am getting ready to set up a new 123 A9 board since I gave up my Eval board. Hard to go back through 155 pages. :smile: )
    You don't need Quartus to program the A9 board with a P2 image.
    Use PX.EXE to program the board.
    1. Set switch to "prog"
    2. Run PX.exe (e.g. COM7)
        px Prop123_A9_Prop2_v32i.rbf /7 /p
    3. Switch to "run" when done.
    

    Thanks Brian. That will get me started on P2. I want to do some P1V later on also.
  • Cluso99Cluso99 Posts: 18,066
    Publison,
    I am only running Quartus 17. Works with a BeMicroCV-A9.
  • Cluso99 wrote: »
    Publison,
    I am only running Quartus 17. Works with a BeMicroCV-A9.

    Quartus cannot program the P123-A7/A9 boards.
    These boards use custom Parallax programming hardware (a Propeller 1) and custom software (PX.exe).

    IIRC Quartus version 15 onwards supports the larger CV-A9 device.
  • evanhevanh Posts: 15,126
    edited 2019-01-14 11:01
    Well, I've been slowly getting around to working on the real silicon. The problem with branch-on-event inside a REP block is still present!

    What's more, if I change that event type to edge detect instead of level detect then that event stops dead 100%. Although I'm still seeing the trap tripping as the execution drops through the bottom of the REP block on rare occasions. Removing the REP and adding a looping JMP then the edge detect immediately works perfectly.

    So, event branching from within a REP block:
    - Level detect works most of the time with a crazy mode of failure.
    - Edge detect never works at all, but still has the crazy failure mode.
    - True for both FPGA and real ES silicon.

    Here's the two alternate event setup lines:
    		setse1  #%110_000000|rx_pin   'high IN from smartpin
    
    		setse1  #%001_000000|rx_pin   'rising IN from smartpin
    
  • evanhevanh Posts: 15,126
    I'll admit now I'm still testing with unwieldy code that is doing many things. I should do a simple version ...

  • evanhevanh Posts: 15,126
    edited 2019-01-15 02:19
    The data corruption from simultaneous R/W in lutRAM sharing also seems to be present in the real silicon.

    Again, this is with the same code base as above. In this case it depends on the alignment timing of the decimation sampling against the emulated sinc3 filter. I have the decimator loop calculated to cycle in-sync on a multiple of the emulated sinc3 filter loop time - which itself is running on the paired cog. But there is no attempt to know the phase timing.

    By repeatedly pressing keys on the keyboard, each one triggers the adjustments on the decimation loop, it breaks the regular loop to recalculate then re-enters the loop at a different phase timing to the sinc3 filter with a possibility of landing bang on top of the lutRAM update. So I presume that is exactly what is occurring when the read lutRAM data goes 100% random. The scope display just fills with blanket noise.

    Press one more keypress, even one that makes no adjustment, and the signal comes back as normal.


    Edited for clarity.
  • evanhevanh Posts: 15,126
    If replacing the lutRAM sharing with a smartpin mailbox, the corruption cleanly and solidly goes away on both the FPGA and P2ES!
  • evanhevanh Posts: 15,126
    For anyone that wants to hook up a scope probe, here's the ES silicon version full source configured for no glitches. Pin9 is the DAC output. To see an interesting signal from that you'd also need a bitstream coming in on pin0. I'm using my AD7400 evaluation board.
  • evanhevanh Posts: 15,126
    edited 2019-01-15 02:40
    Reconfiguring pin0 to internal ADC is easy too.

    A visible signal is not actually needed to get the corruption problem. My sinc3 filter ignores any MCLK so cycles happily without any signal.
  • jmgjmg Posts: 15,140
    I'm not quite following, are there multiple issues here, and do you have minimal, portable test cases yet for Chip to zero in on ?

    I think you mean 2 issues ?
    1) The problem with branch-on-event inside a REP block is still present
    2) The data corruption from simultaneous R/W in lutRAM sharing also seems to be present in the real silicon.

    in 2 the address or data being corrupted ? Is the issue transient ? (eg bad data read, but write succeeded, so next read is valid data )
Sign In or Register to comment.