myhdl-list

[myhdl-list] Sigma-Delta DAC

[Bob C. <Fl...@gm...>]

I'm trying to learn from this code: http://www.myhdl.org/doku.php/projects:dsx1000

I first ran dac_dsx1000_ut.py, and all tests passed.  I next tried to run dac_dsx1000_syn.py, but got the following errors:

    $ pypy ./dac_dsx1000_syn.py
    CLK_HZ =  16000000
    OUTPUT_FREQ_HZ =  440
    FVAL =  461
    Traceback (most recent call last):
       File "app_main.py", line 53, in run_toplevel
       File "./dac_dsx1000_syn.py", line 137, in<module>
         toVerilog(top, clk, rst, pdm_o, CLK_HZ)
       File "/usr/lib/pypy-1.6/site-packages/myhdl/conversion/_toVerilog.py", line 128, in __call__
         h = _HierExtr(name, func, *args, **kwargs)
       File "/usr/lib/pypy-1.6/site-packages/myhdl/_extractHierarchy.py", line 228, in __init__
         _top = dut(*args, **kwargs)
       File "./dac_dsx1000_syn.py", line 97, in top
         @always_comb
       File "/usr/lib/pypy-1.6/site-packages/myhdl/_always_comb.py", line 64, in always_comb
         c = _AlwaysComb(func, symdict)
       File "/usr/lib/pypy-1.6/site-packages/myhdl/_always_comb.py", line 203, in __init__
         raise AlwaysCombError(_error.EmptySensitivityList)
    AlwaysCombError: sensitivity list is empty


I got the same errors when using python instead of pypy.

My naive solution was to modify dac_dsx1000_syn.py to add 'rst' to top()'s parameter list, move the rst declaration to line 132, and comment-out the definition of rstDrv(), after which the above errors went away.

While the tests in dac_dsx1000_ut.py still pass, I'm now torturing my newbie brain to figure out how best to update the testbench to include testing of rst.  The pain is terrible, but slow progress is being made.

I haven't yet fed the generated Verilog code to ISE, nor have I run a cosimulation to test it.

Questions:
1. Is this the right approach to use to fix this problem?
2. When the fix is complete and tested, where should the updated code go?

TIA,

-BobC

Re: [myhdl-list] Sigma-Delta DAC

[Christopher F. <chr...@gm...>]

On 10/1/11 8:20 PM, Bob Cunningham wrote:
> I'm trying to learn from this code:
> http://www.myhdl.org/doku.php/projects:dsx1000
>
> I first ran dac_dsx1000_ut.py, and all tests passed.  I next tried to
> run dac_dsx1000_syn.py, but got the following errors:

You can refer to a recent thread why the error occurs.  If you are only 
concerned with converting the DAC portion you can use the following.

     # PCM Audio signal.
     # Note that we control the (theoretical) resolution of the converter
     # by setting the bit width of this signal.
     DAC_RESOLUTION = 8
     clk_i = Signal(False)
     rst_i = Signal(False)
     pcm_i = Signal(intbv(0)[DAC_RESOLUTION:])
     pdm_o = Signal(False)

     # MyHDL to Verilog conversion
     toVerilog.name = "dsx1000"
     toVerilog(dac_dsx1000, clk_i, rst_i, pcm_i, pdm_o)

If you want to convert the waveform generator as well, simply bring the 
reset to a port and remove the dummy reset driver.

Hope that helps,
Chris

