P2 Streamer and parallel LCD video support

rogloh

Was browsing the P2 documentation today trying to figure out if/how the streamer might be able to support parallel video busses of LCD panels.

Maybe these are going be questions where only Chip currently knows the answers unless someone's already done something like this on one of the P2 FPGA platforms:

For an LCD can you get its CLK and DE signal output synchronously with the video data and in the appropriate phase with the streamer or smartpins perhaps? Let's say the LCD panel needs 40MHz which is a nice submultiple of some 160MHz system clock for example. Will it be possible to have these two LCD control signals generated correctly by the COG or other internal HW and output to the LCD panel?

Also if an LCD with say 18 parallel video inputs (6bpp x 3 RGB) is used, can the unused RGB data bit pins (the LSBs) of the 8:8:8:0 formatted output the streamer generates be freely allocated to other COGs/functions, also in particular including their use for CLK and DE signals as mentioned above, or are there some other limitations there?

Roger.

cgracey

You could coordinate streamer activity with smart pin activity to generate synchronized data and clock signals.

And, yes, if you had 6x3 significant data outputs for RGB, you could repurpose each of the top two bits of the 8:8:8:0 streamer outputs by keeping their DIR bits low. Then, other cogs could control those pins.

rogloh

Thanks for your response Chip.

I had kind of suspected something like that and I guess the proof of the pudding is in the eating. I hope to take a tasty bite once it's all ready.

Cheers!

cgracey

Thanks, Rogloh.

I look forward to actually playing with it, too.

Just ruminating now about how to set up the development tools.

evanh

rogloh wrote: »

... can the unused RGB data bit pins (the LSBs) of the 8:8:8:0 formatted output the streamer generates be freely allocated to other COGs/functions, also in particular including their use for CLK and DE signals as mentioned above, or are there some other limitations there?

There is a limitation in that cog OUTs are or'd with each other and also or'd with any data from the streamers. So although a cog can freely disable an output with DIR and use it as an input, this is not the case if wanting to simultaneously bit-bash them as outputs directly from the cog.

The good news is the smartpins sit in the middle and do have the ability to completely intercede if you wanted to do the LCD control signals on those very pins. Here's a snippet from the manual:

In smart pin modes, the DIR bit is used as an active-low reset signal to the smart pin circuitry, while the output enable state is controlled by a configuration bit. In some modes, the smart pin takes over driving the output state, in which case the OUT bit gets ignored. The IN bit serves as a flag to indicate to the cog(s) that the smart pin has completed some function or an event has occurred, and acknowledgment is perhaps needed.

It should even be possible to then use the DIR line to bit-bash via the smartpin.

cgracey

The trouble is, as soon as your raise DIR for one of those unintended streamer pins, the streamer data OR's with the OUT register to generate the final OUT.

What is needed is a 32-bit mask to gate streamer OUT bits. Too late now, but if we revise the silicon, that could go in.

rogloh

Thanks evanh.

Yeah I figured I would be unable to reuse the disabled streamer output pixel pins in the same COG that is using its streamer directly. In my case I'd like to use these spare pins from other COGs for features such as SD/USB etc, and not just leave them wasted when there are less bits per colour channel than 8 in the case of an 18bit LCD panel for example. However I'd quite like it if the COG that is setting up the streamer could also use Smartpins to do the CLK and DE signals on either a couple of the disabled streamer output pixels (perhaps not possible), or at least using two other pins that are not part of the defined 32 bit group that the streamer is controlling. These LCD CLK and DE signals need to be synchronized with the streamer data and in the appropriate phase, so I imagine the COG driving the streamer will need to coordinate them. From Chip's response I gather it should be possible to reliably set that up (I would hope, anyway).

Roger.

cgracey

Rogloh, if you could ensure that those unwanted bits were always low in the streamer output data, you could freely reuse those pins from that same cog.

So, I don't think there's really a need for a 32-bit mask, after all.

rogloh

Hmmm. Yeah I see the wired OR approach saves you in that case. I guess if the pixels are LUT generated that would be quite possible to enforce, otherwise they always need to be masked when they are written into hub memory. I am now thinking it is best if an LCD group was something like this...

