ADC Sampling Breakthrough

1235752

Comments

  • jmgjmg Posts: 14,495
    potatohead wrote: »
    Very worst case scenario is we find some edge or corner case somewhere, someday, and it somehow doesn't perform well enough. In that rare case, another component is added, or someone makes a ADC out of some of the pins, done, next.

    Err, hopefully, they simply just disable the optional filter !! No PCB mods or product revisions required,


  • jmgjmg Posts: 14,495
    cgracey wrote: »
    The sad part is that the windowing needs to occur on the original bitstream. Once you have a composite sample, it's too late.

    Of course, a single bit can disable the windowing, quite simply.
  • cgraceycgracey Posts: 13,079
    edited 2018-11-21 - 06:58:32
    TonyB_, amazingly, rounding screws things up. You DON'T want to round because if the sub-bits didn't add up to the one's threshold, that's as it should be. All you do is throw away the bottom bits.
  • jmgjmg Posts: 14,495
    cgracey wrote: »
    TonyB_, amazingly, rounding screws things up. You DON'T want to round because if the sub-bits didn't add up to the one's threshold, that's as it should be. All you do is throw away the bottom bits.

    I thought TonyB_ meant rounding when doing the shift right ? /32
  • jmg wrote: »
    cgracey wrote: »
    TonyB_, amazingly, rounding screws things up. You DON'T want to round because if the sub-bits didn't add up to the one's threshold, that's as it should be. All you do is throw away the bottom bits.

    I thought TonyB_ meant rounding when doing the shift right ? /32

    Yes. He did.

    I'm making some tables of what happens with a pure ramp (trapezoid) and there's lots of error. The cosine-shaped ramp-up/down is much better. This is going to improve things a lot.
  • jmg wrote: »
    cgracey wrote: »
    The sad part is that the windowing needs to occur on the original bitstream. Once you have a composite sample, it's too late.

    Of course, a single bit can disable the windowing, quite simply.

    Yes, this will be a special sub-mode, in addition to the ones we already have. Nobody has to use it.
  • cgraceycgracey Posts: 13,079
    edited 2018-11-21 - 08:03:16
    This demonstrates the problem with straight sampling:
    NORMAL SAMPLING (just count highs)
    
    bitstream 6:1	00000010000001
    		||||||||||||||
    offset 6	||||||11111111	= 2 Inconsistent!!!
    offset 5	|||||11111111|	= 1
    offset 4	||||11111111||	= 1
    offset 3	|||11111111|||	= 1
    offset 2	||11111111||||	= 1
    offset 1	|11111111|||||	= 1
    offset 0	11111111||||||	= 1
    


    Here is trapezoidal windowed sampling:
    WINDOWED SAMPLING (count highs with upward/stable/downward values)
    
    bitstream 6:1	000000100000010000001000000100
    		||||||||||||||||||||||||||||||
    offset 6	||||||123456788888888887654321	= 20 = %10100
    offset 5	|||||123456788888888887654321|	= 20 = %10100
    offset 4	||||123456788888888887654321||	= 20 = %10100
    offset 3	|||123456788888888887654321|||	= 19 = %10011
    offset 2	||123456788888888887654321||||	= 19 = %10011
    offset 1	|123456788888888887654321|||||	= 19 = %10011
    offset 0	123456788888888887654321||||||	= 19 = %10011
    
    
    bitstream 5:2	000001100000110000011000001100
    		||||||||||||||||||||||||||||||
    offset 6	||||||123456788888888887654321	= 39 = %100111
    offset 5	|||||123456788888888887654321|	= 40 = %101000
    offset 4	||||123456788888888887654321||	= 40 = %101000
    offset 3	|||123456788888888887654321|||	= 39 = %100111
    offset 2	||123456788888888887654321||||	= 38 = %100110
    offset 1	|123456788888888887654321|||||	= 38 = %100110
    offset 0	123456788888888887654321||||||	= 38 = %100110
    
    bitstream 4:3	000011100001110000111000011100
    		||||||||||||||||||||||||||||||
    offset 6	||||||123456788888888887654321	= 58 = %100111, >>3 = %10
    offset 5	|||||123456788888888887654321|	= 57 = %101000, >>3 = %10	57 vs 68 is a huge error!
    offset 4	||||123456788888888887654321||	= 60 = %101000, >>3 = %10	(reveals trapezoid weakness)
    offset 3	|||123456788888888887654321|||	= 67 = %100111, >>3 = %10
    offset 2	||123456788888888887654321||||	= 68 = %100110, >>3 = %10
    offset 1	|123456788888888887654321|||||	= 57 = %100110, >>3 = %10
    offset 0	123456788888888887654321||||||	= 57 = %100110, >>3 = %10
    

    I'm making a table next using TonyB_'s cosine pattern...
  • cgraceycgracey Posts: 13,079
    edited 2018-11-21 - 08:15:46
    TonyB_ wrote: »
    As the current trapezoidal window has a discontinuous derivative, I've been looking at other, smoother windows, in particular the cosine taper/tapered cosine/Tukey window, which is a combination of Hann and rectangular windows: https://en.m.wikipedia.org/wiki/Window_function

    I think we should try to use a well-known and proven window, rather than invent our own. I've implemented a Tukey window with 32 steps up and down that vary from 0-3, giving a maximum value of 64, not 32 as now.

    The table below shows the accumulator values:
    Trap.:  2, 4, 6, 8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52,54,56,58,60,62,64
    Tukey:  0, 0, 1, 2, 3, 5, 7, 9,11,13,16,19,22,25,28,31,34,37,40,43,46,49,52,54,56,58,60,62,63,64,64,64
    

    The next table shows the accumulator increments:
    Trap., 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2
    Tukey, 0, 0, 1, 1, 1, 2, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 1, 1, 0, 0
    

    It takes very little logic to create these increments from the outputs of a 5-bit counter.

    Chip (or anyone else), would you like to try the Tukey window to see if the quality improves? A 6-bit right shift will be needed at the end. Ideally there should be rounding to get an extra ½ lsb.

    MGFzOcm.png

    Wow! This Tukey curve is supreme!!! And it definitely benefits from rounding.

    Before doing the table exercise, I thought I would just code it and try it. No need to mess with a table. It's obvious this is WAY better than the trapezoid. In fact, the ADC is looking quite PERFECT now. Pictures in a minute...
  • cgraceycgracey Posts: 13,079
    edited 2018-11-21 - 08:27:26
    The auto-ranging mathless ADC conversion technique is now working with the Tukey windowing. It was very dysfunctional when using the trapezoidal windowing.
  • jmgjmg Posts: 14,495
    cgracey wrote: »
    The auto-ranging mathless ADC conversion technique is now working with the Tukey windowing. It was very dysfunctional when using the trapezoidal windowing.

    You could use some of the inbuilt DACs to get plots like the nice TI data, of INL, DNL for the ADCs over a number of pins.
    INL is the difference from an ideal straight line, and DNL is the adjacent step-size comparison.


    eg you could join 4 pins, run 4 triangle sweeps, one from each possible DAC, and plot the deviation from ideal and the spread across the 4 ADCs.
    That does not over all possible ADC values, but it does sweep over the user dynamic range.

    Do you have low noise regulators fitted yet ?
  • cgraceycgracey Posts: 13,079
    edited 2018-11-21 - 08:59:50
    jmg wrote: »
    cgracey wrote: »
    The auto-ranging mathless ADC conversion technique is now working with the Tukey windowing. It was very dysfunctional when using the trapezoidal windowing.

    You could use some of the inbuilt DACs to get plots like the nice TI data, of INL, DNL for the ADCs over a number of pins.
    INL is the difference from an ideal straight line, and DNL is the adjacent step-size comparison.


    eg you could join 4 pins, run 4 triangle sweeps, one from each possible DAC, and plot the deviation from ideal and the spread across the 4 ADCs.
    That does not over all possible ADC values, but it does sweep over the user dynamic range.

    Do you have low noise regulators fitted yet ?

    No low-noise regulator, yet.

    I'm outputting analog values into the ADC via an adjacent pin's DAC in 16-bit random-dither mode. I step the DAC at very fine granularity and then record ADC samples.
  • cgraceycgracey Posts: 13,079
    edited 2018-11-21 - 09:05:26
    Okay. Here are some pictures. These are details of 256-sample conversions (8-bit) with the ADC receiving a finely-stepped rail-to-rail ramp.

    First, a straight accumulator approach (no windowing):
    Direct256.jpg


    Next, TonyB_'s Tukey cosine window operating on the first 32 and last 32 samples:
    Tukey256.jpg


    This seems quite ideal. Now I'll work on some 4096-sample (12-bit) conversions...

    1061 x 849 - 230K
    990 x 779 - 207K
  • ErNaErNa Posts: 1,443
    edited 2018-11-21 - 09:36:13
    Could please someone create a data file with the streamed ADC values that Chip collected? I actually didn't follow, how all this stuff works as I don't understand, what the first post wants me to tell.
    With every clock cycle, the comparator determines, if there is a 0 or 1 and so every clock cycle the counter counts up 0 or 1. The counter readout can not be at clock speed, so the difference between to readouts should be in the range of 0 to number of clocks per readout. (e.g.: 7)
    There will be some noise, so worst case, at constant input voltage, the readout should be 0 to 7. If we average two adjacent values, the result can be 0 -15. The more samples we add, the higher the range is, so noise becomes more.
    But that's an incomplete theory, as noise is distributed and tends to cancel out, so reading over a longer time, the noise floor should decrease. If I read 7 multiple times, it's not noise but a signal.
    So, if there is more noise then expected, it could be systematical or not. In the first case, a filter makes sense, in the second, not. As the filter seems to work better then we could expect from just averaging, it look to be a systematical noise source.
    So: could somebody stream the readout data to a file and upload that file?
  • jmgjmg Posts: 14,495
    cgracey wrote: »
    I'm outputting analog values into the ADC via an adjacent pin's DAC in 16-bit random-dither mode. I step the DAC at very fine granularity and then record ADC samples.

    For these tests it may be best to disable the dithering, at least initially, and compare more than one ADC in the captures ?
    The dispersal of the multiple ADCs all reading exactly the same V, should be a good indicator
  • cgraceycgracey Posts: 13,079
    edited 2018-11-21 - 09:59:44
    Erna, it's not random noise we're fighting, exactly. It's just a need low-pass filter the first 32 bits and the last 32 bits that get accumulated. The problem isn't the noise in the entire bitstream, as that does average out. It's just the initial and terminal samples that want to leave a bad taste in the accumulator's mouth because they are so obstreperous.
  • If this is supposed to have value for audio then hearing would be a good test. If you could record from a line source of a good DAC and some 16-24bit audio and with several ADC methods and play it back that would be informative. Ideally output the data and post/link an mp3 or wav of the a/b for comparison.
  • T Chap wrote: »
    If this is supposed to have value for audio then hearing would be a good test. If you could record from a line source of a good DAC and some 16-24bit audio and with several ADC methods and play it back that would be informative. Ideally output the data and post/link an mp3 or wav of the a/b for comparison.

    Yes, listening is a great way to determine spectral quality and noise. I need to get some audio hookups.
  • T ChapT Chap Posts: 4,035
    edited 2018-11-21 - 10:35:14
    For listening tests It’s best if possible if you can put a switch to toggle immediately back and forth between methods vs listening to one method then stopping and reconfiguring.
  • cgraceycgracey Posts: 13,079
    edited 2018-11-21 - 10:36:17
    TonyB_, this Tukey data you gave me is really 180..0 degrees of a cosine plus 1, right? I was looking at the wiki and that's what I gathered.

    I think you came up with a special rendition that would be easy to generate sequentially, right? The first two values are zero, making it really a 30-step window, but that helped keep the numerics simple, correct?
  • cgraceycgracey Posts: 13,079
    edited 2018-11-21 - 11:26:48
    ...Chip, you seem a bit disappointed with the raw performance of your ADC. But it is what it is. By airbrushing it with a hardware filter to hide its supposed deficiencies, you're not helping everyone who may be using it and are hurting the prospects for some. It will affect not just the noise introduced by the ADC, but also any noise or other high-frequency components generated by the user's analog output, wherever that may come from. I would vote for dropping this whole train of thought to focus on just getting the P2 finished.

    -Phil

    Phil, this initial/terminal-samples windowing doesn't undermine anyone's use of the ADC. It allows the ADC to really do what it's capable of. This problem of incomplete cycles of short delta-sigma patterns appearing at the start and end of measurements cannot be fixed by better analog design. It needs a digital solution. To not implement one when it's so simple would be a shame. And I doubt anybody will even use the ADC without windowing. To do so would just be inviting needless uncertainty into their measurements.
  • cgraceycgracey Posts: 13,079
    edited 2018-11-21 - 12:17:33
    More pictures. These are details of 4096-sample conversions (12-bit) with the ADC receiving a finely-stepped ramp.

    First, the straight accumulator approach (no windowing). The monitor DAC was wrapping vertically because of the noise amplitude:
    Direct4096.jpg


    And next, TonyB_'s Tukey cosine window operating on the first 32 and last 32 samples:
    Tukey4096.jpg


    It looks like the windowing is getting rid of sporadic +1/+2 contributions from the initial and terminal bits samples.

    1039 x 827 - 247K
    1049 x 829 - 215K
  • cgraceycgracey Posts: 13,079
    edited 2018-11-21 - 12:20:10
    Here are some crude cases I worked through to determine the relative efficacy of trapezoidal vs cosine windowing.

    Cosine windowing is clearly better:
    bitstream 4:3	000011100001110000111000011100	trapezoidal-up/down
    		||||||||||||||||||||||||||||||
    offset 6	||||||123456788888888887654321	= 58	max delta = 11
    offset 5	|||||123456788888888887654321|	= 57
    offset 4	||||123456788888888887654321||	= 60
    offset 3	|||123456788888888887654321|||	= 67
    offset 2	||123456788888888887654321||||	= 68
    offset 1	|123456788888888887654321|||||	= 57
    offset 0	123456788888888887654321||||||	= 57
    
    bitstream 4:3	000011100001110000111000011100	cosine-up/down
    		||||||||||||||||||||||||||||||
    offset 6	||||||112467888888888888753211	= 58	max delta = 5
    offset 5	|||||112467888888888888753211|	= 56
    offset 4	||||112467888888888888753211||	= 56
    offset 3	|||112467888888888888753211|||	= 57
    offset 2	||112467888888888888753211||||	= 60
    offset 1	|112467888888888888753211|||||	= 61
    offset 0	112467888888888888753211||||||	= 60
    
  • cgracey wrote: »
    TonyB_, this Tukey data you gave me is really 180..0 degrees of a cosine plus 1, right? I was looking at the wiki and that's what I gathered.

    I think you came up with a special rendition that would be easy to generate sequentially, right? The first two values are zero, making it really a 30-step window, but that helped keep the numerics simple, correct?

    Chip, the Tukey ramps are ((cos -180..cos 0)+1)/2 and ((cos0..cos+180)+1)/2.

    Only 28 steps are needed to get from 1 to 64, so I added two zeroes and two 64's at the start and end to make things symmetrical. I can post the logic for the accumulator increment later today. I'll check first whether having four zeroes reduces the logic, but it may well increase it.

    We can't use the output of a 5-bit counter directly for the Tukey accumulator, obviously. The counter is used to generate the next 2-bit increment to add to a 6-bit accumulator.
  • cgraceycgracey Posts: 13,079
    edited 2018-11-21 - 13:10:13
    TonyB_ wrote: »
    cgracey wrote: »
    TonyB_, this Tukey data you gave me is really 180..0 degrees of a cosine plus 1, right? I was looking at the wiki and that's what I gathered.

    I think you came up with a special rendition that would be easy to generate sequentially, right? The first two values are zero, making it really a 30-step window, but that helped keep the numerics simple, correct?

    Chip, the Tukey ramps are ((cos -180..cos 0)+1)/2 and ((cos0..cos+180)+1)/2.

    Only 28 steps are needed to get from 1 to 64, so I added two zeroes and two 64's at the start and end to make things symmetrical. I can post the logic for the accumulator increment later today. I'll check first whether having four zeroes reduces the logic, but it may well increase it.

    We can't use the output of a 5-bit counter directly for the Tukey accumulator, obviously. The counter is used to generate the next 2-bit increment to add to a 6-bit accumulator.

    Yes, I'm working out the adder values now:
    pos   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
          -----------------------------------------------------------------------------------------------
    up    01 01 01 02 02 02 02 02 03 03 03 03 03 03 03 03 03 03 03 03 03 02 02 02 02 02 01 01 00 00 00 00
    Tukey 00 01 02 03 05 07 09 0B 0D 10 13 16 19 1C 1F 22 25 28 2B 2E 31 34 36 38 3A 3C 3E 3F 40 40 40 40
    dn    00 1F 1F 1F 1E 1E 1E 1E 1E 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1E 1E 1E 1E 1E 1F 1F 00 00 00
    

    'up' works left-to-right.
    'dn' works right-to-left.

    When we are doing the main sample accumulation, we keep using the Tukey value, which will be at 64.

    I'm wondering if it's best to work this windowing into the period set by WXPIN or to use 32+WXPIN+32. Either can be done with about the same logic, I think.
  • TonyB_, if the numbers would work nicely, it would be good to span the values from 1..64 over all 32 steps. We don't need any 0's and we only need one 64.
  • It's possible, TonyB_, that a lookup table might synthesize to be quite small. Maybe no need for counters.
  • TonyB_TonyB_ Posts: 1,524
    edited 2018-11-21 - 13:41:24
    cgracey wrote: »
    TonyB_, if the numbers would work nicely, it would be good to span the values from 1..64 over all 32 steps. We don't need any 0's and we only need one 64.

    Stretching the values to fit would mess up the waveform, probably. What we could do is have 28 steps from 1-64 then four 64s and no zeroes. I'll look into that next.

    So that you have something now, here is the truth table and logic for the symmetrical version with two zeroes and two extra 64s:
    Q4,Q3,Q2,Q1,Q0,,X1,X0
    0,0,0,0,0,,0,0  0=0
    0,0,0,0,1,,0,0  1=0
    0,0,0,1,0,,0,1  2=1
    0,0,0,1,1,,0,1  3=1
    0,0,1,0,0,,0,1  4=1
    0,0,1,0,1,,1,0  5=2
    0,0,1,1,0,,1,0  6=2
    0,0,1,1,1,,1,0  7=2
    0,1,0,0,0,,1,0  8=2
    0,1,0,0,1,,1,0  9=2
    0,1,0,1,0,,1,1 10=3
    0,1,0,1,1,,1,1 11=3
    0,1,1,0,0,,1,1 12=3
    0,1,1,0,1,,1,1 13=3
    0,1,1,1,0,,1,1 14=3
    0,1,1,1,1,,1,1 15=3
    1,0,0,0,0,,1,1 16=3
    1,0,0,0,1,,1,1 17=3
    1,0,0,1,0,,1,1 18=3
    1,0,0,1,1,,1,1 19=3
    1,0,1,0,0,,1,1 20=3
    1,0,1,0,1,,1,1 21=3
    1,0,1,1,0,,1,1 22=3
    1,0,1,1,1,,1,0 23=2
    1,1,0,0,0,,1,0 24=2
    1,1,0,0,1,,1,0 25=2
    1,1,0,1,0,,1,0 26=2
    1,1,0,1,1,,1,0 27=2
    1,1,1,0,0,,0,1 28=1
    1,1,1,0,1,,0,1 29=1
    1,1,1,1,0,,0,0 30=0
    1,1,1,1,1,,0,0 31=0
    
    X[0] =	 Q[4] & !Q[3] & !Q[0] | 
    	 Q[2] & !Q[1] & !Q[0] | 
    	!Q[4] &  Q[3] &  Q[2] |
    	 Q[4] & !Q[3] & !Q[2] |
    	!Q[4] & !Q[2] &  Q[1] |
    	 Q[4] &  Q[2] & !Q[1];
    
    X[1] =	!Q[4] &  Q[3] |
    	 Q[4] & !Q[3] |
    	 Q[3] & !Q[2] |
    	!Q[3] &  Q[2] &  Q[1] |
    	!Q[3] &  Q[2] &  Q[0];
    

    Q[4:0] are the counter output and X[1:0] the increment. I used Logic Friday to create this.
  • TonyB_ wrote: »
    cgracey wrote: »
    TonyB_, if the numbers would work nicely, it would be good to span the values from 1..64 over all 32 steps. We don't need any 0's and we only need one 64.

    Stretching the values to fit would mess up the waveform, probably. What we could do is have 28 steps from 1-64 then four 64s and no zeroes. I'll look into that next.

    So that you have something now, here is the truth table and logic for the symmetrical version with two zeroes and two extra 64s:
    Q4,Q3,Q2,Q1,Q0,,X1,X0
    0,0,0,0,0,,0,0  0=0
    0,0,0,0,1,,0,0  1=0
    0,0,0,1,0,,0,1  2=1
    0,0,0,1,1,,0,1  3=1
    0,0,1,0,0,,0,1  4=1
    0,0,1,0,1,,1,0  5=2
    0,0,1,1,0,,1,0  6=2
    0,0,1,1,1,,1,0  7=2
    0,1,0,0,0,,1,0  8=2
    0,1,0,0,1,,1,0  9=2
    0,1,0,1,0,,1,1 10=3
    0,1,0,1,1,,1,1 11=3
    0,1,1,0,0,,1,1 12=3
    0,1,1,0,1,,1,1 13=3
    0,1,1,1,0,,1,1 14=3
    0,1,1,1,1,,1,1 15=3
    1,0,0,0,0,,1,1 16=3
    1,0,0,0,1,,1,1 17=3
    1,0,0,1,0,,1,1 18=3
    1,0,0,1,1,,1,1 19=3
    1,0,1,0,0,,1,1 20=3
    1,0,1,0,1,,1,1 21=3
    1,0,1,1,0,,1,1 22=3
    1,0,1,1,1,,1,0 23=2
    1,1,0,0,0,,1,0 24=2
    1,1,0,0,1,,1,0 25=2
    1,1,0,1,0,,1,0 26=2
    1,1,0,1,1,,1,0 27=2
    1,1,1,0,0,,0,1 28=1
    1,1,1,0,1,,0,1 29=1
    1,1,1,1,0,,0,0 30=0
    1,1,1,1,1,,0,0 31=0
    
    X[0] =	 Q[4] & !Q[3] & !Q[0] | 
    	 Q[2] & !Q[1] & !Q[0] | 
    	!Q[4] &  Q[3] &  Q[2] |
    	 Q[4] & !Q[3] & !Q[2] |
    	!Q[4] & !Q[2] &  Q[1] |
    	 Q[4] &  Q[2] & !Q[1];
    
    X[1] =	!Q[4] &  Q[3] |
    	 Q[4] & !Q[3] |
    	 Q[3] & !Q[2] |
    	!Q[3] &  Q[2] &  Q[1] |
    	!Q[3] &  Q[2] &  Q[0];
    

    Q[4:0] are the counter output and X[1:0] the increment. I used Logic Friday to create this.

    Wow! That's pretty efficient. I wonder if the ASIC compiler could make such an inference.
  • ErNaErNa Posts: 1,443
    edited 2018-11-21 - 14:32:58
    cgracey wrote: »
    More pictures. These are details of 4096-sample conversions (12-bit) with the ADC receiving a finely-stepped ramp.

    First, the straight accumulator approach (no windowing). The monitor DAC was wrapping vertically because of the noise amplitude:
    Direct4096.jpg
    It looks like the windowing is getting rid of sporadic +1/+2 contributions from the initial and terminal bits samples.
    So, could you tell it a way, I can crasp what I see: The analog input voltage of the input is a staircase function?
    You read out the counter at a given period?
    You substract the last read value from the current value?

    If I didn't know it better, I would think, you look to the future as you start and to the past as you stop reading ;-)

    OK, it's 4096 clocks per sample. At a clock rate of 100 MHz it's about 25 KHz sampling frequency.
    Is this still a slowly ramping analog input voltage? Is the spiked signal always 16 Bits (as if Bit #5 is toggling?)
    What happens if you measure a slightly longer period?
    The spikes are independend of the signal level you start with? What happens if you execute a series of measurement? Is the effect repeated and if you pause between different bursts, is there a minimal pause time to have the effect?
  • TonyB_, have Logic Friday do a lookup table implementation of the whole problem (5 bits in, 7 bits out, stateless). We save 7 flops then.
Sign In or Register to comment.