Author Topic: Understanding SDI video data format  (Read 18242 times)

0 Members and 1 Guest are viewing this topic.

Offline Wiljan

  • Regular Contributor
  • *
  • Posts: 225
  • Country: dk
Re: Understanding SDI video data format
« Reply #100 on: April 02, 2020, 10:28:27 am »
Next version  of the board you need to to rework the ribboncable layout  :)
I found a pdf  regarding pin 27 ... you have to wait 30 sec to download(did not find a direct pdf)
https://pdfhall.com/queue/gpcl-pin-configuration-f4fpt_5b71d00a097c4772308b45fa.html
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: Understanding SDI video data format
« Reply #101 on: April 02, 2020, 02:34:39 pm »
Downloaded straight away (no waiting), thanks for the file.

Quote
This is due to some sharing internal to the device of the registers that control the GPCL and the Color DTO.

There is more than likely some hidden functionality, they use likely for production testing of the IC. There is exactly zero reasons why a "color DTO" should have anything in common with a generic IO pin, completely unrelated to anything with color. Working for 5 years for a major semiconductor manufacturer as their tech support, I have experience quite some bit of this "customer hidden stuff".  So not surprised by this at all, but at least, should be made such that is does not interfere in a normal device operation.

Because this way, I can argue that their TVP5150 configuration examples from the datasheet are in fact incorrect, as they do not handle the damn GPCL pin appropriately!

Quote
5.1Example
15.1.1 Assumptions

Device: TVP5150AM1 Input connector: Composite (AIP1A)
Video format: NTSC-M, PAL (B,G,H,I), or SECAM
Output format: 8-bit ITU BT.656 with embedded syncs
5.1.2 Recommended Settings
Recommended I2Cwrites: For this setup, only one write is required. All other registers are setup by default.
I2C register address 03h = Miscellaneous controls register address
I2C data 09h = Enables YCbCr output and the clock output

But obviously, this is NOT enough.  In fact, one register write is all that is required, but you need to write 0x29 to the misc register (addr 0x03), not 0x09 as they suggest. Damn hell!

Should I open a tech support case and suggest them to correct the datasheet? Would probably save hours of time to others.

Well, the connectors on these boards are completely different, weren't designed with any compatibility in mind. There are signals specific to either of the IC. But sure, thinking about compatibility, should spare me an hour or two of soldering the ribbon on  ;D

I had to pause a bit with toying with this, we've had just a home solar power station installed. Lot of interesting stuff was happening and there is even some room for diy improvements to exploit. (Such as intercepting the CAN bus in between the inverter and battery management system or making remote configuration access to the transfer switch - it has only a USB port for local access).  ;)
 

Offline Wiljan

  • Regular Contributor
  • *
  • Posts: 225
  • Country: dk
Re: Understanding SDI video data format
« Reply #102 on: April 03, 2020, 08:36:23 am »
I think you should drop support a mail, and at least they could have the pdf on the pin 27 in the download section to the chip.

Sounds interesting with a solar power station, not sure how much a hack can improve the efficiency compared to regular wash of the  panels  8)

Let me hear when you are ready for FPGA fun with the video boards, BTW the part-number for you Cyclone chip sound a little bit wrong (I can's find that specific chip in Quartus) try to read what exactly are printed on the chip (not from the Chinese web info)
I did choose the EP4CE6E22C8L instead, just to see how the resources was shown in Quartus
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: Understanding SDI video data format
« Reply #103 on: April 03, 2020, 08:49:24 am »
I have dropped them a mail suggesting the documentation improvement yesterday evening. A reply came quite fast, that the probably indeed should update the datasheet, since it is already 9 years old.  But I have forgot about the document you have found. I will tell them, don't worry  ;D

The part no is correct, I have both kits with EP4CE6E22C8N, not C8L, that is a different speed grade or what. I have also 4 spare LQFP chips, all of them are also C8N on the end.

Ah.. I remember now! See the document below Figure 1-3, it is a "C8" grade, and the N suffix is a signature of the lead-free crap.

Yes, ready for the FPGA now, at least to set up an empty project for it. I will try and report back if something goes wonky.
 

Offline Wiljan

  • Regular Contributor
  • *
  • Posts: 225
  • Country: dk
Re: Understanding SDI video data format
« Reply #104 on: April 03, 2020, 10:47:34 am »
I get it, the last letter "N" are non related to the Die but to the pins so in Quartus it will be EP4CE6E22C8. You can try when you have the board hooked up with the JTAG to click autodetect in the programmer and it report what it sees on the JTAG.
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: Understanding SDI video data format
« Reply #105 on: April 03, 2020, 11:09:41 am »
.. a bit more of our FVE related delay, but I have the project setup and running, successfully compiled the obligatory logic example below.

Programmer does see the FPGA, but only as "EP4CE6", can not resolve any further. Funny it has even asked if I have Cyclone III or some other devices, because someone ... have assigned them the same ID.   :palm:

(To prevent possible future confusion, I use Quartus II 13.0.sp1)

Code: [Select]
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity CycloneIVtest is
  port (
    A, B : in std_logic;
Y : out std_logic
  );
end CycloneIVtest;

architecture behav of CycloneIVtest is

begin
  Y <= A and B;
end;

So what should I do next? I could either toy a bit with it to freshen my VHDL-fu a bit (its been years since I have last touched it!) or just go straight into it.  But I guess the latter is better, enough blinkelinghts already.

So as a first step, I should hook up the TVP and ADV to the FPGA.  Please mind you, I have never done any major HDL designs, in fact never worked with FPGAs, so dumb questions may follow.

I guess it is always good practice to connect a bus clock to a CLK dedicated CLK pin on an FPGA. So the TVP5150 CLK will go to an FPGA CLK input pin.
But what to do with the CLK input pin of the ADV7391? Should I connect it also to the TVP5150 clock, or is there a reason to do it different?
 

Offline Wiljan

  • Regular Contributor
  • *
  • Posts: 225
  • Country: dk
Re: Understanding SDI video data format
« Reply #106 on: April 03, 2020, 01:39:19 pm »
Quote
So what should I do next?
Good question  :)

Sure you can play a bit ad hock to get confident on the Quartus, but you will need to have a plan for what you want the FPGA to do with the signal from the dec/enc and draw a small block schematic in what you blocks need to have in it.

Some ideas

a) Just send all the data inc hte clk into on some pin and out on some other pins between the dec / enc and connect them in the FPGA and see it works without any PLL in the FPGA will be a good start I think

b) Handle the BT656 and you could  then add some sync detect to the bus and drive a few pins out and see on the scope that they fit the analog video.

c) Handle the BT656 and generate a local bar to the encoder and switch between loop through and bars

d) Convert the BT656 from Yuv to RGB and back

e) Swap the RBG around / make it BW or inverted

f) Make and overlay of a some simple graphics

g) Write 1 line to RAM M9K and read it out reversed (flip the image)

Regarding to have the clk on a dedicated clk input pin on the FPGA I would not bother taht mutch for that since it's only 27Mhz and should work on all pins, you will have to into which pin bank support the io votage on the dec/enc.

Also I guess you do have a on-board osc. like 50Mhz which are on clk pin that will go to the PLL later on I expect you will use the PLL on eg 27Mhz but it all depend on what the FPGA have to do.

If you recall from 1 of my first post in this thread I quite some years ago did use the Bitec dev. board and I recall there is a BT656 input module... I will try to find it.


« Last Edit: April 03, 2020, 03:26:35 pm by Wiljan »
 

Offline Wiljan

  • Regular Contributor
  • *
  • Posts: 225
  • Country: dk
Re: Understanding SDI video data format
« Reply #107 on: April 03, 2020, 02:05:53 pm »
Here you have the BT656_tx but it's verilog pope do not mind to mix the different modules in different VHDL / Verilog

To use in Quartus:
In your project you already have created the basic of add new file select Design Files and Verilog HDL file

Copy/paste the code into in and save it as BT656_rx.v

Then in the Files select create/update "Create symbol files for current file"

It should hope full work without any error

Back in you top entry (which I expect to be "schematic" double click and select project and add in the the bt656_rx

This should give you a graphic block which you can connect you input and output pins

You sure have to assign the right pins in the pin planner

I do not have the BT656_tx.v but sure it might be out there somewhere or you will have to make your own

Code: [Select]
// ================================================================================
// (c) 2004 Altera Corporation. All rights reserved.
// Altera products are protected under numerous U.S. and foreign patents, maskwork
// rights, copyrights and other intellectual property laws.
//
// This reference design file, and your use thereof, is subject to and governed
// by the terms and conditions of the applicable Altera Reference Design License
// Agreement (either as signed by you, agreed by you upon download or as a
// "click-through" agreement upon installation andor found at [url=http://www.altera.com]www.altera.com[/url]).
// By using this reference design file, you indicate your acceptance of such terms
// and conditions between you and Altera Corporation.  In the event that you do
// not agree with such terms and conditions, you may not use the reference design
// file and please promptly destroy any copies you have made.
//
// This reference design file is being provided on an "as-is" basis and as an
// accommodation and therefore all warranties, representations or guarantees of
// any kind (whether express, implied or statutory) including, without limitation,
// warranties of merchantability, non-infringement, or fitness for a particular
// purpose, are specifically disclaimed.  By making this reference design file
// available, Altera expressly does not recommend, suggest or require that this
// reference design file be used in combination with any other product not
// provided by Altera.
// ================================================================================
//---------------------------------------------------------------------------
// BT656 Receiver
//---------------------------------------------------------------------------
`timescale 1ns/1ns

module bt656_rx (
clk,
reset_n,

din,

clk_135_en,
v_blank,
h,
field,
pixel,
line,
y,
cb,
cr
);

  input clk; // 27 MHz
  input reset_n;

  input [7:0] din;

  output      clk_135_en;
  output      v_blank;
  output      h;
  output      field;
  output [9:0] pixel;
  output [8:0] line;
  output [7:0] y;
  output [7:0] cb;
  output [7:0] cr;

  //---------------------------------------------------------------------------
  // Scan input stream to decode timing reference signals
  //---------------------------------------------------------------------------
  reg [1:0]    time_ref;
  parameter idle = 2'b00,
    ff = 2'b01,
    ff00 = 2'b10,
    ff0000 = 2'b11;

  always @(posedge clk or negedge reset_n)
    if (~reset_n)
      time_ref <= idle;
    else
      case (time_ref)
idle:
  if (din == 8'hff)
    time_ref <= ff;

ff:
  if (din == 8'h0)
    time_ref <= ff00;
  else
    time_ref <= idle;

ff00:
  if (din == 8'h0)
    time_ref <= ff0000;
  else
    time_ref <= idle;

ff0000:
  time_ref <= idle;
      endcase

  wire     timing_ref = (time_ref == ff0000);

  reg     timing_ref_r;
  always @(posedge clk or negedge reset_n)
    if (~reset_n)
      timing_ref_r <= 1'b0;
    else
      timing_ref_r <= timing_ref;

  //---------------------------------------------------------------------------
  // blanking flags
  //---------------------------------------------------------------------------
  reg     field;
  reg     v;
  reg     h;
 
  always @(posedge clk or negedge reset_n)
    if (~reset_n)
      field <= 1'b0;
    else if (timing_ref)
      field <= din[6];
 
  always @(posedge clk or negedge reset_n)
    if (~reset_n)
      v <= 1'b0;
    else if (timing_ref)
      v <= din[5];

  wire     v_blank = v;
 
  always @(posedge clk or negedge reset_n)
    if (~reset_n)
      h <= 1'b0;
    else if (timing_ref)
      h <= din[4];

  //---------------------------------------------------------------------------
  // Input capture registers
  //---------------------------------------------------------------------------
  reg [1:0] input_phase;
  always @(posedge clk or negedge reset_n)
    if (~reset_n)
      input_phase <= 2'b0;
    else if (h | v)
      input_phase <= 2'b0;
    else
      input_phase <= input_phase + 2'b01;

  reg [7:0] y_reg;
  always @(posedge clk or negedge reset_n)
    if (~reset_n)
      y_reg <= 8'b0;
    else if (input_phase[0])
      y_reg <= din;
 
  reg [7:0] cb_reg;
  always @(posedge clk or negedge reset_n)
    if (~reset_n)
      cb_reg <= 8'b0;
    else if (input_phase == 2'b00)
      cb_reg <= din;
 
  reg [7:0] cr_reg;
  always @(posedge clk or negedge reset_n)
    if (~reset_n)
      cr_reg <= 8'b0;
    else if (input_phase == 2'b10)
      cr_reg <= din;

  reg [7:0] y;
  reg     sav;
  always @(posedge clk or negedge reset_n)
    if (~reset_n)
      y <= 8'b0;
    else if (input_phase[0] & ~sav & ~timing_ref)
      y <= y_reg;
 
  reg [7:0] cb;
  always @(posedge clk or negedge reset_n)
    if (~reset_n)
      cb <= 8'b0;
    else if ((input_phase == 2'b11) & ~timing_ref)
      cb <= cb_reg;
 
  reg [7:0] cr;
  always @(posedge clk or negedge reset_n)
    if (~reset_n)
      cr <= 8'b0;
    else if ((input_phase == 2'b11) & ~timing_ref)
      cr <= cr_reg;
 
  always @(posedge clk or negedge reset_n)
    if (~reset_n)
      sav <= 1'b0;
    else if (timing_ref & ((din == 8'h80) | (din == 8'hc7)))
      sav <= 1'b1;
    else if (input_phase == 2'b10)
      sav <= 1'b0;
 
  reg     clk_135_en;
  always @(posedge clk or negedge reset_n)
    if (~reset_n)
      clk_135_en <= 1'b0;
    else
      // Inhibit first and last pulses to prevent clocking out timing codes
      clk_135_en <= (~sav & input_phase[0]
     & ~(timing_ref & ((din == 8'h9d) | (din == 8'hda))));

  reg [8:0]     line;
  always @(posedge clk or negedge reset_n)
    if (~reset_n)
      line <= 9'b0;
    else if (v)
      line <= 9'b0;
    else if (timing_ref_r & sav)
      line <= line + 9'b1;
 
  reg [9:0]     pixel;
  always @(posedge clk or negedge reset_n)
    if (~reset_n)
      pixel <= 10'b0;
    else if (h)
      pixel <= 10'b0;
    else if (clk_135_en)
      pixel <= pixel + 10'b1;
 
endmodule // bt656_rx
 

Offline Wiljan

  • Regular Contributor
  • *
  • Posts: 225
  • Country: dk
Re: Understanding SDI video data format
« Reply #108 on: April 03, 2020, 04:12:17 pm »
I know you use the external processor board for I2C but you also need some I2C core if you are not going to have NIOS or external processor involved.

Here is a quite informative video where he writes the I2C core and test it

But you can also find ready I2C core many places online

For inspiration:  I also suggest the PDF from Intel "Advanced Synthesis Cookbook" for many small nice ideas and trick
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/manual/stx_cookbook.pdf

And you might also like to look around at https://opencores.org/projects and https://www.fpga4fun.com/ and https://www.nandland.com/ just to mention a few
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: Understanding SDI video data format
« Reply #109 on: April 03, 2020, 06:39:50 pm »
I am glad that my plans how to proceed almost exactly match your suggestions.  >:D

Sorry that I haven't touched Quartus since my last post, but I thought it'd be good to finish some of the already begun work, rather than opening yet another can of worms right away.

I scored a quad SD-SDI video monitor from ebay for just couple of bucks (shipping was I think more expensive than that thing). It sat like three months dismantled in a pile of other stuff to repair or fix. Few days ago I have finally received the replacement CFL tubes for the displays. The original ones were beyond dead. They couldn't even strike an arc, like if they got air into them. With the new ones and after thorough cleaning, it now works and is in a good shape. Good, not great. Second screen has some issues with sync, fourth one has slightly incorrect color tone. Could be likely tweaked up, but would you want to touch any of the 50 trimpots in there? Certainly not me.  >:(

By the way, the screens seem to be some off-the-shelf  modules from Sharp with AUOprtronics LCDs (quite surprised they were not Sharp too). The module just receives I think 12V and analog composite video, plus a NTSC/PAL switching signal. 
SDI inputs are handled on a custom separate board, made from some pretty oldschool stuff from the CLCxx product line from back then. Crazy power hungry PLCC packaged stuff. Then they've sticked an 8bit D/A after the SDI decoder and pass the composite video both to the LCD module and to a dedicated BNC on the back.  (Quite bad they couldn't include another BNC for composite video input too).
So, now I have at least one professionally made SDI sink device (if I don't count the scalers/switcher).

But back to the FPGA stuff.  Dinner first, then I prepare a board holder for the thing. I do not like boards flapping in the breeze.  Quartus still ready to enter some code.

I2C core? Ugh.. huh. Not enough courage to try that yet.  :scared:
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: Understanding SDI video data format
« Reply #110 on: April 04, 2020, 01:00:28 pm »
So I have finally made this obligatory thing working. I can get the BT.656 through the FPGA (working as a simple 1ck delay).

Currently modules all connected using the evil crap arduino wires. Seems signal integrity is not that much of an issue, unfortunately, bad contacts ARE a huge ISSUE and chasing intermittent contacts in stupid wiring always makes me pissed.  :box:

I will also now solder down some beefier more stable connections. But am thinking heavily about spinning a custom board for this right now.

Awesome, picture going stably through almost 20 minutes. But I can't touch the thing at all, not even breath around it.  :phew:

After that, off the next task: SAV/EAV state machine / decoder.

//yup, I have compiled the project with that typo in the signal - haven't noticed until making the picture  ;D//
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: Understanding SDI video data format
« Reply #111 on: April 04, 2020, 01:33:46 pm »
Instead of fixing the wiring, being very impatient, I have tried to decode SAV/EAV.  It werkzzz!!!

I have used the code below to decode SAV/EAV. Sure the state machine is not the nicest, I have troubles remembering all the VHDL syntax and does not likely handle all possible issues, nor does it verify the validity using the parity bits. But either way, I am getting nice  F, V and H signals out, all of the correctly positioned and as expected. (25Hz F toggle, 50Hz V pulse, 15625Hz H pulse).

Now I should fix the wiring.

Code: [Select]
-- SAV/EAV state machine
case state is
  when State0 =>
    if (video_in = x"FF") then
      state <= State1;
    end if;
  when State1 =>
    if (video_in = x"00") then
      state <= State2;
    else
      state <= State0;
    end if;
  when State2 =>
    if (video_in = x"00") then
      state <= State3;
    else
      state <= State0;
    end if;
  when State3 =>
    state <= State0;
    F <= video_in(6);
    V <= video_in(5);
    H <= video_in(4);
end case;
« Last Edit: April 04, 2020, 01:36:12 pm by Yansi »
 

Offline Wiljan

  • Regular Contributor
  • *
  • Posts: 225
  • Country: dk
Re: Understanding SDI video data format
« Reply #112 on: April 04, 2020, 02:18:52 pm »
This is great news  :-+

Let us know your progress and if you need any help
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: Understanding SDI video data format
« Reply #113 on: April 05, 2020, 12:33:25 pm »
Great news didn't last long.

I have soldered a more sturdy and reliable wiring. That required reversing the bits on the DAC outputs - I have just mapped the outputs to different pin numbers.

But now, the state machine makes mistakes. I swear it did not do it before! I haven't touched the VHDL code, I have just swapped pins around in the pin planner tool.

WTF is going on there? The video output from the ADV7391 is correct and without those decoding glitches. The whole code is below. No timing constraints were setup (I don't even know how to do so), but I would not expect any problems at 27MHz. I do not have any long combinatorial paths there. Just a dead simple state machine and a few output flops.

Also attaching a capture from my oscilloscope, to see what the problem does. It seems as if it would sometimes miss SAV/EAV, or find one where it shouldn't be.  H output in the image below. F flag has random glitches in the output and V output seems okay.

Also my oscilloscope is finaly becoming shot too. Restarts about each minute and freezes randomly. Chinese crap.  :horse: :box: :rant: I need to get a new one. Fast. Without one I can't do almost anything.  |O
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: Understanding SDI video data format
« Reply #114 on: April 05, 2020, 01:37:03 pm »
I'm done here.  The shit just ain't gonna work, now I can't even get video through. Touching random wires has still effect on what it does. How thats even freaking possible is beyond me. All data signal are always paired with a GND wire in the ribbon, alternating signal-ground-signal. The Chinese FPGA board isn't helping much, the layout is beyond horrible (who would have guessed, uh?) and I do not want to waste time with this setup any more. Maybe I could figure all that out in a couple of hours, maybe days. But hell I can find better ways to spend time.

And note, that by using the previous piece of cable just in between the TVP5150 and ADV7391, I get reliable image output. Hence why I suspect the FPGA board. The new cables were made the same, there are no shorts or misplaced wires, I have just checked.

My two small decoder/encoder boards served the purpose - I have already found out all quirks using them, already know the do's and don'ts with these ICs.

Now I need to make a proper board with a proper layout for this, all single board.  I will not go yet for the full board I dreamed somewhere on the first or second page of this thread, but at least I will include:

FPGA (this exact EP4CE6E22C8N) + config FLASH (EPCS4N)
TVP5150
ADV7391
some small MCU to handle the I2C (at least for now)
couple of user IO (buttons/switches/LEDs)
probably throw a CLC001/006 in the mix, maybe even CLC014.

Either way, I need to study how to connect the FPGA and all its support circuitry. And also figure out how to interface those PECL chips above with the FPGA.

 

Offline Wiljan

  • Regular Contributor
  • *
  • Posts: 225
  • Country: dk
Re: Understanding SDI video data format
« Reply #115 on: April 05, 2020, 01:50:29 pm »
If the video still goes through the FPGA and look good but your stage-machine fails and did work before and the only thing you have done is swapping to different pins I would say that your might have some data lines swapped in both ends ...?
I doubt the 27Mhz timing is the problem.

You could also try the bt656_rx as I posted above

If you want to make a board I get it, but it will slow you down for a few weeks.

Remember the JTAG connector as well

I would also make the I2C ready from the FPGA to the TVP5150 and ADV7391
There are many easy to go codes around to have that to work... just sending the I2C bytes to a given address

Also for debug / testing later on maybe a RS232 (TTL) interface and even 5 pins out for VGA RGBHV (TTL) to have some info coming out.
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: Understanding SDI video data format
« Reply #116 on: April 05, 2020, 02:00:04 pm »
I2C core? Ugh.. huh. Not enough courage to try that yet.  :scared:
Based on past experiences, I would suggest "expect pain".

So much pain in fact, that for any new project I always check if there is an SPI alternative available. If yes, *boot* I2C part, *insert* SPI part.
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: Understanding SDI video data format
« Reply #117 on: April 05, 2020, 02:08:09 pm »
If the video still goes through the FPGA and look good but your stage-machine fails and did work before and the only thing you have done is swapping to different pins I would say that your might have some data lines swapped in both ends ...?
I doubt the 27Mhz timing is the problem.

I have only modified the output side pin mapping. The input stayed same. So I expect it should work the same.

Hopefully it won't take me two weeks to finish the board. On the other hand I guess, we will still be locked at home for quite some weeks to come.

So much pain in fact, that for any new project I always check if there is an SPI alternative available. If yes, *boot* I2C part, *insert* SPI part.

Unfortunately both TVP5150 and ADV7391 are I2C only. So *insert* small MCU to do the I2C stuff.  :D
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: Understanding SDI video data format
« Reply #118 on: April 05, 2020, 04:00:17 pm »
Unfortunately both TVP5150 and ADV7391 are I2C only. So *insert* small MCU to do the I2C stuff.  :D
Yup, that'll do the trick as well. The potential for I2C related "fun puzzles" is so large IMO, that the extra $0.42 for a small mcu is money well spent.
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: Understanding SDI video data format
« Reply #119 on: April 05, 2020, 05:38:39 pm »
You don't tell me, I hate I2C bus and always try to avoid it too. Combined with how shitty implementations the I2C peripherals mostly have in many MCUs, it is even easier at times to bitbang by SW completely.  ::)

I have started working on some nice PCB. Originally thought about squeezing it onto 2 layers, but then said NO. Not worth the hassle. 4 layers will save a lot of time in the design process and the result will be better electrically anyway.

Now need to figure out the FPGA, add some MCU and power supply cascade.

Decided to use only CLC001, no SDI receiver. We need to leave something for the larger complex board with SDRAM.

MCU will be also used as a USB-UART bridge to the FPGA too, no worries. Also I'll route the I2C to the FPGA too  ;) 
« Last Edit: April 05, 2020, 05:44:22 pm by Yansi »
 

Offline Wiljan

  • Regular Contributor
  • *
  • Posts: 225
  • Country: dk
Re: Understanding SDI video data format
« Reply #120 on: April 05, 2020, 06:33:31 pm »
Yeah don't waste time :-)
What soft do you use for PCB Kicad?  Where do you have the boards made?
Add some pin headers so you can hook up some extra wires for unknown test / add-on stuff



 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: Understanding SDI video data format
« Reply #121 on: April 05, 2020, 07:34:33 pm »
Like an old fart I still use some old version of Eagle.  Because i am used to it and know the limitations well and know how to go around them easily.
I once tried Altium, when I was able to use an official full unlimited license, but I quit with it. Too complicated for the simple stuff I do (or at least I did back then.. it is like... not sure how many years, but it was Altium 15 the latest new shiny version).
Now I would really like to switch to Kicad. Unfortunately, I think it is still a toy, not a CAD. The schematic editor is great, but the PCB editor sucks balls. It misses a lot of really basic stuff, that a usable PCB CAD should have since version 1.
Why have you asked? 

I'll try to route out most of the remaining IO, sure. Would be ill-thought not to do so.

//EDIT: Forgot where to make PCBs: I find JLCPCB the best option for me currently.
« Last Edit: April 05, 2020, 07:47:08 pm by Yansi »
 

Offline Wiljan

  • Regular Contributor
  • *
  • Posts: 225
  • Country: dk
Re: Understanding SDI video data format
« Reply #122 on: April 05, 2020, 08:57:10 pm »
Regarding PCB, I have been thinking for a while to do a 4 layer board with Cyclone V CE A9 (BGA) since I think it's the FPGA where you get most LE for the money and have been playing a bit with the KICAD and think it could work. 
I also had JLCPCB in mind since 4 layer can be done for a fair price. I'm not sure but I believe you are in Europe so it was more  to know if you had a recommendation here to avoid long shipping and taxes when it comes to EU. But I guess it's hard to beat JLCPCB
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: Understanding SDI video data format
« Reply #123 on: April 05, 2020, 09:26:13 pm »
I am still kind of scared of BGA, I have no longer access to any kind of professional BGA soldering machines. Sure, I have seen small BGAs with large pitch can be easily soldered at home with just hot air and a couple of neat tricks...  I have even some projects planned, where there is no way around BGA. For example, I'd like to move to HD- and 3G-SDI later, there are unfortunately not many options to tackle this bitrate without a BGA chip. (couple of EP4CGX22 already waiting here with a couple of GS2971 receivers...) Being able to solder and use these at home would be great.

Almost any kind of Chinese PCB vendor is hard to beat, especially with 4 layer boards. I can get 10 boards from JLCPCB faster and cheaper (including taxes and DHL Express shipping) than a single 2layer pool job from a local vendor. They are very expensive here and have long lead times for 4 layer pooling,  DHL will definitely arrive faster with boards from China, then they could manufacture them.
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: Understanding SDI video data format
« Reply #124 on: April 05, 2020, 09:39:55 pm »
A couple of FPGA n00b questions:

1) What may be the expected current consumption of the 2.5V  VCCA supply pins of EP4CE6E22? They should be just PLL supply pins. (trying to determine if a 150mA SOT23 LDO would do).

2) How to interface the damn CLC001 (datasheet) cable driver to the FPGA? Seems like I need to "waste" a whole IO bank due to 2.5V VCCIO requirement.

Datasheet mentions CLC001 accepts both LVPECL and LVDS voltage levels. The FPGA can do both LVPECL and LVDS.

Datasheet specifies the input common mode range of CLC001 to be 50mV to 3.25V. Does that mean I can DC couple it to the FPGA? The Cyclone IV handbook (Volume 3 Table 1-20 page 14) specifies that LVDS has a Vos = 1.25V. That means choosing LVDS would enable direct DC coupling to the CLC001, with just a single 100ohm termination resistor on the CLC001 side of the line.  No other resistors required. Is that correct?

//EDIT: Picture from the handbook below, it seems that's right then...

//EDIT2: Sleep time is calling, enough for today. I don't think this PCB will take weeks :)
« Last Edit: April 05, 2020, 11:34:39 pm by Yansi »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf