• Content count

  • Joined

  • Last visited

  • Days Won


D@n last won the day on March 22

D@n had the most liked content!

About D@n

  • Rank
    Community Super-Star
  1. @MrKing, Welcome to the forum. Feel free to share your questions, as there tends to be a lot of learning going on here! Dan
  2. Have you considered any of the PModADC demos? The interface you are dealing with looks very much like the interface of one of the PMod ADC's, although I haven't found any with an ADC7266 on it... Dan
  3. @Ananthan, If you aren't getting any output ... then can you plot what your logic is doing and validate that it is doing what you want? Dan
  4. @sachin, In the core I pointed you at above, the input data is written to the core via a memory mapped I/O port on the wishbone bus. Consider the demo program to know how to do it, or look for me at #digilent-fpga on freenode and we can chat in more detail. Dan
  5. @Jayanth, So ... do you have any insight then into what's going on within the FPGA when things are struggling? I like to use a wishbone scope for this purpose, but it does require a wishbone bus to then read the results out. (I tend to apply a UART to wishbone converter to then read the data back out ....) Dan
  6. @Ananthan, Ok, found the data sheet for what you are up to here. Your 20MHz clock is well within the limits between 1MHz and 32MHz. On page 22, you can find a diagram illustrating how the device is to be accessed. Based upon that diagram, I would suggesting that you grab your inputs on the rising/positive edge of the clock. I think that answers both questions you asked. I might also suggest, though, that you don't use a logic clock that is locked to the ADC SPI clock speed. While I don't recall seeing what FPGA you are actually using, from my background an 80MHz clock is a slow FPGA clock. May I suggest that you run your SPI logic at the same speed as the rest of the FPGA, and just generate from this logic a SPI clock? I think you'll have more control over the interface should you do this. Other things to pay attention to include the fact that the illustration shows CS transitioning, whether high or low, when the clock is high. Just some things to think about, Dan
  7. It looks like you posted twice. If you don't mind, I'll confine my comments to the other thread/posting. Thanks, Dan
  8. @Jayanth, Okay, that's a good start but ... honestly, at this point, with the information you've given, there are still just way too many possibilities of things that could cause it. Let me just ask some basics then: are you using asynchronous resets? More than one clock? Transitioning on both positive and negatives edges of any clock? Are you double clocking any asynchronous inputs before using them to avoid any metastability issues? If you are using only one clock, and only the positive (or negative) edge of that clock (but not both), and you are properly registering every asynchronous input twice in order to transition clock domains then ... The next possibility would be to look at how the two modules are interacting with each other. Is there anything you can share there? Dan
  9. @Ananthan, That sounds like a specific question about a specific ADC. Which ADC are you using? Dan
  10. @Jayanth, Can you expand on what you are doing any? What "speed" are you trying to detect? What "modules" are you connecting, and how are you connecting them? Dan
  11. Hmm ... okay, but getting a "rhythmic tapping sound" suggests something's still wrong. From your code, it looks like you are using some form of PWM for an output. Have you considered my own PWM controller? I use it to control a PModAMP2. For now, and until you get your PWM controller doing anything useful, you might wish to just use the high order bit of a counter to determine your output: reg [31:0] phase; // We'll replace the counter variable with one we call phase, // just to be more explicit about what's going on. // // Further, we step by 18897--a number designed to give us a 440Hz tone // assuming a 100MHz clock. (# = Tone_freq / FPGA_freq * 2^32) always @(posedge i_clk) phase <= phase + 32'd18897; assign pwm_output = phase[31]; Be prepared, though, for a LOUD sound. (This would be FULL audio volume on a not-so-pleasant "tone") You can do the same with the DDS as well--ignore all bits but the high order bit. That'll prove that 1) your audio device works, 2) your PWM code (sort of) works, and 3) (when you add in the DDS) that your DDS works. Going from that to a nice, sweet sounding, PWM output will take more bits out of the DDS, and more work getting your PWM controller working. Dan
  12. @Simon, Whatever you do, do not unplug your device while the flash is writing. You may end up with a flash that returns uncertain results--sometimes ones, sometimes zeros. This will lead you to no end of problems, as you will struggle to debug it. This becomes somewhat of an achille's heel with modern electronics. You can read about it here. I would recommend that you only consider continuing following being unplugged if you 1) maintain power somehow so as to maintain your state, or 2) restart your state from a known startup condition. Dan
  13. For those interested ... The project has since been moved from OpenCores to GitHub. (I was unable to update the OpenCores repository.) The ZipCPU on board now supports 8-bit byte accesses (as opposed to 32-bit bytes), a divide unit, and a much faster approach to reading from the flash (80MHz flash clock, 80MHz CPU clock). As a result, the CPU should be able to execute one instruction every 17 clocks when running from the flash vice 52 clocks per instruction before. If nothing else, this proves that with a little creativity, you can do a lot with a very minimalist board. Dan P.S. The CPU can nominally run at nearly one clock per instruction at 100MHz, but that requires a faster FPGA and enough logic to place an instruction cache on board.
  14. @rb251415, Looking over what you just posted, I'm not seeing the problem. Care to share any more of your problem? Perhaps the problem exists some distance from your error? Dan
  15. @paolo_unice, Is it possible? Yes. Is it worth doing? Probably, depends upon your application. For example, you might be able to place a nice digital amplifier, filter, or even an echo generator in the middle. Is it hard? That depends: are the two devices running at different clock rates? If so, then it's ... not nearly as simple. If not, then things are easy. The basics of it is this: On every valid sample, you need to create and keep track of a sample_valid flag, and then you'll want to gate *all* of your signal processing with that sample_valid flag. This will allow you to do signal processing with a sample waveform that is slower than your clock rate. Then, at the end, you can use the gate to output your value, or (gasp!) even get sloppy and just trust that the output will be there on the top of every sample. This only works, though, if the two are sampled at the same rate. For anything beyond that, I'd need to stare at the code involved. Dan