Odd vs Even Parity
This will depend slightly on what communication you are using. I know you said you are using UART, but I am going to answer a bit broader. If you do decide to go with parity, select the option that will cause your "idle" state to require the parity bit to switch.
If you have an active high system, then all 0's is idle. So make it odd parity so that the parity bit will have to change state from idle.
In an active low system you should look at how many bits the parity will be over. If it is 8 bits, then even parity will result in a 0 parity bit, which follows the idea of forcing a change in state for the parity.
Should you use Parity?
Well this is a bit of a difficult questions. In general we like to model the noise as Gaussian noise which means that the bit errors will be completely random. In actuality noise that has an effect on our system is not always random. The reason for this is things that can cause errors on a PCB are radiators from something else. If you think about it, in order for a trace that short to have enough noise to cause bit error then it had to be something rather extreme. When you have a noise source like this, there is a decent chance that you will flip more then one bit. Parity is useless against an even number of bit errors. With out diving into the math, parity will help, but doesn't help tons. If you can't afford to do much processing then parity may be the best that you can do..
Why use a CRC?
First of all, you say you have a built in CRC generator, this means it should be very easy for you to compute. CRCs are much better at catching multiple bit errors. In an environment where you want a very low chance of getting any errors, you really want to use a CRC. In fact, go with the biggest CRC you can afford in your system. One little trick that I know works for atleast crc16 if not others is if you CRC the message you received with the CRC on it you should get 0 as your answer. If you have hardware to compute the CRC then this is a very efficient way of both generating CRC and checking CRC.
I'm basing my answer completely on the code and documentation of the dvi_decoder module, and assuming it actually works as advertised. This file seems to be a (modified?) copy of the IP in the app notes Video Connectivity Using TMDS I/O in
Spartan-3A FPGAs and/or Implementing a TMDS Video Interface in the
Spartan-6 FPGA. These app notes are chock-full of important details, and I suggest you read them carefully.
As you indicated in the question, I will assume you are treating unencrypted streams, that is non-HDCP streams. I'm fairly certain that the information in the NeTV project can be adapted to decrypt HDCP, but it would involve a non-trivial amount of additional work and be on questionable legal grounds depending om your jurisdiction.
It looks like you will be able to obtain the data you need from the outputs of the dvi_decoder block. The block outputs 24-bit color information using the wires red
, green
and blue
, synced to the pixel clock pclk
. The outputs hsync
and vsync
alert the user to the end of a line/screen respectively. In general, you should be able to do on the fly averaging using these outputs.
You will need some basic logic to translate hsync
, vsync
and the pixel clock into an (X,Y) location. Just instantiate two counters, one for X
and one for Y
. Increment X
at every pixel clock. Reset X
to zero at hsync
. Increment Y
at every hsync
. Reset Y
to zero at every vsync
.
Using red
, green
, blue
, X
and Y
, you can do on the fly averaging. By comparing with X
and Y
, you can determine what box each individual pixel should contribute to, if any. Sum the color values into an accumulation register. To obtain the average value, you need to divide the value in the register by the number of pixels. If you are smart, you will make sure the number of pixels is a power of two. Then you can just wire the MSBs of the register to whatever you want to drive.
Because we want to drive displays while doing the accumulation, we will need to do double buffering. So we will need two registers per box per component. If you are using a 25-led string, this means you will need 25*3*2=150 registers. That's quite a bit, so you might want to use block ram instead of registers. It all depends on your exact requirements, experiment!
I assume you will be driving a led string like the one used in the original adafruit project kit. You should be able to figure out how to drive it from the values in the registers quite easily using SPI.
The dvi_decoder module is a fairly complex piece of kit. I suggest you study the app notes in detail.
As an aside, if you have not yet purchased an NeTV for use in this project, I recommend you also have a look at Digilent's Atlys board. With two HDMI inputs and two HDMI outputs, it appears to be tailor made for projects of this kind.
Best Answer
Yes there is, you need a state machine. Is it easy? Thats up for debate. I've written state machines that control uarts. I don't know what ports your uart has. But usually they have a data in port and a load signal. Here is an example, I'm letting you know that its possible to answer your question. Go read up on state machines in verilog. This will give you some idea of what a state machine that controls a uart could look like:
Initilze state 1) Reset Uart -goto Initialize state2
Initialize state 2) Set Control reg signals param 1 (like setting an internal register, like for baud rate) -goto Initialize state 3
Initialize state 3) Enable control load -goto Initialize state 4
Initialize state 4) Set Control reg signals param 2 -goto 1st state) Wait
1st state) Wait If load X signal == high, Go to 2nd state if you want to load X character If load Y signal == high, Go to 4th state if you want to load X character
2nd state) Put X data on load line -goto state 3
3rd state) Enable load -go back to state 1
4th state) Put Y data on load line -goto state 5
5th state) Enable load -go back to state 1