D@n

Members
  • Content count

    1670
  • Joined

  • Last visited

  • Days Won

    123

Everything posted by D@n

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

    xadc and fft output in vivado through ILA core

    Why use ILA? Why not start instead with a proper simulator? I'm personally rather partial to Verilator, although I know others who use iverilog (for Verilog simulation), or ghdl (for VHDL simulation). Vivado also has a simulation tool internal to it. I'd recommend creating a simulated A/D input, running your entire design through the simulator, and then making sure you have the right outputs from the simulator before moving to the next step. Incidentally, you'll need an open source A/D simulator. You can find an example of one in this project. You may also need an open source FFT. You can find an open source pipelined FFT generator in this project. It's even got a recent addition of a window function processor at the front end. Dan
  17. D@n

    XADC and the FFT

    I think you are asking a different question from the OP. Let's follow your thread from your other post therefore. Perhaps the kind Digilent staff will move that post to the FPGA forum for us where it properly belongs? Dan
  18. D@n

    FFT without using Processor

    @addyD, Let's see ... 1ksps / 50Hz = 20 samples per cycle. 8 cycles would then be 20*8 = 160 samples per FFT. Are you really sure that's what you want? FFT's work naturally at 2^N samples. In order to get 160 samples, you'll need to stuff the FFT with zeros. While this is doable, it's harder than to just fill the rest of your FFT with raw samples. As for the window function, ... let's discuss that for a moment. The FFT window function is a lowpass filter. It needs to be by design, and all of the common window functions meet this criteria. You want it to have a cutoff of roughly 2 frequency bins (i.e. a frequency response from -1/N to 1/N). If you do that, then you will only ever need 50% overlap between your FFT's to avoid losing information. Anything more than that is doing more work than you need to do. The information you would get from 75% overlap could also be gained by just interpolating the FFT's outputs. Now, back to your question. You have a working A/D. Good start! ... how do you "know" it's working? Do you have a simulation for your A/D? Have you managed to measure the samples from your A/D over an extended period of time? Or can you only "see" the results of your A/D with a scope of some type? Where you need to go next will depend upon your answers to these questions. When building digital logic, I always recommend starting with a simulation, debugging your design in simulation, then and only then placing it onto your hardware. Incidentally, you can find an example A/D simulator here that you might find valuable (or not). If you don't already have a means of doing so, you'll need a means of reading from that A/D. I prefer a means I can use both within my simulation environment as well as within the actual hardware environment. I discussed building something like that here, but your own needs may vary. Not sure if you can simulate the Xilinx LogicCore IP or not. You should be able to simulate an FFT from this repository using Verilator (I've done it). There's also code to accomplish a window function within the repo, although you'll need to create the appropriate coefficients (hex file) describing that window function yourself. The biggest problem with that FFT right now is that it'd be overkill: it only performs a complex FFT at this time, and most A/D's create real samples. Still, it'd work ... it just might be more than you need and the simulator won't (really) care if it's overkill or not. You'll also need some means of getting the data out of your FFT and to somewhere you can examine it. I discuss reading from an FFT using a Wishbone bus here, but you'll still need some sort of debugging bus to get you into the FPGA where you can read and write the Wishbone bus. Hopefully this'll get you started, Dan
  19. @Nikhil Singh, Have you seen this article? Dan
  20. D@n

    Artix-A7 (CMOD-A7) System Clock Question

    No, sorry, those are specific to the Spartan 6 used in the CMod S6. If you want to use this type of primitive within your Verilog code, the series 7 versions are MMCME2_BASE or PLLE2_BASE. (There are also advanced versions of each.) You can find these two hardware elements defined in summary in the 7-series libraries guide, and in detail within the 7-series FPGA clocking resources user guide. Should you choose to use the wizard, the code generated will just simply configure one of these elements. Personally, I find it easier to just include the elements within my code to properly configure the clocks. The problem with that approach is that it isn't as friendly for beginners, despite being more powerful for the user of the elements. Dan
  21. D@n

    Artix-A7 (CMOD-A7) System Clock Question

    @tnet, I have to deal with this often, although not with ModelSim. I do most (all?) of my simulation using Verilator. Verilator works using open source IP, and does not simulate Xilinx hard cores--like the result of the clocking wizard. Here's how I handle it. First, anything that I can simulate, I place into a main module. "main" and everything that cannot be simulated goes into a "toplevel" design module. You can see an example of this in my CMod S6 project. Inside the toplevel.v file there's a reference to a digital clock management component, as well as the main simulatable core I called busmaster. Within busmaster (i.e. the "main" simulatable file), everything is pure verilog. That pure verilog incidentally knows nothing about the 8MHz clock input, but only the 80 MHz system clock. Incidentally, the fact that I kept building projects to the same form was one of the motivations behind building AutoFPGA. You can read about that project here. Hope that helps, Dan
  22. D@n

    Generate if - For construct.

    @Sandeep I, Try reversing the if and the for. See this article for a description of the realities of generate statements. The statements you are creating while using them are not like software if and for statements, Dan
  23. Looking for an open source flash controller you could use? You might wish to try this one. You can find it integrated into several open source ZipCPU projects, to include this one. That includes not only the flash controller, but also software to read an ELF file and program the flash with it. The cool thing about all of the above is that you can then run the whole thing through an open source similator. For example, here's a post showing the difference between using a DMA to copy instructions from flash to RAM, and running the same program from flash memory directly (with an I-cache mind you). Dan P.S. I'm hoping to blog about how to build an I-cache soon enough, so that might be a next blog article on zipcpu.com
  24. D@n

    Hello! here to learn about Processor.

    @addyD, It's done all the time. Indeed, it's probably the "industry" solution to the problem you mentioned above. Here, try this article on filtering, see if it helps. If not, I'm betting some of the links will. It's from the middle of a long series on the topic. Dan
  25. D@n

    Victor

    @Victor McKeighan Welcome to the forums! I've always programmed my own CMod S6 using the Digilent Adept utilities. If you look at my own Spartan S6 project, you can find the scripts I use for this purpose in the master make file. One make target, "xload" loads the Xilinx configuration for my project into the chip (not necessarily the ROM). Alternatively, if you are interested in programming the flash, there's another design program there that I run using "make axload". This loads a configuration onto the device, one with full read/erase/program to the flash, that I can then program using the zipload program found in the sw/host directory. I'm sure the Digilent staff will join this conversation shortly and tell you how to use their tools, but consider this .... the ones cited above are open source (except for Digilent's Adept). Dan