LVDS, 8b/10b, etc...
Seairth
Posts: 2,474
I've been looking at LVDS and similar technologies, and I notice that 8b/10b encoding is used in conjunction quite frequently. How could 8b/10b be handled with P2? I don't see any dedicated instructions, but am unsure if this can be implemented reliably in software. I also notice that most commercial applications of this are high-speed, so this might not be something that would be reasonably supported by the P2 (even with hardware). On the other hand, it might be a good choice for inter-prop communications.
Anyhow... thoughts?
Anyhow... thoughts?
Comments
I think Chip is fixing the Serdes to include CLK - to leave that off, is to severely restrict the P2 available market, and if P2 fails to hit critical mass, there may never be a following shorter design cycle.
SERDES needs to work at the speeds and modes of most common expected connected controllers/peripherals.
A good example given already is the top end PIC32, which hits 50MHz for SPI modes, and there are many SPI slave devices for large display apps, that need ~ 50MHz.
I think Chip was also adding quad SPI, and it is now a widespread standard, and will be more common when P2 actually ships.
Main issue with Quad SPI is manage of pin-map, the Verilog for quad-shifting is not complex.
On the topic of this thread, bit stuff handling hardware, I would also try to include - but that is Chip's call.
The correct over-all design approach, is to have hardware manage the bit-level work, and software manage the words.
an internal separate register(s) to track/count the running disparity state. A trade off between hardware/software
implementation dictates the final transmission speeds.
The question is @ 160/200 MHz what is the max speed achievable in software vs a basic hardware implementation.?
Lattice have a device RD1012 (8b/10b encoder/decoder) that might fit the job.
I'm not sure what size the AUX memory is in the latest iteration of P2, but these can always be managed as tables, either as
512 x 10 one way, and 1024 x 8 the other for data-path only, or
(512+24) x 10 one way, and 1024 x 9 the other for data-path with Control Code option.
An opcode could manage the DC disparity, (if the prop 2 does not already have a suitable opcode )
As far as I know the AUX ram is still 256 longs. Apparently their a custom design and space was better utilised as HUB ram.
The table method is a possible solution though.
MOV tmp,reg2 SHR tmp,#1 RDAUX reg1,tmp TESTB reg2,#0 wz If_nz SHR reg1,#16 AND reg1,_FFFF _FFFF long $ffffTABLEB is a little more involved again.A single TABLE instruction would help with conversion/transmission speeds.
Not sure how this fits the pipeline sequencing and Verilog complexity, just an idea
http://en.wikipedia.org/wiki/8b/10b_encoding
This would be something to implement in Verilog because the bit rates are in the several GHz (right?). The Verilog description of this would not be complicated. The challenge might be to get 180nm (in the case of Prop2 to signal that fast - it would involve SPICE-level design). This is not something that will go into the first Prop2 because there is too much development time required. However, as soon as Prop2 is done in its first incarnation, we could work to add this feature. It sure would be neat to be able to get hires video and audio out on one cable.
On Transmit, that user control of Length would allow load of 3 x 10b symbols into a 30 bit Tx shifter.
Receive would be trickier, as like in USB, some form of edge-detect locking is needed.
ROLSYMB,GETSYMB,SETSYMB instructions would assist in building these 30bit chunks of data, P3 maybe?
Speaking of Serial Video Silicon support, I saw this upcoming ADV8005 device at Analog.com :
http://www.analog.com/en/audiovideo-products/analoghdmidvi-interfaces/adv8005/products/product.html
Claims to have 2 x HDMI LVDS pathways, and also HD and SD video DACs, as well as TTL port for 38/48b video, and also shows DDR2 memory support, and Serial Video (HDMI) in.
Yeah, I don't see this being added (at those rates) in this version of the P2.
Also, building on what ozpropdev suggested (TABLEx instructions), would it be possible to fit a single-port memory into a cog that's just for table(s)?
At least a CLK output and maybe a CLK input.
There's no more silicon room in Prop2 for that now, because of the logic growth.
Man, they want you to sign an NDA before you can see the whole datasheet. I've heard things are going this way. Selling chips is enough of an uphill battle. I can't imagine asking people to agree to NDA terms before they can even evaluate if they need the part, or not. Strange world!
"We've designed this great product, but we don't want anyone to use it and don't tell anyone else about it either!"
A CLK-IN is important for P2 as a SPI slave.
Most SPI engines run a CLK synchroniser here, so the SPI shifts internally on a Gated SYSCLK, and only the last D-FF at the pin, is slave-edge clocked to give a stable Tco time.
That keeps the Logic simple, and the same CLK_EN Logic can be used in master mode, for /N baud adjustments.
Usually, slaves have a lower SYSCLK/N value but at 200MHz, you should be able to slave to above ~ 50MHz ok.
Not necessarily "GHz" from a transition point of view
Most of the 8 inch and above LCD screens use LVDS. Their dot clocks are typically 40 MHz or upwards, times 7 data bits per dot clock per lane (ie ~ 152+ million "transitions" per second), times 3 to 5 "lanes" to get the required 18/24/30 bits out within that single dot clock. Have a look at page 8 of this spec, they have two possible encoding modes:-
http://www.sharp.net.au/cms/articles/439/files/LQ084S3LG01.pdf
Or, page 11 of this spec
http://pixelqi.com/yahoo_site_admin/assets/docs/3Qi-1_V22_spec_20110919.306200524.pdf
It'd be interesting to think about (not necessarily implement before P3), what would be required to be able to drive these LVDS screens, since you now have 256kB hub ram, enough for 3 bit / 8 color graphics modes. You would need
- "complementary" (inverted 2nd pin) pin driver modes (which you probably already have), that can put out something that looks like lvds
- video generators whose PLL can run at least 152 MHz (for the Pixel Qi, or 245 MHz for the Sharp 800x600 displays)
- a 7 step state machine that picks up the correct 3~5 bits from AUX ram, adds the clock signal (4 states high, 3 states low) and guides it to the pins
An emerging alternative to HDMI looks to be MHL,
http://en.wikipedia.org/wiki/Mobile_High-Definition_Link
which can support a smaller connector >= 5 pins, and some use Micro USB.
I think this specs a 75MHz clock rate and 2.25GHz pixel (30x the CLK rate).
Or, in time domain terms, this is 13.333ns period, and phase-defined to 444ps on the Pixel edges.
My nvidia cards also are able to pass sound to my monitors over DVI->HDMI cables, so that should also be possible
Talk about a moving target! And who knows how long SlimPort will last (though royalty-free might give it some legs). It makes me wonder: are there dedicated ICs for most of these, and what protocol do those ICs support on the back-end for communicating with a CPU?