Sign in to follow this  
D@n

FPGA based PWM generation

Recommended Posts

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

Share this post


Link to post
Share on other sites

@D@n,

I don't understand the question. More precisely, I can't find a question to your thread

On 9/4/2017 at 9:45 AM, D@n said:

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.

What do you mean by "unique fashions" ? If you want to put forth the idea that an FPGA can create custom PWM waveforms and control over how that waveform is produced that a particular micro-controller doesn't support I'd agree. As you application for your IP is for audio use I don't see the connection to "much higher frequencies. I glanced through the blog that you are advertising here and it seems that your idea of a better PWM is to not use a PWM. ( that's how I read your word.. ). Gee it'd be swell if viewers could post comments to your blog...

When I finish off a couple of projects I want to revisit this. For now I'll say that modern DSP/micro-controllers directed toward the motor control market offer pretty sophisticated PWM controllers with better precision than you can do in an FPGA and offer a heck of a lot more functionality at lower power, simpler power supply design and lower cost. Check out the ATMS320F2837XX Delfino family from Texas Instruments. Of course there are times when your FPGA design might want to implement a PWM type function, I've done this, but I don't buy the sales pitch.

Share this post


Link to post
Share on other sites

@zygot,

Sales pitch?  "Sales" pitch?  That doesn't make any sense.  Visiting and reading the blog is free.  I'm not asking for a site registration.  I'm not charging your credit card.  There are no loud and flashy advertisements.  You don't need to sign in to read the content.  There's no *sale* taking place here.

For the record, I'm not making any money off of whether or not someone visits the blog.  If anything I am losing money.  There are no advertisements on the blog.  If you like it, bonus.  If not, then do what the rest of the world does and find something you do like to occupy your time.

Dan

Share this post


Link to post
Share on other sites

The term "sales pitch" can be used generically. Not everything being sold involves an exchange of money. Nothing is free. You do ask for contributions to fund your blog however. But I'm not referring to that. I was just referring to your basic propositions. But I'll double down on using the term. When you pose an advertisement to your blog as a user question then you are selling something; and not in a straight forward way.

When I have the time I intend to address your blog PWM "educational" material. For now I'll just suggest that you use the forums meant for questions to ask questions. Submit a project if you want to demonstrate an idea. Mostly, pontificate on what you know instead of what you don't know very well. You certainly know a lot that would be helpful to a wide audience. Blog about that; or at least blog about your learning experiences.

Share this post


Link to post
Share on other sites

In my opinion, because the original post is unsolicited it was posted here by mistake.

That is it. If somebody has opinion about implementation of PWM on FPGA it is appropriate to hear about it but in a professional manner.

Share this post


Link to post
Share on other sites

@Notarobot,

Honestly, I don't understand your post. I don't think that there was any mistake in the original post or the purpose for doing so.

9 minutes ago, Notarobot said:

If somebody has opinion about implementation of PWM on FPGA it is appropriate to hear about it but in a professional manner.

Please elaborate.

Share this post


Link to post
Share on other sites

In my opinion, professional manner means staying within the technical scope of the subject.

I didn't perceive D@n's post as a sales pitch but rather an unsolicited offer or suggestion. I think it was posted in this thread by mistake.

I've used TI DSP motor controllers and familiar with its PWM implementation. I think it is excellent but it is limited to 10Khz rate (may be 20KHz these days) which is not always sufficient; then FPGAs could be a viable option.

Unfortunately, the format of the forum leaves a lot for personal interpretation which sometimes results in misunderstanding. For example, I don't think D@n should explain all possible applications and benefits of it. The reader can figure it out when he finds this article.

I believe that in our best interest to support each other in a constructive way.

Share this post


Link to post
Share on other sites

I have created a new sub-forum for this style of post and moved this thread to that sub-Forum ("Tutorials", available in the "Learn" section in the "General Discussion" category).

If anybody ever sees a thread that they feel is in the incorrect location, please contact me directly about it as I am the one who is able to do something about it.

As always, if anybody has suggestions and feedback about the Forum structure (new subForums, etc), please share it in the conveniently named Suggestions & Feedback subForum.

Thanks,
JColvin

Share this post


Link to post
Share on other sites

@Notarobot

The elaboration is appreciated.

39 minutes ago, Notarobot said:

I believe that in our best interest to support each other in a constructive way.

I agree. Sometimes supporting each other in a constructive way means pointing out behaviour that demands a bit of negative criticism. No one like having their faux pas moments brought to their attention but in the end it can be corrective and constructive. Conversely, ignoring such behaviour is not support... just an absence of acknowledgement. 

I think that your idea notion of how fast many modern micro-controllers can operate their PWM units ( I tend to think of this in terms of resolution and span of minimum/maximum width ) is a bit dated. But I'm not arguing against the use of PWM components in an FPGA.

 

Share this post


Link to post
Share on other sites

@D@n

I've read through your blog. There's a lot that needs to be addressed. But let's start with the code. One thing that you don't provide is a testbench. It's hard to discuss HDL without a visual representation of what's going on. So I'll give you a testbench that I wrote and simulated in Vivado. The first thing that I need to to understand is how you used this code to provide your doorbell ring tone that you mention in your blog. Please provide this so that we have a specific example to discuss. I can't find code showing how you actually use your IP to run the PmodAMP2. This can get us started.

I use VHDL and have showed you how to instantiate a Verilog module in VHDL, in case you haven't done this before. I know that you prefer Verilog so you can either write your own testbench and I will translate it into VHDL, you can modify my testbench or you can just describe the input that drives your IP. Also, I'd be helpful when teaching beginners about stuff to provide basic information about how you connect the PmodAMP2 to your code so that they can actually recreate your example.

You may want to run the simulation anyway. I think that there are some loose ends to tie up.

regards

T_wbpwmaudio.vhd

Edited by zygot

Share this post


Link to post
Share on other sites

@D@n

I realize that you are off "across the pond" so there's no rush to reply.

When I do DSP development or FPGA designs implementing an algorithm I like to use OCTAVE or SCILAB to simulate the approach algorithmically. This provides an added way to confirm functional correctness of the algorithm implementation and helps understand details that might not be obvious during design. Since SCILAB is free and available to all readers I've provided a first cut of my version of a SCILAB script that demonstrates your PDM, "better PWM", algorithm. SCILAB and OCTAVE both work on Linux and Windows. 

Does this fairly represent your design so far? What I'd like to do is replicate the PWM plus sinewave and PDM plus sinewave plots that your blog presents. Could you supply the math that transforms your digital waveforms into analog waveforms?

 

pwmaudio.sci

Edited by zygot

Share this post


Link to post
Share on other sites

@D@n

In your blog you make this rather surprising statement: "First, notice the negation of bit fifteen–a 16-bit sample’s most significant bit. This is the two’s complement sign bit. Flipping the sign bit is the way to convert two’s complement values, ranging from -2^(N-1) to 2^(N-1)-1 to the offset binary values, ranging from 0 to 2^N-1 , that a PWM modulator needs."

- It is not my experience that a PWM modulator needs offset binary values

I contend that:

- unsigned binary numbers range from 0 to 2^N-1

- signed binary numbers range from -2^(N-1) to 2^(N-1)-1.
- two's complement, one's complement, offset binary and some others are all signed binary number representations.
- flipping the sign bit of a two's complement signed binary number gives you an offset binary signed binary number
- if you want to have an HDL module that uses binary numbers that range from 0 to 2^N-1 use unsigned binary representation because there is no sign bit.

One advantage of VHDL is that the language explicitly supports signed and unsigned values.

I've provided an old but still useful application note that meshes with my experience.

 

an9657.pdf

Edited by zygot

Share this post


