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

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

12357160

Comments

  • evanh wrote: »
    Intriguing, since I don't have a FPGA I haven't tried to read any of sources previously. Mike, you say launch then copy ... this means that the SETQ + RDLONG pair somehow does a block copy, correct?
    Correct
    See Chips link for more details
    https://docs.google.com/document/d/10qQn_-B7avY2ce0N1MDDdzOF1lACPNWUJkjHFyzITiY/edit?usp=sharing

  • evanhevanh Posts: 15,916
    edited 2015-10-03 02:04
    Ah, SETQ is as simple as a length parameter. It hadn't sunk in that "x" label was considered as the end of code.

    Thanks Oz, I hadn't found those docs either.
  • evanhevanh Posts: 15,916
    edited 2015-10-03 02:21
    Well, that's certainly effective, looking at SETQ2 also, but not something to be showing the average beginner. Just keeping a grasp of who is running what and where can become fragile me thinks.

    I guess it can't really be much simpler while still allowing so many operating modes.
  • evanhevanh Posts: 15,916
    Hehe, CORDIC ... the streamer ... and what will SmartPins be capable of? The Prop2 can't not have an adventurous life.
  • SETQ is the number of bytes/words/longs the WRxxx/RDxxx transfers. (SETQ2 for LUT)
  • jmgjmg Posts: 15,173
    evanh wrote: »
    Well, that's certainly effective, looking at SETQ2 also, but not something to be showing the average beginner. Just keeping a grasp of who is running what and where can become fragile me thinks.

    I guess it can't really be much simpler while still allowing so many operating modes.

    I think this is best merged into one opcode at the Assembler, given a clearer name and a count parameter.

    The fact it generates a must-be-paired 2 x 32b pattern, is hidden from the user.
    Just HOW the P2 shuffles things about, they do not care.


  • evanhevanh Posts: 15,916
    edited 2015-10-03 04:58
    I was really starting to think more about the implications of the various execution modes and placement of data and code and automated hardware features. All of that on top of something that many a newbie already struggles with - the multi-processor execution of user code.

    The Prop is easy on the whole, but those mental models still have to be confidently constructed in the mind's eye.
  • Should this thread be locked and stickied?
  • Why lock it? They will probably be several more FPGA updates in the near future.
  • User NameUser Name Posts: 1,451
    edited 2015-10-07 00:25
    retracted
  • User Name wrote: »
    Why lock it? They will probably be several more FPGA updates in the near future.

    There is already a new thread to cover that.
    There is? What is it?

  • Maybe not locked but definitely stickied.
  • RaymanRayman Posts: 14,646
    We do need some new stickies with updated instructions for DE2-115 and P123 boards. The links in the old ones don't seem to work.

    Also, it'd be nice to have the most current doc's in a sticky.
  • Cluso99Cluso99 Posts: 18,069
    I will update my stickie once we get a more stable FPGA release.
    Meanwhile, please post any updated instructions for the DE2 and A7 in that stickie and I will add a pointer to it in the first post. Same goes for documents.
  • Is there a thread that consolidates the latest documentation for the P2 instructions? The instructions.txt file that is included in the FPGA zip file only provides a list of instructions, but there are no descriptions of what the instructions do. Chip has posted information about some of the instructions in various threads. It would be nice if there was a single thread that had links to the latest posts describing the instructions.

    Also, can someone point me to the instructions for loading the DE2?
  • Dave,

    From Ozpropdev in this post

    On DE2-115 set switch on left side to program

    In Quartus programmer
    Mode - Active serial programming
    Open file DE2_115_prop2.pof
    Check pconfigure
    Press start

    P.S.: USB cable connected to USB Blaster port top left corner of DE2-115.
    Prop plug on adapter board (logo facing away from you)
  • Cluso99Cluso99 Posts: 18,069
    Hey guys,
    I just updated the stickie (copied the above post).
    But how do I get a link to the actual post so I can add a link in the first post???
  • Cluso99 wrote: »
    Hey guys,
    I just updated the stickie (copied the above post).
    But how do I get a link to the actual post so I can add a link in the first post???

    For a specific comment, the link is on the comment timestamp.
  • Cluso99Cluso99 Posts: 18,069
    Thanks Seairth. I tried everything but the timestamp :(
  • cgraceycgracey Posts: 14,155
    Okay. I've got everything working. I just need to do the separate compiles for the DE2-115 and the Prop123 boards.

    I've got to get some sleep now, but when I get up, I'll get these two things done and get new FPGA files out.

    Thanks for all your patience.

    Not having to start in hub exec and having 1:1 long:address in cogs is now making code much simpler to work with.

    I got the debug hooks working, too.
  • Thanks for all your hard work Chip. Look forward to the release and some tips (hint) :)
  • Nice work Chip! :)
  • I'm good at simple!! :)

    Thanks!
  • cgraceycgracey Posts: 14,155
    Updates images are now available from the top of this thread!
  • cgracey wrote: »
    Updates images are now available from the top of this thread!
    Excellent! Thanks, Chip!

  • Thanks Chip! :)
  • RaymanRayman Posts: 14,646
    Do we really need to always populate the interrupt vectors?

    Or, is this only required for debugging? (hope so)
  • cgraceycgracey Posts: 14,155
    edited 2015-10-08 23:05
    Rayman wrote: »
    Do we really need to always populate the interrupt vectors?

    Or, is this only required for debugging? (hope so)

    They always need to be there. In a system-level situation, this won't be a big deal. While writing small programs, it's a bit of a nuisance.

    This is the only way I can think to make all cogs debug-able without modifying their intended programs.
  • Could you make it so that if the CCCC bits of the interrupt vector are 0, it's the same as a RETI0?

    Or, and this would cost zero silicon, could you add an include directive to PNUT.exe's assembler? Then people can just
    DAT
      include "nodebug.pasm"  ' lives in Propeller Library folder, sets debug vectors to all be RETI0
    
    and have everything taken care of for them.
  • I think populating them is easy...

    What happens when they get trashed. It's gonna make sense to write those values at times to insure a proper COGINIT...

Sign In or Register to comment.