>
>     $ pypy ./dac_dsx1000_syn.py
>     CLK_HZ =  16000000
>     OUTPUT_FREQ_HZ =  440
>     FVAL =  461
>     Traceback (most recent call last):
>        File "app_main.py", line 53, in run_toplevel
>        File "./dac_dsx1000_syn.py", line 137, in<module>
>          toVerilog(top, clk, rst, pdm_o, CLK_HZ)
>        File "/usr/lib/pypy-1.6/site-packages/myhdl/conversion/_toVerilog.py", line 128, in __call__
>          h = _HierExtr(name, func, *args, **kwargs)
>        File "/usr/lib/pypy-1.6/site-packages/myhdl/_extractHierarchy.py", line 228, in __init__
>          _top = dut(*args, **kwargs)
>        File "./dac_dsx1000_syn.py", line 97, in top
>          @always_comb
>        File "/usr/lib/pypy-1.6/site-packages/myhdl/_always_comb.py", line 64, in always_comb
>          c = _AlwaysComb(func, symdict)
>        File "/usr/lib/pypy-1.6/site-packages/myhdl/_always_comb.py", line 203, in __init__
>          raise AlwaysCombError(_error.EmptySensitivityList)
>     AlwaysCombError: sensitivity list is empty
>
>
> I got the same errors when using python instead of pypy.
>
> My naive solution was to modify dac_dsx1000_syn.py to add 'rst' to
> top()'s parameter list, move the rst declaration to line 132, and
> comment-out the definition of rstDrv(), after which the above errors
> went away.
>
> While the tests in dac_dsx1000_ut.py still pass, I'm now torturing my
> newbie brain to figure out how best to update the testbench to include
> testing of rst.  The pain is terrible, but slow progress is being made.
>
> I haven't yet fed the generated Verilog code to ISE, nor have I run a
> cosimulation to test it.
>
> Questions:
> 1. Is this the right approach to use to fix this problem?
> 2. When the fix is complete and tested, where should the updated code go?
>
> TIA,
>
> -BobC
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Sigma-Delta DAC

[Bob C. <Fl...@gm...>]

Hi Chris,

On 10/01/2011 06:38 PM, you wrote:
> You can refer to a recent thread why the error occurs. 

I've searched, but found no such thread.  Would you send me a link to it?

> If you want to convert the waveform generator as well, simply bring the
> reset to a port and remove the dummy reset driver.

Nothing is 'simply' done by a newbie.


-BobC

Re: [myhdl-list] Sigma-Delta DAC

[Christopher F. <chr...@gm...>]

On 10/3/11 7:56 PM, Bob Cunningham wrote:
> Hi Chris,
>
> On 10/01/2011 06:38 PM, you wrote:
>> You can refer to a recent thread why the error occurs.
>
> I've searched, but found no such thread.  Would you send me a link to it?

http://article.gmane.org/gmane.comp.python.myhdl/2057/match=driving+constants

>
>> If you want to convert the waveform generator as well, simply bring the
>> reset to a port and remove the dummy reset driver.
>
> Nothing is 'simply' done by a newbie.
>
>
> -BobC
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1

Re: [myhdl-list] Sigma-Delta DAC

[Bob C. <Fl...@gm...>]

On 10/03/2011 06:36 PM, Christopher Felton wrote:
> On 10/3/11 7:56 PM, Bob Cunningham wrote:
>> Hi Chris,
>>
>> On 10/01/2011 06:38 PM, you wrote:
>>> You can refer to a recent thread why the error occurs.
>> I've searched, but found no such thread.  Would you send me a link to it?
> http://article.gmane.org/gmane.comp.python.myhdl/2057/match=driving+constants

Oh, THAT thread.  I have it archived, but had no clue it was in any way related to my questions.

Well, still don't, really.  But I'm studying it.

Beware the newbie:  Speak slowly.  Use small words.

-BobC

Re: [myhdl-list] Sigma-Delta DAC

[Bob C. <Fl...@gm...>]

More questions about this code: http://www.myhdl.org/doku.php/projects:dsx1000

I'd like to optimize the DAC output performance so the analog audio output would faithfully as possible represent a 10-bit digital input sequence at 44.1 KHz.  I have two usage scenarios:  a) Driving a line-out connection to an external amplifier, and b) driving a local analog comparator (with known hysteresis) as part of a sigma-delta ADC.  In both cases, I'd want to optimize both the RC filter design (for the intended load and PWM drive current/voltage) and the digital DAC design (mainly to use a minimum PWM output bit rate).  Ideally, the synthesized circuit would default to the current code (or raise an error) when the output filter characteristics are not specified.

With this goal in mind, my first detailed pass through the existing code raises two related questions:

1. The definition of dac_dsx1000() in dac_dsx1000_hd.pydoes not take into account either the characteristics of the load on the PWM output pin, nor the drive capability of that pin.  If these characteristics are known prior to synthesis, shouldn't the generated PWM bitstream be pre-compensated accordingly?  That is, when the input value changes, shouldn't the output be driven hard until the estimated filter output (not the pin output) gets to within a single bit-time delta of the desired value?

