Jump to content

FPGA based PWM generation


D@n

Recommended Posts

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

Link to comment
Share on other sites

@D@n,

1 hour ago, D@n said:

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 forgot to ask this. I've never encountered a "truth" signal before in my 35+ years of engineering. Please do elaborate. If you provide the math it might help with the mysteries surrounding your plots. Actually if you provide any sort of documentation backing your your claim of inventing "a proposed new method of handling single bit modulation" that would be more helpful than waving your hands, invoking odd incantations, and saying that you don't have to respond to valid questions with invalid logic..

I really feel like James Randi talking to Uri Geller. This exchange is absolutely surreal to me. Maybe I'm a "truth" signal.

 

 

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

1 hour ago, D@n said:

 

Here's my proposal:

 

While I was posting this one from you was not visible..

Here's my proposal:

Let's break down the conversation to three components:

  • HDL
  • How your novel modulation is supposed to work
  • Analysis of your IP feeding the PmodAMP2.

The first can be done using a testbench. The second requires you to answer valid questions with valid responses. It also demands a technical description of what the functional elements are and how it works. The third requires designing a valid test and measurement of your IP working on hardware. I will say that demonstrating how you can control both frequency and amplitude of your analog signasl would be nice.

I'm going to stop posting for a while so that we can sync posts....

 

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

@D@n,

You certainly don't have to dig a deeper hole than you've already dig for yourself.

The elaboration of your so called "IP" is really simple and uses just a few lines of Verilog. The analysis of both the algorithm and the Verilog elaboration is simple enough to test. The idea separating the part and testing them with the appropriate tools doesn't require $$ or an NDA. Your algorithm and implementation have already been published. If the algorithm is suspect or the HDL elaboration is suspect then so are your conclusions about the validity.

I believe that we can proceed just as I have laid out in my previous post. You are free to do what you feel is best for you.

Link to comment
Share on other sites

I am currently evaluating the HDL elaboration of your "IP" and need to move past this assertion that you have ignored.

 

On 9/12/2017 at 0:47 PM, zygot said:

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);

Instead of pointing to some reference, if you do not agree with the above statement please post a table with 16 decimal values, the two's complement format and the offset binary format. It's a pretty fundamental issue. I only see a few ways to make sample_out an unsigned value:

  • replace your sample.c samples with only positive values ( they will be 15-bit values with the sign bit = 0)
  • constrain the sample.c samples to 15-bit values and add an offset to in your Verilog

Both of these are fairly common practice. Your code clearly wants to deal with unsigned values and 15-bit values should be sufficient. You can then remove the sign-bit flipping that doesn't do what you claim it does. Since you don't want to explain how comparing a bit-reversed up counter to an unsigned value creates a PDM I'm left with a quandary. You say that your demo works but it's clear that the HDL can't work as written

Link to comment
Share on other sites

@D@n

Are you referring to this table?

Offset binary code, K = 8     Decimal code     Two's complement binary
1111     7     0111
1110     6     0110
1101     5     0101
1100     4     0100
1011     3     0011
1010     2     0010
1001     1     0001
1000     0     0000
0111     −1     1111
0110     −2     1110
0101     −3     1101
0100     −4     1100
0011     −5     1011
0010     −6     1010
0001     −7     1001
0000     −8     1000


The one that shows that 4-bit offset binary format is a signed representation spanning -8 to +7, just like two's complement binary is a signed representation spanning -8 to +7? The one that purports to show that flipping a sign bit in a two's compliment binary word does not get rid of the sign bit or turn it into an unsigned binary representation spanning 0 to 16? Is that what you've been referencing? 

And don't tell me that K16 in your HDL. Binary representations don't work that way. You can't flip an sign bit and have it turn into a data bit. Did you read AN9657 that I uploaded earlier in this thread?

Link to comment
Share on other sites

@D@n

While you are off brushing up on binary number representations on Wikipedia I decided to move on with the HDL analysis. 

I've uploaded a new VHDL testbench that simulates your S6SOC doorbell audio. The sample data is taken directly from sample.c and are clearly  signed 16-bit values. The new testbench uses ieee.numeric because VHDL is a strongly typed language and complains about confusion involving data formats when you do something stupid. The simulation takes a while but you don't have to run for the full 237 ms to see what's going on.

One nice feature of Vivado simulation is that you can display signals as analog. Right click on t_offset_audio and select waveform style. Choose analog. I prefer to go into the Analog Settings and choose the hold interpolation style as the linear style can be misleading. Do the same for  the sample_out signal in the wbpwmaudio instantiation.