Link to post
Share on other sites

Since Dan seems to want to avoid this discussion we can certainly proceed without his input. As I suggested earlier, if you want
to present yourself as an authority on a subject and provide guidance to those who are decidedly not then you should actually have the experience and knowledge to do the analysis of the topic at hand. Some people are better at judging their own competence in an area than others. When I read the material that the reader is directed to at the beginning of this thread there were quite a few  things that bothered me. Hence it became a little side project for me. I intend to work through these. Since I can't divine or  know what Dan was thinking or doing we'll be limited as to drawing conclusions. On one hand I might be accused of sending more people to a blog that I can't recommend but on the other hand perhaps anyone reading this will gain some information that spurs them to apply critical thinking skills when reading random blogs on any topic, but particularly technical ones.

I do hope that anyone with the technical experience to understand this thread will weigh in, as this is now properly in the Learning Forum.

Companies that care about whether or not their products perform to specification will subject their design engineers to peer reviews of their work product. This usually happens at the some point when the basic design gels into a cohesive and documented state. I happens again after most of the design work has completed and a new design is ready to move toward production. The purpose of a design review is to find errors, omissions, and potential issues that haven't been addressed properly. It is mostly to avoid finding mistakes before they become very costly to fix. It is also a way to develop the skills of the technical staff. I have been the subject of a lot of design reviews so this is second nature. I also know how difficult it is to catch all of my own mistakes when there isn't someone else around to verify my work. While all errors can be a big problem, the errors due to a lack of competency are the most worrisome; especially if people take your work product as a way to learn how to do things.  

So let's proceed with a few issues that immediately bothered me. The source material that I posted earlier will be for later.

Issue 1:

Dan claims that his "bit-reversed PWM" driver is a digital pulse density modulation signal. I am very skeptical about that. But issue 1 is that he uses his driver to operate the PmodAMP2. The SSM2237 device on the PmodAMP2 that constitutes the class D amplifier is a spread-spectrum sigma-delta modulator that does create a PDM to drive a speaker and takes in a single-ended analog signal. Analog Devices also sells the SSM2257 which is basically the same as the SSM2237 but with a PDM input, instead of an analog input. Perhaps if his driver were a PDM he could use to drive an SSM2257 device. But more importantly, since the driver is clearly a digital signal of some type, one has to know how to manipulate this signal to get the desired output from the amplifier. I didn't see any treatment of this point. I do suspect that Dan read the SSM2237 data sheet which gave him the idea for his tutorial.

Issue 2:

If you take the time to run the simulation you will see that the driver can put out pulses that are 1 80 MHz clock period (12.5 ns) wide. Digilent is very clear that the normal PMODS are good for signals that toggle at less than about 10 MHz ( 100 ns period ). So here is a problem. If you look at the schematic for the PmodAMP2 you might notice that the input signal goes through a series of resistors and capacitors. The design information about this circuit is not available but I contend the control signal that comes out of Dan's driver does not make it to the SSM2237 delta-sigma modulator intact.

Issue 3:

In his blog Dan writes: "From this figure, you can see that there are many more transitions in the bit-reversed PWM signal.
Another way of saying this is that the bit-reversed PWM signal has a lot more high frequency content.
This extra high frequency content should be easier to filter out with cheap analog circuitry, and hence
the remaining audio quality should be better."

I'd like to read his detailed defence of that argument.

Issue 3:

The driver design clearly is based on the incorrect assumption that the "sample" input is an unsigned value. It is not and requires further exploration as to what is actually going on.

That should be enough for today."

 

Edited by zygot

Share this post


Link to post
Share on other sites

Hey so no one has chimed in so far. I guess this means that either I haven't said something really stupid yet or no one has taken the time to run either the Vivado simulation or SCILAB simulation.

Today I present the next issue:

Issue 4:

Dan makes the following argument: "

