DIY evaluation board with XE216-512-TQ512

XCore Project reviews, ideas, videos and proposals.
User avatar
akp
Respected Member
Posts: 428
Joined: Thu Nov 26, 2015 11:47 pm

Re: DIY evaluation board with XE216-512-TQ512

Postby akp » Mon Jun 03, 2019 12:08 pm

I think you will have difficulty implementing 8 channels of very high speed DSD output on a 1 x 8 bit port. You should use 8 x 1 bit ports to simplify the code. There is a method to use multibit ports with zip/unzip instructions https://www.xmos.com/developer/download ... rc1%29.pdf

However, I understand the maximum speed is somewhere around 12.5MHz for a 4 bit port. That is enough for DSD 256 (11.29MHz). I suspect DSD 512 (22.58MHz) might just be possible on a 4 bit port but I would be surprised... all I know is that 12.5MHz will work, and 25.0MHz will not. As to what's possible on an 8 bit port, I don't know. I would suspect DSD 128 should work. Maybe you will need to use multiple high priority cores to handle all the manipulation and then could you get DSD 256? That I don't know.

It would likely have to be on a different tile from the RGMII since the RGMII in Gbps mode uses nearly all the tile. Then you are limited by the streaming channel but that is supposed to give almost 500mbps.
pastaclub
Junior Member
Posts: 4
Joined: Thu Apr 02, 2020 2:10 pm

Postby pastaclub » Fri May 08, 2020 11:08 pm

This comes late... but is the approach with the deserialization of RGB data feasible at all? 480 x 272 pixels x 16 bits = 2 million clock cycles to write one complete screen, not even counting the porch times. That means you would need an output frequency on the 1 bit serial port of more than 2 MHz to get only one frame per second. In order to get a more useful frame of 30 or so, that would be an output frequency of over 60 MHz. Is that achievable?
User avatar
akp
Respected Member
Posts: 428
Joined: Thu Nov 26, 2015 11:47 pm

Postby akp » Mon May 11, 2020 1:09 pm

I suspect you read the lib_lcd documentation which says it can do parallel lcd pixel clocks up to 62.5 MHz. But are you referring to serial RGB interface rather than parallel? Like SPI or something? But I don't understand what you mean by deserializing, it seems more like you want to serialize?

EDIT: I don't know if it's true that it can do 62.5 MHz pixel clocks. But the RGB interface is pretty simple, and you can achieve ultimate performance using hand coded assembly in dual issue mode if you need more performance than XC will give you. I can stream SPI data with > 50 MHz clocks. I think around 24 fps could be possible with a serial pixel line at 480 x 272 x 16 bpp
pastaclub
Junior Member
Posts: 4
Joined: Thu Apr 02, 2020 2:10 pm

Postby pastaclub » Fri Jul 03, 2020 6:45 pm

This question occured to me when looking at the schematics of the board. specifically the VHC595 registers. The way I understand it, you are shifting RGB data from the XMOS serially into those two VHC595 registers using a 1-bit-port for data (SPI0_MOSI). Then, on the rising edge of SPI0_STROBE, that data is output to the LCD, 16 bits in parallel. This is what I mean by "deserialization".

Obviously, if you need a pixel clock frequency of N, then the clock frequency on that 1-bit port needs to be at least 16*N. I was wondering if the XMOS device can output data fast enough to drive LCD displays at useful frame rates.

The value 60 MHz in my post did not actually come from the lib_lcd documentation, but from my own calculation: 480 columns * 272 lines * 16 bits * 30 fps = 62.67 MHz. I guess you answered that question... 24 fps would require a serial clock of 50.1 MHz, so if you can reach that, then the conclusion is that an XMOS device is just fast enough to drive a hardware with two 595 shift registers and a 480x272 display at fluent rates, using a serial 1-bit data port. Screens with higher resolution would require parallel ports (or slower refresh rates if those are supported by the LCD).

Do you have working code for that?
User avatar
akp
Respected Member
Posts: 428
Joined: Thu Nov 26, 2015 11:47 pm

Postby akp » Fri Jul 03, 2020 7:22 pm

I don't have LCD code, sorry. I probably can't send the SPI code since it's proprietary. But it's pretty simple, just spent a lot of time hand optimizing the dual issue assembly.

Who is online

Users browsing this forum: No registered users and 1 guest