• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by D@n

  1. @dcc, This is really the backwards way to get something like this going. You should be proving your design in simulation before jumping into a design on hardware. Let me offer you an alternative. Here is a Verilog driver for talking to an SD card using SPI. If you have already chosen to use the AXI bus, you can find an AXI-lite to WB bridge here that will allow you to talk to this core. Even if you already have a driver you like, this documentation for this one describes how to set up the SD card to where you can talk to it, and provides examples of how to read and write sectors. Even better, there's a piece of C++ code which can be used as a simulator with Verilator. (Not sure if this would work with MicroBlaze or not.) You can then use Linux tools, such as mkfatfs and such, to create a file with a FAT format that you can use as a "simulated" SD card. When the simulation isn't running, you can mount the card on your system and check out/modify the files, and so know that things will work (based upon your experience with simulation) once you finally switch to hardware. Indeed, if you are willing to accept the risks, you could even interact with your SD card from the simulation environment itself. If you want an example of a set up that would control the SD card interface from a ZipCPU, you can check out the ZBasic repository which has such a simulation integrated into it. Indeed, there's even an sdtest.c program that can be used for that purpose. As for reading and comprehending the FAT filesystem, there's a FATFS repository that is supposedly good for use with embedded software. I haven't tried it, so I can't comment upon it that much. Alternatively, if you can control how the file system is laid out, you should be able to place a file of (nearly) arbitrary length a couple of sectors into the FS, and force the file to be use contiguous sectors. If you do that, then you've dealt with the most complicated parts about reading from the SD card. Just my two cents, and some thoughts and ideas along the way. Dan
  2. @Ahmed Alfadhel To understand what's going on, check out table 8 of the datasheet on page 15. Basically, the DAC provides outputs between 0 and max, where 0 is mapped to zero and all ones is mapped to the max. In other words, you should be plotting your data as unsigned. To convert from your current twos complement representation to an unsigned representation where zero or idle is in the middle of the range, rather than on the far end, just toggle the MSB. Dan
  3. @LazerBoi64, Are you sure you have the right vendor? I just checked through all of the items on sale in the embedded processor section and didn't see any BeagleBone Blacks (BBBs) for sale. Dan
  4. I'm going to disagree. The fastest way to verify your code is working is with formal verification. Unlike your traditional test bench methodologies, the formal tools tend to be more thorough in finding bugs. They can often be much faster as well. Similarly, generating and running a simulation tends to be much faster when using Verilator over and above what Vivado offers. As for simulating LEDs and buttons, I cover those in my tutorial. If you want VGA, I've posted a VGA simulator on line--the same one I used for my BASYS3 board, so it should work for you. Similarly, I've also posted simulators for the PS/2 mouse and the Flash device, so you should be able to do just about anything with simulation before touching the hardware. (No, I haven't simulated the PS/2 keyboard--I had to leave something left for you to work on ) Dan
  5. @FPGAMaster, If you want to take a peek at what the missing pieces from the schematic (probably) look like, check out the schematic for the MAX-1000 from Trenz. It's got the missing USB/FTDI programmer circuitry shown, and operates in roughly the same fashion. Dan
  6. D@n

    Passing FFT result to DDS

    @FR There are many ways to construct a sine wave. You could do a table lookup, or even a quarter table lookup. You could do a CORDIC. You could do a table lookup followed by a linear or even a quadratic interpolation. That part is the least of your worries. Your bigger problem is going to be the fact that short-time Fourier Transforms (STFTs, such as what you've just used), are not phase continuous in nature. As a result, depending on how you set up the overlap, you might find that every odd bin jumps 180 degrees of phase between transforms. Worse, if that wasn't enough, what happens if the incoming tone doesn't line up exactly on an FFT bin? This piece of reality has been known to kill a lot of poorly thought out FFT approaches. Something else to think about: Are you hoping to match the phase of the incoming sine wave? The phase delay through the FFT is both coarsely sampled and linear in frequency. I might suggest perfecting your algorithm off-line before even experimenting with it on an FPGA. I often use Verilator to accomplish both at once, although I know there's a large group of individuals who like using MATLAB for prototyping before moving to hardware. Dan
  7. @jrosengarden, Ooohh, I've got one: Check out this tutorial, and the articles on this blog. </shameless plug> Dan
  8. @yildizabdullah, Are you using ISE or Vivado? I would've expected Vivado if you are working with the Nexys A7. ISE uses UCF files, Vivado uses XDC files--that's why I'm asking. Either way, you don't need to declare the SPI SCK pin in the constraints file. However, getting access to it is a bit more involved. To get access to the spi_clk pin you need to use a special primitive, either STARTUP_SPARTAN6 for the S6 (not the Nexys A7) or the STARTUPE2. You can find an example of using the STARTUPE2 primitive to get access to the SPI clock pin here, and more general instructions here. Dan
  9. 166.667MHz out of the clocking wizard and going into the DDR3 MIG controller? That sounds too high by a factor of two Dan
  10. @FR, No, that's not quite right. Your data rate is not 100MHz, it is 61MHz. Therefore your bin separation should be 61MHz / 65536. Dan
  11. @FR, Since you haven't provided me with enough information to really answer what's going on, here are some guesses: You mentioned that your FFT and FIFO are both running at 100MHz. May I assume that this is your system clock rate? Looking at your image above, it appears as though you have a much lower data rate than 100MHz. Can you tell me what your data rate is? I notice that you are using a FIFO. Can you explain the purpose of this FIFO within your design? If the data rate going into the FFT is at 100MHz, then the FIFO really only makes sense if you have bursty data at a rate faster than 100MHz. I have strong reason to believe that your tlast isn't quite right. Can you verify that if TLAST && !TVALID, then TLAST will be remain true on the next clock? Indeed, is your TLAST generation done at the rate of your incoming data? Or is your counter independent of incoming data samples? I understand you double checked your FIFO with MATLAB. You can read about my experiences with double checking my FIFO here, and the problems that remained unchecked. These are just some ideas I had. They are by no means definitive. It is difficult to be definitive without more information about your design. Dan
  12. @yildizabdullah, You might also find these blog articles useful: Here's one on building a basic SPI flash controller, and here's a more detailed one discussing how to build a full-featured &nbsp;QSPI flash controller. Dan
  13. D@n

    Nexys 4 store data in flash

    @savmil, @JColvin is right. Here's a trace showing what sending a 0x05 should look like. In this trace, the o_qspi_dat[0] line is the same as the MOSI line in your design. Of course, since this is a read-status command, you'll want to keep the CS_n line high for longer ... (I had thought this was a write-enable command when I created the trace ...) Dan
  14. D@n

    Nexys 4 store data in flash

    @savmil, None of my examples used microblaze, so it's not too difficult .... Dan
  15. D@n

    Nexys 4 store data in flash

    @savmil, If your goal is to store data, then be aware: flash memory doesn't work like other memory. There are two operations required of storing data. The first operation turns the bits from zeros to ones. It is typically applied to sectors only, meaning that if you want to change an 0xa0 to a 0xa3, you will first need to wipe the entire sector clean of data. This is controlled by the ERASE command. (Sectors are usually around 64kB, although some devices allow access to 2kB sectors.) Once the sector has been erased, *EVERY BYTE* within it will be 0xff. This operation can take up to a couple of seconds to complete--see your data sheet for more details. The second operation is more selective. That's the PROGRAM operation. This operation turns one bits to zeros. So, going back to our example of trying to change a 0xa0 to a 0xa3, you first ERASEd the whole sector. That would turn this byte (and many others) into 0xff. You could then program this byte to be a 0xa3. Indeed, you can program up to a PAGE at a time (typically 256 bytes). While programming flash memory is faster than erasing, it is still incredibly slow. Indeed, it is so slow to do that all of my FPGA CPU designs treat the flash as a ROM rather than any other type of memory. If you look at the flashdrvr.cpp program component within my design, you'll see the code I use to adjust the contents of the flash memory. This driver is usually called from within another program, both external to the FPGA, such as zipload.cpp, which loads a program and/or a design configuration file into flash memory. Dan
  16. D@n

    Nexys 4 store data in flash

    @savmil, Heh, I'm in the process of writing a (rather long) blog article about how to build a flash controller within your design. Here's a link to the last flash controller I've written, and then here's some thoughts to get you going: If the flash isn't responding right, rule number one is to first get and examine a trace of what values you are sending to the flash. Make sure that trace matches the spec for the flash. I use a flash simulator with most of my designs. It works with Verilator. You can find an example of the flash simulator I am using for the Nexys Video board here. (It's probably still close enough to work with your board--the Spansion devices are quite similar.) If it's still not working, send a command for which you expect a known response--something like the 0x9f command to read the manufacturer ID. From this known response, you can debug any delays you have in the logic. After all this, you can then try to switch to QSPI if you want. If things go bad, I've found that sending (via normal SPI) two words of 0xff on dat[0] or MOSI (same wire) and then raising CS_n again should usually get you back into SPI mode. If you have more problems beyond that, then let me encourage you to be more specific, share waveforms and/or logic, and let us know what's really going on within your code. Dan
  17. @Denci, Your test setup has a large variety of problems. If the rat trap sound duration is 5ms, it's going to have kHz frequency components. Viewing the output of the rat trap in frequency should confirm this: short time events have very high frequency components. If you are subsampling, roughly at anything less than 8kHz for example and still perhaps even then, then you are losing important sound information. Even at 8kHz, if you aren't using an antialiasing filter, you'll be still losing information. Are you checking for clipping? For overdriving the microphone? The PMic3 is a very sensitive microphone, and so it is easy to overload. You might wish to check within your design that the output samples never go past 95% of the entire range. Physics is a really annoying thing. To expect the exact same waveform from the rat trap from one snap to the next is ... more than you are likely to get. Remember, if it stinks it's chemistry, if it crawls it's biology, and if it doesn't work it's physics. Little things like moving the rat trap, opening or closing a cupboard, moving your circuit board, leaning back in your chair and more can adjust the received rat trap waveform. For this reason, I'd probably use some sort of energy F-test rather than a waveform matching test. If this is what your instructor wants, though, you might wish to note these realities. You should be able to push your serial port up to about 1MBaud, sometimes even as high as 4MBaud, using the FTDI devices. They are rated for 12MBaud, although I've never managed to get speed anywhere near that high If you really want to check the shape of the rat trap audio waveforms, rather than just energy detection, I might recommend taking a snapshot of the waveform based upon an energy detect trigger. You can use a simple LED to determine if the snapshot has triggered, and only dump the samples in that case. Just some thoughts, Dan
  18. Wow! That twitter survey surprised me a bit. Based upon a (self-selected) sampling of all FPGA designers (who follow my twitter feed), a full 65% of them are self taught! From that (un)scientific study alone, I would judge that @Jonathon Kay is in good company 😎 Dan
  19. @hello.parth, Check out this distribution. ( @zygot was going to make you work for it ) While my own ethernet controller receives packets just fine on a Nexys Video, it's not (yet) transmitting packets reliably. (I tied the transmit network clock to the receive network clock .... oops.) Dan
  20. Wow, I'm a genius now!! Okay, to seriously answer the question, I thought I'd ask those following my twitter feed. The poll will take approximately a day before Twitter reports the results to everyone. That said, of the first 16-votes, the results are overwhelmingly self-taught from on-line sources. While this is hardly a statistically significant sample, and while my twitter feed is probably a touch biased, it's still a fascinating data point. Feel free to join in with your own vote, and lets see how this turns out! Dan
  21. @hello.parth, You are quickly going to run into the problem that Digilent holds its configuration logic to be proprietary. It's not shown on the board schematic. (I haven't asked them, though, if they'd ever sell this information ...) Regarding reading the configuration from flash, that part of the design can usually be found on their boards. Each Xilinx FPGA has a specific set of pins for the configuration flash. Use those pins, and set the appropriate mode pins for loading from flash, and you should be good. Loading from JTAG is a bit more difficult. While you don't need to adjust the mode pins to switch from SPI loading to JTAG loading, you'll still need to figure out how to hook up the FTDI chip and that's the part of the Schematic that's missing on the Digilent boards. Let me suggest that you instead copy the JTAG+UART portion of the design from the Max-1000 circuit board from Trenz. If you dig a little deeper, you'll quickly discover that FTDI is so committed to supporting FPGA designs that they also have demonstration designs showing how to use JTAG when using their chips. If worse comes to worse, you can at least load a design via an FTDI chip using the open source libxsvf driver. Dan
  22. @Jonathon Kay, The short answer to your question is that, Yes, you can. I self learned on the Artix 7, and later on Altera's ARM+FPGA board, the Cyclone V. It is doable. The long answer to your question is that there are a lot of things to learn, and not all of them are easily self taught. Particular lessons include not only the language itself (I also recommend Verilog), but you should also have a good understanding of clock crossings (what they are and how to manage them), design to resource mapping (this can be learned through trial and error--pay attention to how much logic your design uses), how to correct timing problems (you can wait 'til you get some, and write back here for help if need be), how to connect to external pins for both inputs and/or outputs (PMods are good for this), as well as how to design a component using the AXI bus. I recommend learning how to use AXI-lite first, but the reality is--if you want to use a Zynq device, you'll need to be able to make and integrate AXI peripherals and AXI-lite is a whole lot easier than just AXI. You'll also need to learn very quickly that FPGA designs are not nearly as easy to debug as software designs--to include microcontroller designs. Most early/beginner lessons discuss how to use LEDs to debug a design. These are great for your first lesson or two, but you'll quickly outgrow them. Make sure you take some time to learn the other debugging methods available to you, or you will really struggle to get any significant design working. Remember, the simulator is your friend. Learn how to use it early, and use it often. Further, when you get to the point where you want to build an AXI peripheral, I strongly recommend having an understanding of formal methods. These come for free with Verilog, not so much with VHDL or SystemVerilog. (It's amazing how easy it is to debug someone else's AXI-lite core using formal methods ... your own core would be easier.) Just my two cents, Dan
  23. Are you building an FFT or using an FFT? Dan
  24. @raymondlam, If you check out Xilinx's 7-series CLB user's guide, you'll read, The difference stems from the fact that 7-series devices don't have four input LUTs, they have 6-input LUTs. This leads to an apparent bit of inflation in the advertising material, until you read the fine print. However, if you look at the Xilinx 7-series overview datasheet, you'll see that right next to the logic cells number they identify a number of slices found within the design. In the case of the S7, using a XC7S50 part, there are 8,150 slices within the design. Each of these "slices" has (roughly) 4 LUTs, and so this matches your design numbers above where you've discovered your design has only 32,600 LUTs available to you. Dan
  25. @gummadi Teja, What you are asking for is not the common approach to building FFTs, therefore let me take this moment to invite you to build an FFT that uses the CORDIC algorithm without any multiplies. Let me also share with you what I think you will discover. While CORDIC algorithms do not use multiplies, they aren't necessarily logic efficient by any stretch of the imagination. Worse, CORDICs apply a gain to the incoming signal. Before you think this gain might be easily factored out since it applies to all incoming samples, let me remind you that there are two paths through each butterfly--one that would get the gain and one that would not. That brings you back to needing a multiply again. The FFT algorithm I linked to above does have an option that doesn't require hard multiplies (DSPs). Be aware, though, if you use this option the generator will build your multiplies from shifts and adds and this will cost you a lot of logic resources. Yes, I am aware of an alternative multiplication algorithm that I've come across that is very light on logic resources, but it also requires a delay equal to the number of bits in the multiply. That would slow the FFT processing down to (roughly) one sample every 54 clocks or so. Yes, the algorithm is similar to a shift-add multiplication algorithm, although about 2x less the area. While I've thought of integrating this into my own FFT design, no one has been paying for this upgrade so ... it may take a long while before I get to it. All that said, there's a saying in English that "Beggar's can't be choosers." If you really want a specific type of FFT implementation, you might be stuck with needing to build it yourself. Perhaps if you share more about why you are so interested in such an algorithm, and what engineering problem you are trying to solve, it might be easier to actually recommend a solution to your design problem. So far, you've been asking for an implementation, when I think what you need is a solution. The two are very different. Dan