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

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

11415171920160

Comments

  • Both Z and C represent the bit state.
    Here's what i'm seeing
    dat		orgh	0
    		org
    
    		or	dirb,#%1111
    
    		mov	regx,##$fffffffe
    		isob	regx,#0 wz,wc
    		setbnz	outb,#0
    		setbc	outb,#1
    
    		mov	regx,##$ffffffff
    		isob	regx,#0 wz,wc
    		setbnz	outb,#2
    		setbc	outb,#3
    
    here		jmp	#here
    
    regx		res	1
    
    Led0,1 not lit = zero bit
    led2,3 lit = one bit
  • Kerry S,

    I wholeheartedly agree, mnemonics as mentioned are much easier to read and teach/learn.
    At this point though, I think the current open process is going to give that short shrift. My memory is a bit hazy, but IIRC even the multiple addressing modes on the 6502 were all pretty clear.
    Mnemonics are instantly understandable, whereas conditional symbols are.. not.
    The 'fun' part of this is going to be lessened I think, because hey, we can type one less letter?
    Kerry S wrote: »
    Clear descriptive mnemonics are a lot easier to learn (and read) when working with code that a single one with a bunch of non descriptive conditional symbol characters attached.

    Example A___ = Absolute mode, R___ = Relative mode, I___ indirect mode, etc.

    They can be grouped together in the documentation with the differences identified. With some standard labeling this is clear across multiple instructions (common theme).

    Since a major target here is educational use making things as easy as possible for beginners would seem to be a priority. Gurus already know this stuff like the back of their hands and sometimes forget how something so easy for them can be very hard for a new programmer.

  • ozpropdev wrote: »
    Both Z and C represent the bit state.
    Here's what i'm seeing
    dat		orgh	0
    		org
    
    		or	dirb,#%1111
    
    		mov	regx,##$fffffffe
    		isob	regx,#0 wz,wc
    		setbnz	outb,#0
    		setbc	outb,#1
    
    		mov	regx,##$ffffffff
    		isob	regx,#0 wz,wc
    		setbnz	outb,#2
    		setbc	outb,#3
    
    here		jmp	#here
    
    regx		res	1
    
    Led0,1 not lit = zero bit
    led2,3 lit = one bit

    Yup. This works for me too. I wonder why I'm not seeing the same with my code snippet...
  • rjo__rjo__ Posts: 2,114
    I agree wholeheartedly, but I would prefer expanded mnemonics as a compiler option.
    To make things easier to use as they are now, I would like to see an eventual auto help function in the tool... sort of like a commented autocomplete function, without the "complete"... hit a keycombo and it pops up a little help window... or leave the help window in the corner and have it constantly updating itself with each new line of code.

  • Seairth wrote: »
    Yup. This works for me too. I wonder why I'm not seeing the same with my code snippet...

    Ah! I found my problem. I was using @ozpropdev's showhex code, which does not save/restore C/Z. Once I changed that, I got the values I was expecting. So, ignore my rambling...

  • I agree, however rather than discuss here Seairth is correct and this thread should focus on the important stuff.
    rjo__ wrote: »
    I agree wholeheartedly, but I would prefer expanded mnemonics as a compiler option.
    To make things easier to use as they are now, I would like to see an eventual auto help function in the tool... sort of like a commented autocomplete function, without the "complete"... hit a keycombo and it pops up a little help window... or leave the help window in the corner and have it constantly updating itself with each new line of code.

  • SeairthSeairth Posts: 2,474
    edited 2015-10-27 00:17
    Chip has mentioned that he will be releasing another image soon. Here is the list of things I think will be included:

    * PNUT fix for SUBX
    * Fix RET to set C/Z properly
    * Fix hub memory events
    * Separate lock events from pin events
    * Add one (or two?) more timers
    * Enhance CORDIC (mindrobots)
    * Dedicated "JMP D" instruction
    * Correct/add if_00, if_1x, etc. (ozpropdev)

    Anything else? I think chip was going to start a thread to document this stuff, but as he hasn't yet, I figured I'd try to consolidate at least a few of the items (the ones I can remember).

    (note: there appears to be some hub-related streamer issues that I did not include above, since I don't know if the exact problem has been identified yet. I'm only listing the items above which are specifically known at this time. Hopefully we can get an interim update for the above items while we continue to troubleshoot additional issues.)
  • From the "Cordic Pipeline Test" thread:

    "I've got the read/new result overlap case covered. I expect to have new FPGA files out today. Just need to compile for all 4 boards. "
  • mindrobots wrote: »
    From the "Cordic Pipeline Test" thread:

    "I've got the read/new result overlap case covered. I expect to have new FPGA files out today. Just need to compile for all 4 boards. "

    Good to know! I haven't been reading that thread, so I missed that announcement.
  • Also the IF_00,IF_1X etc conditional aliases need correction in Pnut.
  • cgraceycgracey Posts: 14,133
    ozpropdev wrote: »
    Also the IF_00,IF_1X etc conditional aliases need correction in Pnut.

    Got these covered.
  • cgraceycgracey Posts: 14,133
    Seairth wrote: »
    Chip has mentioned that he will be releasing another image soon. Here is the list of things I think will be included:

    * PNUT fix for SUBX
    * Fix RET to set C/Z properly
    * Fix hub memory events
    * Separate lock events from pin events
    * Add one (or two?) more timers
    * Enhance CORDIC (mindrobots)
    * Dedicated "JMP D" instruction
    * Correct/add if_00, if_1x, etc. (ozpropdev)

    Anything else? I think chip was going to start a thread to document this stuff, but as he hasn't yet, I figured I'd try to consolidate at least a few of the items (the ones I can remember).

    (note: there appears to be some hub-related streamer issues that I did not include above, since I don't know if the exact problem has been identified yet. I'm only listing the items above which are specifically known at this time. Hopefully we can get an interim update for the above items while we continue to troubleshoot additional issues.)

    Got all these, too.

    I went in to see what trouble there was with the SETRDL/SETWRL-related events and I had forgotten to use an index in one place. Got that all fixed.

    There are now three timers: CT1, CT2, CT3.

    The masked WRLONG is now done by the WMLONG instruction, which works with SETQ/SETQ2 to write masked (don't write $FF bytes) data from cog/lut into hub.

    I also added two new events and interrupt sources:

    WAITRLE/POLLRLE - read lut end (lut location $1FF was read)
    WAITWLE/POLLWLE - write lut end (lut location $1FF was written)

    Perhaps these can be used as software interrupts.

    Just waiting for the DE2-115 compile to finish, then I'll do the DE0-Nano compiles.
  • Thanks Chip! :)
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    I also added two new events and interrupt sources:

    WAITRLE/POLLRLE - read lut end (lut location $1FF was read)
    WAITWLE/POLLWLE - write lut end (lut location $1FF was written)

    Perhaps these can be used as software interrupts.

    Cool.
    I was wondering about an off-chip software interrupt ?
    Very similar to those LUT, but for
    HUB exceeded ->software interrupts.

    That would allow a trap for uninitialized pointer (fill memory first with 0xff), and should also allow a form of DLL load from much larger memory.

  • It's quiet here this morning... almost too quiet. Is this the calm before the storm?
  • cgraceycgracey Posts: 14,133
    edited 2015-10-27 14:30
    I intended to get the new file out last night, but the DE2-115 was taking so long to compile that I was falling asleep. I went to bed at the 1.5 hour point. I'll be out there within an hour and I will see if it finished. I still have to do the DE0-Nano compiles, but they only take about 7 minutes each.
  • cgracey wrote: »
    I intended to get the new file out last night, but the DE2-115 was taking so long to compile that I was falling asleep. I went to bed at the 1.5 hour point. I'll be out there within an hour and I will see if it finished. I still have to do the DE0-Nano compiles, but they only take about 7 minutes each.

    No hurry. :) I'm glad you're still getting sleep!
  • ElectrodudeElectrodude Posts: 1,614
    edited 2015-10-27 15:28
    cgracey wrote: »
    I also added two new events and interrupt sources:

    WAITRLE/POLLRLE - read lut end (lut location $1FF was read)
    WAITWLE/POLLWLE - write lut end (lut location $1FF was written)

    Perhaps these can be used as software interrupts.

    What would be the point of software interrupts? Can't the program just do an indirect jump somewhere? I thought software interrupts were only useful on processors with memory protection.

    Can the LUT be used as a stack? If so, these events would be useful for detecting stack overflow/underflow and automatically swapping more stack out to or in from hubram.

    Would an hubram out-of-bounds event be more useful, like jmg suggested?
  • Hmm... I am beginning to think that at least the DE0-Nano files would be an easy port over the BeMicroCV or BeMicroCVA9.

    I will take a look and try some things.. then report back.
  • Loopy, all Chip is providing are the binary image files (.rbf, .pof, .jic). They are built for the specific boards and I can't imagine there is any way to port them ot another board. You'd need the actual verilog source so you could take care of pin assignments and such and then rebuild them for the target boards.
  • cgraceycgracey Posts: 14,133
    New FPGA files are up at the top of this thread!
  • RaymanRayman Posts: 13,805
    Thanks for the update. Can anyone explain this?

    WMLONG added - like WRLONG, but doesn't write $FF bytes, works with SETQ/SETQ2

    I think I'm lost... I thought SETQ2 was used to not write $FF bytes... What does WMLONG do that's different?
  • cgraceycgracey Posts: 14,133
    Rayman wrote: »
    Thanks for the update. Can anyone explain this?

    WMLONG added - like WRLONG, but doesn't write $FF bytes, works with SETQ/SETQ2

    I think I'm lost... I thought SETQ2 was used to not write $FF bytes... What does WMLONG do that's different?

    I'm working on the docs now, to clear this up.

    SETQ2 now means LUT transfer for RDLONG/WRLONG/WMLONG.

    WMLONG means 'write masked long (s)', and it works like WRLONG, but skips writing any $FF bytes.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    SETQ2 now means LUT transfer for RDLONG/WRLONG/WMLONG.

    If it is now explicitly & only LUT, then it probably needs renaming, to something clearer ?

  • cgracey wrote: »
    New FPGA files are up at the top of this thread!

    PNUT is still compiling WAITCNT.
  • jmg wrote: »
    cgracey wrote: »
    SETQ2 now means LUT transfer for RDLONG/WRLONG/WMLONG.

    If it is now explicitly & only LUT, then it probably needs renaming, to something clearer ?

    REPLUT D/#

    For consistency, make an alias for SETQ to the cog variant:

    REPCOG D/#
  • cgraceycgracey Posts: 14,133
    edited 2015-10-28 00:23
    Seairth wrote: »
    cgracey wrote: »
    New FPGA files are up at the top of this thread!

    PNUT is still compiling WAITCNT.

    I just checked and you're right, sort of.

    It just thinks you've declared a symbol. No code is generated.
  • RaymanRayman Posts: 13,805
    What is difference between setq2 usage with wrlong and wmlong?
    Seems like it'd be the same...
  • Rayman wrote: »
    What is difference between setq2 usage with wrlong and wmlong?
    Seems like it'd be the same...

    It goes like this:

    Before:

    SETQ2 with RDxxx would read data into LUT
    SETQ2 with WRxxx would write cog data to hub, except for $FF

    Now:

    SETQ2 with RDxxx reads data into LUT
    SETQ2 with WRxxx writes data from LUT

    SETQ with WMLONG writes cog data to hub, except for $FF
    SETQ2 with WMLONG writes LUT data to hub, except for $FF
  • RaymanRayman Posts: 13,805
    Thanks, I see it now.

    Maybe I'd change setq2 to setqlut ... I don't know...
Sign In or Register to comment.