The formula for a simple first-order RC output filter is simple.  My naive guess is the correction could be implemented as a digital filter (the inverse of the output filter), perhaps by modifying the integrator stage (Adder()).  The main benefit would be that the required PWM clock rate could be significantly reduced and/or output fidelity improved.

The question is: Would the extra processing be worth doing?  Why or why not?


2.  The unit test in bench_static() in dac_dsx1000_ut.py sets "INTEGRATION_TIME = 512".  This seems like a very long time.  I doubt I'll see that many PWM clock periods in any realistic implementation scenario.
  - Is there a better or more realistic way to determine this value?  Perhaps as a function of input word width and output bitstream frequency?
  - How should the value change if the optimization described in the prior question were implemented?  That is, I'd like the test to tell me if the PWM output will drive the filter output (not just the pin output) with the desired level of error.
  - Or am I missing some of the intent of the test?


-BobC

Re: [myhdl-list] Sigma-Delta DAC

[Christopher F. <chr...@gm...>]

On 10/4/11 2:37 AM, Bob Cunningham wrote:
> More questions about this code: http://www.myhdl.org/doku.php/projects:dsx1000
>
> I'd like to optimize the DAC output performance so the analog audio output would faithfully as possible represent a 10-bit digital input sequence at 44.1 KHz.  I have two usage scenarios:  a) Driving a line-out connection to an external amplifier, and b) driving a local analog comparator (with known hysteresis) as part of a sigma-delta ADC.  In both cases, I'd want to optimize both the RC filter design (for the intended load and PWM drive current/voltage) and the digital DAC design (mainly to use a minimum PWM output bit rate).  Ideally, the synthesized circuit would default to the current code (or raise an error) when the output filter characteristics are not specified.
>

I think what you are getting at, is that you want an AGC part of your 
design.  This should not be part of the delta-sigma module.  You might 
consider it part of your "DAC" but I don't think it should be part of 
the delta-sigma module.

> With this goal in mind, my first detailed pass through the existing code raises two related questions:
>
> 1. The definition of dac_dsx1000() in dac_dsx1000_hd.pydoes not take into account either the characteristics of the load on the PWM output pin, nor the drive capability of that pin.  If these characteristics are known prior to synthesis, shouldn't the generated PWM bitstream be pre-compensated accordingly?  That is, when the input value changes, shouldn't the output be driven hard until the estimated filter output (not the pin output) gets to within a single bit-time delta of the desired value?
>
> The formula for a simple first-order RC output filter is simple.  My naive guess is the correction could be implemented as a digital filter (the inverse of the output filter), perhaps by modifying the integrator stage (Adder()).  The main benefit would be that the required PWM clock rate could be significantly reduced and/or output fidelity improved.
>
> The question is: Would the extra processing be worth doing?  Why or why not?
>
>
> 2.  The unit test in bench_static() in dac_dsx1000_ut.py sets "INTEGRATION_TIME = 512".  This seems like a very long time.  I doubt I'll see that many PWM clock periods in any realistic implementation scenario.
>    - Is there a better or more realistic way to determine this value?  Perhaps as a function of input word width and output bitstream frequency?
>    - How should the value change if the optimization described in the prior question were implemented?  That is, I'd like the test to tell me if the PWM output will drive the filter output (not just the pin output) with the desired level of error.
>    - Or am I missing some of the intent of the test?
>

The integration time, might be poorly named, in the testbench.  It is 
simply some amount of time delayed for each step to test.  You can work 
backwards and analytically determine the response time (I don't know 
this off the top of my head).  Or you could apply a step function to the 
module and empirically determine the response time.  Is there a reason 
you want to change it?

For the most part, these are general design questions.  You might want 
to cross-post to comp.arch.fpga or sci.electronics.design (.basic). 
There were no protest to post here, as stated I think it is fine, but 
you might get a better response from some of the other news/irc groups 
in addition.

Regards,
Chris
>
> -BobC
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1

Re: [myhdl-list] Sigma-Delta DAC

[Bob C. <Fl...@gm...>]

