K1 Controller Board with Video Capture

[ElEctric_EyE]

HDMI Receiver wiring almost complete. The HDMI connector wiring is a little hairy, I'll need to review the circuit description again to see if I actually need everything. I was working strictly from the Analog schematics.
Running out of spare pins, only 33 left.
Bottom pic shows the internal power planes for the 1.2V and 1.8V core voltages needed for the FPGA and Receiver on the 3.3V layer.

[ElEctric_EyE]

This is how I'll be posting snapshots in the future. Higher quality so every detail is seen. I use SnagIt on extended window preference. It's a few more steps to save a pic, but the end result is worth the effort.
SyncRAM1 now is much closer to the FPGA just like SyncRAM2.
Also, you can see the SDA/SCL I2C lines snaking their way from the FPGA to the Touchscreen Controller, HDMI Receiver and Audio Codec. That's abit daring and we shall see if it works.

[ElEctric_EyE]

Now, I need to choose which signals to use from the K1 connector.
Pin assignments have already been defined, since the female receptacle is already present on the mainboard backplane, and 3 PVBs and been tested successfully.
I'll be lucky if I can control 2 PVBs with the amount of pins I have left!

This is a pinout of the K1 Connector on the backplane.
Right off the bat, 19 pins are needed for the raw RGB data, HSync, VSync and Pixelclock.
After that, for just for 1 PVB:
8 pins are need for the parallel control data bus,
4 pins to control that data bus, per PVB, (i.e. CLK, R/W, BoardRDY, BoardEnable),
2 pins, per PVB, for FPGA PROM MUX control & FPGA Program.

So this adds up to 33 pins!

So this project will roll forward with only 1 PVB and the K1 controller board due to the limitations of pins I have available in this 256-pin XC6SLX25-256FTG Spartan 6.

[ElEctric_EyE]

Today I am wiring up the SPI FLASH used for the FPGA PROM. I realized that a few dedicated pins are incorrectly being used as signal lines to SyncRAM2. This will take away from the 33 free pins I thought I had.
The solution is to only wire up the 16 data bus line for each SyncRAM and not use the 2 parity data bits. I originally had ideas to use the 2 parity bits as some math function assigned to each pixel.
That will free up 4 lines from the FPGA, but will require some time to rewire.

[ElEctric_EyE]

Very close to preliminary finish. All the pins are used up so I can't experiment with the wireless transceivers or SD card.
The board size has shrunk from 6"x3.5" to 5"x3.5", now the 3rd saved iteration.
Still need to finish up some extraneous pins from the HDMI audio IC and HDMI receiver.
Will probably move the HDMI audio section to the right side of the board away from the HDMI connector.
Also, the touchscreen controller will be moved to the right side and I'll try to center the main connector.
Need to add lands for bypass cap's.

Overall, I am happy with the progress of the past 2 weeks.

The very next thing I need to do is rewire the clock pins on the SyncRAMs so that they go to an FPGA NCLK or PCLK pin.

[ElEctric_EyE]

The IC/connector placement is solidified. Still need to get those P_GCLK & N_GCLK pins in order...

[MichaelM]

EEyE:

Unless you are working to provide clock deskewing for your clock distribution, you do not need to use a global clock pin to drive the clocks to your SyncRAMs. You may want to read over the application note that I've attached. It describes a way to use a DCM to remove the skew between the active edge of an external input clock source and the active edge of that clock at an external device such as your SyncRAMs. Appropriate deskew of your external clock distribution networks can allow you to operate closer to the theoretical limits of your devices. It can also be applied to the internal clock distribution networks in order to allow higher internal operating frequencies.

The attached application note is primarily targeted to the Spartan 3/3A families, but the techniques described are equally applicable to the Spartan 6 family. The Spartan 6 family also supports dynamic control of the input delays for each I/O pin. This is how the parts implement the SDRAM interfaces, which require adjustment of the input delays of each data path.

I try to avoid using the techniques described in the attached application note, but I think you may need to consider their application because of your ambitious performance goals for your new project. I have applied the techniques described on several designs, but in more recent personal/hobby designs, I've just opted to go for lower performance in order to avoid applying the techniques described.

xapp462.pdf

