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?
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.
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.
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.
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?
Comments
See Chips link for more details
https://docs.google.com/document/d/10qQn_-B7avY2ce0N1MDDdzOF1lACPNWUJkjHFyzITiY/edit?usp=sharing
Thanks Oz, I hadn't found those docs either.
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.
The Prop is easy on the whole, but those mental models still have to be confidently constructed in the mind's eye.
Also, it'd be nice to have the most current doc's in a sticky.
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.
Also, can someone point me to the instructions for loading the DE2?
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)
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.
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!
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.
Or, and this would cost zero silicon, could you add an include directive to PNUT.exe's assembler? Then people can just and have everything taken care of for them.
What happens when they get trashed. It's gonna make sense to write those values at times to insure a proper COGINIT...