Streamer gets configured to use the following pins:

%eppp : 1111 = enable output on pins 23..0, 63..56

DIR bits set to enable only pixels MSBs on red, green, blue channels with 6 bits each. The redundant fourth streamer byte lane (the "0" in the 8:8:8:0 output) is wrapped around to high pins and also disabled in DIR.

So DIR is
0000000000000000000000000000000000000011_111111_00_111111_00_111111_00

and

P0..P1 - free for use by other COGs
P2..P7 - Blue channel (6 MSBs of 8 bit data, sourced from HUB/LUT)
P8..P9 - free for use by other COGs
P10..P15 - Green channel (6 MSBs of 8 bit data, sourced from HUB/LUT)
P16..P17 - free for use by other COGs
P18..P23 - Red channel (6 MSBs of 8 bit data, sourced from HUB/LUT)
P24..P25 - two Smartpins for LCD CLK, DE signal generation, under control of same COG using pixel streamer
P26..P63 - free for other functions

If that is possible I will be a happy person.

EDIT: looking at the Smartpin stuff I guess DE signal could be generated using a Pulse/cycle output mode, with the high time set as the same as the number of active pixels, and the cycle time as the number of total pixels, with the base clock period equal to the pixel period. The Y register would be set to the number of active lines once each frame, after which DE would drop low. I'd hope this sequence could remain synchronized with the streamer, as the streamer gets reconfigured for each video line and frame. The LCD clock output should be easy enough if it is an integer fraction of the system clock and we can delay down to individual clock cycles and/or it's rising/falling edges.

evanh

cgracey wrote: »

... the streamer data OR's with the OUT register to generate the final OUT.

But isn't the OUT register in the cog? OUT can be overridden by smartpins. So then the smartpin activity becomes the sole pin control. EDIT: I should test it out but I'm still in middle of lots of XORO32 testing.

Yanomani

Hi @rogloh

cgracey wrote: »

You could coordinate streamer activity with smart pin activity to generate synchronized data and clock signals.

And, yes, if you had 6x3 significant data outputs for RGB, you could repurpose each of the top two bits of the 8:8:8:0 streamer outputs by keeping their DIR bits low. Then, other cogs could control those pins.

rogloh wrote: »

DIR bits set to enable only pixels MSBs on red, green, blue channels with 6 bits each. The redundant fourth streamer byte lane (the "0" in the 8:8:8:0 output) is wrapped around to high pins and also disabled in DIR.

So DIR is
0000000000000000000000000000000000000011_111111_00_111111_00_111111_00

Could be my poor understanding, but, wasn't Chip talking about the 6 LSbs of each one of the color bytes, and you, in turn, about the 6 MSbs of the same bytes?

Henrique

evanh

Yanomani wrote: »

... wasn't Chip talking about the 6 LSbs of each one of the color bytes, and you, in turn, about the 6 MSbs of the same bytes?

Either works. It depends on what you want. It would probably be easier to work on full bytes in hubram and just have the two LSbits not go to pins. That way, any depth changes within 8 bits don't affect software.

EDIT: I haven't looked at using LUT tables. Maybe a good advantage to low order output bits then.

rogloh

@evanh is spot on, @Henrique, that was how I was thinking. I think Chip's LSB was an alternative approach and I didn't question it further. I'd plan to use the high bits because it would be more compatible with multiple bit depths supported on the P2. For example you could also have the 5:6:5 format automatically upgraded to 8:8:8:0 by the P2 HW which is then re-interpreted as 6:6:6 on the LCD panel.

Another thing to consider is that if you want to simultaneously output this data to DACs (assuming that is possible), by using the top bits you should get a larger dynamic range of analog voltages at the output and a brighter image.

Yanomani

Hi evah

Yes, that was the way I've understood it.

Perhaps its due to the fact I have a long history with indexing, anyway, I tend to always use the LSbs first, by principle.

Acting otherwise, I feel like I'm trying to follow Ben Turpin's line of sight.

Henrique