You will notice that sample_out properly occupies the upper half of the unsigned 16-bit range. When we offset the signal by 16384 we got rid of the sign bit ( it's now all positive data ) but lost half our range. (see Dan's wikipedia reference or better yet the AN9657 application note that I posted earlier. This all works out as long as the signed samples are scaled to be less than +/- 16384. If the signed data exceeds this then we can't fit the signed 16-bit data into an unsigned 16-bit binary number.

Since Dan's wishbone bus is a 32-bit signed value it should be clear that the better approach would be to just create offset samples from 0 to 64435 or whatever the maximum signal value you want instead of samples centered around zero.

Now I suspect that Dan will argue that his Verilog code works just fine as long as the data is scaled from -16384 to +16383. I'll argue that if that's the case then there's no reason for this line in his code:

next_sample <= { ~i_wb_data[15], i_wb_data[14:0] };

as wb_data[15] is never a 1.

I'll also argue that not only is this formally incorrect but that it's exceedingly poor HDL design. Not only will wbpwmaudio.v fail for certain wb_data inputs but the code has a landmine for anyone using it outside of the S6SOC project. Even if you add a comment to wbpwmaudio.v warning of the limitations of wb_data range it is still bad code.

I will continue the analysis of Dan's "IP" using my own VHDL elaboration for consistency using unsigned inputs; unless Dan says that his algorithm doesn't work with samples not centered around zero.

 

T_wbpwmaudio.vhd

Link to comment
Share on other sites

20 hours ago, zygot said:

@D@n

Are you referring to this table?

Offset binary code, K = 8     Decimal code     Two's complement binary
1111     7     0111
1110     6     0110
1101     5     0101
1100     4     0100
1011     3     0011
1010     2     0010
1001     1     0001
1000     0     0000
0111     −1     1111
0110     −2     1110
0101     −3     1101
0100     −4     1100
0011     −5     1011
0010     −6     1010
0001     −7     1001
0000     −8     1000


The one that shows that 4-bit offset binary format is a signed representation spanning -8 to +7, just like two's complement binary is a signed representation spanning -8 to +7? The one that purports to show that flipping a sign bit in a two's compliment binary word does not get rid of the sign bit or turn it into an unsigned binary representation spanning 0 to 16? Is that what you've been referencing? 

And don't tell me that K16 in your HDL. Binary representations don't work that way. You can't flip an sign bit and have it turn into a data bit. Did you read AN9657 that I uploaded earlier in this thread?

@zygot Why do you need binary offset as in AN9657 ?

Link to comment
Share on other sites

@kevin123,

I don't need offset binary at all for this little project. D@n thinks that offset binary is an unsigned representation ( it is not ) and that you can manipulate a sign bit to convert a signed binary number to an unsigned binary number ( you cannot ).

As to the application note; offset binary is often used by A/D converter vendors as the data format. Typically, these converters have an analog input that varies between -Vin and +Vin and the design was simpler (cheaper) (..an assumption on my part) to implement using the offset binary representation. Some A/D converters have inputs between 0 and +Vin and are happy to output codes in unsigned binary format. Some A/Ds output codes in two's complement or one's complement to represent -Vin to +Vin. As you no doubt saw in the application note there are other binary formats but I've only run into the ones that I mention here.

I do hope that you take the time to try the simulation that I posted. The code for D@n's work is in the S6SOC project where he referenced it in an earlier post.

Thanks for the question. I was hoping that someone other than D@n and I were paying attention to it. Sometimes you learn more trouble-shooting than designing stuff. I have often run into work that kinda looks like it's working only to discover, after lengthy and arduous effort,  that not only the implementation but the entire concept was fatally flawed. It's astonishing how wrong something can be and almost look correct. That's why we need to be very careful drawing conclusions without careful and well thought out testing.

Link to comment
Share on other sites

Stay tuned. I expect that a PmodAMP2 will arrive in a few days. In the meantime, I have created my own VHDL version of D@n's "PDM IP" and a toplevel test bed to run it on a Nexys Video. D@n has one of these but if you don't it shouldn't be too hard to modify for any FPGA board with a standard PMOD.... just change the device type and constraints file.

Please contribute questions and or comments.

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

@D@n,

I've already expressed what my approach is.

On 9/13/2017 at 10:54 AM, zygot said:

Let's break down the conversation to three components:

  • HDL
  • How your novel modulation is supposed to work
  • Analysis of your IP feeding the PmodAMP2.

The objective is to analyze the method that you create your signal driving the PmodAMP2. Before we do that we need to have the IP implementation in the HDL working correctly. The concept, the implementation of the concept, and the verification of first two in both simulation and on actual hardware all need to be tested. They are all parts of the analysis. Whether you agree or not, testing the premise of your "PDM IP" can be broken up into testing the individual pieces. The first step is to have an HDL that does what it claims to do in terms of implementing the algorithm. Once we have that we can create an HDL  test bed to run experiments on real hardware to see what's actually happening. Relative "Audio Quality" without quantifiable measurements and a rigorous methodology is meaningless. I've moved past the HDL and have coded my VHDL version of your PDM algorithm ( not much to do there...) and coded a VHDL  test bed for testing all of the parts using a Nexys Video so that you can replicate my work. Your Verilog code will be included to verify that my VHDL is doing the same thing.

While I'm not expert enough on PWM and PDM concepts to present a tutorial,  I do have a lot of experience with PWMs and modulation and have a pretty good idea as to how they should work.  The analysis of your understanding of both will be the last step; just after the analysis of the algorithm. I do have an idea as to what's going on but you'll have to put up with my methodical approach. While I wait for my hardware to arrive I plan on presenting some basic PWM concepts that are familiar to me. I realize that you like OCTAVE and indeed it is a great deal faster than SCILAB but I will likely continue to use SCILAB as it has an IDE that is more convenient. If I were processing large arrays of data I'd certainly choose OCTAVE as it is a great deal faster.

As to this:

3 hours ago, D@n said:

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.

I don't think anything. You simply refuse to acknowledge that in spite of the reference that I presented and the reference that you presented you want to believe that offset binary is an unsigned binary representation and that you can change a sign bit into a data bit. I suggest that you run the testbench that I last uploaded to see what everyone else sees. This has nothing to do with opinion, just basic concepts. I'm tired of playing whack-a-mole.

I will upload the test bed project soon for inspection before the real fun begins. Here's how I anticipate that things will proceed. I'll use the testbed to drive your IP with a single tone that can be easily varied and will use a scope to capture what's happening along the way to the SSM2237 input. I expect to see something that doesn't look at all like the desired single tone analog signal on the large DC blocking capacitor that is part of the high pass filter. If you want to ignore the SSM2237 datasheet specifications then that's your privilege. From there I will work backwards to an analysis of what I think might be happening. After that will be an analysis of the "better PWM" that you claim.

By the way I will be testing the IP with unsigned values since that is obviously the way that you want to do it in your Verilog code. You can change the samples.c data to offset the doorbell samples to be all positive and use your own code if your want. I don't see a reason why you wouldn't want to do that and ditch the "conversion" altogether. It fixes the code and eliminates your unfortunate inability to understand basic concepts of number representation.

I am getting the impression that you don't know how to use normal Vivado tools instead of Verilator. I visited the Verilator web site and read this:

 Verilator is the fastest free Verilog HDL simulator, and beats most commercial simulators. It compiles synthesizable Verilog (not test-bench code!), plus some PSL, SystemVerilog and  Synthesis assertions into C++ or SystemC code.

Perhaps this is the root of your problem understanding what is going on with your HDL.

If you need help with testbench concepts or using Vivado simulator I can help with that. Just ask... Have you actually ever written a Verilog testbench and run a simulation using Vivado simulator or ModelSim?

Link to comment
Share on other sites

This thread is disturbingly long and often off topic.

The premise is that, if a set contains 0 to 2**N - 1 it will have k elements less than k for any permutation of the set.  (k  < 2**N - 2)  (the article has an off by one codeword issue IIRC)

From there, a heuristic for choosing a sequence that maximizes high-frequency energy while maintaining the same average would be bit reversing the value of a counter.  Bit reversing does not create random numbers, it mostly just moves the lsb to the msb which leads to an increase in max-frequency content.  The effect of moving the 2nd lsb to the 2nd msb does this to a lower effect.

There are legitimate concerns comparing PDM to PWM in a practical system.  Slew-rates and other parasitics lead to a case where not all 1's are equal.  This is true of any PDM system and are not unique to this approach.  Likewise, there are concerns with comparing lower-rate PDM to a higher-rate PWM that results in the same number of transitions or uses the same switching energy of a power device.

If you want to construct a case where this method is inferior to PWM you certainly can.  It is not strictly inferior though.  It should be better than the PWM version that has the same counter period and not better than an optimal PDM implementation -- assuming no output device imperfections.  

 

Also, why is VHDL/Verilog even being discussed?  That is purely an implementation detail.  Both languages work fine for this purpose and neither provides much insight into the topic.  Octave/Matlab/etc.. or an analog circuity simulator would be more relevant.

Also, why are binary formats being discussed?  That is based on input to the P*M and how the P*M converts a codeword into an analog value.

Link to comment
Share on other sites

@Piasa

9 hours ago, Piasa said:

 

This thread is disturbingly long and often off topic.

 

Perhaps you should have intervened earlier. At least you offered an explanation for D@ns concept. He hasn't. As to off topic please elaborate. As this is in a "learning" forum it make sense to me to resolve issues that come up.

You write: "The premise is that, if a set contains 0 to 2**N - 1 it will have k elements less than k for any permutation of the set.  (k  < 2**N - 2)  (the article has an off by one codeword issue IIRC)"

I don't quite get what premise you are referring to.

9 hours ago, Piasa said:

Also, why is VHDL/Verilog even being discussed?  

If an algorithm is implemented in an HDL and you want to examine the algorithm then you have to work through any implementation error that you find. By the same reasoning if you want to demonstrate an algorithm in OCTAVE had there is an error in that implementation the same is true. Are you offering to provide an OCTAVE script to demonstrate how this all works? I agree that SPICE would be a better simulation tool but there is no model for the SSM2237 and I don't have specific board trace data to be complete. Are you offering a SPICE simulation to shorten this thread and illuminate your comments?

9 hours ago, Piasa said:

Also, why are binary formats being discussed?  That is based on input to the P*M and how the P*M converts a codeword into an analog value.

I really don't understand this comment. Please elaborate.

I'm puzzled that you don't have a comment on the discussion as to whether or not you can change a 16-bit signed value into a 16-bit unsigned value. This seems to me to be important in understanding D@n's Verilog as doing something wrong and getting the correct results hasn't been my experience. As this is an FPGA forum understanding basic  concepts seems relevant to me.

Lastly, I have an idea as to how a class D amplifier creates an analog signal using a PDM and the impedance of a speaker but not how D@n's signal creates an analog signal at the input to the SSM2237. There's theory and there's reality. Making a convincing demonstration as to how the theory works would certainly be helpful but I've been working backwards ( without the hardware so far ) from my understanding of reality. Regardless of whether the algorithm works I have doubts about the actual digital signal ( 10 ns pulses, 12.5 ns pulses, 1 ns pulses... ) making it to the SSM2237 intact. If you point is that I don't understand the analog ( digital samples ) to PDM to analog at the SSM2237 input I've said that this is true.

Care to provide the analysis in OCTAVE, SPICE or whatever you prefer? I might spare you from reading more irrelevant material.

Oh, and thanks for the input.

 

Link to comment
Share on other sites

@D@n

I glanced at the referenced test directory material.

It seems to reinforce my suspicion that you've never done an HDL simulation and that all of your design/verification flow is in C++.

One aspect of ModelSim or Vivado simulator is that the simulator understands HDL and the details of the language on the most basic level. Working in C++ allows one to abstract away a lot of those details which can be very helpful but also an impediment. I suggest you should develop a facility with the HDL testbench writing and simulation flow. 

Link to comment
Share on other sites

2 hours ago, zygot said:

If an algorithm is implemented in an HDL and you want to examine the algorithm then you have to work through any implementation error that you find.

This does make sense if there is an error in the implementation.  From my glance to the code the only issue is that the comparison prevents either the all 0 or the all 1 sequence (I don't recall which was not possible).  That is independent of the bit-reversal.  A simulation of a specific implementation is not helpful in illustrating the core concept though.  The core concept can be explained without even giving a reference implementation.

 

2 hours ago, zygot said:

If you point is that I don't understand the analog ( digital samples ) to PDM to analog at the SSM2237 input I've said that this is true.

Both PWM and PDM expect some form of filter.  In some cases this will be an RC filter, in some cases a LR filter, in some cases an RLC filter, and in some cases the load will have these properties already.

 

2 hours ago, zygot said:

Regardless of whether the algorithm works I have doubts about the actual digital signal ( 10 ns pulses, 12.5 ns pulses, 1 ns pulses... ) making it to the SSM2237 intact.

Yes, this is correct.  This is the "not all 1's are equal" comment.  This method is similar to PDM in that there are many transitions.  This makes it less suited for power amplifiers or when the output device cannot switch suitably fast.

 

2 hours ago, zygot said:

I'm puzzled that you don't have a comment on the discussion as to whether or not you can change a 16-bit signed value into a 16-bit unsigned value

In this application, a signed value must be mapped into "number of cycles on per 2**N cycles".  This is an unsigned value independent of if the input is signed or unsigned.  The design assumes that a 1 output maps to +V and a 0 output maps to -V.  To output 0V, the design would need to output an equal number of 0's and 1's.  In this case, the number of cycles in the period is also related to the precision of the input.  That is not required in general.  However, for this case the operation to get from signed input sample to unsigned number of on-cycles is the same as the conversion from signed to offset binary.

Link to comment
Share on other sites

1 hour ago, Piasa said:

This does make sense if there is an error in the implementation.  From my glance to the code the only issue is that the comparison prevents either the all 0 or the all 1 sequence (I don't recall which was not possible).  That is independent of the bit-reversal.  A simulation of a specific implementation is not helpful in illustrating the core concept though.  The core concept can be explained without even giving a reference implementation.

Yeah, It makes sense to me because I am implementing a testbed in HDL to test the actual hardware. I want to use an algorithm that works with any input value. When you flip the sign bit of a signed binary number you change how the data bits are to be interpreted. If you don't care about the value of the remaining bit then why not just ignore the sign bit in the comparison logic? The HDL compares a 16 bit binary word without a sign bit to one with a sign bit and this cannot be correct. As I've pointed out if you don't use signed data then this whole issue becomes moot. Pardon my reluctance to buy into your argument the implementation is irrelevant to the discussion as this is exactly the kind of detail that I've seen break a design implementation.

I will be uploading my testbed with a simulation testbench. You might find it interesting.

I don't disagree that evaluating the IP as an independent entity is worthwhile. As to whether or not the output of D@n's PDM turns into the expected analog signal that the SSM2237 is designed to use, that's not be shown by anyone yet. This includes D@n's recently released test report. This is certainly illuminating but doesn't answer the question as to what is going on to get that "more pleasing" sound that he hears from his PmodAMP2 connected speaker.

I am also not understanding how comparing a permutation of an up counter to an input encodes a representation of the input. I understand how a pwm does that. I understand how it provides many more transitions. Perhaps you might offer your insight as to how this works?

Your argument: "In this application, the 16b signed value is re-encoded into a representation that will be used with unsigned inequality comparison.  The value that is represented by the conversion is a signed value -- we are mapping some code words to negative values.  However, the representation is used with unsigned operators.  From an implementation perspective it is unsigned.  Most languages force an interpretation of either signed/unsigned even when neither are correct." is a helpful insight that I've been missing though not complete to grasping the encoding of amplitude.

I do want to say that if someone wants to know, say, how to use a feature of Vivado, then the answer(s) should be as concise as can be clearly presented. When a discussion is complicated and the goal is learning then I say let the discussion go where it needs to go as new questions arise. The reader is free to speed-read through what isn't interesting, focus on what is or just ignore the whole thread all together if there is no value to it. Learning is a equal opportunity pursuit and the process works differently for everyone.

Link to comment
Share on other sites

1 minute ago, zygot said:

I am also not understanding how comparing a permutation of an up counter to an input encodes a representation of the input. I understand how a pwm does that. I understand how it provides many more transitions. Perhaps you might offer your insight as to how this works?

Sorry, I updated my post as you were typing this.  The post now gives a more accurate description.  The signed input must be converted into an unsigned "on-cycles per period."  In this case, the design accomplishes this in the same way that signed values would be converted to offset binary.  

Link to comment
Share on other sites

@Piasa

1 hour ago, Piasa said:

In this application, a signed value must be mapped into "number of cycles on per 2**N cycles".  This is an unsigned value independent of if the input is signed or unsigned.  The design assumes that a 1 output maps to +V and a 0 output maps to -V.  To output 0V, the design would need to output an equal number of 0's and 1's.  In this case, the number of cycles in the period is also related to the precision of the input.  That is not required in general.  However, for this case the operation to get from signed input sample to unsigned number of on-cycles is the same as the conversion from signed to offset binary.

Ah, even more illuminating. Thank you.

Link to comment
Share on other sites

@D@n

Yesterday I received a PmodAMP2 so I was able to try out my testbed using the Nexys Video. The project HDL runs fine but the support code needs work to be in a finished state. I will post when ready. I mention this now because I as able to reach some conclusions that should be posted in the interim. All of these involve aspects of your "better PWM" that really bothered me which turned out not to be issues. My testbed runs your wbpwmaudio as well as my version at 100 MHz so there are 10 ns pulses driving the analog input pin of the PmodAMP2. The following points are counter to what I expected ( that is to say my expectations were incorrect ).

  • The signal quality of the 100 MHz PDM is quite adequate at the input to the initial low pass filter.
  • The PDM does get converted into a reasonable representation of the source digital waveform at the SSM2237 input.
  • The wbpwmaudio counter interval is independent of the sampling period ( as long as it's longer ).
  • I think that I've figured out how the pulse density encoding works.

I will put the project code and observations here for anyone who wants to work this out when ready. I'm still working through a few details about how it all works.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...