• Content Count

  • Joined

  • Last visited

Everything posted by sLowe

  1. Yes, I put in the ability to record from line in or headphone in. Although before I start the transfer from Line in, i call fnAudioWriteToReg(R4_ANALOG_PATH, 0b000010010); fnAudioWriteToReg(R5_DIGITAL_PATH, 0b000000000);
  2. I just posted a DMA audio demo for the zybo and the volume seems to be right. The register assignments I used to initialize the codec are below. fnAudioWriteToReg(R15_SOFTWARE_RESET, 0b000000000); fnAudioWriteToReg(R6_POWER_MGMT, 0b000110000); fnAudioWriteToReg(R0_LEFT_ADC_VOL, 0b000010111); fnAudioWriteToReg(R1_RIGHT_ADC_VOL, 0b000010111); fnAudioWriteToReg(R2_LEFT_DAC_VOL, 0b101111001); fnAudioWriteToReg(R3_RIGHT_DAC_VOL, 0b101111001); fnAudioWriteToReg(R4_ANALOG_PATH, 0b000000000); fnAudioWriteToReg(R5_DIGITAL_PATH, 0b000000000); fnAudioWriteToReg(R7_DIGITAL_IF, 0b00000
  3. sLowe

    I2S IP core and AXI DMA

    I just uploaded an AXI DMA example on the Zybo github today. It records 5s into ddr memory then plays it out. It should answer your sample number questions. Demo can be found here Ill keep an eye on this thread if you have any more questions or ideas -Sam
  4. Hey Edge, Unfortunately, for Spartan-6, microblaze is not included with the webPack lisence in ISE. However newer boards can use microblaze designs under their webpack lisences. (artix, kintex, and zynq) The basys3 works fine for microblaze. However if you are creating a microblaze design that requires a lot of memory, the arty may be a better bet since the basys3 does not have external memory. You will be limited by the amount of block ram in the FPGA. Hope this helps, Sam
  5. Hey, Unfortunately both of these boards use the "commercial" flavor of the chips. This means that the FPGA operating range is specced at 0 C to 85 C. This can be found of the data sheets below. This also does not take additional hardware on the board into account. The industrial versions of these chips meet your range but I don't believe Digilent has any boards that have them. Although if you are just looking at the high bound, you may be fine. If that's the case, we can look at the hardware on the board and see if it too can stand the heat.
  6. Hey Jay, The PmodBT2 IP is located in the vivado library repo on github found here. We are also now adding support for the zedboard board files and that should be out shortly. -Sam
  7. sLowe

    ddr2 spartan6 in ATLYS

    Hi, While not having any experience with the mig for spartan 6 devices, this guide looks really helpful, I may try to take a stab at it myself too.
  8. Hey Bajelly, Your random values idea should produce some audible static. Unfortunately I don't know of any non-linux audio codec examples. We had a lot of fun figuring out the codec on the nexys-video for the looper but that uses a different codec. Good Luck! Sam
  9. For now you can make the pins external and constrain them with the XDC. We will edit the board files so that the OLED is supported. Ill have to refresh myself on how interfaces work so the spi pins get connected to a SPI IP and the GPIO to GPIO IP. -Sam
  10. No problem! I think you are over the biggest hump and will slowly become familiar with the tools. To see the UART I usually use a third party serial program. I use real term but a ton of people seem to like tera term. You can see it in sdk if you select run as->launch on hardware (GDB) then click the run menu-> run configurations. Select GDB, then go to the STDIO Connection then check "Connect STIO to Console" then select the serial port and Baud rate which I believe is 9600 for this application. This will put you UART in the console window at the bottom of sdk. Glad to help!
  11. First off that upgrade message doesn't really involve you that much. Xilinx decided to improve their packaging of the IP's. They will work the same regardless but the new format may be more compliant with future tools and may be smaller in size. That change just happened and the transition is still happening. So who knows maybe it could cause problems. Those other warnings don't raise any flags with me since I don't believe any of those signals are used explicitly in the design. The BSD wiki is correct, the current project will only build with 15.4 now. Since so many IP's change, there i
  12. oops I never synced with github.... That is absolutely where you should look for it. The updated project should be up now.
  13. New 2015.4 project is on the wiki/github now. I didn't run into any problems upgrading it at all. Basically opened the project in 2015.4, upgraded all the IPs and everything built correctly. I still don't know where your critical errors are coming from though. Hopefully starting from scratch will help you out.
  14. Honestly starting over would be my next step. Your diagram looks exactly like mine upon inspection. Now that you know the steps to take, it would be a relatively quick process and if the errors are still stemming from the shield I/O pins, then the project may just be broken. (I wish I could explain more but the software just isn't perfect) The process should look something like 1.) Exit Vivado and run the cleanup script in the project folder. 2.) Rebuild the project by calling the create_project.tcl in Vivado 2015.3 3.) Change the clocking nets that we discussed. 4.) Buil
  15. Yeah if this were true verilog, changing nets in text is an option and I am sure there is some tricky way of doing it that way. (maybe editing the Verilog file enclosed inside the block design.) But unfortunately when using block designs, you are for the most part locked into the GUI and its functions. By the way to reset a run usually a little trick I use is putting a space in the system wrapper.vhd file then deleting it and saving. The tools will think the design has changed and will reset your run. The way you found is probably the correct way to do this though. The dates you are refer
  16. For educations sake, the reason we made those connections were to put the XADC core onto the same clock domain as the DDR memory. The design has a couple clock domains. One comes from the clk wizard which generates the system clock and a couple reference clocks for the MIG to use. The MIG then uses these clocks to read and write data. However this data stream has now created a new clock domain. One that is defined by uiclk. The temperature data that comes from XADC needs to be on this new memory/uiclk domain. In order to accomplish this we need to make the XADC clocked by uiclk. The only thing
  17. Its not too hard at all! I will make some steps for you. The first thing you will want to do is disconnect some nets. To disconnect them without deleting the whole interconnect, click the pin label, then right click and select "disconnect pin" The first two pins will be on the xadc wizard block. The pins to disconnect are named s_axi_aclk and s_axi_aresetn. Then connect s_axi_aclk to the uiclk pin on the MIG. Connect s_axi_aresetn to peripheral_aresetn[0:0] on the rst_mig_7series_0_83M block. Now we are going to do the same thing with two more pins. On the microblaze
  18. Adding to this thread that the Xilinx Web Server demo mentioned is posted here
  19. First off any record of people hitting walls and breaking through them will be helpful to any people in your same situation so no worries about posting so much! I will start off with some good news that the Web Server demo from Xilinx finally got posted so that IoT destination just became much easier to get to. Although I would definitely work these projects out until you are comfortable with these small Microblaze demos before diving into that one. I haven't tried it but the source/tutorial can be found here The COM port problem
  20. Ok I think I have this figured out. First off my cube mate filled me in on how to fix those timing errors we were seeing in the BSD, Basically the XADC needs to be put in the same clock domain as the MIG. This can be achieved by disconnecting the clock and reset pins of the XADC and the M13 port on the AXI interconnect. Then attaching the clocks to the uiclk output of the MIG and the reset to the peripheral reset from the rst_mig_7series_0_83M block. I did this and the timing errors went away. Eventually this will be fixed and the project will be updated to at least 2015.4 The debugging e
  21. Yeah looks like the temperature reference data is not being set up in time for the MIG to look at it. From all the guides I just looked through it seems like it uses this to keep the data lined up since it knows how the memory IC is affected by heat. This temperature reading comes from the XADC sequencer. I was not able to immediately get rid of these errors. The hardest part being that the axi clock in the design is set to 100 MHz which is where is should probably stay. Then the MIG is running at 200 MHz on a different clock domain. Another possible problem is that we are just including too m
  22. Hey lemoutan! Sorry to hear about your frustrations. Could you maybe take a screenshot of these "critical errors" you are getting if you still have the project up? When I ran the project I got "critical warnings" that although may look bad and in other projects can point to large issues, these refer to problems that the design accounts for. The xadc demo lets the wizard initialize the IP so that the demo itself does not need to talk to the IP over the DRP interface. That is why those pins are not connected. Those critical warnings can most likely be eliminated if those ports are explicitl
  23. Hey Lemoutan, To see if your board files are actually installed correctly, make a new project then click next until you are asked to specify the part. You should be able to click the boards tab and see the ARTY in the list. Next is addressing the critical errors. These should just be warnings about unconnected pins to the XADC IP. This is ok since the design does not need them. The dialog you are getting is expected because the export hardware option is used for Microblaze designs. The XADC demo is purely a digital logic demo and does not utilize the Microblaze core. To load t
  24. Hey Steve, The advantage to using the prj file vs a traditional xdc is that the prj will configure the whole MIG IP whereas an xdc will only constrain the pins. Along with the pins, the prj handles options such as device ID, data formatting, and signal impedance. Going through all these options are a serious pain when configuring the mig and the .prj gets rid of this hassle. The MIG is very configurable for different memory devices but since the ARTY just has the one, there isn't a need to run through the whole IP configuration repeatedly when the prj handles it. However you do learn
  25. sLowe

    MUX 2x1 using VHDL

    Hey Jaiko, On top of this module I would use the clocking ip wizard to generate these two frequencies. Once you do this, you can feed the two clocks into your mux. However, you may get some critical warnings about logic on clocks but since you are using them for PWM and not actual clocking, this should not affect your design. Hope this helps a bit!