I cannot get the following code to produce the correct results of a subtraction and I'm not sure what is wrong with it. Current is an input from an ADC that is in two's complement form. The clk is the same for both the ADC so that I should be clocking in a new sample at the same rate of the ADC sampling.
The only thing I can think of is that I need to register in current as well, although I think that syncing the process to the clock would give the same effect. Also, maybe converting the std_logic_vector type of current and prev_current to signed signals is not working correctly. This is my first time doing this so if this is the wrong approach I would appreciate any criticism/critique.
Code:
prev_current_reg: process(clk) begin
if(rising_edge(clk)) then
prev_current <= current;
prev_di_dt <= curr_di_dt;
end if;
end process;
current_i <= signed(current);
prev_current_i <= signed(prev_current);
di_dt_calc: process(clk) begin
if(rising_edge(clk)) then
curr_di_dt <= current_i - prev_current_i;
end if;
end process;
The subtraction is not giving me the correct result when I'm looking in the signal tap results. For example, it lists current at 18, prev_current at 37 and the subtraction result of 4. This is incorrect. Basically I'm trying to write some code to find some extremes and currently this is toggling the there is an extreme pin all the time because the subtraction results are wacky.
Added after 8 minutes:
It seems that the ADC rate is changing so fast that trying to sync the data with all the processes at a rising clock edge doesn't work.
Well not working as I thought it was. I still believe it has something to do with values changing while in the process.
Hi,
Make sure it is not an issue with signed unsigned math conversions. I have run into
problems with this. For instance if you had 5 bit unsigned vector 01111 (15) and converted it to signed it would still be 01111 (15). If it was 4 bit 1111 then it would become -1.
It ended up being the clock issue. I had the wrong clock connected to the component. Instead of using the clock coming back from the ADC I was using the clock going to the ADC. So, I was getting wrong values registered in. Anyways, put in a register on the input and now everything works fine from 400 KHz up. Still need to think of an algorithm to help me sense false min/max though. I'm thinking of possible using a threshold value but not sure if it will work.
Yea that works but I was looking for something that would know in real time, not at the end of the half period. It seems to me at least, that the range at 100kHz provides such a small slope change that being able to distinguish the actual peak value is impossible without relating it the zero crossings.
For example, I see the max value 8 cycles before it should occur and then again when it should occur after those 8 cycles and again 6 cycles after. If I take the last time value I'm off by 65MHZ^-1*6 which is around 1kHz. Averaging gets me to about 500 Hz. Is that the realistic precision I'm going to be limited to?
Well more or less I can figure out the zero crossings without any false crossings. This means if the waveform changed frequency I would only find out on the zero crossings which at 100KHz could be roughly 5 us. Now, I'm trying to figure out if I can figure out a change in half that time or 2.5 us by checking every quarter period instead of half period. This would require me to have a somewhat fast response time in finding out the min/max.