Android

Members
  • Content Count

    23
  • Joined

  • Last visited

About Android

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi again, I notice that I have two versions of Arty-Master.xdc floating around, both say on line 1: ## This file is a general .xdc for the ARTY Rev. B but they are different with regard to the ck_io[]-to-package-pin assignments, at least. Will you point me to the latest-and-greatest? My board is Rev. C. Thanks AN
  2. OK, no problem. Thanks for the user guide chapters. I'll bother Xilinx at this point, although you guys are WAY more responsive and helpful. AN
  3. Hi jon Hey John, thanks for your response. Yes you are correct, microblaze_enable_interrupts() is what I am using. If my manager would stop pulling me away, I wouldn't forget what I already know when I get back to this. Another my-dumb: microblaze_enable_interrupts() is working correctly. I saw the MSR getting the value 0x2, when I expected 0x40000000, and since bit 1 is reserved, my reaction was WTF? I dumbly forgot that microblaze is big-endian (why, why, why?). So ... Interrupts ARE enabled at the microblaze's IRQ input, and the problem is at the XINTC. By the way, for those of you out there in television land who were wondering, with only 1 interrupting device in a microblaze system that uses the AXI Interrupt controller, below is all that one must do to use a fast interrupt for your device: First, Compile your ISR with the following pragma, so that the saving and restoring of context is handled by the compiler, and the requirement for an intermdediate handler at address 0x10 is removed. __attribute__((fast_interrupt)) void my_ISR(void) {blah; blah; blah;} Then, in your main routine ... *xintc_ivar = (unsigned int)(&my_ISR); // Supply the address of the ISR for the device on slot 0 *xintc_imr = 0x1; // Configure the interrupt mode for slot 0 as a fast interrupt *xintc_ier = 0x1; // Enable slot 0 *xintc_mer = 0x3; // Set the 2 bits in Master enable (no more fakey hw ints, real ones only) microblaze_enable_interrupts(); // Enable the CPU to respond to its IRQ I will need to simulate in order to get to the bottom of this. Questions (sorry for the long list) A. When I'm debugging my system on the Arty board, can I get the debugger to generate a reset? B. What is the difference between disconnect and terminate? C. Why does relaunch reset the BD but not my RTL? D. How can I get a full system pin-resetting, or power-cycling the Arty board and starting over? E. Can I recompile the software and reset without leaving the debugger? Questions about the simulator before I dive in: 1. In the Vivado simulation environment will I be able to probe inside my RTL design which is external to my BD? 2. If the answer to (1) is no, then if I package the IP and put it inside the BD, will I be able to probe inside it? 3. Does simulating the block design reference RTL? If so, where is it located?
  4. Hey John, thanks for your response. Yes you are correct, microblaze_enable_interrupts() is what I am using. If my manager would stop pulling me away, I wouldn't forget what I already know when I get back to this. Another my-dumb: microblaze_enable_interrupts() is working correctly. I saw the MSR getting the value 0x2, when I expected 0x40000000, and since bit 1 is reserved, my reaction was WTF? I dumbly forgot that microblaze is big-endian (why, why, why?). So ... Interrupts ARE enabled at the microblaze's IRQ input, and the problem is at the XINTC. By the way, for those of you out there in television land who were wondering, with only 1 interrupting device in a microblaze system that uses the AXI Interrupt controller, below is all that one must do to use a fast interrupt for your device: First, Compile your ISR with the following pragma, so that the saving and restoring of context is handled by the compiler, and the requirement for an intermdediate handler at address 0x10 is removed. __attribute__((fast_interrupt)) void my_ISR(void) {blah; blah; blah;} Then, in your main routine ... *xintc_ivar = (unsigned int)(&my_ISR); // Supply the address of the ISR for the device on slot 0 *xintc_imr = 0x1; // Configure the interrupt mode for slot 0 as a fast interrupt *xintc_ier = 0x1; // Enable slot 0 *xintc_mer = 0x3; // Set the 2 bits in Master enable (no more fakey hw ints, real ones only) microblaze_enable_interrupts(); // Enable the CPU to respond to its IRQ I will need to simulate in order to get to the bottom of this. Questions (sorry for the long list) A. When I'm debugging my system on the Arty board, can I get the debugger to generate a reset? B. What is the difference between disconnect and terminate? C. Why does relaunch reset the BD but not my RTL? D. How can I get a full system pin-resetting, or power-cycling the Arty board and starting over? E. Can I recompile the software and reset without leaving the debugger? Questions about the simulator before I dive in: 1. In the Vivado simulation environment will I be able to probe inside my RTL design which is external to my BD? 2. If the answer to (1) is no, then if I package the IP and put it inside the BD, will I be able to probe inside it? 3. Does simulating the block design reference RTL? If so, where is it located?
  5. Another update: With a debug session running I see that the IE bit in the MSR is NOT set after all that screwing around with configuring the AXI INTC correctly. Searching for "how do I set the IE bit in the microblaze MSR" produced no hits on either Xilinx site search or Google. Can you imagine?! So ... how DO I set the IE bit in the microblaze MSR (using C, or C with embedded assembly)? Thanks, AN
  6. Hey Jon, thanks for the reply. I tried to attach the project, but it's way too big, 45 MB, and the forum site limits attachments to 1.95 MB. I used my code to implement the steps in the intc_example1 SDK project that I found in SDK somewhere, and my code is nearly identical and works perfectly with the phony (software generated using an XIntc register write) interrupt that they do. In the microblaze, there should (I hope) be an internal register where the status of the 32-bit address input and the 1-bit INT (or IRQ, or whatever they call it) input to the CPU can be read. If so, then I should be able to step through in a debug session and see if those ports are doing what they're supposed to. But this toolset and environment as well as the hardware designs are all brand new to me, so there is so much to learn on the way to getting a stupid interrupt.
  7. Hello again, I am a failure. I can't get interrupts working. I followed the example as closely as possible, given the differences. Xilinx support is ignoring me. Maybe you guys can get me out of this hole ... I have a block design with 1 interrupt controller, using only 1 interrupt source, which comes in from my external RTL module. Am I missing something stupid and obvious that everybody else knows about? Here is my super-simple test code:
  8. Thanks. I got it working different way. I have one interrupt controller with 2 interrupts (uart and my design). Can you point me to simple example C code to setup the interrupts? Thanks, AN
  9. Hi again, Indeed a reinstall of Vivado finally was the only way out from under this. Now, I have my verilog IP and my block design all stiched up and synthesized error and warning free. Final step before proceeding, I need to control with my IP, multiple I/O pins on a clock-by-clock basis, including both pad-direction ad pad data. Can you point me to a tutorial or a UM section that explains how to connect this up? Is there a prepackaged connector IP available for this purpose? Thank you again for your patience. AN
  10. Another typo, Im sorry. Should have tried it in my ncsim env first. 'timescale directives are optional. Also functionality obviously wrong, but irrelevant. But, here's my screen capture after adding the less dubious file i have attached. Top module name is giving me fits. design2_wrapper.v and design2.v keep ending up in the wrong places. I don't understand your statement: " I guess you could try copying the file into a Vivado project that doesn't use IPI to check them before you go to add the module." Should I be bothering xilinx and not you about this? Andy prot_mux2.v
  11. Hi Arthur, I'm back on this. Still, I find it impossible to add any RTL source files and then use the modules in my block design. When I create my design_2_wrapper.v it always shows up under non-module files. Same with the verilog files I add using add sources. Always I get the severe warnings below. Where are the details of the problem? Is there a detailed log that I can read? Attached is a simple verilog test file. This should not have compilation or heirarchy errors. I must have a screwed up env. [filemgmt 20-2001] Source scanning failed (launch error) while processing fileset "sources_1" due to unrecoverable syntax error or design hierarchy issues. Recovering last known analysis of the source files. [filemgmt 20-2001] Source scanning failed (launch error) while processing fileset "sim_1" due to unrecoverable syntax error or design hierarchy issues. Recovering last known analysis of the source files. prot_mux2.v
  12. Thank you so much for your help, and sorry to drag you into this elementary problem of compilation. I had asked about these 4 warnings earlier, because they are beyond vague, and your response confirmed my suspicions. It's incredible to me that such a severe error wouldn't be flagged as such. I should have taken this up with vivado support, but thanks again for steering me right. AN
  13. Sorry for being so terse. Here is a screenshot. As you can see there is no indication to me (the admittedly new user) that there are compile issues with the file I am adding. Am i looking at the wrong window? How should I know to look at the log for errors, and where would that log be? AN
  14. Good catch. But why can't I see the error that's being raised, but you can? It's not correct for you to be debugging my simple compile issues. AN
  15. Yeah, that thing on line 60 of capt_wrapper.v was a direct copy from the user manual, and is apparently a note to me the user, and not part of the attributes that need to be added. But having tried it with the the attributes fixed, I get the same result and the file ends up in non-module sources. Attqached is the fixed file. AN capt_wrapper.v