Wilton

Members
  • Content Count

    9
  • Joined

  • Last visited

  1. Wilton

    Zybo Block interface

    I have at least a partial answer. By looking at the "External Interfaces" and expanding ADC_INT_3v3IN I found out the program breaks that down into two signals suffixed with "_v_n". Making the xdc file conform to that solved the ADC issue. (At least it built without error, I haven't tried to use it in SDK, yet.) And while this is a bit more crude than I would have hoped for, I found "Utility Buffer" in the IP that can be configured to be a OBUFDS which I could then map to external ports that matched the xdc file. I'd have preferred to be able to tell it the port was differential and have it infer the OBUFDS because it would keep the block diagram much simpler, but this did the trick.
  2. Wilton

    Zybo Block interface

    I'm still trying to connect the dots between the various pieces of Vivado. I just created an xdc file for a project. It has some differential I/O. By looking at examples, I figured out that PACKAGE_PIN is not needed for the _N pin. Next is how I connect a block IP to this. I've done it for some simple single ended uses. But here are two differential examples I can't sort out: 1. Create a differential clock. The block diagram has FCLK_CLK1 which I have set to 40 MHz. The xdc file has: #8 channel 40 Ms/s DDR Serial ADC #IO_L4P_TO_34 set_property PACKAGE_PIN V12 [get_ports ADCCLKout_p] set_property IOSTANDARD DIFF_HSTL_I_18 [get_ports ADCCLKout_p] #IO_L4N_T0_34 pin W13 set_property IOSTANDARD DIFF_HSTL_I_18 [get_ports ADCCLKout_n] How do I connect the two together? I put an external port on FCLK_CLK1 and named it ADCCLKout. Or should that bt ADCCLKout_p? or? or do I have to place an OBUFDS between the two? If so can that be done at the block level or does it have to get buried in a Verilog file somewhere? 2. I instantiated an XADC Wizard with four ADC inputs. In this case I created xdc file entries for each: #The following pins are external ADC inputs. #The IOStandard does not matter so long as it is compatible with the I/O Bank voltage #IO_L5P_TO_AD9P_35 set_property PACKAGE_PIN E18 [get_ports ADC_INT_3V3IN_p] set_property IOSTANDARD LVCMOS33 [get_ports ADC_INT_3V3IN_p] #IO_L5N_TO_AD9P_35 set_property PACKAGE_PIN E19 [get_ports ADC3V3IN_n] set_property IOSTANDARD LVCMOS33 [get_ports ADC3V3IN_n] Again, the question is how to tie this to the block? I put an external port on Vaux6, for example and named it . . . Well I named it ADC_INT_3V3IN, but maybe I needed the _p. But then they aren't defined as differential in this case, so it couldn't find the _N. Help me bridge this gap. I haven't been able to find anything on-line or in UGs. Thanks
  3. Wilton

    JTAG-HS3 vs JTAG-HS2

    The web pages and data sheets indicate that HS3 can't program SPI flash chips and HS2 can, so for some users, that could be a reason to have at least one HS2 on hand. In my case at present, I'm working with Zynq devices and I'm sure there are ways of passing FLASH code through the device using JTAG and possibly some PS code (still to be explored), but the HS2 provides a direct hardware method and I believe Digilent has drivers to simplify using that capability.
  4. Here's an interesting post-solution addition. The design is less than compelling as created due to the fact that it increases the PWM linearly whereas the eye observes the LED logarithmically. I made a small change to the program that causes it to increase exponentially, creating a more visually pleasing effect. The key is to scale the variable by 256 so integer truncation is not a problem. Then multiply it each time by 257 and divide by 256. The step increase is 1 initially, but as the value grows larger, the step grows with it. The result is that the observer can see the LEDs essentially off and growing dimly, whereas the original appeared to start well up on the brightness curve and grow very slowly at the end. Here is the modified code: #include "xparameters.h" #include "xil_io.h" //#define MY_PWM XPAR_MY_PWM_CORE_0_S00_AXI_BASEADDR //Because of a bug in Vivado 2015.3 and 2015.4, this value is not correct. #define MY_PWM 0x43C00000 //This value is found in the Address editor tab in Vivado (next to Diagram tab) int main(){ int num=0; int i; while(1){ if (num >= 262144) { num = 0; } else if (num == 0) { num = 256; } else { num = (num * 257) / 256; } i = num / 256; Xil_Out32(MY_PWM, i); Xil_Out32((MY_PWM+4), i); Xil_Out32((MY_PWM+8), i); Xil_Out32((MY_PWM+12), i); for(i=0;i<100000; i++); } }
  5. OK. I finally succeeded on my own. For anyone else who might fall into a trap, my issue was at step 8.2. It says click next and finish, which is a bit too abbreviated. I probably missed the part about next (there isn't a picture of the screen after that). Clicking finish uses the default project (that will be seen if you click next). In my case it was Hello World. Exactly why it didn't give me a conflict on a duplicate copy of main() I don't know. When I built this for the third or fourth time, it did give me a conflict. As Jon pointed out early in this exchange, you have to select "Empty Application" for a template. Once I did that I built something that worked as intended. It is also fairly easy to get the board in an uncontrollable state. Failure to download the bitstream or downloading an inappropriate project (such as a conglomerate of Hello World and this project. It can get to the point that the SDK can't communicate with the board. Fortunately, unplugging the USB (at least if it is USB powered) and plugging it back in rather painlessly puts it back in a known and blank state. The bitstream has to be downloaded again and then the project can be run. Jon, thanks for hanging in there with me through this one. Now I get to try packaging my own IP and seeing if I can put all the pieces together. I think I have enough information from this tutorial to do so. The major new step for me at present is interfacing my Verilog to AXI, and I think this has given me what I need. So this issue is resolved and closed. I don't know if there is a formal process for that.
  6. I've made a little progress. I downloaded the second zip. I found sdk in the start menu and launched it and opened the project, downloaded the bitstream and ran the code--and it worked as intended. (other than the fact the when running SDK from the start menu it couldn't figure out how to edit main.c--there's some link to the editor missing). So I will go back a third time and try to build this more carefully myself. My guess is that I may not have absorbed enough of the first demo. The IP demo is rather brief on the generic starting instructions and I may have overlooked something important. Thanks for the help. I will post a resolution (or further questions) later.
  7. Thanks for the quick response. Unfortunately I'm still not at the end of the tunnel. I copied the project to my system and tried to open it in SDK. The only way I know to open SDK is from Vivado. SDK isn't even on my desktop. So I had to open it in Vivado, which immediately complained about the xdc file, so I gave it a valid file location on my system. Then it complained things were out of date, so I had to generate a new bit stream and all that entails. Then I tried to launch SDK, but it couldn't match up anything, so refused to launch, so I had to remove the sdk directory and export it, which meant rebuilding stuff in the SDK. The end result was no pulsing LEDs! I did see some differences that might be worth noting. Your sdk source file had helloworld.c and platform.c and h and platform_config.h in it that mine did not. The resulting elf file included them. I guess my main goal here is to understand the process more. I didn't end up with the same outcome you did. I need to know how to open and run your version without changing it, which will probably help me to know how to maintain designs in general.
  8. I just completed the Zybo custom IP tutorial and everything appeared to be fine until I ran the application (last step). It did nothing. I tried running in debugger and eventually concluded that it was stuck at memory address 0x10, not in the source code. I previously did the getting started tutorial just fine, so I know the hardware is working and presume I have a basic understanding. The custom IP tutorial was preparatory to creating some custom IP of my own for a custom board, so I need to understand the process. My initial guess is that there should have been some initialization function called from main, like there was in the getting started tutorial. I even tried copying the function call from getting started, but the function didn't exist. Given how many things happen automatically behind the scenes in Vivado/SDK and my lack of experience with ARM, I don't quite know where to go. I don't even know if the issue is in Vivado or in SDK. I could blow the project away and start over. Maybe I wouldn't make the same mistake a second time. I don't know. (I'm an experienced programmer, but new to Vivado and SDK and Arm, and relatively new to gnu).
  9. I'm not sure why all the secrecy about this interface. I would like to use the Zybo as the starting point for a much simpler dedicated design using Z010, and would like to include that remote programming capability. The Zybo bootstraps the process for intial experimentation and until boards can be fabbed and assembled. Is that a problem? The final design contains a number of application specific components (including a 40 MHz 8 channel ADC) but omits DRAM, uSD card, video, audio and PMOD