D@n

Members
  • Content count

    1,387
  • Joined

  • Last visited

  • Days Won

    108

Everything posted by D@n

  1. FPGA based PWM generation

    FPGA's can do some really neat things when it comes to PWM generation that micro-controllers can't do. Specifically, because they can operate at such high speeds, they can toggle the analog output line in unique fashions, and at *much* higher frequencies, than most PWM controllers. This blog article describes a simple "no-cost" change to creating better quality PWM. By "no cost" I mean that for certain interval lengths, this audio controller requires no additional flip flops, LUTs, multiplies, etc. I'm sharing it here because I've used it with the PMod AMP2 with great success. Dan
  2. FPGA based PWM generation

    Feel free to read my own test report here. It has been written based upon quantitative simulation results, and only qualitative hardware results. Dan
  3. FPGA based PWM generation

    @zygot, All right, I'll ask: You seem to think that the code I've presented will not work because of how I've handled the conversion from two's complement to binary offset. Let's accept this as a hypothesis that needs to be tested. What result would you expect from code that has this problem? Would the audio be of poorer quality as a result? Would you expect distortions within the audio? If so, what distortion would you expect? Or alternatively do you think this difference will only create a confusion in the mind of whoever attempts to maintain the code later? Dan
  4. @WaveRep, Yes and no. The PModMIC3 will allow you to sample an audio waveform. Think of this as reading the deflection that sound will make upon a membrane (this might be literally how the MIC3 works). A single membrane deflection often doesn't mean much, so you will need to measure many such deflections to capture an audio waveform. The PModMIC3 can be used to do this. Calculating frequency, though, is not such a simple task. Your first difficulty will be the fact that most sound components are composed of energy at *many* frequencies. Perhaps an example might help this discussion. Below is a spectrogram from a discussion preceding one of my favorite songs. Zero frequency is at the bottom, and frequency goes up from there to the top. Time as well goes from left to right. Energy, as in the amount of energy in the signal comes out of the page with black being the least energy and white being the most. This image shows you, spectrally, what you might get from the PModMIC3: lots of frequencies at various volumes superimposed on top of each other. Some applications, though, require frequency estimation--such as you are requesting. For music applications this often means 1) generating a chart like this one vertical slice at a time. This usually involves collecting samples together, windowing them, taking a Fourier transform, and squaring the complex valued result (see periodogram). 2) Picking the strongest component somehow. There are lots of ways to do this. Perhaps my favorite is to take an inverse Fourier transform of the result of the last step and to look for a maximum--the location of this maximum will be the period of the fundamental frequency that you are looking for. 3) Applying some form of frequency super-resolution method focused on this frequency alone to find the "frequency" of the dominant component in the chart. While not strictly required, every application I've seen has done this. There are many methods for achieving such superresolution. One is to interpolate the peak location from the last step to get subsample resolution. Another method is to take two Fourier transforms, separated by a short distance, and to look for a changing phase within the frequency bin of interest. (See frequency detector) If you haven't guessed, there are whole fields of study designed for this task. By "sound in db", I'm going to assume that you are looking for an absolute measure of the volume of sound received rather than decibels as a relative measure. Again, the PMod MIC3 can be used for this purpose, but you need to start with sampled audio as before. In this case, if you aren't interested in the strength of each individual tone, you might consider squaring the output of the PModMIC3 and averaging the result. You'll then need to take a logarithm of this result. For this purpose, that can usually be as simple as finding the highest bit set, and running a table lookup on the bits following. In other words, doing what you want is a touch more involved--however, the PModMIC3 can be a valuable component of your solution. Dan
  5. FPGA based PWM generation

    @zygot, I posted the wikipedia reference because it provides a more complete discussion of the matter than is appropriate for this forum. If you choose not to read it, then I see no purpose in continuing the discussion of it here. If you do choose to read it, you'll find the table you are looking for posted there. Dan
  6. Differential PMOD Challenge

    (Yes, I got my forum threads crossed ...) As for the differential PMOD challenge, I think I bit off more than is necessary to accomplish the problem, so I might need to scale back the requirements of my design. I had designed an entire packet framing scheme (8*256 bits per frame), feed through scrambler, synchronization pattern, forward error correction (247,255), CRC checking, and more and ... all the extra stuff is creating more work than I perhaps need to do. Of course, this is all taking place slowly, as I have opportunity between other projects. Dan
  7. Differential PMOD Challenge

    Sorry ... didn't pay attention to the forum title. The above comments should've gone into the PWM forum. Dan
  8. Differential PMOD Challenge

    As an example of what I'm looking at, here's what I'm currently getting for a PWM spectrogram output. The "correct" answer is a single line coming from the top left corner diagonally down to the bottom right. The multitude of lines indicates a distortion being produced by the traditional PWM output. The first (top) of these is the correct one. Towards the far right of the screen, this correct line crosses with an alias line which you would expect given that I'm sampling a tone at 32kHz with no anti-aliasing filter to protect it. (The simulator has such a filter with a cutoff at about 22kHz, supporting a 44.1kHz resampling effect). I'm a little concerned that I might have a bug in this demo output--since I wasn't expecting any harmonics at low frequencies, so I'm still working hard to dot my I's and cross my T's before posting "official" results. Dan
  9. Differential PMOD Challenge

    Oh it's coming along quite nicely. The design is written. Simulation testing has completed several times. I have Octave code which will create a nice and pretty spectrogram output. The differences are pretty stark. I'm now implementing the example design on a Nexys Video board. It doesn't need to be a Nexys Video, but that's the one that's on my desk right now. If you don't want to run the simulation, that will at least allow you "listen" to the difference and decide for yourself which you like better. I did make one change to the output list: I'm going to mirror the switch input to an LED, just to give you some confidence that you've selected the result you think you've selected--so that you know which of the two you are listening to. Dan
  10. FPGA based PWM generation

    @zygot, Ahm, no. Sorry. Without a contractual business relationship and $$ involved, I acknowledge no "requirements" to do anything. Should I wish to answer any questions, it will be from the kindness of my heart. I also reserve the option and right to ignore questions, or to take my sweet time in answering them. Dan
  11. FPGA based PWM generation

    @zygot, Never heard the term "truth" applied to a signal before? Sorry, I guess I just assumed you'd know it. A "truth" input is nothing more than a completely known input. I learned the term while testing big ($B+) systems. It is different from, for example, a microphone audio input in that the "truth" input is completely known whereas a microphone input may pick up things which are not intended to be part of the test. Indeed, this is one of the problems with the doorbell signal, and why I am moving away from it as an example. The doorbell signal has some cackles in it that can lead to test uncertainty--were they caused by the test or not? Using a "truth" signal (i.e. because you know everything about the input signal), you can measure the differences between the output produced by your hardware and the output it "should" have produced. My guess is you already know all of this, though, and just haven't heard the term. Dan
  12. FPGA based PWM generation

    Here's my proposal: Suppose I present a simple design that can be used for comparing the two methods side by side. The inputs to this design shall be 1) a 100 MHz clock (since it's what I have on my current hardware), and 2) a single switch input. The design will output 1) the single bit for the PMod AMP2 component, 2) a gain setting (on), and 3) the shutdown value--these latter three pins being the inputs to the PModAMP2. The test will consist of 1) a two second tone, followed by a 2) three second frequency sweep. Silence will surround these two test cases. To illustrate how aliasing can affect this test, I'll set the audio sample rate to 32kHz--although other rates will be instructive as well. I currently have the tone set for a 440Hz tone, followed by a sweep from 110Hz to above 20kHz. If you can think of a better test, please speak up and explain what would constitute a better test and why. For those without a PModAMP2 on their desks who are also interested in this test, the design will permit simulation via Verilator. The simulation result will be a sampled audio signal file at 44.1kHz of double precision values which can then be examined via your favorite tools. Mine is Octave, yours may be Matlab or ... whatever. An Octave script will be provided. If you think this would make for a valid and sufficiently revealing test case, then let me know and I'll move forward with this approach. Dan
  13. motor controller with BASYS3 and UART

    @fpgauser, I'll offer what help I can: UART is inappropriate for controlling a rotor's rotation on a rotation by rotation basis. It might work well for controlling a controller, but not for communicating the control signals to the rotor. So, for example, I would have no problem with connecting a joystick to a computer and sending its values via UART to a rotor controller. Some time ago, I wrote about how an FPGA could be controlled via a UART port through software. You can read about the hardware interface here, and a discussion of the software interface here. You might find this approach valuable, even though all of the examples are in Verilog. Controlling a real-time device, such as a rotor, which requires inputs and outputs faster than a UART can manage them, creates another problem: how do you discover what's going wrong within your design? For this reason, I discussed how to place a scope within a design. Such a scope can record a certain amount of values, rarely enough, but at high speed. This can then be used to find and recover from any problems you might have. If this doesn't help (and I sort of doubt it will), then can you please be more specific about the problem you are having and what help you would like? Dan
  14. FPGA based PWM generation

    So, I took a look at the VHDL testbench posted earlier in this thread. Sadly, despite the fact that the test bench invokes the wbpwmaudio.v component, in the end it is irrelevant to the question at hand. Here's why: the argument being made is that of a proposed new method of handling single bit modulation, and that this method produces better sound quality. The form of such an argument therefore demands both signals: the before (PWM) signal and an after (PDM) signal which can then be compared to a truth signal. The "truth" signal itself need be nothing more than something that can clearly distinguish the difference between the two. Neither the test bench above, nor the scilab script, accomplish this test. The original article presented such a test, showing both a tone and how that tone would be interpreted under each scheme. A Fourier transform of this tone was also presented. Applying tone signals as inputs, and reviewing Fourier transforms, is a common means of evaluating audio quality, since the output of the Fourier transform *should* be a tone (single bin) and not a tone plus other stuff. In the example provided, the PWM output produced a tone plus distortions (other "stuff") while the PDM output was closer to pure. This was then an indication that the modified PWM (really a PDM) signal produced a higher quality result than the PWM result. A test bench that demonstrates the difference is required in this case, not one that just toggles wires and generates a trace. While test benches that produce pleasant traces can have value, they are fundamentally irrelevant to the discussion at hand. Instead, inputs to the test bench need to be chosen so that they can easily be compared (after processing) to known or expected results. The processing result from the test bench then needs to be lowpass filtered and resampled at an appropriate audio frequency rate. The two resulting signals then need to be compared to the desired signal. This is the form required of the comparison, and therefore the form required of the discussion. Verilator supports test benches which can be this complex. While I would love to believe that there is a similar VHDL option, I don't know of one. Without a suitable test bench, the only remaining testing possibility is to test upon actual hardware--in a situation where it is more difficult to definitively measure audio quality. Dan
  15. FPGA based PWM generation

    Actually, @Natsu is correct. I only just got home yesterday and I'm still working through the jet-lag. The posts that I've made while I have been gone have been mostly in response to simple requests that needed little work or thought. As for why I have not responded on this thread, yet, I am a firm believer that everyone should be "swift to hear, slow to speak, slow to wrath". Even with that as a background, many of the issues presented really don't merit a response. For example, "issue one" is about the inappropriateness of sending a digital signal into an analog input, whereas "issue two" is about the signal not being digital at all by the time it reaches the PMod port--which is expecting an analog input. You'd think these criticisms would cancel each other and I would encourage anyone struggling with this idea to think through it. Indeed, the PWM article stated as much when it declared that one of the purposes of a PWM signal was "as a poor man's low-frequency digital to analog converter." Another example would be the discussion regarding converting a two's complement number to an unsigned binary offset value. I never expected that this would be difficult to understand at all. Basically, if you have an N-bit signal centered at zero, but ranging from -2^(N-1) to 2^(N-1)-1, and you want to convert this into a signal centered around 2^(N-1) and ranging from 0 to 2^(N)-1 then it only makes sense that you would need to add 2^(N-1) to your signal to do so. With an N-bit register, this is equivalent to toggling the MSB (the sign bit of a two's complement number) and then treating the result as an unsigned value. If this confuses you, perhaps you should read the wikipedia articles describing the difference between two's complement and offset binary representations. I might also refer anyone struggling with the comment about something being "spread uniformly" to the wikipedia article on random variables, and then specifically on uniformly distributed random variables. It's a fun topic, and I would thoroughly commend the study of probability and statistics to anyone interested in it. My original understanding of the criticism presented here was that a test bench would be useful. For this reason I had provided a link to how this code was used within the article, to include referencing the doorbell sound that I had been using (it's in the repository). My actual test bench code, however, remains proprietary. If it is something that would be valuable to others, then I might be able to spend the time to strip the proprietary methods from it and post what remains. As a result, posting the test bench requested is not something that can be done quickly or with haste--inflammatory comments aside. I'm not, however, going to respond to inflammatory comments such as "if you want to present yourself as an authority ...", nor "I have a lot more experience ...". These comments are off topic, and serve no purpose in a discussion regarding whether or not a particular PDM method is an improvement upon PWM in general. I'm also not convinced that this discussion is offering anything valuable at this point, and do not anticipate responding to any more inflammatory inquiries. Thank you, @Natsu, for your kindness and understanding while I was out. Dan
  16. motor controller with BASYS3 and UART

    @fpgauser, I'm not sure I understand your question. I may need you to explain it some more. From what I understand, you are reading the motor's speed within your FPGA, sending that value over UART to a PC/host, and then trying to adjust the motor's current as a result. And .... you are struggling with the fact that UART communications have a delay associated with them, with the delay between when they are sent and when you read them, or some such? (I trust you've put the terminal into raw mode, instead of cooked, so that it isn't waiting on line feeds ... right?) I guess my first thought would be .... why use the UART at all? One of the reasons for using an FPGA in the first place is that you can control the timing between events, and even better that you can guarantee a particular response time or times. Computers, whether on the FPGA or connected to the FPGA, don't usually have predictable response times. Dan P.S. Looks like I may be doing a brushless DC motor problem of my own later this year. The hardware is now on my desk already, although I don't have the schematics for it yet. I'm just saying this because I'm curious about anything you might wish to share.
  17. New member, greeting from Wyoming

    @wallkerrmartin, Welcome to the forums! If you don't find something you are looking for, please ask. There's lots of friendly people here, Dan
  18. UART and XADC

    @cristian_zanetti, Why not send six bits at a time, and use the top two bits to specify which of the six bits you are sending? { 2'b00, 6'b(highbits) } or {2'b01, 6'b(lowbits)} ? Then any time you receive 2'b01 in the high bits, you can join it to the previous 2'b00 high bit value. Dan
  19. @boyerkg, The MIG does require a REFCLK which must be at 200MHz. This is separate and distinct from the clock you give it, or the clock you get back. I don't think there's a phase requirement between the REFCLK and the input clock, but you might wish to check me on that. Have you looked at the code where I did this for the Arty? The Arty is really close to the Nexys Video, save that the Nexys Video runs at a higher speed, has (IIRC?) a bigger memory, and no CS pin. Still, there's a migsdram.v component, a wb2axisp wishbone to AXI slave(pipelined) component, and the top level component containing the clocking infrastructure. The Arty code, though, runs the memory at 82MHz, whereas on the Nexys Video you should be able to run it at 100MHz. (Remember the clock frequency that had to be between 330 and 400MHz? That's the actual memory frequency. The user frequency will be 1/4 of that rate.) Dan
  20. @boyerkg, On the 330-400MH clock request, set it to 400. On the input clock frequency, you can give it either 100 or 200. Then use the output for your file. Try comparing the .prj file the MIG generates and places into your projname.srcs/sources_1/(component_name)/mig_a.prj with the one I've attached. Perhaps you can see a difference, Dan mig_b.prj
  21. @boyerkg, So ... I have the MIG core up and running with a Verilog interface. Is this what you are trying to do? I'm attaching the UCF file that you can use to set up the core. You should be able to find the parameters necessary to configure the core from reading the board-support XML files. The big thing I see different form your description above is the comment about the MIG memory running with a 200MHz clock. That is the input clock rate to the core. You can give it the 100MHz clock directly from the board if you'd like. The MIG will adjust the input clock 'til it's something useful for it. The actual clock that you are going to need to use to interface with the memory is a 100MHz clock. You'll pass the memory requests, and receive responses, all on a 100MHz clock. Hopefully this helps, Dan migmem.ucf
  22. @cnun999, Well, if you can't share your code, then there's not much I can do to fix it. Sorry. You might find it valuable though to take pieces out of it, and see if that helps you narrow down the problem--but I'm repeating myself to say this at this point. You might also considering entering into a contract arrangement with a more experienced designer, working some non-disclosure agreements through the legal team, and trying again. I'd offer my services to that end but ... I don't use system designer much. So, again, I'm sorry I can't be of much more help. Dan
  23. arty not auto-loading from flash. must push "PROG"

    @stewart, Do you still have the jumper over JP1? Dan
  24. @cnun999, Looks like you posted on the Xilinx forum as well. No response, huh? Sadly, you haven't provided enough information for anyone to solve your problem. You've offered no code, and haven't found any offending line. The fact that it's running for 36 hours means there's a problem, but you might need to break the problem down before help will make sense. Normally, I'd tell any Verilog designers to run their design through Verilator with the "-Wall" option. This is fast, and finds most of my errors. However, you appear to be using system generator so Verilator is not likely to be an appropriate option. So, let's start at the top: What chip and/or board are you using? Can you post your code? Can you remove one item (or more) from your code and get it to build successfully? That can often help find the one item (or more) that's the problem. We can then focus on that one item. Not sure if I'll be able to help, but ... this should be a good start. Dan
  25. Using CMOD-a7's FTDI usb-uart

    @sfd, I use the bench testing designs found here. The hello world example would be worthwhile to start from. The most common UART problems are: Getting the TX and RX pins mixed up. Within a schematic, both one of these pins will connect to two parts. It's often not clear *which* part is TX and which is RX. Getting the baud rate right. Sometimes, you can see corrupt characters in your terminal if this is the problem. (Sometimes) Check the baud rate on both ends, and double check the clock rate on the CMod A7. You can do a really quick/dirty test of clock rates using the LED (see here), just to confirm that the clock rate isn't the problem. I've had troubles with the really fast clock rates before, so you might want to try something more reasonable--such as 115,200--and then make the transition to high speed (assuming you want high speed) Another *really* common problem is hardware flow control. Make sure you have it turned off for your first UART design--once you have that working, and you understand hardware flow control, then feel free to turn it back on again. The USB cable doesn't support data due to a broken wire (this is more commonly a configuration problem than a UART problem) Less common problems include not looking at the right UART port, or not having the right UART port in the first place due to an install issue. Dan