Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

FPGA for filtering LVDS data?

Status
Not open for further replies.
P

player80

Full Member level 2
Full Member level 2
Joined
May 31, 2013
Messages
122
Helped
0
Reputation
0
Reaction score
1
Trophy points
1,298
Activity points
2,419
Hi,

I'm totally new to this topic.
I have a TS receiver and would like to filter TS packets in an FPGA.
Are there any cheap FPGAs out there with onchip memory which could do such a job?
I guess it needs at least 188 bytes*2 or 3 for buffering.
The first few bytes carry the packet id which I would like to match up.

The serial TS LVDS signal has 4 data lines (TS DAT, TS VAL, TS CLK, TS SYNC)
My thinking is that I could just use the TS CLK for input and output (I do not want to slow down the forwarded data, only cut it down).

Code: 
[ Serial TS Data ] - [ FPGA Filter? ] - [ embedded platform ]
                                 \--- I2c --------/

I know this is pretty easy with software, so now I'm curious how to do that in hardware.
 

Short answer is: absolutely. When you say "filter" what do you mean, exactly?
 

Are there any cheap FPGAs out there
Click to expand...

Are u looking for cheapest FPGA for your work or cheap one?
I think perhaps also 1 CPLD can do that task, but what is the complete definition for the task.
 

Port Map said:
Are u looking for cheapest FPGA for your work or cheap one?
I think perhaps also 1 CPLD can do that task, but what is the complete definition for the task.
Click to expand...

I just want to filter the TS data.
a Packet has 188 bytes byte 2 and 3 carry the ID, let's take the fictional IDs 1,2,3 The input will be the complete stream, and the output should be the filtered one.

[1] [2] [3] [1] [2] [3] -> [ fpga/cpld? ] -> [1] [1] [1] [1] [1]
PID Table configured via I2C [1] --- Embedded System

I'm looking for how to do that at all since I have no experience with FPGAs :) and I think it's a good starter project for me as well.

In software it would be following:

Code: 
buffer=188 bytes packet buffer
pid=buffer[2]|((buffer[1]&0x1f)<<8);
if (pid == 1) { 
   ... do something else
} else {
  ... trow away PID 2 and 3
}
 

As player80 says, you might actually be able to fit this into a CPLD. I'm not sure you actually need the buffer; you might be able to do this on the fly (as the data comes in) depending on the rate.

Rather than us telling you how to do this, you need to educate yourself about FPGAs and learn VHDL or Verilog. If you already know some programming languages then making the jump to an HDL shouldn't be that hard
 

I don't think the others understand that TS stands for Transport Stream (a.k.a. MPEG transport stream) packets which are 188 bytes in length, and you're probably getting something that is around 38.8107Mbps, so it's pretty low speed for an FPGA.

If your plan is to pass or drop the packets in the programmable device based on some sort of PID filtering then you'll need to deserialize the input and store it before forwarding it (If you plan on doing any other checking on the packets, store-and-forward). You could also do this on the fly with a delay in the data path that is long enough to synchronize to the TS_SYNC and then capture the entire PID before deciding to forward the packet or drop it (cut-through). Depends on the required processing, which way you want to go. Are you planning on checking the TEI or anything else in the header? What are you going to do with the packet if it was corrupted in transit? Do you plan on setting the TEI?

Would need more details to suggest which way would be better and whether or not your "channel" is noisy and how you're dealing with corrupted packets.

Regards,
 
  • Like
Reactions: FvM

    FvM

    FvM

    Points: 2
    Helpful Answer Positive Rating
The embedded system has 2 TS inputs, however the performance goes down if I pass 2x full bandwidth to that system and filter those things in Software.
Occasionally passing through corrupted data should not be a problem.
I'm only interested in getting the bandwidth down as much as possible, the rest should be handled in software (also I'm curious about FPGAs so I'd like to learn more about it, I'm experienced with several software programming languages - except the HDL ones).
I have an altera UP1 (Altera Max EPMM7128SLC84-7 and FLEX EPF10K20RC240-4) and Altera Cyclone II board here. I'm doing some experiments with the UP1 at the moment and reading through some books.
 

player80 said:
The embedded system has 2 TS inputs, however the performance goes down if I pass 2x full bandwidth to that system and filter those things in Software.
Occasionally passing through corrupted data should not be a problem.
I'm only interested in getting the bandwidth down as much as possible, the rest should be handled in software (also I'm curious about FPGAs so I'd like to learn more about it, I'm experienced with several software programming languages - except the HDL ones).
I have an altera UP1 (Altera Max EPMM7128SLC84-7 and FLEX EPF10K20RC240-4) and Altera Cyclone II board here. I'm doing some experiments with the UP1 at the moment and reading through some books.
Click to expand...

Looks like you're using a MCU that probably doesn't have much performance. So filtering out PIDs you're not interested in is a good way to go. If you don't care about corrupted packets potentially getting through to the SW the HW requirements are simple and straight forward. If you bring the LVDS TS packet into either board you shouldn't have any trouble implementing a serial PID filter. As you only need enough storage to hold the header up to the PID you can easily implement that in 24 registers. You'll need a few more to deal with the time it takes to run an FSM that monitors the TS_SYNC and the logic to drop or forward the packet. Instead of an FSM you could use the TS_SYNC to reset a simple bit counter to determine where you are in the header, when you reach the last bit of the PID you compare the TS serial data you've shifted in with the PID you want to pass, etc. If you have more than 1 PID then you'll need to have fancier PID compare code, which means registers for PID storage. If you have a lot of PIDs to compare against then you'll probably have to go with an FPGA so you can store TS packets in a ping-pong buffer or FIFO, while searching though a table of PID values to check. Do you want the data as 8-bit or serial back to the MCU? Could be part of your original BW problem is the serial data. Most MCUs I've run across aren't powerhouses when it comes to streaming serial data through them.

Regards
 

I don't think the others understand that TS stands for Transport Stream (a.k.a. MPEG transport stream) packets which are 188 bytes in length
Click to expand...
Good guess.

As an additional comment, if you want help from those FPGA experts that aren't particularly familiar with "TS", you would preferably describe the problem in a more general way, presumed you already know what the problem is.
 

And apparently PID doesn't stand for Proportional-Integral-Derivative, either. I've got nothing to offer...
 

PID = Program ID. I figured the OP would know this and if someone was interested in this thread they would actually know what it stood for. :)

like PID = 13'h1269 for Playboy channel. ;-)
 

Out of the 3 CPLD/FPGAs you mentioned, only the Cyclone II can handle LVDS. The other two are... a bit older than ancient (in IC terms ;))
 
  • Like
Reactions: ads-ee

    ads-ee

    ads-ee

    Points: 2
    Helpful Answer Positive Rating
Ice-Tea,

Good point didn't even take a look at what those parts were.

Also noticed the 2nd post of the OP so he does want to have a PID table, therefore he'll need to at minimum buffer at least 1 packet depending on how fast he can search the PID table.

Regards
 

I'm also getting a little bit confused about the term LVDS (Low Voltage Differential Signaling)
At the beginning I mentioned that there are 4 lines (TS data, TS Clock, TS Valid, TS Sync).
Doesn't LVDS require a second trace to each of them? I guess if those are just on the same board with short traces the system ground will be used for the - part of it?
On the scope the signal is active within 0 - 3.3V. So for real this is not really LVDS I guess?
I'm reading some documents and specs but I'm still a little bit confused about that.

So in my case basically all CPLDs/FPGAs should support it?

Thanks for all the participation! :)
 

That isn't LVDS. LVDS only has a swing of ~800mV around 1.25V.

So the I/O are probably 3.3V CMOS or LVTTL
 
Thanks now I have a better understanding about that!
 

player80 said:
So in my case basically all CPLDs/FPGAs should support it?

Thanks for all the participation! :)
Click to expand...

I doubt the MAX has enough resources and/or speed. The Flex? Maybe.. Not exactly a very fast device. Migth require some skill to close timing, depending on how complex it is what you wish to do. My advice? Skip ahead to the Cyclone...
 

Ice-Tea said:
I doubt the MAX has enough resources and/or speed. The Flex? Maybe.. Not exactly a very fast device. Migth require some skill to close timing, depending on how complex it is what you wish to do. My advice? Skip ahead to the Cyclone...
Click to expand...

I will do some testing and learning with those parts (FLEX/MAX), however I'll switch over to the cyclone afterwards.
The MAX/FLEX use 5V while the Cyclone II can handle 3.3V (which should be my target)
 

Actually, de Flex handles 3V3 equally well, just depends on how the board is designed.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top