On 10/05/2011 03:36 AM, Christopher Felton wrote:
> On 10/4/11 2:37 AM, Bob Cunningham wrote:
>> More questions about this code: http://www.myhdl.org/doku.php/projects:dsx1000
>>
>> I'd like to optimize the DAC output performance so the analog audio output would faithfully as possible represent a 10-bit digital input sequence at 44.1 KHz.  I have two usage scenarios:  a) Driving a line-out connection to an external amplifier, and b) driving a local analog comparator (with known hysteresis) as part of a sigma-delta ADC.  In both cases, I'd want to optimize both the RC filter design (for the intended load and PWM drive current/voltage) and the digital DAC design (mainly to use a minimum PWM output bit rate).  Ideally, the synthesized circuit would default to the current code (or raise an error) when the output filter characteristics are not specified.
>>
> I think what you are getting at, is that you want an AGC part of your
> design.  This should not be part of the delta-sigma module.  You might
> consider it part of your "DAC" but I don't think it should be part of
> the delta-sigma module.

AGC?  No, I don't think that's an issue.

But if you start with an d-s DAC, adding an analog comparator and a simple circuit change yields a d-s ADC.  It won't necessarily be high-fidelity (that will best be accomplished using external ADC and DAC hardware), but it will be both minimal and adequate.  And interesting!

>> With this goal in mind, my first detailed pass through the existing code raises two related questions:
>>
>> 1. The definition of dac_dsx1000() in dac_dsx1000_hd.pydoes not take into account either the characteristics of the load on the PWM output pin, nor the drive capability of that pin.  If these characteristics are known prior to synthesis, shouldn't the generated PWM bitstream be pre-compensated accordingly?  That is, when the input value changes, shouldn't the output be driven hard until the estimated filter output (not the pin output) gets to within a single bit-time delta of the desired value?
>>
>> The formula for a simple first-order RC output filter is simple.  My naive guess is the correction could be implemented as a digital filter (the inverse of the output filter), perhaps by modifying the integrator stage (Adder()).  The main benefit would be that the required PWM clock rate could be significantly reduced and/or output fidelity improved.
>>
>> The question is: Would the extra processing be worth doing?  Why or why not?
>>
>>
>> 2.  The unit test in bench_static() in dac_dsx1000_ut.py sets "INTEGRATION_TIME = 512".  This seems like a very long time.  I doubt I'll see that many PWM clock periods in any realistic implementation scenario.
>>     - Is there a better or more realistic way to determine this value?  Perhaps as a function of input word width and output bitstream frequency?
>>     - How should the value change if the optimization described in the prior question were implemented?  That is, I'd like the test to tell me if the PWM output will drive the filter output (not just the pin output) with the desired level of error.
>>     - Or am I missing some of the intent of the test?
>>
> The integration time, might be poorly named, in the testbench.  It is
> simply some amount of time delayed for each step to test.  You can work
> backwards and analytically determine the response time (I don't know
> this off the top of my head).  Or you could apply a step function to the
> module and empirically determine the response time.  Is there a reason
> you want to change it?

The signal seems to be correctly named.  The PDM output is summed until the integration time passes.

The test integrates for the specified number of clocks, then checks to see if the PDM output reaches the correct average value.  It ignores any specification for DAC response time: How long *should* it take for the output to stabilize?

If you look at the specified output RC filter (3.3 Kohm, 2 nF), it has a tau of 6.6 uS, for a 3 dB knee at 24.1 KHz ('good enough' for a 20 KHz audio output bandwidth).  So allowing a minimal amount of Nyquist headroom, a 44.1 KHz input word rate to the DAC seems about right.

Nominally, the DAC output integration time shouldn't (can't?) be slower than the input word rate (44.1 KHz), else the output won't be stable before the next input sample starts to be processed.  That would be no more than 362 cycles of the 16 MHz clock.  512 samples doesn't seem to test anything useful, and it could allow a poorly-converging DAC to pass!

Then again, using an integration time that is a power of 2 does make the test *slightly* simpler.

In my current career of creating software for embedded real-time systems, such as nuclear power plant monitoring systems and aircraft instruments, fanatical testing at all levels (hardware and software, from components to system) forms the core of safe and reliable products.  I'm not about to start getting sloppy now!

In this specific case, it may be best to calculate the maximum allowed number of PDM clocks, then round down to the next lower power of 2, which in this case would be 256.  If it passes at that count, it should pass with any higher count.