The other thing you may notice is that the timer reload value isn’t connected to the PWM counter any more. Heresy! No, actually it makes a lot of sense. Because the output bit order is spread uniformly across the sample interval, chopping a value off before it’s had enough time to send all of its bits isn’t something the ear will notice."

I won' quibble about the ear part but I do have a problem with the part that I've underlined. The pwm counter is simply an arbitrarily (16-bit ) wide unsigned value that increments 0,1...32766, 32767, 0,1.... So it takes 32768 clocks to wrap around to zero and complete a bit sequence. The rate at which the sample_out signal is updated is 1814 clocks, or about 44.1KHz with an 80 MHz clock. Clearly the counter does not repeat a bit sequence every 1814 clock periods or 1 "sample" period. Moreover, as 32768/1814 is not an integer, the bit sequence for each sample period will rarely be the same or uniformly spread across the sample interval. I suggest that setting the o_pwm output signal high or low based on the value of the bit-reversed counter relative to the sample_out signal ( and it is not an unsigned value as I pointed out previously ) is not a PDM encoding useful information. Usually, when I think of modulation it involves encoding useful information onto a signal. Perhaps a signal jammer might be an exception.

Someone has probably asked themselves why my testbench doesn't use the ieee.numeric library and signed and unsigned signal types. It's a reasonable question but instead of answering it directly for now I'll give you a pop quiz. Pretend that you're attending the first class of a new course and the first thing that the professor does is give a pop quiz? It only has one question so either you start off the semester with an A+ or an F-.

Question. Which of the following choices represents the decimal value of X"8001" in VHDL or 16'h8001 in Verilog?

  1.     -32767
  2.     +32769
  3.     -32766
  4.     +1
  5.     +8.0078125
  6.     -0.0078125
  7.     all of the above

The correct response is probably to leave the class and head to the dean's office to get out of this class... but here's my answer.... it's 7.

  •     -32767 in signed twos-complement binary representation
  •     +32769 in unsigned binary representation
  •     -32766 in signed ones-complement binary representation
  •     +1 in signed offset binary representation (K=32768)
  •     +8.0078125 in unsigned iiiiiiii.ffffffff format
  •     -0.0078125 in signed siiiiiii.ffffffff format

NOTE: Clearly, a 16-bit unsigned counter wraps at 65535, not 32767 as I stated above. This was a typo that should have been spotted by anyone reading this. I'm disappointed to correct myself. As this thread is in a "learning" forum all posts to it should be challenged when assertions are incorrect or dubious. That's kind of the point of critical analysis. As I've posted updates to numerous project vault code ( my own code ) when I find an error I am certainly not exempt from scrutiny. The problem that got me to reply to Dan's post, which is not technical and not about simple errors, is a serious one needing conversation. So where are all of the experts? Zygot 09/11/17

 

 

 

Edited by zygot

Share this post


Link to post
Share on other sites

A useful exercise for using the PmodAMP2 is to read the data sheet. I present a few interesting specifications below.

  • Input Common-Mode Voltage Range is 1.0V to Vdd-1V
  • Clock Frequency is 6.2 MHz (typical)
  • Average Switching Frequency is 256 KHz (typical)

The device input is differential analog but can but can be used as a single-ended input; the PmodAMP2 uses a single-ended input. The topic of Sigma-Delta Modulator A/D conversion, as is used in the SSM2237 is very interesting and worthy of you time to track down a few good treatments.

Share this post


Link to post
Share on other sites

@D@n can and should clear up some troubling implications of my posts by providing simple information that he says that is already done. He needs to show how he created his plots so that they can be replicated. He needs to finish the blog tutorial by demonstrating how to create a particular tone using his IP and a PmodAMP2. Not doing so is an admission of hubris or worse. I'll be happy to be proven the fool here.

I have to mention that I have a lot more experience in a number of topics that Dan's blog expounds on and I don't feel qualified to lecture on any of them.

Share this post


Link to post
Share on other sites

Hello!

I don't know much about PWM or PDM, so maybe I've misinterpreted everything but I was under the impression that the blog post wasn't intended to be the ultimate solution for everything. I don't disagree that engineering should be replicated by other people to help ensure it all works rather than accepting stuff blindly, especially if it's vital for a projects success, but it looked like D@n was looking for better audio quality rather than launching rockets... 

On a different note, it looks like from his main blog page that D@n was at some conference these past few days so maybe he hasn't looked at this thread in the meantime? I'm just a little confused since it seems like you were aware of this in one of your posts with the "across the pond" statement but then proceeded to reply several more times with some apparent confusion as to why he hasn't responded. Then again, I'm neither D@n nor you nor a contributor for this Forum, so I'm probably just putting words in people's mouths. Sorry if I've offended anybody.

~Natsu

Share this post


Link to post
Share on other sites

@Natsu,

You comments are welcome and pertinent. What people intend to mean when they write and what people infer from what they read is often not the same.

I waited until D@n was back and making posts again before continuing my presentation. I believe that he has been reading the thread. 

I've presented multiple projects with code that certainly are not "intended to be the ultimate solution for everything". None of what I've presented is perfect or above critical technical evaluation. The technical aspects of my posts are a secondary concern. I am concerned about misleading people who want to learn and don't have the technical expertise in an area. No one is technically competent in all areas. I've provide the framework for anyone to analyse the code and claims and decide for themselves as to what's going on here. Only one person can speak for D@n and in my opinion his silence is a response. When someone who is well educated, technically competent and trained, hard working and generally helpful makes claims and presents ideas as an expert on a subject then I have high expectations.

Let me state this categorically; I am completely open to the idea that I am all wrong. That's the idea of having an open discussion. Absolute truth doesn't exist for mere mortals. Dishonestly or carelessness is a bit easier to define. It is not possible to know the intent of anyone's speech or actions. It is possible to analyse the technical merits of claims. 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
1 hour ago, D@n said:

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. 

Oh I've though this out and they do not "cancel each other out". Electronics and physical things or even logic, in general, don't work that way. I don't challenge the notion that you connected a PmodAMP2 to a board and heard a tone. I do challenge the notion that you (or I for that matter) understand what is actually going on. The SSM2237 will certainly try to use any "analog" signal that it sees at its inputs.... hearing a tone doesn't verify the design claims. I'm very skeptical that it has much to do with your limited technical explanation for how this is supposed to work. 

1 hour ago, D@n said:

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 don't get my math from Wikipedia. But you don't understand your own references. Binary offset is a signed number representation that still has a sign bit but is biased by some offset. The only time I've encountered offset binary is using A/D converters using it. Flipping a sign bit does not make it go away... just how you interpret the remaining bits. If you have a 16-bit signed number ranging from -32768 to +32767 flipping the sign bit does not give you an unsigned number ranging from 0 to 65535. (OK now I'm tempted to make a snide remark but will resist....) The following code is comparing a 16-bit unsigned value (br_counter) to a signed 16-bit value (sample_out).

    always @(posedge i_clk)
        o_pwm <= (sample_out >= br_counter);

 

I do have some understanding about the spectral nature of random variables. Your bit-reversed counter just doesn't provide random variables and most certainly not "uniformly distributed random variables".  Don't look this up in Wikipedia pick up a good textbook. Better yet Use Vivado to run my testbench. That's the main reason for my skepticism about your "novel" PDM claims. I think that you should learn how to use Vivado simulator as a "backup" to Verilator. Your Digilent audience certainly uses it. You might get some insight as to what your design is doing.

1 hour ago, D@n said:

My actual test bench code, however, remains proprietary.

Say what???? Your technical breakthrough,  in creating a PMD never seen in literature before is freely available and your testbench is proprietary?  Did you bother to run my testbench? Did you bother to run my SCILAB script? I provided these so that anyone can understand your claims for themselves.

