D@n

Members
  • Content Count

    1815
  • Joined

  • Last visited

  • Days Won

    129

D@n last won the day on April 14

D@n had the most liked content!

About D@n

  • Rank
    Prolific Poster

Contact Methods

  • Website URL
    http://zipcpu.com

Profile Information

  • Gender
    Not Telling
  • Interests
    Building a resource efficient CPU, the ZipCPU!

Recent Profile Visitors

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

  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