K1 Controller Board with Video Capture

ElEctric_EyE · Post by **ElEctric_EyE** » Thu Nov 06, 2014 2:20 am

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 · Post by **ElEctric_EyE** » Thu Nov 06, 2014 11:53 am

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

MichaelM · Post by **MichaelM** » Fri Nov 07, 2014 11:34 am

EEyE:

I was not referring to clock inputs within an FPGA, but rather clock outputs from the FPGA to an external device such as the SyncRAMs. The FPGA has a dedicated, low skew path from a GCLKxxP/GCLKxxN pin to a BUFG buffer within the FPGA. No such device is required or provided for output clocks. Thus, if you are having a hard time routing from a GCLKxxP/GCLKxxN pin to your SyncRAMs, you can choose any convenient pin instead of a GCLKxxP/GCLKxxN pin.

On the other hand, it is very true that a DDR-based external clock driver should be driven from an internal clock net that is buffered by a BUFG driver as you showed in your example.

In most cases, external clocks which are to be used as inputs to the FPGA should connected to GCLKxxP/GCLKxxN pins to ensure that the low skew dedicated connection paths to the clock buffers can be used. In some situations, a clock not connected in this manner will not be usable in certain high performance circuits/applications such as PCI Express, DDR2 SDRAM, etc. However, in many other cases, a mis-connection of an external clock input can be routed to a BUFG driver using normal FPGA routing resources. There may be significant skew between the clock net and any associated data nets, but it may still work.

ElEctric_EyE · Post by **ElEctric_EyE** » Fri Nov 07, 2014 3:25 pm

MichaelM wrote:

EEyE:

I was not referring to clock inputs within an FPGA, but rather clock outputs from the FPGA... No such device is required or provided for output clocks. Thus, if you are having a hard time routing from a GCLKxxP/GCLKxxN pin to your SyncRAMs, you can choose any convenient pin instead of a GCLKxxP/GCLKxxN pin...

I understand now. Thanks!

On the topic of delaying inputs to the FPGA, say from the databus of a RAM during a read cycle, have you had any success? I've tried to use IOBDELAY unsuccessfully in the Verilog and in the .ucf constraints file.
I've given up only because the design seems to work correctly without any delays. I guess the SyncRAM is plenty fast at 4ns.

MichaelM · Post by **MichaelM** » Sat Nov 08, 2014 11:25 am

EEyE:
i've not needed to use IOBDELAY. I've studied how they are used for DDR2 interfaces, but have not attempted to use them yet in one of my designs.

ElEctric_EyE · Post by **ElEctric_EyE** » Sun Nov 09, 2014 2:07 pm

Finished adding in all the bypass capactiors.
I've added filled planes on the bottom of the board around the voltage regulators that should increase the performance.
Originally I did it to avoid adding more vias, for the negative side of the bypass cap's, as there alot of lines running on top of the board (not shown).
The white pads will be free of silkscreen so I can solder the voltage regulators and 0805 cap's.

Now I'll do the same underneath the HDMI audio section, touchscreen section and USB to UART section.

ElEctric_EyE · Post by **ElEctric_EyE** » Sun Nov 09, 2014 5:23 pm

ElEctric_EyE wrote:

...Now I'll do the same underneath the HDMI audio section, touchscreen section and USB to UART section.

I meant on top, for shielding.
Almost done!
Starting the .ucf pin constraints file for the FPGA today. This is yet another check that will help ensure all the pins are correctly wired.

ElEctric_EyE · Post by **ElEctric_EyE** » Mon Nov 10, 2014 6:12 pm

The constraints file is finished and posted on the header post. Found a few errors.
Redid some portions of the layout to make it look neater, the pic of the final version 1.0a is also posted on the header post.
Redefined the goals on the header post.
I'm toast. I might read up on the audio codec, it can sample inputs.

ElEctric_EyE · Post by **ElEctric_EyE** » Mon Nov 10, 2014 7:55 pm

Would be a shame to waste that big blank space in there, 4 boards are going to cost me $200US.
That space can comfortably fit an 80-pin QFP. I'm looking into Analog Devices Audio Processors before I finalize this design. Since I have no FPGA pins left, I'm looking for devices I can add to the I2C bus and that can take advantage of other signals already present.
Another possibility might be wireless transceivers?

ElEctric_EyE · Post by **ElEctric_EyE** » Wed Nov 12, 2014 12:14 am

In the effort to maximize functionality of this board, every inch must be utilized so I continue optimizing...

Instead of 1 switch to reset 3 IC's simultaneously, i.e. 3x USB to UART ICs, a HDMI Receiver IC and a FPGA Program, there was room to add 2 more of these momentary reset switches so now the user can reset each of these IC's individually whenever necessary.
Still doing research on the IC that will fill in the blank space... Probably isn't going to be an Analog part, I'm leaning towards wireless transceivers. The difficult part is finding a transceiver that has a I2C interface. The ones I've seen have a UART interface, some have SPI. Still looking for the one with I2C.

ElEctric_EyE · Post by **ElEctric_EyE** » Thu Nov 13, 2014 12:46 am

Was reviewing this thread tonnight. I found 1 missing signal in the constraints file. It was for the clock (CLK) signal for the bidirectional 8-bit communication interface, pin 6 on the 96-pin I/O connector. Updated the .ucf file...

ElEctric_EyE wrote:

... The difficult part is finding a transceiver that has a I2C interface. The ones I've seen have a UART interface, some have SPI. Still looking for the one with I2C.

In addition to this desire, I was wanting to add a large serial FLASH to this project maybe for sprite pattern storage or something cool like that. So I did some research on I2C flash and came upon a link I would like to share.
I2C bus is too slow for these higher end devices. I2C is usually 100Khz or 400kHz (hi-speed). New/large (64Mbit) SPI FLASH bus is 75 MHz. On the other hand there are I2C EEPROMs, the largest I found was 2Kx16 (unacceptable). I'm starting to realize a serial system needs both SPI and I2C to take advantage of both worlds of ICs presently out there. Taking another look at the project.

GARTHWILSON · Post by **GARTHWILSON** » Thu Nov 13, 2014 5:42 am

ElEctric_EyE wrote:

On the other hand there are I2C EEPROMs, the largest I found was 2Kx16 (unacceptable). I'm starting to realize a serial system needs both SPI and I2C to take advantage of both worlds of ICs presently out there.

I knew they went up to at least 128Kx8 in I2C and 1MHz (the 24c1024), but I just found Mouser has a 256Kx8 1MHz I2C one, 1.8V to 5.5V, in SO-8, at http://www.mouser.com/ProductDetail/STM ... fKv7un8%3d . It would be nice to have them much denser (many megabytes, or more), but I'm sure the reason they're not made in I2C is that it would take too long to read and write a large quantity of memory.

ElEctric_EyE · Post by **ElEctric_EyE** » Thu Nov 13, 2014 9:58 pm

Thanks for checking that out Garth, I appreciate it!

But I was thinking today the amount of money that this (these) board(s) is going to cost and the fact that I am not maximizing the 21sqin board space means that I am wasting money.
That together with a few other facts: 1) I can't control more than 1 PVB. 2) I can't use the higher performance SPI FLASH. 3) I can't utilize the wireless transceivers. All because of FPGA pin limitation, I ran out of pins quickl!... I was just trying to race to finish with this thing because last time I designed a board, it took me 4 painstaking months and I already had the PCB footprint nailed down for the 256-pin 1mm XC6SLX45 Spartan 6....

I think what I really need to do is take one step back and do 2 things with this design, in order to accomplish everything I wanted to put into this design but presently can't, i.e. wireless transceivers, massive SPI FLASH, etc.. For this I'll need to maximize the board dimensions and go back to 6"x3.5", and start designing around the XC6SLX150 1mm 484-pin Spartan 6.

If I'm going to go "all in" with BGA experimentation, I might as well go large and do it correctly, including possibly purchasing a re-flow oven instead of using my custom hot plate.

ElEctric_EyE · Post by **ElEctric_EyE** » Thu Nov 13, 2014 10:10 pm

Checking prices for the 484-pin XC6SLX150T-3FG484C @$181US vs. a 676-pin for $228US.

on avnet in the -3 speed grade, commercial, non lead-free (for better soldering). Man that's alot of money!

ElEctric_EyE · Post by **ElEctric_EyE** » Thu Nov 13, 2014 11:27 pm

Checking spacing for the 676-pin beast on the 6"x3.5" board. Some trimming and IC reorganization... Looks good so far. I'll work on the VCCINT power pin plane since it requires a separate dedicated power plane within the 3.3v power plane. Also, I'll assign the ground pins.
Interesting observation: More User I/O pins, same number of P/N_GCLK pins as the 256-pin Spartan 6.

K1 Controller Board with Video Capture

Re: K1 Controller Board with Video Capture

Re: K1 Controller Board with Video Capture

Re: K1 Controller Board with Video Capture

Re: K1 Controller Board with Video Capture

Re: K1 Controller Board with Video Capture

Re: K1 Controller Board with Video Capture

Re: K1 Controller Board with Video Capture

Re: K1 Controller Board with Video Capture

Re: K1 Controller Board with Video Capture

Re: K1 Controller Board with Video Capture

Re: K1 Controller Board with Video Capture

Re: K1 Controller Board with Video Capture

Re: K1 Controller Board with Video Capture

Re: K1 Controller Board with Video Capture

Re: K1 Controller Board with Video Capture