1 hour ago, D@n said:

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.

What you prefer to infer as inflammatory to avoid discussing facts is perhaps the most important thing for you to defend, because it's about honesty. You can do this my helping everyone replicate your claims and addressing technical questions with something other than snide bluster. Feigning insult is not an argument. The only posturing on this thread so far has been your responses in my arguments. I've resisted any temptation to copy your behavior of ignoring a statement by tossing out a reference in a way that suggests ignorance on the part of the person making it (It's not my nature but like foul language when you are subjected to it often enough it can be tempting to respond in kind). It's a bad habit and you should consider doing something different.

So I'll ask again. Add the functions that create your "audio samples" to my SCILAB script to create, let's say a 540 hz tone at the output of the PmodAMP2. Add the function that changes your PWM and "PDM" plots into perfect sinewaves that you've displayed in your blog so that we can all understand and repeat your plots for ourselves. From most of your posts in which you extol open designs I'd have thought that this is something that you'd want to do. If your plots represent what they purport to it's already been done so there shouldn't be much effort for you. I've been willing to put effort into the discussion.

I do apologise if I mis-interpreted your recent posts as having caught up to the thread discussion. But we are caught up now so there are no excuses.

Challenging and defending extraordinary claims is what science and engineering is all about. Fraud happens all of the time. Honest mistakes happen even more frequently. Help me sort out what is what. Don't quote Wikipedia, defend your technical arguments and provide the information that makes your claims able to be replicated. That doesn't seem inflammatory to me.

 

Edited by zygot

Share this post


Link to post
Share on other sites

@D@n,

So correct me if I'm wrong.

  • You are claiming that by bit-reversing a counter you are creating random numbers
  • You are claiming that the sequence of the values coming from your bit-reversed counter over the relatively short 44.1KHz audio sample interval ( about 1/36th the counter wrap interval) are uniformly random values

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

@D@n

Wow. You're kind of an expert at avoiding facts by tossing out nonsensical gibberish.

  • About my testbench. If you don't like mine then present your own written in Verilog, The purpose of an HDL testbench is to test HDL not the transfer function of complex circuitry and RCL networks. Let's see how my testbench fails to simulate your code by comparing it to your testbench. Your code is wrong by the way as it compares a 16-bit signed value to an unsigned 16-bt value.
  • You keep referring to your plots in the blog as proof of something. My point is that as long as no one can replicate them they have no technical merit other to suggest the possibility of fraud.

I do acknowledge a problem that I have however. I don't have a PmodAMP2 so I can't actually test your "IP". One could so a spice simulation but Analog Devices doesn't offer a model for the SSM2237. Digilent doesn't have the PmodAMP2 in stock but I will try find one at a distributor. It's worth the money.

I did look at your S6SOC-master code. I found samples.c so I know what your demo is sending to your IP. I can simulate with my testbench. In this file there is this statement: "The generator file can  be found in trunk/sw/host/buildsamples.cpp". I was unable to find buildsamples.cpp anywhere in the archive. It would be nice if you provided that... but as you are reluctant to provide anything that can test your claims we will have to proceed with what we have.

39 minutes ago, D@n said:

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.

I really don't know how to respond to this silliness, other than to say that we can certainly use a testbench to verify the functionality of your verilog code. Your bizarre thinking that by trying to make evaluation of your claims too difficult that we need to trust words and pictures that can't be replicated is simply delusional.

I notice how you keep not answering my questions by avoiding them and redirecting the conversation. So about that "new method of handling single bit modulation": I repeat...

So correct me if I'm wrong.

  • You are claiming that by bit-reversing a counter you are creating random numbers
  • You are claiming that the sequence of the values coming from your bit-reversed counter over the relatively short 44.1KHz audio sample interval ( about 1/36th the counter wrap interval) are uniformly random values
19 hours ago, zygot said:

@D@n,

 

Edited by zygot

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this