Questions about port buffering behavior
-
- Active Member
- Posts: 40
- Joined: Wed Dec 18, 2013 11:51 am
Questions about port buffering behavior
I am curious to know, if I have an 8 bit buffered port, and I want to use it in a FIFO manner how can I do this? I have observed that whenever I feed the buffer an INT value it always seems to turn it into a 32 bit INT, so if I pass 1+(2<<8), FIFO gets the proper first 2 bytes (I.E. port outputs 1, then 2), but also put's 0 for the next 2 bytes, and because only a 32 bit INT used if you try to give the output anything it will wait until a full 32 bit opening is clear in the buffer.
-
- XCore Expert
- Posts: 970
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
How have you declared your port please?
-
- Active Member
- Posts: 40
- Joined: Wed Dec 18, 2013 11:51 am
Code: Select all
out buffered port:32 dac = XS1_PORT_8B;
-
- XCore Expert
- Posts: 970
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
Okay. So what you have is an 8 bit port buffering 32bits of data. Every 32bit words you output to the port will cause outputs from the port on 4 clock edges. In your case you have outputted the value 512 (0x00000201). So the 4 outputs will be 0x01, 0x02, 0x00, 0x00.
If you only every want to output 16 bit values you could declare your port with :16 instead of 32. Alternatively or two 16bit values together to create a 32bit word.
If you only every want to output 16 bit values you could declare your port with :16 instead of 32. Alternatively or two 16bit values together to create a 32bit word.
-
- Active Member
- Posts: 40
- Joined: Wed Dec 18, 2013 11:51 am
Yeah I got that idea, but what I noticed when simulating and running trace I can see that the buffer gets full with the first 32 bit word the buffer is given, this is obvious, but once a clock cycle hits, it puts out 8 bits and the buffer is no longer full, however you are saying that there is no way to put something on the buffer unless it is an entire 32 bit word in this case? Even if the buffer is no longer full, so no matter what you have to wait 4 cycles to fill the buffer again, even if you have data for it before that.Ross wrote:Okay. So what you have is an 8 bit port buffering 32bits of data. Every 32bit words you output to the port will cause outputs from the port on 4 clock edges. In your case you have outputted the value 512 (0x00000201). So the 4 outputs will be 0x01, 0x02, 0x00, 0x00.
If you only every want to output 16 bit values you could declare your port with :16 instead of 32. Alternatively or two 16bit values together to create a 32bit word.
What if I want a buffer much larger then 32 bit? I assume the hardware buffering only supports up to 32 bit? So I guess I would have to institute my own FIFO.
-
- XCore Expert
- Posts: 970
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
Yes, quite often you are outputting from a data/packet buffer/array or similar.MatCat wrote:Ross wrote:
What if I want a buffer much larger then 32 bit? I assume the hardware buffering only supports up to 32 bit? So I guess I would have to institute my own FIFO.
The point with a buffered port, in your case, is you only need one output instruction per 4 bytes instead of 4, offloading the core somewhat. For a 1-bit port clearly this is even more of an offload (1 vs 32 instructions). We couldn't achieve interfaces such as ethernet and USB without these buffered ports.
-
- Active Member
- Posts: 40
- Joined: Wed Dec 18, 2013 11:51 am
Yeah, what I am trying to do is at 28MHz, if I didn't use buffered ports I would only have 3 1/2 clock cycles, when I actually need 4, so buffered port is a must.Ross wrote:Yes, quite often you are outputting from a data/packet buffer/array or similar.MatCat wrote:Ross wrote:
What if I want a buffer much larger then 32 bit? I assume the hardware buffering only supports up to 32 bit? So I guess I would have to institute my own FIFO.
The point with a buffered port, in your case, is you only need one output instruction per 4 bytes instead of 4, offloading the core somewhat. For a 1-bit port clearly this is even more of an offload (1 vs 32 instructions). We couldn't achieve interfaces such as ethernet and USB without these buffered ports.