> For the most part, these are general design questions.  You might want
> to cross-post to comp.arch.fpga or sci.electronics.design (.basic).
> There were no protest to post here, as stated I think it is fine, but
> you might get a better response from some of the other news/irc groups
> in addition.

Well, this is still seems (to me) to be more about myHDL than anything else.  As a newbie, I want to make maximal use of published myHDL sample code before I start writing anything of my own.  I want to know what really good myHDL code should look like (content and style), and how all instances of the test and development processes should proceed.  So I'm beating on this DAC for multiple reasons!

Next, I'll want to wrap good VHDL and Verilog code within myHDL, and eventually translate it to pure myHDL.  Only as a last resort will I want to do my own design on this first project!  My FPGA board should arrive fairly soon, and I hope to not just have a demo binary ready to go, but one that has been tested well enough to present no surprises when loaded into the FPGA.

Despite not being a much of a circuit designer, I see things in the referenced code that don't look quite right.  I'm not sure if it is due to a poor circuit design, a poor test harness, my own limited knowledge of myHDL and circuit design, or a combination of all of them.  Hence the use of this forum.

For the specific case of an all-digital ADC and DAC (the gateway to my audio effects processor), if my learning curve permits I hope to also cosimulate the RC output and input networks using myHDL with Spice.  So the 'real' test could be in the analog domain, where an audio signal is supplied to the ADC and compared to the DAC output.  It's about more than just a specific circuit or project: My true goal is to put the myHDL development and test environment through its paces in every way I can.

I expect to pursue my digital design education at a fairly lazy rate, driven by the problems I want to solve and the projects I want to build, rather than a textbook or a class.  But I will want to do it *all* within the myHDL environment, which is why I plan to collect my notes and eventually write a "FPGA Projects in myHDL" tutorial, based on a progression of non-trivial but easily understood and useful examples that are well-designed, well-written, and obsessively tested (simulation, cosimulation, circuit test with and without a synthesized test bench, etc.).

That's a primary reason why I chose an audio effects processor:  Once the ADC and DAC are in place, much of the rest is just creating relatively simple audio processing modules.  Due to the slow data rate (KHz, not MHz), the design can easily be evolved to use single module instances with multiple audio streams (time domain switching), perform multi-track mixing, and change the module order (crossbar switching).  I also expect it to consume a relatively small portion of the FPGA, leaving adequate room to integrate a processor core and proceeding to an entire SoC (perhaps with a Wishbone interface).  I have no idea how I will test a processor core within the myHDL environment, but I can't wait to figure it out!

In other areas of study, the tutorials that have been the most useful to me were written by recent beginners, and edited by gurus.  Plus, I learn best by teaching:  Writing a thorough introductory tutorial is a great way to master the basics of any field of endeavor.  I'll be pushing the members of this forum to help me create examples of myHDL code (and a library of polished projects) we'll all be proud to share with the world.

If I visit the other forums you recommend, I'm afraid they'll ask me to speak VHDL or Verilog or SystemC or something...  Or, worse, ask for an ASCII-art schematic.   ;^)  But I will start monitoring them.

Thanks,

-BobC

Re: [myhdl-list] Sigma-Delta DAC

[Christopher F. <chr...@gm...>]

On 10/5/2011 10:51 AM, Bob Cunningham wrote:
> On 10/05/2011 03:36 AM, Christopher Felton wrote:
>> On 10/4/11 2:37 AM, Bob Cunningham wrote:
>>> More questions about this code: http://www.myhdl.org/doku.php/projects:dsx1000
>>>
>>> I'd like to optimize the DAC output performance so the analog audio output would faithfully as possible represent a 10-bit digital input sequence at 44.1 KHz.  I have two usage scenarios:  a) Driving a line-out connection to an external amplifier, and b) driving a local analog comparator (with known hysteresis) as part of a sigma-delta ADC.  In both cases, I'd want to optimize both the RC filter design (for the intended load and PWM drive current/voltage) and the digital DAC design (mainly to use a minimum PWM output bit rate).  Ideally, the synthesized circuit would default to the current code (or raise an error) when the output filter characteristics are not specified.
>>>
>> I think what you are getting at, is that you want an AGC part of your
>> design.  This should not be part of the delta-sigma module.  You might
>> consider it part of your "DAC" but I don't think it should be part of
>> the delta-sigma module.
>
> AGC?  No, I don't think that's an issue.

