• Content Count

  • Joined

  • Last visited

  • Days Won


D@n last won the day on March 4

D@n had the most liked content!

About D@n

Contact Methods

  • Website URL

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. D@n

    Nexys 4 store data in flash

    @savmil, None of my examples used microblaze, so it's not too difficult .... Dan
  2. 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
  3. 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
  4. @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
  5. 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
  6. @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
  7. 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
  8. @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
  9. @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
  10. Are you building an FFT or using an FFT? Dan
  11. @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
  12. @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
  13. If memory on the Basys3 board is an issue, why not check out the HyperRAM PMod from 1-bit squared? It competes nicely with the traditional DRAMs, and easily adds on to the side of the Basys3 board. That would allow you to (slowly) load audio from the SD card, and buffer it in a massive external RAM for later (fast) use. Dan
  14. Source code for an FFT? Sure! Here's a directory containing the output of an FFT code generator. You can read more about it here. Dan
  15. @Ahmed Alfadhel, The real answer is that if you have both sys_clk and ddr3_sdram_ck* on the same bank, your pinout is still wrong. sys_clk is on a 3.3V bank, ddr3_sdram_ck* is on a 1.35V bank. If you give Vivado the wrong pins for these three wires, it will complain about the wrong voltage standard. Go back and set these pins to their right values. If you want a quick way to do this, consider using this UCF file to load the pin definitions directly into the MIG DDR3 SDRAM controller generator. Dan