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

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

1150151153155156160

Comments

  • evanhevanh Posts: 15,126
    jmg wrote: »
    Given P2 is a 2-clock opcode, another option might be to write on one clock and read on the other ?

    It would have been single ported if that road was taken.

  • RaymanRayman Posts: 13,797
    I was wondering about the SETQ+RDLONG combo...
    Will that work inside REP?

    I vaguely remember some conditions on REP... I'm pretty sure you can't have nested REPs... There was something else though...
  • evanhevanh Posts: 15,126
    jmg wrote: »
    In this mode, you also have two output choices: old data or don't care.
    In Old Data Mode, a read-during-write operation to different ports causes the RAM outputs to reflect the old data at that address location.

    I suppose the explanation for this is timing stays the same when treating the RAM as a buffer. "Old" data would work fine. I'm guess Chip can easily edit this setting.

    So, to get "new" data passing through would require explicit logic outside the RAM block.

    I'm guessing OnSemi arrangement is likely very similar except maybe "old" could be default setting there.

  • evanhevanh Posts: 15,126
    edited 2018-12-17 23:39
    Rayman wrote: »
    I was wondering about the SETQ+RDLONG combo...
    Will that work inside REP?
    Yep, there's no restriction on time, excepting IRQs disabled, or data memory ranges. The one big restriction is all branching is a loop cancel. Including another REP. Issuing a second REP while still within the first, from the hardware's view, is just restarting the REP operation at the new REP instruction. The old REP instruction is forgotten.

    It's like comparing GOTO vs GOSUB. REPs are all GOTO type branching.

    I think even a branch over one instruction within the REP loop will cancel the REP operation, ie: It'll fall out the bottom as if the loop count had completed. This is where having conditional execution is another bonus.

  • @evanh

    I was able to replicate weirdness in my code using a JATN instruction.
    It terminates the REP block then restarts the REP block again.

    I replaced it with a POLLATN WC and a IF_C JMP #somewhere and it worked.

    Looks like there is something about the Jxxx instructions inside REP blocks that breaks things.

    This is a separate issue to the last instruction being a branch that was mentioned earlier.
  • evanhevanh Posts: 15,126
    ozpropdev wrote: »
    Looks like there is something about the Jxxx instructions inside REP blocks that breaks things.

    This is a separate issue to the last instruction being a branch that was mentioned earlier.

    Sounds right. Thanks for the checking.

  • cgraceycgracey Posts: 14,133
    ozpropdev wrote: »
    @evanh

    I was able to replicate weirdness in my code using a JATN instruction.
    It terminates the REP block then restarts the REP block again.

    I replaced it with a POLLATN WC and a IF_C JMP #somewhere and it worked.

    Looks like there is something about the Jxxx instructions inside REP blocks that breaks things.

    This is a separate issue to the last instruction being a branch that was mentioned earlier.

    All of the 9-bit-immediate-address jump instructions are relative. I think they may be jumping relative to the REP loop address, because the REP affected the program counter in the prior instruction cycle, already. If this is the trouble, you just can't use a relative branch at the very end of a REP block. I don't think there is anything that can be done about this.
  • jmgjmg Posts: 15,140
    ozpropdev wrote: »
    @evanh

    I was able to replicate weirdness in my code using a JATN instruction.
    It terminates the REP block then restarts the REP block again.

    I replaced it with a POLLATN WC and a IF_C JMP #somewhere and it worked.

    Looks like there is something about the Jxxx instructions inside REP blocks that breaks things.

    This is a separate issue to the last instruction being a branch that was mentioned earlier.

    To clarify, was that tested on a P2 ?
    Does it fail always, or at some lower failure rate like evanh mentioned ?
  • evanhevanh Posts: 15,126
    edited 2018-12-18 00:09
    cgracey wrote: »
    ... you just can't use a relative branch at the very end of a REP block. I don't think there is anything that can be done about this.

    That particular issue is not an end-of-block problem. It can intermittently happen with the Jxxx instruction at any position in the block.

    The end-of-block issue is separate one.

  • jmgjmg Posts: 15,140
    edited 2018-12-18 00:52
    cgracey wrote: »
    All of the 9-bit-immediate-address jump instructions are relative. I think they may be jumping relative to the REP loop address, because the REP affected the program counter in the prior instruction cycle, already. If this is the trouble, you just can't use a relative branch at the very end of a REP block. I don't think there is anything that can be done about this.

    That would fit the symptoms, and means the reljmp is not actually finally jumping at all, but simply falls thru the packer NOPs (a delay test would verify that).
    If a double-change is occurring, and is stable, you could still use a reljmp at the very end, it just needs a fix-up of the rel value.

    For immediate rep loops, the assembler could catch this, but for var based REPs (far less common) it may just have to issue a warning, but here it would be nice to know where the rep boundary is.
    Such VAR reach reps would be rare, but a specific repend local label could give a bound to the assembler, as well as help clarity and editing.
    In this case, if Asm sees VAR reach REP and reljmps inside that longest-indicated bound, it needs to issue the 'do this only if you really know what you are doing' warning.
    For CONST REP loops, the ASM can manage the reljmps.
  • evanhevanh Posts: 15,126
    edited 2018-12-18 05:05
    JMG,
    The lock-up on branch at last instruction issue is the one that is PC-relative encoding sensitive. There is no fall-through in this case. And it happens every execution.

    Two distinct behaviours.

    The fall-through issue is all about the Jxxx branch on event instructions exclusively. And can be triggered from any position in the REP block, but only has a probability of triggering. It makes no diff about rel vs abs. I've even tested using register absolute.


    The workaround for the lock-up flaw is move the branch off the end of the block.
    The workaround for the fall-through flaw is don't use event branching inside a REP block at all.

  • jmgjmg Posts: 15,140
    evanh wrote: »
    JMG,
    The lock-up on branch at last instruction issue is the one that is PC-relative encoding sensitive. There is no fall-through in this case. And it happens every execution.

    Two distinct behaviours.

    The fall-through issue is all about the Jxxx branch on event instructions exclusively. And can be triggered from any position in the REP block, but only has a probability of triggering. It makes no diff about rel vs abs. I've even tested using register absolute.

    Yes, Chip's post, and my reply, were solely focused on the last-instruction case. As ozpropdev mentions, that's separate from erratic Jxx issue.
    You said NOP packers were needed, and I explained why that fits with Chip's summary. ie The PC is modified twice, but in a predictable manner, and there is an Assembler solution possible.
  • evanhevanh Posts: 15,126
    There is no fall-through with that issue. It simply locks solid.

  • jmgjmg Posts: 15,140
    evanh wrote: »
    There is no fall-through with that issue. It simply locks solid.

    Oops, is was ozpropdev that said NOPs were needed, not you, I confused posters.
    His code shows the effect, and that NOP 'fix' matches Chip's note about early loading of PC, so it actually loads PC twice - once to get ready to go back, and again by reljmp, only now the reljmp is applied from REP opcode addr not the end.
    NOP's fix that by moving the 2nd change to span the REP loop. Code works, but with an added delay, as it falls thru the block of NOPs.

    My point is that the assembler can do the pre-fix, (for CONST rep size), so the NOPs are not needed.
  • evanhevanh Posts: 15,126
    There's no falling through with that issue! The cog never exits the REP block in any way.

  • jmgjmg Posts: 15,140
    evanh wrote: »
    There's no falling through with that issue! The cog never exits the REP block in any way.

    Did you read ozpropdev's post and comment ? Here :

    With the NOP's REP loop works as expected.
    Without the NOP's, an extra loop is executed.


    All of which is explained by the PC loading twice.
  • evanhevanh Posts: 15,126
    It does one extra loop then locks solid.

  • See the REP block thread for more details on the branch at end of block issue.

    http://forums.parallax.com/discussion/comment/1458296/#Comment_1458296
  • evanhevanh Posts: 15,126
    Hmm, I'm getting a different outcome there Brian. I can throw lots of NOPs at it, but it never gets to the debug code after that. The REP loop stops cycling and nothing else appears to happen.

    One difference I can see is I'm relative branching back to before the REP instruction.

  • evanhevanh Posts: 15,126
    Huh, forward relative branch is working.

  • Cluso99Cluso99 Posts: 18,066
    edited 2018-12-18 09:14
    Maybe the REP might need another restriction - no jumps in the loop too :(

    The REP is a special case and works nicely. I can live with restrictions.
  • evanh wrote: »
    Huh, forward relative branch is working.

    Maybe reverse relatve branching only works in the northern hemisphere. :lol:
  • jmgjmg Posts: 15,140
    evanh wrote: »
    Hmm, I'm getting a different outcome there Brian. I can throw lots of NOPs at it, but it never gets to the debug code after that. The REP loop stops cycling and nothing else appears to happen.

    One difference I can see is I'm relative branching back to before the REP instruction.
    evanh wrote: »
    Huh, forward relative branch is working.

    If going back the, NOPs would need to be before the destination ?
    ( as the PC first sets to REP start, then it reljmp modifies next, but the ASM uses the reljmp address as the base)


  • evanhevanh Posts: 15,126
    jmg wrote: »
    If going back the, NOPs would need to be before the destination ?
    ( as the PC first sets to REP start, then it reljmp modifies next, but the ASM uses the reljmp address as the base)

    Damn, I think you're right. I filled before the destination with NOPs and it's working.

    What I hadn't thought about is my code, without the NOPs, is reusing that space for variables after initial execution.

  • evanhevanh Posts: 15,126
    Chip,
    Found another one! A little comical too. Smartpin "long repository" modes only seem to work when DIR is forced on with TT=%01.

  • In order to avoid nasty surprises with the final Silicon: Will there be an FPGA update with all the changes corresponding to the B-silicon?
  • evanhevanh Posts: 15,126
    Definitely will be. Just for all the fixes alone, never mind any enhancements. I'm thinking there is still many months of testing to get through.

  • cgraceycgracey Posts: 14,133
    Yes, we will have an FPGA update soon.
  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    Chip,
    Found another one! A little comical too. Smartpin "long repository" modes only seem to work when DIR is forced on with TT=%01.

    I will look into that.
  • evanhevanh Posts: 15,126
    edited 2018-12-18 15:23
    PS: IN is not raising upon WXPIN either. I've been using COGATN to notify of update instead.

    EDIT: Using a smartpin for this came about only because I didn't want to disable the total hubRAM filling happening from another cog.

Sign In or Register to comment.