I am a little confused, I don't know if you are worried about ENOB or 
loading on the circuit (or impedance matching or any other circuit 
issue).  I would argue not the same issues.  In one case you need to do 
the noise analysis of your analog circuit and make sure the noise floor 
doesn't corrupt the dynamic range of of your DAC#bits.  The other you 
might desire a pre-emphasis (equalization) to account for any 
distortion.  In both cases I would not modify the d-s modulator, unless 
it was the number of bits used.

You are probably better off, backing up looking at the system design and 
analysis.  Determine the architecture of the ADC and DAC you want and 
what external circuits you want.  You should not need to add anything to 
the d-s DAC.

>
> But if you start with an d-s DAC, adding an analog comparator and a simple circuit change yields a d-s ADC.  It won't necessarily be high-fidelity (that will best be accomplished using external ADC and DAC hardware), but it will be both minimal and adequate.  And interesting!
>

You don't need a delta-sigma (d-s) DAC for a d-s ADC.  You only need one 
d-s modulator per converter, just happens, in one case it is a 
continuous and the other a discrete.

>>> With this goal in mind, my first detailed pass through the existing code raises two related questions:
>>>
>>> 1. The definition of dac_dsx1000() in dac_dsx1000_hd.pydoes not take into account either the characteristics of the load on the PWM output pin, nor the drive capability of that pin.  If these characteristics are known prior to synthesis, shouldn't the generated PWM bitstream be pre-compensated accordingly?  That is, when the input value changes, shouldn't the output be driven hard until the estimated filter output (not the pin output) gets to within a single bit-time delta of the desired value?
>>>
>>> The formula for a simple first-order RC output filter is simple.  My naive guess is the correction could be implemented as a digital filter (the inverse of the output filter), perhaps by modifying the integrator stage (Adder()).  The main benefit would be that the required PWM clock rate could be significantly reduced and/or output fidelity improved.
>>>
>>> The question is: Would the extra processing be worth doing?  Why or why not?
>>>
>>>
>>> 2.  The unit test in bench_static() in dac_dsx1000_ut.py sets "INTEGRATION_TIME = 512".  This seems like a very long time.  I doubt I'll see that many PWM clock periods in any realistic implementation scenario.
>>>      - Is there a better or more realistic way to determine this value?  Perhaps as a function of input word width and output bitstream frequency?
>>>      - How should the value change if the optimization described in the prior question were implemented?  That is, I'd like the test to tell me if the PWM output will drive the filter output (not just the pin output) with the desired level of error.
>>>      - Or am I missing some of the intent of the test?
>>>
>> The integration time, might be poorly named, in the testbench.  It is
>> simply some amount of time delayed for each step to test.  You can work
>> backwards and analytically determine the response time (I don't know
>> this off the top of my head).  Or you could apply a step function to the
>> module and empirically determine the response time.  Is there a reason
>> you want to change it?
>
> The signal seems to be correctly named.  The PDM output is summed until the integration time passes.
>
> The test integrates for the specified number of clocks, then checks to see if the PDM output reaches the correct average value.  It ignores any specification for DAC response time: How long *should* it take for the output to stabilize?
>
> If you look at the specified output RC filter (3.3 Kohm, 2 nF), it has a tau of 6.6 uS, for a 3 dB knee at 24.1 KHz ('good enough' for a 20 KHz audio output bandwidth).  So allowing a minimal amount of Nyquist headroom, a 44.1 KHz input word rate to the DAC seems about right.
>

Yes, it is an ok name.  But the tb does not try to emulate the RC-LPF 
used in the tb.  Introducing the parameters of the external RC-LPF at 
this point will only cause confusion, IMO.

The value is arbitrary, but it is fine for what the tb is testing.  It 
is just verifying, for each input state the modulator converges to a 
value.  If the input is not changing, the output should have an average 
of zero, regardless of the input value.

