• Content count

  • Joined

  • Last visited

  • Days Won


D@n last won the day on July 20

D@n had the most liked content!

About D@n

  • Rank
    Prolific Poster

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

    Setting up AXI Quad SPI on Arty

    @UncleSlug, I've now written several SPI controllers ,for several parts. XIP has been an important feature to those controller. Other than trouble shooting, I can't think of any reason not to use XIP. Dan
  2. D@n

    Odd timing violation

    Sounds like you are trying to build an asynchronous FIFO. There are some tricks you need to take care of to make it work right. See this article for a discussion and some references. 'Dan
  3. D@n

    CMOD A7 Unable to program

    @StijnVM, FT_PROG will render the board unusable? Likely. Recoverable? Definitely. If you have reprogrammed the board at all using FT_PROG, please say so--the Digilent staff has been more than helpful to folks recovering their boards from this problem, and it could help quickly cut down the troubleshooting time for your board. Dan
  4. D@n

    Extremely exact clock frequency

    In general, you should want to do everything in the same clock domain. Crossing clock domains is usually considered a potential source of errors that can be hard to debug. Dan
  5. D@n

    Extremely exact clock frequency

    I just instantiate a BUFG anytime I need it. In verilog, it looks like, wire bufg_input, bufg_output; assign bufg_input = clock_input_pin; BUFG mybufg(.I(bufg_input), .O(bufg_output)); After this, you'll want to avoid using bufg_input or clock_input_pin anymore. Make all your references to bufg_output instead. A bufg by itself doesn't halve the clock rate, it just places the incoming clock wire onto one of the high speed global clock distribution nets within your design. But let's come back to the dividing a clock by two. Is it unwise? Yes. If the divided clock is only going directly to an output port, it might work. You may have a problem that one design will have one phase relationship between the two clocks and another design will have another. An alternative, again if you are only driving an output port, might be to use an ODDR module. For outputting the original clock, send a 2'b10 to the ODDR module. For outputting the halved clock, send alternating 2'b00 and 2'b11 to it. Since the ODDR module has a fixed relationship to the pin, it guarantees a phase relationship on the output port. Now, regarding that half clock rate clock, do you need it within your FPGA? Or can you use the full rate clock and only operate on every other cycle as determined by a logical chip enable? Dan
  6. D@n

    Extremely exact clock frequency

    @dgottesm, A couple things to note. First, the PLL implementation in 7-series devices is a subset of what the MMCMs can do. You may wish to try switching to an MMCM instead of a PLL. Looking over the clocking specification, what you are asking for appears to be well within the limits of what is possible. May I suggest that if you want a PLL implementation, that you instantiate it yourself apart from the wizard? That'll allow you to set the CLKFBOUT_MULT_F (multiplication) value so that the intermediate frequency is between 800MHz and 1600MHz, and then the CLKOUT_DIVIDE value to be something near where you want. I've personally only ever directly instantiated the PLL's, and they aren't hard to do at all. (Not like the iCE40 PLLs--those are next to impossible to get right.) Dan
  7. D@n

    Extremely exact clock frequency

    @dgottesm, Why not just run the clock directly into a global buffer, and then use a OBUF to output the half rate clock? You can use the full rate clock within your design, and create the second clock logically on an output. As an off-hand guess, I doubt the frequencies involved are so high and the phase tolerances so tight that you actually need the PLL. Dan
  8. D@n

    Using FFT to analyze a sine wave

    @bhav, I recently put a demonstration project together for just this purpose on my github page. You can find it here. Although it's entirely a simulated project, you should find some useful pieces within it. Key details include: 1Msps A/D, based upon Digilent's PMod MIC3--a MEM's based PMod. Of course, since this is entirely a simulated project, no PMod MIC3 is actually required. The project just demonstrates how Verilog code can interact with the A/D in a simulated fashion. In this case, there's a MICNCO C++ file that simulates the Pmod. 1ksps complex FFT. (My core generator doesn't yet build real FFT's) DMA data write to memory. This is all based upon a wishbone bus--much simpler to work with than AXI. Video read from memory onto a simulated VGA 800x600 screen. (GTK based) The pixel clock is a 40MHz clock, the system bus/memory clock runs at 100MHz. The video slides from the right to the left as new data comes in. Feel free to take a look, and then ask yourself how you would go about simulating your task in order to know that your code works in the first place. Dan
  9. @train04, All of the pictures you've given are consistent with a sampled sine wave. I'm still not getting what the problem is. The first thing I'm noticing from your discussion above is that it seems like you are jumping directly to an end-to-end test without first going through a series of separate component tests. Have you broken the problem down into verifiable pieces? If so, which pieces have you tested that you now have confidence in? Perhaps this might help you understand what is going on: Whenever I build a data acquisition system like this one, one of my first tests is to create a test mode which replaces the input data stream (your sine wave) with a counter. I would patch the counter in between the A/D and the CPU, using all of the XADC's interface pins but only replacing the output with a counter that increments on every new sample. Since filtering would destroy the counter, I'd also bypass any filters--just not any downsamplers. That allows me to quickly see if any data is dropped or repeated. Only once the counter properly passes through my system do I return the data stream to the actual measured A/D input I want. Can you tell if any data is getting dropped or repeated in your test setup? That's test one. Test two: You said you were sampling the data at 1Msps. Tell me, are you receiving data at 1Msps? This is usually a really easy test to do: Create two counters. One counts from 0 to your system clock rate in Hz (minus one), the other counts data samples. Make sure both counters clear at the same time, and record the number of data samples counted before clearing. This second test is an important one because many students don't necessarily understand how to properly create and manage pipeline logic control systems, and a 1Msps data acquisition system depends upon such pipeline control systems. See if those help, Dan
  10. @train04, All of the charts you've shown above could easily be created under the appropriate circumstances. Not knowing the conditions of your test, or what sort of response you were expecting, it'd be hard for me to comment. Can you tell me what you were expecting to see and how/why the result you do see looks different from what you were expecting? Dan
  11. D@n

    Beginner DSP Projects

    @ho0pla, You should thank @zygot for such sensible advice: build it in Matlab or Octave, get it working, then port to hardware. Let me add another step in the middle, though, that I'm sure @zygot would agree with: Octave, then simulation, then hardware. After that, the sky's the limit! Well, you might want to study a particular application of interest as well. DSP is such a varied field, and so many things from so many fields are called DSP that ... well, it's hard for me to pontificate from here. Still, if you are interested in some examples, feel free to read some of ZipCPU's DSP articles on line. (The ZipCPU is the name of a CPU/processor I've built, and now blog about under the name ZipCPU.) They tend to hit on many topics surrounding DSP theory and implementation. Indeed, I recently posted a rather cool simulation demo of a spectrogram to github. There's a nice screenshot avaialble there too in order to give you an idea of how far you might get with simulation. Perhaps these ideas might stir up in your mind a project you'd like to try? Dan
  12. D@n

    xadc and fft output in vivado through ILA core

    @farhanazneen, You need to start with simulation. Just to drive my point home, you can find an example design that runs entirely from a Verilator based simulation here. That includes interacting with an A/D (sorry, not the XADC), lowpass filtering and resampling the result, taking an FFT, and the plotting the results on a scrolling spectrogram. You can see the design outline below. Here's a screenshot of the output you might expect: (the A/D simulator is producing a ramp in frequency) It's all quite doable, but you do have to be willing to do the work. In this case, you would need to build not only the driver for the XADC, but also a simulation component to match that driver to know that you've done it right. In my example, I also have both an ADC controller (pmic/pmic.v) and a simulation component to match it. You would also likely want to adjust the processing flow to your own needs. Dan
  13. D@n

    Systematic approach for Verilog implementation

    @tnet, Let me try to add to what @xc6lx45 just said. I've seen several design processes. The typical student design process is This ends up quite confusing for the student. What @xc6lx45 is recommending would look more like, I've argued in the past that this approach only makes sense if you have a means of properly viewing what's going on within the FPGA. If you have no way of viewing the logic within an FPGA, then I'll argue that should be your first task. You can read about the problem that results when you don't have that ability here. This process, however, will not work for ASIC flows. (FPGA flows typically teach students the design methods that they'll get paid more for when working for ASIC companies ... ) In an ASIC flow, the design *must* work right the first time (if you want to keep your job). There's a *HEAVY* dependence on simulation and so forth. Broken designs aren't allowed by the boss to go to the next step. My own design process has morphed a bit since I first wrote the article on this topic. I've now picked up formal methods as a means of building designs, using the free and open source tool yosys with SymbiYosys as the driver. With every new bug I find using them, I get hooked all the more. As a result, my new development approach for something like this would be: Scribble out some code Add a property package, like the one for the wishbone bus. (I also have packages for Avalon and AXI available for sale, at least until I blog about them and then they will be public) Add some other ad-hoc assertions (or assumptions about inputs) based upon my own estimation of my code Apply the formal tools View the VCD waveform in gtkwave. Compare it to the trace I'm trying to match. Create a cover property once the tools stop producing failing traces. Lather rinse repeat until the code matches Create a simulation component for the hardware I am attempting to interact with Create a design including this component, and test via simulation At this point ... the yellow figure above now applies again. You can read my ramblings on how this works here if you'd like. Hopefully that helps, if not then I've just rambled on for longer than @xc6lx45! Dan
  14. D@n

    Verilog Question

    @tnet, You count up to five with the output negative, and then five more with the output positive. The result is that it takes 10 cycles to return to the original state. That said, the exercise has a serious problem with it: you don't want to use any clocks that have been generated in this manner within a @(posedge clk) or @(negedge clk) structure. While what you have will toggle like a clock, it won't work like a true hardware clock due to the nature of the FPGA circuitry and tools that you are working with. A better technique is to use what I like to call a clock strobe, with a circuit more like: initial counter = 0; always @(posedge i_clk) if (counter == 9) begin counter <= 0; stb <= 1'b1; end else begin counter <= counter + 1; stb <= 1'b0; end Rather than toggling on the outgoing counter, following circuitry can then toggle based upon the (stb) value. For more information, feel free to read this article--it also discusses doing this using fractional timing as well. Dan
  15. D@n

    xadc and fft output in vivado through ILA core

    @farhanazneen, Is it possible to do (fill in the blank)? Read here. Do you have to simulate? Good question. It was recently debated on reddit, see the link here. My own answer is that, No, you don't need to simulate your design, but from my own experience I tend to go about 10x faster through the design process if I do. (and another 10x faster through the process if I can formally verify my design ...) As for directly viewing XADC and FFT signals in ILA and exporting the result to MATLAB, I've never used that approach so I can't really comment on it. (I've never even used Xilinx's ILA, nor have I ever used their simulator.) You can read a discussion of how I move simulated data to Octave here. That particular discussion helps to illustrate at least one of the problems of working directly from a trace. Dan