sLowe

Members
  • Content Count

    132
  • Joined

  • Last visited

  • Days Won

    12

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, 0b000001010); fnAudioWriteToReg(R8_SAMPLE_RATE, 0b000000000); fnAudioWriteToReg(R9_ACTIVE, 0b000000001); fnAudioWriteToReg(R6_POWER_MGMT, 0b000100000); Demo can be found here https://github.com/Digilent/ZYBO/tree/master/Projects/dma It uses microblaze but may still be useful designing for HDL -Sam
  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 https://github.com/Digilent/ZYBO/tree/master/Projects/dma 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. http://www.xilinx.com/support/documentation/data_sheets/ds180_7Series_Overview.pdf http://www.xilinx.com/support/documentation/data_sheets/ds162.pdf - Sam
  6. Hey Jay, The PmodBT2 IP is located in the vivado library repo on github found here. https://github.com/Digilent/vivado-library 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, https://joelw.id.au/FPGA/XilinxMIGTutorial 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 isn't really a good way of making projects span multiple versions short of writing everything in HDL. To go to 2016.1, someone will need to go through the same process I went through to upgrade it to 15.4. Although we usually try to only keep our designs updated to the latest even release so that will most likely happen when 16.2 comes out. To delete the work space, it is safe to exit SDK then delete the .sdk folder in \Arty\Projects\BSD\proj. (not the sdk folder located at Arty\Projects\BSD. ) I would do this, then export your hardware from vivado. File->export hardware. check "include bitstream" then launch SDK from vivado. (local to folder) Launch SDK can be found in the file tab as well. Once in SDK you should see your hardware platform. Click file->new->application project. Name your project, then click next. Select hello world then click finish. Here is your basic program. This should be able to run and print out "hello world" just fine and where in the future you can create new projects from scratch! To run the faux arduino bsd demo delete all the files located in the src folder and copy over everything from the src folder of the Arty/projects/bsd/sdk/user into the src folder of your project. Your new generated BSP and hardware platform should be the same as the ones in the sdk folder so you don't really need these. This code should run now and you can play around with digital I/O reads and writes. Just be sure to look at the digital.c library for how conventional xilinx projects do GPIO. I'm sure I missed a step so we will see how far you get. The programming flow is click xilinx tools->program fpga, then click into your main C file and click run on system debugger. Good luck! I'm sure I missed a step somewhere.
  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.) Build the project and hope for a success! I'm going to go ahead and try to port this to 2015.4 and fix the clocking issues to try to update the project so if that doesn't work hold tight and that hopefully comes out today or tomorrow. But that isn't quite the learning experience you are looking for so I'll try to document any problems I run into. - Sam
  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 referencing is when Vivado 15.4 was actually built at Xilinx so nothing to worry about there. Now for those critical warnings. It is really weird that all of a sudden your GPIO headers on top of your ARTY are complaining now. These correspond to the same named pins on the top right of the design. Especially since none of the other pins are throwing critical warnings (would point to the board files) Without looking at your project, my first step would be to hope the IP got messed up somehow and right click the system.bd file and select "reset output products". This will essentially make your project synthesize from scratch including the xdc file buried inside the gpio IP that is causing the critical warnings. The tools usually keep the same synthesis of IPs from run to run in order to save time. (this run should take longer than your last successful one.) Could you take a screen shot of your full block design and attach it? Sorry for making you take so many pictures. The dropbox links work great! -Sam
  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 left to consider is that the Microblaze processor needs to also talk to the XADC block. Luckily the axi_peripheral interconnect can buffer and handle clock domain crossing fairly well. This is why we changed the M13 pins on the interconnect. These corresponded to the AXI bus leading to the XADC core. So in review we took the XADC block and placed it into the same clock domain as the MIG. Whenever you see that your design fails timing, checking if your clock domains are the problem is a great first step! What exactly were your critical warnings in the synthesize stage? Your diagram looks fine so I can't tell what you are running into from the log. -Sam
  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_0_axi_periph block disconnect the M13_ACLK and M13_ARESETN[0:0] pins and connect them to the same respective nets as the XADC signals. The block diagram should look like this after. I have highlighted the reset and clk nets
  18. Adding to this thread that the Xilinx Web Server demo mentioned is posted here http://www.wiki.xilinx.com/ARTY+FreeRTOS+Web+Server
  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 http://www.wiki.xilinx.com/ARTY+FreeRTOS+Web+Server The COM port problem is something we seem to have a tough time explaining. Usually for me, if I am using a third party UART program I just flip between the non-zero com ports until I get an output. (I usually have a lot of boards connected to my computer). In my experience to debug pure HDL, we use simulations to analyze the design. In Microblaze designs this doesn't really apply. Another method is to use the ChipScope IP previously mentioned if the system edition license is there. I know in the Vivado HLS releases ChipScope is free for webPack but I am not certain about vanilla Vivado 2016.1. It may be worth a try to open up help->manage license and look in the certificate section to see if a ChipScope license exists. In my opinion the main benefit of Microblaze is to abstract you a little from whats actually going on at the logic level since it accelerates the development process and saves the time of designing all of the components needed. If you are interested in getting one step deeper, you can make your own IP blocks to interface into your block design. This process can be found at https://reference.digilentinc.com/zybo/custom_ip_cores Although the content is written for the Zybo, the process is there as long as you replace the other boards with ARTY. I found that to make the jump from user to designer with the tools was doing what you plan to do by starting to adapt designs then having to dive into the IP user guides when something didn't work. These are pretty dense at first but eventually you get a feel about how Xilinx designed these things and you begin to understand more and more about the tools along the way. -Sam
  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 error you are seeing is from not having the ILA (Integrated Logic Analyzer) ip in the design. You will still be able to debug the C code in the design later in SDK without this IP. The IP is included in the system edition of Vivado but I don't think it is in the Webpack edition. This tool basically lets you sniff internal signals of the design in real time. It is very useful for digital design projects but if you are using Microblaze, the debugging in SDK will be fine enough. The reason everything seems to use ISE is because ISE and Vivado use the most of the same background processes so a lot of Vivado tasks have ISE titles. Have you tried exporting your design and programming it at all in SDK? -Sam
  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 many XADC ports in the sequencer. This many inputs may slow down the update rate to the point where this error is created. Usually I think the way to get around this is by using the mig as a clocking wizard so that everything runs in sync with the speed of the mig. However that doesn't seem viable in this design. You can go ahead and run "generate bitstream" and it will work. Although an important signal, it is already averaged and shouldn't change too much. (assuming you aren't in an extreme environment) I ran the memory test with the timing errors and it passed just fine. While this isn't something to just ignore, for your purposes I don't think this timing error will affect you other than the ugly redness at the implemented design. ---------- As far as the debugging goes, wait and see if this design works for debugging. If you want to see where I spent the last hour reading about clocking and the MIG in general.... http://www.xilinx.com/support/documentation/ip_documentation/ug086.pdf http://www.xilinx.com/support/documentation/ip_documentation/mig_7series/v3_0/ug586_7Series_MIS.pdf http://www.xilinx.com/support/answers/51687.html -Sam
  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 explicitly driven to 0. (The tools end up doing this anyway.) If the errors do stop bitstream generation that is a big problem and would love to see the errors you are getting. Do they look like the ones below? [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[15] [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[14] [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[13] [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[12] [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[11] [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[10] [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[9] [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[8] [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[7] [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[6] [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[5] [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[4] [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[3] [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[2] [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[1] [Synth 8-4442] BlackBox module xadc has unconnected pin di_in[0] [Synth 8-4442] BlackBox module xadc has unconnected pin dwe_in [Synth 8-4442] BlackBox module xadc has unconnected pin reset_in [Synth 8-4442] BlackBox module xadc has unconnected pin vp_in [Synth 8-4442] BlackBox module xadc has unconnected pin vn_in It is interesting that the debugger did not work for you in SDK. Were you able to just run the program on your board without debugging it? It is awesome that you are hungry to play with the ARTY. The learning curve with the tools is pretty steep but as many will tell you the experience is very rewarding! -Sam
  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 this onto your board, open the hardware manager found under Program and Debug then open target. After your computer connects to your board, you can click program to load the demo onto the board. I haven't heard anything new about the web server demo but if it is just the freeRTOS components of the web server that you want, it is not too hard to get a simple RTOS project going in Vivado. You can respond to this and I can make a little reference design for the resource center. Hope this helps! -Sam
  24. sLowe

    Arty DDR3 Pins in .xdc File

    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 a lot by going through the wizard and trying to set it up manually too! Hope this gives a little reason as to why we put out the prj file. -Sam
  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!