Shop Learn P1 Docs P2 Docs
ADC Sampling Breakthrough - Page 20 — Parallax Forums

ADC Sampling Breakthrough

1171820222352

Comments

  • Seairth,
    It was not a personal attack, just stating the facts of what anyone can see here in the P2 forums. Phil constantly posting for Chip to stop doing what he wants to do.
    I like Phil, and he has contributed a great deal over the years to Parallax and the forums, but he just seems to be nothing but negative in this P2 sub forum. I don't understand why he does it over and over. It's not healthy to always be so negative.

    I want the P2 to get done also, but I also want Chip to make what he wants and be happy/satisfied with it. That will be the P2 chip that we all love to use. I know Chip would regret not making the changes he felt he could in the time he feels is available.

    Also, I am not one that subscribes to the idea that all opinions are welcome, sorry, but constant negatives are not welcome. It's different from just having a differing opinion about how and what get done, it's about being negative towards the whole process. Phil has said several times he'd rather have Chip go off alone, not listening to any of us, and make the P2. He views this whole open process as a bad thing that should not have been done.
  • Roy, Phil's concerns relate to Parallax's business and future. He wants to see the company and employees succeed and is looking at the P2 from the perspective of value-engineering and diminishing returns. Parallax also has business with Phil, and his success depends on ours to some extent.

    I'm sure Chip will be happy with the outcome no matter what people ask him to do. Nobody has ever forced Chip successfully to do anything other than what he wants to do. It has not happened in our history.

    Ken Gracey
  • Roy,

    I think Phil is just expressing the frustration that many of us have had waiting for the P2 over the past several years. I have made comments similar to Phil's many times in the past. At this point I don't think Chip is in the critical path as far as the schedule is concerned. The P2 development board should be in the hands of dozens of users within a couple of weeks. I'm looking forward to trying out lots of things on the P2. However, I would be disappointed if I don't get the board by Christmas.

    Phil, maybe you are concerned that Chip isn't focusing on Spin for the P2. I would suggest using Eric's fastspin compiler. It has some of the new features that have been proposed for Spin2, and it should run pretty fast on the P2.
  • evanhevanh Posts: 13,851
    edited 2018-11-28 02:37
    cgracey wrote: »
    evanh wrote: »
    cgracey wrote: »
    And, no chip has ever been designed this way before, because of the secretive nature of the semiconductor industry.

    Heater might raise the RISC-V about now. Although, that isn't a collective effort for one implementation - It's just a collection for pillaging. Like BSD was before Linux brought GPL into the mix.

    Please explain more. I want to understand.

    By "a collection for pillaging" I mean same as what we're doing with Sinc. We've discovered it's a useful addition for the Propeller to have. So we cherry pick just what we want from a much larger mathematical heritage. One function from a bigger library.

    BSD was functional in the 1980's but no-one treated it as a finished product. It was always just picked over for useful methods and tools to add to other products.

  • Guys,

    I really do want the P2 to succeed -- but not at the expense of Parallax's other business, which seems to be where things are headed with these interminable delays and sidetracks. There's a cost to be reckoned with, and I don't think Chip is cognizant of that. Family-wage jobs and Parallax's financial survival are at stake here, while Chip fiddles away at one self-indulgent diversion after another. So even though I don't see the P2 in any future implementations of my own, its success is vitally important to Parallax's continued viability with the P1 and their other products, and hence to me.

    So I shall continue to hammer on the theme that I've established from the beginning: that the P2 should be a result of Chip's singular vision -- as was the P1 -- and that it needs to get FINISHED, even if that entails compromise. Remember, "Perfect is the enemy of good enough." And after nearly 13 years in development, good enough will have to suffice, or there never will be a P2; and the very survival of Parallax -- the company we all love -- will be challenged as never before.

    -Phil
  • jmg wrote: »
    rogloh wrote: »
    A 4 channel "scope" does sound pretty cool and even if the analog bandwidth is limited to several MHz I can imagine it could come in very handy for audio and for other signal processing.
    Yes, and of course there is the 250Mhz streamer in there for the Logic Analyzer capture of digital signals too.

    Also in there I think, is a threshold adjustable by DAC, but I've not seen the speed spec testing results on that yet, or the range ?

    Yes, it turns out this is a separate DAC, slower and presumably higher impedance than the others.

    I missed/forgot about it when testing the other DACs, so we'll come back to it. There is a way to expose the threshold voltage through adjacent pin B that we'll take advantage of, then run the same GIO/ramp up/VIO/ramp down/GIO sequence that we did for the other DACs

  • evanhevanh Posts: 13,851
    edited 2018-11-28 02:48
    TonyB_ wrote: »
    Evan, do you have a simulated bitstream that you could input into Sinc3? If so, could you try acc1/2/3=30/27/24-bit?

    I've got a basic auto-generating ramp setup from earlier work.

    First attempt:
    - Reset every 256 clocks, with 4 sub-samples, is matching the old output perfectly.
    - Pure rolling window has some sort of roll-over problem going negative ... at 8th sample - clock 2000ish.

  • Roy ElthamRoy Eltham Posts: 2,995
    edited 2018-11-28 02:57
    Phil,
    The P2 is not and has never been Chip's single vision. He has collaborated with others continuously over the 13 years. It's the path that Chip & Ken chose for the P2 to be open in its development. You disagree with that, you have said so many times. I'm sorry, but I don't think it's going to change.

    I get all the other stuff, and I worry about them also, but I don't tell Chip and Ken how to run their development. They wouldn't and shouldn't listen to me on that. I also know Ken and his team have made changes and are succeeding and I believe they will continue to do so. The P2 is closer to done than it's ever been, and they are on the path to its completion WITH the collaboration and Chip working on what he feels is important.

    I'm just tired of hearing "stop doing what you want to be doing and feel is important, and instead do what I say" coming from you for the last decade.
  • Ken,
    I share the worry about Parallax with Phil, but I trust that you have been running things and keeping things going.

    Honestly, I am more concerned about the things impacting your business besides the P2, like the tariff Smile raising costs, and the impending economic disasters we all face in the near future (from many fronts).
  • jmgjmg Posts: 14,980
    Tubular wrote: »
    jmg wrote: »
    rogloh wrote: »
    A 4 channel "scope" does sound pretty cool and even if the analog bandwidth is limited to several MHz I can imagine it could come in very handy for audio and for other signal processing.
    Yes, and of course there is the 250Mhz streamer in there for the Logic Analyzer capture of digital signals too.

    Also in there I think, is a threshold adjustable by DAC, but I've not seen the speed spec testing results on that yet, or the range ?

    Yes, it turns out this is a separate DAC, slower and presumably higher impedance than the others.

    I missed/forgot about it when testing the other DACs, so we'll come back to it. There is a way to expose the threshold voltage through adjacent pin B that we'll take advantage of, then run the same GIO/ramp up/VIO/ramp down/GIO sequence that we did for the other DACs

    Those tests would all be useful additions to the DAC test portfolio, but I was meaning more the speed of the digital pathway, and the common mode range of the comparator used with the DAC
    I doubt that will manage to follow a 100+MHz signal ?
    You could test the narrow pulse operation, by generate of a PWM on one pin, and Threshold-path capture on another, and vary duty down to 1 sysclk.
    A capture of 2 pin paths, one straight std digital, and one via threshold-compare could also show the propagation delays ?
  • Roy,

    I've had my say. Feedback from you and other forumistas is always welcome. We share the same objectives -- the ultimate success of Parallax -- but perhaps not the same methods. And I respect that.

    -Phil
  • jmgjmg Posts: 14,980
    evanh wrote: »
    TonyB_ wrote: »
    Evan, do you have a simulated bitstream that you could input into Sinc3? If so, could you try acc1/2/3=30/27/24-bit?

    I've got a basic auto-generating ramp setup from earlier work.

    First attempt:
    - Reset every 256 clocks, with 4 sub-samples, is matching the old output perfectly.
    - Pure rolling window has some sort of roll-over problem going negative ... at 8th sample - clock 2000ish.

    If you restore the pruned bits, does that roll-over problem go away ? Is there any pruned-count solution, or do all accs need to be 30 bits ?
  • Cluso99Cluso99 Posts: 18,063
    My concern is also for Parallax, not my own interests.

    The current P2 silicon (alpha if you like) is here. It works but has some minor flaws.

    What concerns me is that the digression from just fixing what needs to be fixed is being derailed by some keen to see the chip go in different directions, and add in many new features. They are not fixes nor minor tweeks!

    There is a limited time frame here. And that time is not being spent on the things that matter!

    If it were not for the signed bug, and the power issue, I would be saying keep the P2 as-is.

    Everyone is entitled to state their position without fear. Whether it's taken is for Chip & Ken to decide.
  • evanhevanh Posts: 13,851
    edited 2018-11-28 03:18
    Here's the plot. It should be two cycles of a 50000 ramp.

    EDIT: And the code for each variant:
    	case 23:// Sinc3 algorithm, with pruning
    		if( reset & 1 )  acc1 = acc2 = acc3 = diff1 = diff2 = diff3 = 0;
    
    		indexSV = bitindex + chunklen;
    		do {
    			acc3 = (acc3 + acc2) & ACC3MASK;
    			acc2 = (acc2 + acc1) & ACC2MASK;
    
    			bits = bitstream[bitindex >> SIZEEXP];
    			if( (bits >> (bitindex & SIZEMASK)) & 1 )  // C bitfield extraction
    			{
    				acc1 = (acc1 + 1) & ACC1MASK;
    			}
    			bitindex++;
    
    		} while( bitindex < indexSV );
    
    		reading = acc3 - diff1 - diff2 - diff3;
    
    		diff3 = (acc3 - diff1 - diff2) & DIF3MASK;
    		diff2 = (acc3 - diff1) & DIF2MASK;
    		diff1 = acc3 & DIF1MASK;
    		break;
    
    
    	case 33:// Sinc3 algorithm, with pruning, alternate truncation
    		if( reset & 1 )  acc1 = acc2 = acc3 = diff1 = diff2 = diff3 = 0;
    
    		indexSV = bitindex + chunklen;
    		do {
    			acc3 = (acc3 + acc2) & ACC3MASK;
    			acc2 = (acc2 + acc1) & ACC2MASK;
    
    			bits = bitstream[bitindex >> SIZEEXP];
    			if( (bits >> (bitindex & SIZEMASK)) & 1 )  // C bitfield extraction
    			{
    				acc1 = (acc1 + 1) & ACC1MASK;
    			}
    			bitindex++;
    
    		} while( bitindex < indexSV );
    
    		reading = acc3 - diff1 - diff2 - diff3;
    
    		diff3 = (acc3 - diff1 - diff2) & ACC3MASK;
    		diff2 = (acc3 - diff1) & ACC3MASK;
    		diff1 = acc3 & ACC3MASK;
    		break;
    
    

    EDIT2: The truncation masking:
    // register masking for pruning
    #define  ACC1SIZE  30
    #define  ACC1MASK  ((1 << ACC1SIZE      ) - 1)
    #define  ACC2MASK  ((1 << (ACC1SIZE - 3)) - 1)
    #define  ACC3MASK  ((1 << (ACC1SIZE - 6)) - 1)
    #define  DIF1MASK  ((1 << (ACC1SIZE - 7)) - 1)
    #define  DIF2MASK  ((1 << (ACC1SIZE - 8)) - 1)
    #define  DIF3MASK  ((1 << (ACC1SIZE - 9)) - 1)
    
    2416 x 1221 - 108K
  • evanhevanh Posts: 13,851
    edited 2018-11-28 03:28
    Ah, got the alternate working by truncating the final reading too. So, this variant is all 24-bit from Acc3 onwards.

  • TonyB_TonyB_ Posts: 2,002
    edited 2018-11-28 03:29
    evanh wrote: »
    // register masking for pruning
    #define  ACC1SIZE  30
    #define  ACC1MASK  ((1 << ACC1SIZE      ) - 1)
    #define  ACC2MASK  ((1 << (ACC1SIZE - 3)) - 1)
    #define  ACC3MASK  ((1 << (ACC1SIZE - 6)) - 1)
    #define  DIF1MASK  ((1 << (ACC1SIZE - 7)) - 1)
    #define  DIF2MASK  ((1 << (ACC1SIZE - 8 )) - 1)
    #define  DIF3MASK  ((1 << (ACC1SIZE - 9)) - 1)
    

    Evan, I think you're pruning the MSB's, which is wrong. The LSB's are pruned. Also you don't actually need DIFxMASK as pruning the differentiators saves no logic.
  • Cluso, I am of the same opinion that Parallax should just be fixing bugs in the P2, and not adding other features. I I
    I'm concerned that additional bugs will be introduced, and Parallax will have to do a third round of silicon to fix the new bugs. Time will tell.
  • evanhevanh Posts: 13,851
    TonyB_ wrote: »
    evanh wrote: »
    // register masking for pruning
    #define  ACC1SIZE  30
    #define  ACC1MASK  ((1 << ACC1SIZE      ) - 1)
    #define  ACC2MASK  ((1 << (ACC1SIZE - 3)) - 1)
    #define  ACC3MASK  ((1 << (ACC1SIZE - 6)) - 1)
    #define  DIF1MASK  ((1 << (ACC1SIZE - 7)) - 1)
    #define  DIF2MASK  ((1 << (ACC1SIZE - 8 )) - 1)
    #define  DIF3MASK  ((1 << (ACC1SIZE - 9)) - 1)
    

    Evan, I think you're pruning the MSB's, which is wrong. The LSB's are pruned. Also you don't actually need DIFxMASK as pruning the differentiators saves no logic.

    Ah, I shouldn't have called that pruning or truncating. It's defining the register size to emulate.

  • TonyB_TonyB_ Posts: 2,002
    edited 2018-11-28 15:23
    evanh wrote: »
    TonyB_ wrote: »
    evanh wrote: »
    // register masking for pruning
    #define  ACC1SIZE  30
    #define  ACC1MASK  ((1 << ACC1SIZE      ) - 1)
    #define  ACC2MASK  ((1 << (ACC1SIZE - 3)) - 1)
    #define  ACC3MASK  ((1 << (ACC1SIZE - 6)) - 1)
    #define  DIF1MASK  ((1 << (ACC1SIZE - 7)) - 1)
    #define  DIF2MASK  ((1 << (ACC1SIZE - 8 )) - 1)
    #define  DIF3MASK  ((1 << (ACC1SIZE - 9)) - 1)
    

    Evan, I think you're pruning the MSB's, which is wrong. The LSB's are pruned. Also you don't actually need DIFxMASK as pruning the differentiators saves no logic.

    Ah, I shouldn't have called that pruning or truncating. It's defining the register size to emulate.

    Right, but it's working? If so, that's excellent.

    If you're interested in precise pruning, take a look at
    https://www.so-logic.net/documents/trainings/03_so_implementation_of_filters.pdf
    and search for: Pruning LSBs

    Pruning the differentiators/combs is a waste of time, literally. I wonder if we could prune acc2 and acc3 a bit more. The basic concept is that the cumulative errors from pruning should be no more than the truncation error without pruning. If we don't prune the combs, we might be able to have bigger errors and hence bigger pruning for the acc's.

    I think acc1 should be 30+1 bits wide, but we can prune it by 1 bit so 30-bit is OK.
  • cgraceycgracey Posts: 13,873
    evanh wrote: »
    TonyB_ wrote: »
    evanh wrote: »
    // register masking for pruning
    #define  ACC1SIZE  30
    #define  ACC1MASK  ((1 << ACC1SIZE      ) - 1)
    #define  ACC2MASK  ((1 << (ACC1SIZE - 3)) - 1)
    #define  ACC3MASK  ((1 << (ACC1SIZE - 6)) - 1)
    #define  DIF1MASK  ((1 << (ACC1SIZE - 7)) - 1)
    #define  DIF2MASK  ((1 << (ACC1SIZE - 8 )) - 1)
    #define  DIF3MASK  ((1 << (ACC1SIZE - 9)) - 1)
    

    Evan, I think you're pruning the MSB's, which is wrong. The LSB's are pruned. Also you don't actually need DIFxMASK as pruning the differentiators saves no logic.

    Ah, I shouldn't have called that pruning or truncating. It's defining the register size to emulate.

    This pruning is slightly lossy, right?
  • Cluso99Cluso99 Posts: 18,063
    Dave Hein wrote: »
    Cluso, I am of the same opinion that Parallax should just be fixing bugs in the P2, and not adding other features. I I
    I'm concerned that additional bugs will be introduced, and Parallax will have to do a third round of silicon to fix the new bugs. Time will tell.

    And can Parallax afford a third round of silicon???
  • evanhevanh Posts: 13,851
    edited 2018-11-28 04:19
    Got it! Both variants are doing exactly same ramp. Point for point.

    I've taken on board Tony's suggestion about moving everything up to the top of the native variables too, in this case C datatype uint32_t. So, for each bit in the bitstream, I'm adding four to Acc1 and masking off the bottom two lsbits instead of adding one and masking off the two msbits. Same story for the remaining register emulation.

    So that probably means I had a register alignment problem before. As he said, the msbit is what lines up down the stages.

    EDIT: Here's latest source code:
    	case 23:// Sinc3 algorithm, with pruning
    		if( reset & 1 )  acc1 = acc2 = acc3 = diff1 = diff2 = diff3 = 0;
    
    		indexSV = bitindex + chunklen;
    		do {
    			acc3 = (acc3 + acc2) & ACC3MASK;
    			acc2 = (acc2 + acc1) & ACC2MASK;
    
    			bits = bitstream[bitindex >> SIZEEXP];
    			if( (bits >> (bitindex & SIZEMASK)) & 1 )  // C bitfield extraction
    			{
    				acc1 = (acc1 + (1 << (WORDSIZE - ACC1SIZE))) & ACC1MASK;
    			}
    			bitindex++;
    
    		} while( bitindex < indexSV );
    
    		reading = acc3 - diff1 - diff2 - diff3;
    
    		diff3 = (acc3 - diff1 - diff2) & DIF3MASK;
    		diff2 = (acc3 - diff1) & DIF2MASK;
    		diff1 = acc3 & DIF1MASK;
    		break;
    
    
    // word size exponent, taper length exponent
    #define  SIZEEXP   5
    #define  WORDSIZE  (1 << SIZEEXP)
    #define  SIZEMASK  (WORDSIZE - 1)
    
    // register emulation masking
    #define  ACC1SIZE  30
    #define  ACC1MASK  (~((1 << (WORDSIZE - ACC1SIZE)) - 1))
    #define  ACC2MASK  (~((1 << (WORDSIZE + 3 - ACC1SIZE)) - 1))
    #define  ACC3MASK  (~((1 << (WORDSIZE + 6 - ACC1SIZE)) - 1))
    #define  DIF1MASK  (~((1 << (WORDSIZE + 7 - ACC1SIZE)) - 1))
    #define  DIF2MASK  (~((1 << (WORDSIZE + 8 - ACC1SIZE)) - 1))
    #define  DIF3MASK  (~((1 << (WORDSIZE + 9 - ACC1SIZE)) - 1))
    
  • cgraceycgracey Posts: 13,873
    evanh wrote: »
    Got it! Both variants are doing exactly same ramp. Point for point.

    I've taken on board Tony's suggestion about moving everything up to the top of the native variables too, in this case C datatype uint32_t. So, for each bit in the bitstream, I'm adding four to Acc1 and masking off the bottom two lsbits instead of adding one and masking off the two msbits. Same story for the remaining register emulation.

    So that probably means I had a register alignment problem before. As he said, the msbit is what lines up down the stages.

    Will all this work for non-power-of-2 sample counts?
  • evanh wrote: »
    Got it! Both variants are doing exactly same ramp. Point for point.

    So both pruning variants are exactly the same as no pruning?

  • evanhevanh Posts: 13,851
    cgracey wrote: »
    This pruning is slightly lossy, right?

    It has lost a little resolution. The slow starting ramp up of that 50000 clocks now has a flat three samples then a one sample over reaction before settling.
  • evanh wrote: »
    cgracey wrote: »
    This pruning is slightly lossy, right?

    It has lost a little resolution. The slow starting ramp up of that 50000 clocks now has a flat three samples then a one sample over reaction before settling.

    I think you're still pruning the diff's. If so, please don't as there is no need.

    How many errors in the two 50000 cycles? Just the LSB? Try rounding.
  • evanhevanh Posts: 13,851
    edited 2018-11-28 04:59
    TonyB_ wrote: »
    I think you're still pruning the diff's. If so, please don't as there is no need.

    Done, no difference at all that I could see. :(

    Here's a graph with all three:
    - Yellow is my older method using all 32-bit
    - Blue is the tightest with diff masking
    - Red has no diff masking
    4832 x 2442 - 63K
  • TonyB_ wrote: »
    It's not my idea. I've been doing some reading and this is called Integrate and Dump. It could be used elsewhere in the smart pins, probably. In the differentiator diff1 stores the previous value of acc3, but if acc3 is reset after being read then diff1 is redundant.
    I like this idea. In typical operation we would just be calculating the difference anyway. This saves an instruction or two.

    The proposed Tukey window is better than a sinc3 length 8, mostly because the inpulse response is longer. Comparing it to a length 16 sinc3 it's mixed.
    Top line=Tukey   full scale = 1023 , truncate 2 lsb (/4)
    Middle line=Sinc^3 8  full scale =512, truncate 1 lsb (/2)
    Bottom line=Sinc^3 16 full scale = 4096, truncate 4 lsb (/16)
    Mean Value (channels 1-8 gio) , (channels 1-8 vio)
        45.367    48.506    44.407    45.596    43.596    43.394    48.906    46.799   212.372   214.971   214.590   214.560   211.250   212.677   215.867   215.058
        45.468    48.796    44.694    45.739    43.672    43.452    49.247    47.111   212.613   215.312   214.924   214.897   211.585   212.879   216.276   215.406
        45.236    48.339    44.605    45.468    43.485    43.265    48.929    46.685   212.550   215.054   214.720   214.702   211.387   212.827   215.931   215.120
    Standard Deviation (channels 1-8 gio) , (channels 1-8 vio)
       0.55194   0.51324   0.55921   0.50285   0.53237   0.61839   0.35290   0.47419   0.72835   0.40526   0.52742   0.53002   0.49377   0.54610   0.40421   0.31277
       1.56901   1.88077   1.74451   1.51102   1.77894   1.71822   1.88983   1.51053   1.35328   1.56201   1.64810   1.65715   1.73280   1.35994   1.06898   1.49403
       0.43681   0.51541   0.50886   0.50528   0.56974   0.69142   0.70789   0.49365   0.71113   0.53671   0.47227   0.50249   0.53767   0.51045   0.38889   0.42351
    

    For the Tukey, the max could be anywhere from 1020-1023. It doesn't have to be 1023.

    The cutoff frequency seems just a little low for analog video. Although I wonder what the response is on the analog part of the chip.
    1200 x 900 - 38K
    1200 x 900 - 29K
  • evanhevanh Posts: 13,851
    Source code for Red line: The bit shift on "reading" is just to scale it down to same as original. I've now done the same for case 23 too.
    	case 33:// Sinc3 algorithm, with pruning, with 32-bit software diff'ing
    		if( reset & 1 )  acc1 = acc2 = acc3 = diff1 = diff2 = diff3 = 0;
    
    		indexSV = bitindex + chunklen;
    		do {
    			acc3 = (acc3 + acc2) & ACC3MASK;
    			acc2 = (acc2 + acc1) & ACC2MASK;
    
    			bits = bitstream[bitindex >> SIZEEXP];
    			if( (bits >> (bitindex & SIZEMASK)) & 1 )  // C bitfield extraction
    			{
    				acc1 = (acc1 + (1 << (WORDSIZE - ACC1SIZE))) & ACC1MASK;
    			}
    			bitindex++;
    
    		} while( bitindex < indexSV );
    
    		reading = (acc3 - diff1 - diff2 - diff3) >> (WORDSIZE - ACC1SIZE);
    
    		diff3 = acc3 - diff1 - diff2;
    		diff2 = acc3 - diff1;
    		diff1 = acc3;
    		break;
    
    
  • evanhevanh Posts: 13,851
    edited 2018-11-28 05:20
    cgracey wrote: »
    Will all this work for non-power-of-2 sample counts?

    No problem at all. In my source there, the "chunklen" is the clocks per sample. EDIT: Amusingly it should even work for sub-word bit positions in the bitstream. Not something I explicitly tried to make work.

Sign In or Register to comment.