> Nominally, the DAC output integration time shouldn't (can't?) be slower than the input word rate (44.1 KHz), else the output won't be stable before the next input sample starts to be processed.  That would be no more than 362 cycles of the 16 MHz clock.  512 samples doesn't seem to test anything useful, and it could allow a poorly-converging DAC to pass!
>
> Then again, using an integration time that is a power of 2 does make the test *slightly* simpler.
>
> In my current career of creating software for embedded real-time systems, such as nuclear power plant monitoring systems and aircraft instruments, fanatical testing at all levels (hardware and software, from components to system) forms the core of safe and reliable products.  I'm not about to start getting sloppy now!
>
> In this specific case, it may be best to calculate the maximum allowed number of PDM clocks, then round down to the next lower power of 2, which in this case would be 256.  If it passes at that count, it should pass with any higher count.
>
>
>> For the most part, these are general design questions.  You might want
>> to cross-post to comp.arch.fpga or sci.electronics.design (.basic).
>> There were no protest to post here, as stated I think it is fine, but
>> you might get a better response from some of the other news/irc groups
>> in addition.
>
> Well, this is still seems (to me) to be more about myHDL than anything else.  As a newbie, I want to make maximal use of published myHDL sample code before I start writing anything of my own.  I want to know what really good myHDL code should look like (content and style), and how all instances of the test and development processes should proceed.  So I'm beating on this DAC for multiple reasons!
>

This particular conversation is mostly about d-s basics.  Don't mean to 
discourage conversation here, just want to set expectations.

> Next, I'll want to wrap good VHDL and Verilog code within myHDL, and eventually translate it to pure myHDL.  Only as a last resort will I want to do my own design on this first project!  My FPGA board should arrive fairly soon, and I hope to not just have a demo binary ready to go, but one that has been tested well enough to present no surprises when loaded into the FPGA.
>
> Despite not being a much of a circuit designer, I see things in the referenced code that don't look quite right.  I'm not sure if it is due to a poor circuit design, a poor test harness, my own limited knowledge of myHDL and circuit design, or a combination of all of them.  Hence the use of this forum.
>
> For the specific case of an all-digital ADC and DAC (the gateway to my audio effects processor), if my learning curve permits I hope to also cosimulate the RC output and input networks using myHDL with Spice.  So the 'real' test could be in the analog domain, where an audio signal is supplied to the ADC and compared to the DAC output.  It's about more than just a specific circuit or project: My true goal is to put the myHDL development and test environment through its paces in every way I can.
>
> I expect to pursue my digital design education at a fairly lazy rate, driven by the problems I want to solve and the projects I want to build, rather than a textbook or a class.  But I will want to do it *all* within the myHDL environment, which is why I plan to collect my notes and eventually write a "FPGA Projects in myHDL" tutorial, based on a progression of non-trivial but easily understood and useful examples that are well-designed, well-written, and obsessively tested (simulation, cosimulation, circuit test with and without a synthesized test bench, etc.).
>
> That's a primary reason why I chose an audio effects processor:  Once the ADC and DAC are in place, much of the rest is just creating relatively simple audio processing modules.  Due to the slow data rate (KHz, not MHz), the design can easily be evolved to use single module instances with multiple audio streams (time domain switching), perform multi-track mixing, and change the module order (crossbar switching).  I also expect it to consume a relatively small portion of the FPGA, leaving adequate room to integrate a processor core and proceeding to an entire SoC (perhaps with a Wishbone interface).  I have no idea how I will test a processor core within the myHDL environment, but I can't wait to figure it out!
>

> In other areas of study, the tutorials that have been the most useful to me were written by recent beginners, and edited by gurus.  Plus, I learn best by teaching:  Writing a thorough introductory tutorial is a great way to master the basics of any field of endeavor.  I'll be pushing the members of this forum to help me create examples of myHDL code (and a library of polished projects) we'll all be proud to share with the world.
>
> If I visit the other forums you recommend, I'm afraid they'll ask me to speak VHDL or Verilog or SystemC or something...  Or, worse, ask for an ASCII-art schematic.   ;^)  But I will start monitoring them.

Again, just depends on the feedback you want.  You will get good 
feedback here for all things MyHDL and good feedback for other design 
domains.  Some topics, such as d-s design and theory, cross posting 
might be useful.  You can separate the design/functionality questions 
from the language implementation.  The suggestion wasn't to indicate to 
get MyHDL information from somewhere else, but the others forums might 
help with d-s or other general issues.

Good luck with the endeavor.

Regards,
Chris

>
> Thanks,
>
> -BobC
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1