Slave fifo with non multiple of 4 byte sizes

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

cross mob
Anonymous
Not applicable
        We have an application where we're using the 32 bit gpif bus to stream data from an fpga. That works fine but for some reads, we'd like to read a number of bytes that are not a multiple of 4. One we we experimented with this is to use manual commit mode and if the amount of data we wanted is not a multiple of 4 then to modify the buffer count to be less in order to truncate the unneeded extra bytes. This of course is much slower than auto commit mode and not ideal. Does anyone have a solution to this problem or is everyone always simply reading data in multiples of 4 bytes? What if I wanted to read 510 instead of 512 bytes for instance?   
0 Likes
6 Replies
Anonymous
Not applicable

 Hi,

   

 

   

You could use the PKEND signal to accomplish this. You would need to assert this signal from the FPGA if the number of bytes written into FX3 is not a multiple of DMA buffer size. Take a look at this implementation in the slavefifo example in GPIFII designer. The COMMIT action is done whenever PKEND is asserted.

   

This would, in effect, take care of your non 4-byte multiple issue as well.

   

 

   

Regards

   

Shashank

0 Likes
Anonymous
Not applicable
        We based our gpif design off the slfifo example to begin with so we already have a short packet state that has a COMMIT action when pktend is asserted. We use that to send shorter packets already and it works fine. I don't see how this can take care of the 4 byte problem though. When the data bus is driven as far as I can tell it always increments in multiples of 4 bytes since there are 4 bytes on the 32 bit data bus. How do we tell it to commit only one, two, or three of those bytes for instance? In MANUAL commit mode the firmware can change the count dynamically at the end of the transfer to truncate the last packet to the desired length but I still don't see a way to do this automatically. Perhaps I'm missing an important feature of the gpif state machine?? Thanks for your input.   
0 Likes
Anonymous
Not applicable

Hi,

   

check GPIF II designer from cypress there you can change bus lenght and re-built your GPIF configuration descriptors with different bus length (8-/16- and 32-bit are possible).

   

Then reload GPIF descritpor when you like to use other lengthen. Or find out the differences between the generated GPIF descriptor files and try if you can switch just the register values.

   

regards,

   

lumpi

0 Likes
Anonymous
Not applicable

 I know how to switch the bus size.  But if I switch the bus size less than 32 bits I'll then limit my data transfer speed.  Are you suggesting a way to still use 32 bits for non multiple of 4 byte reads or are you suggesting loading a different state machine?  (Sounds like the latter to me).   

   

What I want to do is find a way to not sacrifise data transfer speed but still have the ability to do a non multiple of 4 byte transfer.   We already have this solved for BULK_OUT transfers because the fpga is smart enough to know to discard the extra bytes (we tell the length of the transfer).  It's only for BULK_IN transfers.  By chance would the SetXfer function help with this if I set the length of the the transaction to the length we were looking to transmit instead if infinite? 

0 Likes
Anonymous
Not applicable

Hi,

   

I am not really sure what the best way is. But if you switch the state machines you may have to handle dma reset,... deeper and I read in the forum sometimes about some issues in this case. I also think you may like to switch very dynamically in this case.

   

Perhaps, the best way is to use the 32-bit mode and you just use the bytes you need on host side. Alike you described it on the OUT transfer in the FPGA.

   

regards,

   

Lumpi

0 Likes
Anonymous
Not applicable

 Thanks for responding.

   

 

   

What I'd really like is for a way to do this without having to use a different gpif state machine.  As is tear down the dma channel and create it again in manual mode and when it's in manual mode I just truncate the packet.

   

 

   

It's not ideal to do it on the host side.  I'm attempting to maintain compatibility with an older board (fx2).  The host software passes in the buffer to store the transfer and it doesn't have extra space at the end of the buffer.  I'd have to allocate a new buffer and copy the data every transfer.  The host side has user space libraries that allow interaction so I can't just modify the software myself and deal with it that way.

   

 

   

Anyway, if it can't be done then I'll just deal with it the way we are.  Sheshank's post above suggests you can but perhaps he didn't understand correctly the problem or I'm missing some important bit of information.

0 Likes