App Note on Use of DCM/DLL to Eliminate Clock Skew.

(796.4 KiB) Downloaded 90 times

[ElEctric_EyE]

MichaelM wrote:

EEyE:

Unless you are working to provide clock deskewing for your clock distribution, you do not need to use a global clock pin to drive the clocks to your SyncRAMs...

No plans for deskewing, but I've often had the need to implement a DDR FF for a global clock net going off of the FPGA. I had thought this was only possible through a global clock pin?

[ElEctric_EyE]

MichaelM wrote:

...The Spartan 6 family also supports dynamic control of the input delays for each I/O pin. This is how the parts implement the SDRAM interfaces, which require adjustment of the input delays of each data path...

I had looked into this before when I was having issues when reading from the SyncRAM. I never did figure out how to implement the delays.
After some experimentation with the state machine, I did get correct data when reading. I say some experimentation because the state machine was running 1/2 speed of the SyncRAM which was running @ 150MHz, the pixel clock rate.

[ElEctric_EyE]

I was able to work one more trace out from the FPGA, I think this will be it though...
Currently, the main clock which feeds the FPGA is the pixel clock generated by a PLL inside of the ADV7611 HDMI Receiver from an external 28.636 MHz crystal which I have yet to add.
To take the most advantage of this 1 extra FPGA pin, I thought of adding another IC to the I2C bus. It's a programmable frequency synthesizer in the form of an 8-pin DS1085L. It has a limitation of a max frequency of 66MHz, but not so much a limitation since it can generate thousands of frequencies starting at 4.1kHz. Together with the Spartan 6' own BASE_PLL / ADV_PLL, this will make for a very flexible frequency generator. Also, when programming the DS1085L to change frequencies, there are no 'runt' pulses that could lock-up some pieces of hardware.
The output of the DS1085L will go back to the FPGA on this K1 Controller board and also to pin 50 on the K9 connector so it will be available to the other PVBs to add flexibility.

[ElEctric_EyE]

DS1085L is U21. Just a few details remain. Maybe 2 weeks I will feel confident forking out $200 for these boards.

[BigDumbDinosaur]

ElEctric_EyE wrote:

DS1085L is U21. Just a few details remain. Maybe 2 weeks I will feel confident forking out $200 for these boards.

What are the board dimensions?

[ElEctric_EyE]

BigDumbDinosaur wrote:

ElEctric_EyE wrote:

DS1085L is U21. Just a few details remain. Maybe 2 weeks I will feel confident forking out $200 for these boards.

What are the board dimensions?

5"x3.5". Originally it was 6"x3.5" as I mentioned a few posts ago.

My original implementation of the DS1085L was abit flawed as I needed 2 FPGA pins to complete the idea. 1 pin takes the programmable frequency from the IC and 1 pin to output a signal from the FPGA PLL.
I was actually able to free up 1 more pin on the FPGA, so I can actually utilize this idea!
Would be sorta neat to try to overclock a design as a side experiment.

[ElEctric_EyE]

Wiring is complete...
Part of me wants to delay this design and go for a 484-pin 1mm Spartan 6 layout in order to accommodate more signals needed to Rx/Tx data from/to the wireless transceivers... This is what usually takes my designs 4 months. I usually give in to an up-mod, but I must resist. There's enough here in this design to implement some new ideas.
The board is very close to production:
28.636MHz crystal and /Reset signal has been added to the ADV7611 IC.
Bypass cap's lands must be added.

Sorta cool that the Xilinx clock tool was able to generate 28.636MHz exact from a 70MHz input clock frequency. I still decided to use a dedicated crystal to free up that programmable clock.

[ElEctric_EyE]

ElEctric_EyE wrote:

MichaelM wrote:

EEyE:

Unless you are working to provide clock deskewing for your clock distribution, you do not need to use a global clock pin to drive the clocks to your SyncRAMs...

No plans for deskewing, but I've often had the need to implement a DDR FF for a global clock net going off of the FPGA. I had thought this was only possible through a global clock pin?

