6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Apr 28, 2024 9:43 am

All times are UTC




Post new topic Reply to topic  [ 95 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 7  Next
Author Message
PostPosted: Sun Nov 02, 2014 5:19 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.


Attachments:
2014-11-02_12-47-39.jpg
2014-11-02_12-47-39.jpg [ 622.08 KiB | Viewed 730 times ]
power planes.jpg
power planes.jpg [ 114.19 KiB | Viewed 733 times ]

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
PostPosted: Sun Nov 02, 2014 8:33 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.


Attachments:
11-2-2014 3-18-56 PM.jpg
11-2-2014 3-18-56 PM.jpg [ 1.2 MiB | Viewed 725 times ]

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
PostPosted: Sun Nov 02, 2014 9:09 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.


Attachments:
K1 Connector.jpg
K1 Connector.jpg [ 243.92 KiB | Viewed 724 times ]

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 03, 2014 3:07 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 03, 2014 6:38 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.


Attachments:
11-3-2014 1-23-06 PM.jpg
11-3-2014 1-23-06 PM.jpg [ 1.42 MiB | Viewed 694 times ]

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 03, 2014 10:48 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
The IC/connector placement is solidified. Still need to get those P_GCLK & N_GCLK pins in order...


Attachments:
11-3-2014 5-35-00 PM.jpg
11-3-2014 5-35-00 PM.jpg [ 1 MiB | Viewed 682 times ]

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 04, 2014 12:45 am 
Offline
User avatar

Joined: Mon Apr 23, 2012 12:28 am
Posts: 760
Location: Huntsville, AL
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.

Attachment:
File comment: App Note on Use of DCM/DLL to Eliminate Clock Skew.
xapp462.pdf [796.4 KiB]
Downloaded 75 times

_________________
Michael A.


Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 04, 2014 1:26 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 04, 2014 11:08 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 04, 2014 11:35 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Wed Nov 05, 2014 1:04 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
DS1085L is U21. Just a few details remain. Maybe 2 weeks I will feel confident forking out $200 for these boards.


Attachments:
11-4-2014 7-58-40 PM.jpg
11-4-2014 7-58-40 PM.jpg [ 1.17 MiB | Viewed 633 times ]

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
PostPosted: Wed Nov 05, 2014 5:19 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8147
Location: Midwestern USA
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?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Wed Nov 05, 2014 12:04 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 06, 2014 2:20 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.


Attachments:
11-5-2014 9-09-44 PM.jpg
11-5-2014 9-09-44 PM.jpg [ 1.01 MiB | Viewed 739 times ]

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 06, 2014 11:53 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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:
// 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:
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:
`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

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 95 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 7  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: