How to copy an ADC result's range detect status and sign to a datapath's D0 and D1 with DMA?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ChRe_4711096
Level 4
Level 4
50 replies posted 25 replies posted 25 sign-ins

Is it possible to get an SAR ADC result's range detect status and sign into an 8-bit datapath with DMA? It seems that a 32-bit read would be right on the ADC's side, and now I'm trying to figure out how to get only two bytes of the result into the datapath. The range detect status is in byte 3 (bits 31:24) of the result, and the sign is available in byte 1 (15:8).

Could I use an xy loop to achieve this?

X loop 1: copy two bytes (bits 7:0 and 15:8) from result to D0. Increment source address by 1, but don't increment destination address. That copies byte 0 first, and then overwrites it with byte 1. So I'd end up with byte 1, which contains the sign, in D0.

X loop 2: copy two bytes (bits 23:16 and 31:24) from the result to D1 (same as above with different destination base address). The range detect bit would then be available in D1.

The Y loop destination increment would have to be &D1 - &D0.

Would it work that way or would the DMA transfer always drop the 24 MSBs of the ADC result? If so, is there an alternative way?

My current solution copies just the result into a 16-bit datapath that performs the range check and sign extraction, but that results in an overall hard-to-route solution resulting in undesired tradeoffs and setup time violations that I'd like to avoid by using an 8-bit dp only. Other alternatives would require an 8-bit dp to perform 16-bit operations, but those are different questions.

0 Likes
1 Solution
RodolfoGL
Employee
Employee
250 solutions authored 250 sign-ins 5 comments on KBA

You could do a WORD to WORD transfer to 2x 16-bit datapath. You need to place these two datapaths adjacent to each other.

One of them will store the 16-bit ADC result. The other 16-bit will store the two bits.

If you are tight in number of datapaths, then you could place the 32-bit result in RAM first. Then trigger another DMA to parse the results. You can copy the limit result in a control register.

View solution in original post

2 Replies
RodolfoGL
Employee
Employee
250 solutions authored 250 sign-ins 5 comments on KBA

You could do a WORD to WORD transfer to 2x 16-bit datapath. You need to place these two datapaths adjacent to each other.

One of them will store the 16-bit ADC result. The other 16-bit will store the two bits.

If you are tight in number of datapaths, then you could place the 32-bit result in RAM first. Then trigger another DMA to parse the results. You can copy the limit result in a control register.

I'm not exactly tight in number of datapaths, but routing resources. One 16-bit dp was already troublesome, and two would probably not work at all. I tried the ADC -> word to 32-bit memory -> 2 bytes to 8-bit dp approach and it worked with one transfer with two descriptors. That's probably a reasonably simple and efficient approach. The test code - without any ADC involved, but showing the DMA setup - is attached.

Regarding your suggestion to copy the limit result to a control register - it's not that simple since I need to demux the limit result to 1 of 4 different destinations, based on input previously received from those 4 destinations. It's turning out to be very hard to transform a naive schematic based approach to something that is easier to route with good use of datapaths, especially when used in parallel in/out mode. Outlining the whole task and problem here in the community feels like a huge effort with little hope of success.

0 Likes