I had to research this and refresh my memory in order to proceed with confidence. Page 65 of UG393 mentions the GCLK pins and the use of BUFG.
Currently, the PVB project uses a PLL_BASE that uses the BUFG primitive although the tools convert it to a PLL_ADV. I'll need to do something similar in this project. These are just details, the point is: when designing a PCB, one must connect either a P_GCLK or an N_GCLK to an external IC's clock. P or N doesn't matter unless a differential clock is used according the UG :

Code: Select all

// file: clkgen.v
// 
// (c) Copyright 2008 - 2011 Xilinx, Inc. All rights reserved.
// 
// This file contains confidential and proprietary information
// of Xilinx, Inc. and is protected under U.S. and
// international copyright and other intellectual property
// laws.
// 
// DISCLAIMER
// This disclaimer is not a license and does not grant any
// rights to the materials distributed herewith. Except as
// otherwise provided in a valid license issued to you by
// Xilinx, and to the maximum extent permitted by applicable
// law: (1) THESE MATERIALS ARE MADE AVAILABLE "AS IS" AND
// WITH ALL FAULTS, AND XILINX HEREBY DISCLAIMS ALL WARRANTIES
// AND CONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING
// BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, NON-
// INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE; and
// (2) Xilinx shall not be liable (whether in contract or tort,
// including negligence, or under any other theory of
// liability) for any loss or damage of any kind or nature
// related to, arising under or in connection with these
// materials, including for any direct, or any indirect,
// special, incidental, or consequential loss or damage
// (including loss of data, profits, goodwill, or any type of
// loss or damage suffered as a result of any action brought
// by a third party) even if such damage or loss was
// reasonably foreseeable or Xilinx had been advised of the
// possibility of the same.
// 
// CRITICAL APPLICATIONS
// Xilinx products are not designed or intended to be fail-
// safe, or for use in any application requiring fail-safe
// performance, such as life-support or safety devices or
// systems, Class III medical devices, nuclear facilities,
// applications related to the deployment of airbags, or any
// other applications that could lead to death, personal
// injury, or severe property or environmental damage
// (individually and collectively, "Critical
// Applications"). Customer assumes the sole risk and
// liability of any use of Xilinx products in Critical
// Applications, subject only to applicable laws and
// regulations governing limitations on product liability.
// 
// THIS COPYRIGHT NOTICE AND DISCLAIMER MUST BE RETAINED AS
// PART OF THIS FILE AT ALL TIMES.
// 
//----------------------------------------------------------------------------
// User entered comments
//----------------------------------------------------------------------------
// None
//
//----------------------------------------------------------------------------
// "Output    Output      Phase     Duty      Pk-to-Pk        Phase"
// "Clock    Freq (MHz) (degrees) Cycle (%) Jitter (ps)  Error (ps)"
//----------------------------------------------------------------------------
// CLK_OUT1_____70______0.000______50.0______346.711____235.738
//
//----------------------------------------------------------------------------
// "Input Clock   Freq (MHz)    Input Jitter (UI)"
//----------------------------------------------------------------------------
// __primary_________100.000____________0.010

`timescale 1ps/1ps

(* CORE_GENERATION_INFO = "clkgen,clk_wiz_v3_3,{component_name=clkgen,use_phase_alignment=true,use_min_o_jitter=false,use_max_i_jitter=false,use_dyn_phase_shift=false,use_inclk_switchover=false,use_dyn_reconfig=false,feedback_source=FDBK_AUTO,primtype_sel=PLL_BASE,num_out_clk=1,clkin1_period=10.0,clkin2_period=10.0,use_power_down=false,use_reset=false,use_locked=false,use_inclk_stopped=false,use_status=false,use_freeze=false,use_clk_valid=false,feedback_type=SINGLE,clock_mgr_type=AUTO,manual_override=false}" *)
module MainCLK
 (// Clock in ports
  input         CLK_IN1,								//100MHz can oscillator
  // Clock out ports
  output        CLK_OUT1,
  output			 CLK_OUT2,
  output			 CLK_OUT3,
  output			 CLK_OUT4
 );

  // Input buffering
  //------------------------------------
  IBUFG clkin1_buf
   (.O (clkin1),
    .I (CLK_IN1));


  // Clocking primitive
  //------------------------------------
  // Instantiation of the PLL primitive
  //    * Unused inputs are tied off
  //    * Unused outputs are labeled unused
  wire        clkfbout;
  wire        clkfbout_buf;

  PLL_BASE
  #(.BANDWIDTH              ("OPTIMIZED"),
    .CLK_FEEDBACK           ("CLKFBOUT"),
    .COMPENSATION           ("SYSTEM_SYNCHRONOUS"),
    .DIVCLK_DIVIDE          (5),								//100MHz/5 =20MHz*52 = 1040MHz/7 = 148.571MHz for 1920x1080 @60Hz
    .CLKFBOUT_MULT          (52),							
    .CLKFBOUT_PHASE         (0.000),						
    .CLKOUT0_DIVIDE         (14),							//74.25 MHz CPU clk
    .CLKOUT0_PHASE          (0.000),
    .CLKOUT0_DUTY_CYCLE     (0.500),
	 .CLKOUT1_DIVIDE         (7),								//148.5 MHz SyncRAM clk 
    .CLKOUT1_PHASE          (0.000),						
    .CLKOUT1_DUTY_CYCLE     (0.500),
	 .CLKOUT2_DIVIDE         (7),								//148.5 MHz next PVB clk
    .CLKOUT2_PHASE          (0.000),						
    .CLKOUT2_DUTY_CYCLE     (0.500),
	 .CLKOUT3_DIVIDE         (7),								//148.5 MHz videoDAC clk
    .CLKOUT3_PHASE          (0.000),						
    .CLKOUT3_DUTY_CYCLE     (0.500),
	 .CLKIN_PERIOD           (10.00),
    .REF_JITTER             (0.010))
  pll_base_inst
    // Output clocks
   (.CLKFBOUT              (clkfbout),
    .CLKOUT0               (clkout0),
    .CLKOUT1               (clkout1),
    .CLKOUT2               (clkout2),
    .CLKOUT3               (clkout3),
    .CLKOUT4               (),
    .CLKOUT5               (),
    .LOCKED                (),
    .RST                   (1'b0),
     // Input clock control
    .CLKFBIN               (clkfbout_buf),
    .CLKIN                 (clkin1));
		
  // Output buffering
  //-----------------------------------
  BUFG clkf_buf
   (.O (clkfbout_buf),
    .I (clkfbout));

  BUFG clkout1_buf
   (.O   (CLK_OUT1),
    .I   (clkout0));

	BUFG clkout2_buf
   (.O   (CLK_OUT2),
    .I   (clkout1));
	 
	BUFG clkout3_buf
   (.O   (CLK_OUT3),
    .I   (clkout2));
	 
	BUFG clkout4_buf
   (.O   (CLK_OUT4),
    .I   (clkout3));
	 
	 
endmodule

Then the clocks go through DDR FFs (top_level):

Code: Select all

MainCLK PLL ( .CLK_IN1(MAINCLK1), 		//using 100MHz, generate video pixel clock and CPU clock using PLL
                 .CLK_OUT1(clk),				//CPU clock 
					  .CLK_OUT2(clk2),			//SyncRAM clock
					  .CLK_OUT3(clk3),			//to next PVB
					  .CLK_OUT4(clk4));			//to videoDAC
	
							
	ClkOutDDRFF SRCLKOUT ( .SigIn(clk2), 		//to SyncRAM	
								  .SigOut(SRCLK));	
								  
	ClkOutDDRFF PCLKOUT ( .SigIn(clk3), 		//to next PVB	
								 .SigOut(PCLKout));	
								 
	ClkOutDDRFF VCLKOUT ( .SigIn(clk4), 		//to videoDAC	
								 .SigOut(VCLKout));

DDR FF instantiation:

Code: Select all

`timescale 1ns / 1ps

module ClkOutDDRFF (input SigIn, 
						  output SigOut
						  );

   ODDR2 #( .INIT(1'b0), 					//from the Spartan 6 HDL Library
				.SRTYPE("SYNC"), 
				.DDR_ALIGNMENT("NONE") )
				
				inst (.CE(1'b1), 
                  .C0(SigIn), 
                  .C1(!SigIn), 
                  .D0(1'b1), 
                  .D1(1'b0), 
                  .R(1'b0), 
                  .S(1'b0), 
                  .Q(SigOut));
endmodule