UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Teacher eteam00
Teacher
13,051 Views
Registered: ‎07-21-2009

Configuring clocks when using S6 MIG/MCB

Jump to solution

I've started 4 threads on this (and closely related) subject(s).  I'm not happy with the latest addition to UG388 v2.3, section "Modifying the Clock Setup" starting on page 39.  The rest of this post is my own implementation, with notes, of customised clocks -- without Xilinx' blessing.  So no warranty is expressed or implied, especially by Xilinx.

 

- Bob Elkind

 

For the rest of this post, here are the example assumptions

Spartan 6 target

Verilog

MIG-generated files as a baseline (MIG v3.5), using name "DRAM_BOB"

"DRAM_BOB" block is instantiated in top-level source file

333MHz memory clock (mem clock period is 3003 pS)

input source clock changed from 333MHz (MIG default) to 66.6MHz

add 3 "user clocks":  133MHz, 67MHz, and 10MHz

 

 

Section 1:  How to change input source clock frequency

 

Step 1 -

The following parameter line is added to the top-level instantiation of "DRAM_BOB"

 

// multiplier from input source clock to 2x DRAM clock

.C1_CLKFBOUT_MULT(10),   // (e.g.  10 * 66.6MHz = 666MHz)

 

This will be passed through the source code chain to the PLL_ADV block, directing it to multiply the 66.6MHz input source clock up to 666MHz, the output frequency required by the MCB.

 

Step 2 -

In the file "DRAM_BOB.v", generated by MIG, comment out the following line (somewhere around line 190 in the file):

 

// localparam C1_CLKFBOUT_MULT = 2;  // DRAM_BOB change

 

We are defining this parameter at the top level, and localparam may not allow this.

 

Step 3 -

In the same file "DRAM_BOB.v", add the following line to the module parameter list (around line 76 in this example):

 

parameter C1_CLKFBOUT_MULT = 10,   // DRAM_BOB add

 

This should allow the top-level setting of C1_CLKFBOUT_MULT parameter to flow down to the PLL.

 

Step 4 -

In the file "memc1_infrastructure.v" make the following change

 

around line 111 comment out this line

//  localparam CLK_PERIOD_NS = C_MEMCLK_PERIOD / 1000.0;

 

and insert this line as a substitute

localparam CLK_PERIOD_NS = (C_MEMCLK_PERIOD * C_CLKFBOUT_MULT) / 2000.0 ;    // DRAM_BOB mod

 

The parameter CLK_PERIOD_NS is used around line 174 to tell the simulator the input source clock frequency, so the PLL can be modeled properly.  The C_MEMCLK_PERIOD parameter, generated by MIG, specifies the memory clock period (not the input source clock period).  This change includes the input source clock multiplication factor in the calculation.

 

 

Section 2:  How to change add and config user fabric clocks

 

The PLL in the MIG-generated file "memc1_infrastructure.v" has 6 PLL outputs.  CLKOUT0 and CLKOUT1 are dedicated to the MCB.  CLKOUT3 is dedicated to the calibration logic.  There are 3 other outputs which are available for generating fabric clocks for general use.

 

CLKOUT2 is pre-configured by MIG, and is used to generate stretched RESET and PLL_LOCKED signals, but the intent of this clock output is to provide a user fabric clock.  CLKOUT4 and CLKOUT5 are unconnected in the MIG output files, but they are available for fabric use.  In this example, CLKOUT2 is configured for 133MHz, CLKOUT4 is configured for 67MHz, and CLKOUT5 is configured for 10MHz.

 

Step 1 -

 

The following parameter lines are added to the top-level instantiation of "DRAM_BOB"

 

.C1_CLKOUT2_DIVIDE(5),  // DRAM_BOB To gen 133MHz from 667MHz
.C1_CLKOUT4_DIVIDE(10), // DRAM_BOB To gen  67MHz from 667MHz
.C1_CLKOUT5_DIVIDE(67), // DRAM_BOB To gen  10MHz from 667MHz

These will be passed through the source code chain to the PLL_ADV block, directing it to generate the desired fabric clock frequencies.

 

Step 2 -

In the file "DRAM_BOB.v", generated by MIG, comment out the following line (somewhere around line 190 in the file):

 

// localparam C1_CLKOUT2_DIVIDE  = 16;  // DRAM_BOB changes

 

We are defining this parameter at the top level, and localparam may not allow this.

 

Step 3 -

In the same file "DRAM_BOB.v", insert the following lines to the module parameter list (around line 77 in this example):


parameter C1_CLKOUT2_DIVIDE = 5,  // DRAM_BOB To gen 133MHz from 667MHz
parameter C1_CLKOUT4_DIVIDE = 10, //
DRAM_BOB to gen  67MHz from 667MHz
parameter C1_CLKOUT5_DIVIDE = 67, // DRAM_BOB to gen  10MHz from 667MHz

 

The actual parameter values don't matter, as they will be superseded by definition at the design top level.  This should allow the top-level setting of C1_CLKOUTx_DIVIDE parameters to flow down to the PLL.  The clock frequency generated by the PLL, in this example, is 667MHz.  To generate 133MHz, 67MHz, and 10MHz clocks; division factors of 5, 10, and 67 (respectively) from 667 MHz are applied.

 

Step 4 -

In the same file "DRAM_BOB.v", insert the following lines to the module port list (around line 77 in this example):

 

output   c1_clk1,   // user clock 1
output   c1_clk2,   // user clock 2

 

And around line 300 of the same file, insert the following lines to the port connection list for the memc1_infrastructure block

 

.usr_clk1  (c1_clk1), // DRAM_BOB addition
.usr_clk2  (c1_clk2), //
DRAM_BOB addition

 

This will connect the additional fabric clocks generated in memc1_infrastructure to the top level.

 

 

Step 5 -

In the file "memc1_infrastructure.v" insert the following lines in the module parameter list section, around line 77

 

parameter C_CLKOUT4_DIVIDE   = 8,    // DRAM_BOB add
parameter C_CLKOUT5_DIVIDE   = 8,    //
DRAM_BOB add

The actual parameter values don't matter, as they will be superseded by definition at the design top level.  Adding these lines to the module parameter list ensures that the parameters are "connected" to the PLL_ADV through the design hierarchy.

 

Step 6 -

In the same file "memc1_infrastructure.v", add the following lines to the module output port list, around line 85:

 

output usr_clk1,        // DRAM_BOB add
output usr_clk2,        //
DRAM_BOB add

 

Step 7 -

In the same file "memc1_infrastructure.v", add declarations for the new clock nets

 

wire  usr_clk1, usr_clk2;          // DRAM_BOB add
wire  clk1_bufg_in, clk2_bufg_in;  // DRAM_BOB add

 

Step 8 -

In the same file "memc1_infrastructure.v", in the PLL_ADV parameter list around line 180, replace the following lines


.CLKOUT4_DIVIDE     (1),
.CLKOUT5_DIVIDE     (1),

 

With

 

.CLKOUT4_DIVIDE  (C_CLKOUT4_DIVIDE), // DRAM_BOB mod
.CLKOUT5_DIVIDE  (C_CLKOUT5_DIVIDE), //
DRAM_BOB mod

 

 

Step 9 -

In the same file "memc1_infrastructure.v", in the signal/port list for PLL_ADV around line 205, replace the following lines

 

.CLKOUT4     (),
.CLKOUT5     (),

 

with

 

.CLKOUT4  (clk1_bufg_in),  // DRAM_BOB mod
.CLKOUT5  (clk2_bufg_in),  //
DRAM_BOB mod

 

The PLL_ADV block is now configured, and its outputs named.

 

Step 10 -

Next we need to buffer the two new PLL outputs with BUFGs to make them usable fabric clocks.  In the same file "memc1_infrastructure.v", add BUFGs as follows:

 

// two additional user/fabric clocks
BUFG USR_BUFG_CLK1
  ( .O (usr_clk1),
    .I (clk1_bufg_in) );

BUFG USR_BUFG_CLK2
  ( .O (usr_clk2),
    .I (clk2_bufg_in) );

 

And that should wrap it up.

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
1 Solution

Accepted Solutions
Highlighted
Teacher eteam00
Teacher
15,306 Views
Registered: ‎07-21-2009

Addendum #2 - rewording UG388 v2.3

Jump to solution

Here is an example of how the introduction to the "Modifying the Clock Setup" section in UG388 (version 2.3, page 39) might be reworded (hopefully to help clarify the content of this section).

 

The MCB requires 3 clocks generated by a PLL.  The MCB PLL can generate up to 6 clocks.  By default the MIG tool configures the PLL to use 4 of its 6 clock outputs, with the PLL input source clock operating at the memory clock frequency.  By editing the design files generated by the MIG tool, you can accomplish the following:

1.  Change the input source clock to a lower frequency which may be simpler and less expensive to generate on the board (e.g. 25MHz oscillator instead of 400MHz oscillator).
2.  Customise one of the clocks required by MCB (the calibration clock) to a specific frequency between 50MHz and 100MHz which may be useful as a global fabric clock.
3.  Combine two of the default configuration PLL outputs, freeing up a PLL output and a BUFG for resource or power savings.
4.  Customise up to four of the PLL outputs for use as global fabric clocks.

Designs which are constrained by the availability of PLLs, availability of BUFGs, or power consumption may benefit from one or more of these options.  Using these customisation options requires understanding of the PLL block and its capabilities and limitations.  This essential information can be found in the "PLL" chapter of UG382, Spartan-6 FPGA Clocking Resources User Guide, and in the "PLL Switching Characteristics" section of DS162, Spartan-6 FPGA Data Sheet: DC and Switching Characteristics.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
18 Replies
Teacher eteam00
Teacher
13,023 Views
Registered: ‎07-21-2009

Addendum #1 - configuring MIG/MCB clocks

Jump to solution

If your design needs a fabric clock in the 50MHz-100MHz, range, nothing stops you from consolidating the CLKOUT2 and CLKOUT3 PLL outputs (see MIG-generated file "memc1_infrastructure.v")  to a single clock.  This can save a BUFG (with its power consumption), or free up a PLL output for an additional fabric clock.

 

To refresh your memory, here is a brief description of these two PLL clock outputs, as instantiated in "memc1_infrastructure.v":

CLKOUT2

This is the PLL output which is ostensibly intended to be a fabric clock for user logic.  It is buffered with a BUFG, and is used in the MIG-generated files for stretching RESET and PLL_LOCKED signals, and very little else.  It is up to you to customise this clock's frequency to meet the needs of your design.  MIG will not do this for you.

CLKOUT3

This is a clock configured by MIG to run the MCB calibration logic.  Its frequency isn't critical, but UG388 explains that it should fall in the range from 50MHz to 100MHz.  It is buffered with a BUFG.

The fabric clocks generated from these two PLL outputs, as MIG generates them in the file memc1_infrastructure.v, are clk0_bufg and mcb_drp_clk, respectively.  They are passed up to the next level with output port names clk0 and mcb_drp_clk, respectively.

 

In the original example of "DRAM_BOB" which began this thread, the 67MHz top-level fabric clock can be combined with the calibration clock generated from PLL output CLKOUT3.

 

DISCLAIMER:  The examples and directions I've posted in this thread have not been reviewed, approved, or authorised by Xilinx.  This was written as a set of Spartan 6 examples, and I have no idea how much of this (if any) is applicable to designs based on other FPGA families.

 

- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Highlighted
Teacher eteam00
Teacher
15,307 Views
Registered: ‎07-21-2009

Addendum #2 - rewording UG388 v2.3

Jump to solution

Here is an example of how the introduction to the "Modifying the Clock Setup" section in UG388 (version 2.3, page 39) might be reworded (hopefully to help clarify the content of this section).

 

The MCB requires 3 clocks generated by a PLL.  The MCB PLL can generate up to 6 clocks.  By default the MIG tool configures the PLL to use 4 of its 6 clock outputs, with the PLL input source clock operating at the memory clock frequency.  By editing the design files generated by the MIG tool, you can accomplish the following:

1.  Change the input source clock to a lower frequency which may be simpler and less expensive to generate on the board (e.g. 25MHz oscillator instead of 400MHz oscillator).
2.  Customise one of the clocks required by MCB (the calibration clock) to a specific frequency between 50MHz and 100MHz which may be useful as a global fabric clock.
3.  Combine two of the default configuration PLL outputs, freeing up a PLL output and a BUFG for resource or power savings.
4.  Customise up to four of the PLL outputs for use as global fabric clocks.

Designs which are constrained by the availability of PLLs, availability of BUFGs, or power consumption may benefit from one or more of these options.  Using these customisation options requires understanding of the PLL block and its capabilities and limitations.  This essential information can be found in the "PLL" chapter of UG382, Spartan-6 FPGA Clocking Resources User Guide, and in the "PLL Switching Characteristics" section of DS162, Spartan-6 FPGA Data Sheet: DC and Switching Characteristics.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Teacher eteam00
Teacher
12,937 Views
Registered: ‎07-21-2009

Addendum #3 - ambiguity in UG388 v2.3

Jump to solution

This is the content of a webcase I've opened, which (for a VERY NARROW group of designers) might call for some clarifications in UG388 v2.3.  Further, it should give one pause if you are thinking of adjusting the calibration clock frequency to make it useful as a general purpose fabric clock (see my comments on the subject a couple of posts 'back' in this thread).

UG388 v2.3 includes a section on modifying clock setup, on page 39. There is a 'calibration' clock generated in the MCB code, which is affected by the property Cx_CLKOUT3_DIVIDE. UG388, top of page39, states that the calibration clock can be any frequency from 50-100MHz.

Is it required to maintain a frequency ratio of 8:1 between the sysclk_2x clocks and the calibration clock (mcb_drp_clk)?

I noticed that the calibration clock also drives the GCLK input to a BUFPLL cell, and I'm not sure if this use of the calibration clock prohibits tinkering with its frequency as set up by the MIG tool
.

- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Observer harisankar98
Observer
11,834 Views
Registered: ‎09-23-2011

Re: Addendum #3 - ambiguity in UG388 v2.3

Jump to solution

man, thanks for this thread.. i was reading ug388.pdf and not able to make anything out of it ( i mean the clock thingy).

here is my thread i created..

http://forums.xilinx.com/t5/MIG-Memory-Interface-Generator/creating-custom-memory-and-MCB-clocking-two-doubts/td-p/184710

 

Thanks bob.. :)

 

0 Kudos
Visitor sashuma
Visitor
11,805 Views
Registered: ‎07-22-2009

Re: Addendum #3 - ambiguity in UG388 v2.3

Jump to solution

Good post.  But what I really would like to see is an option to furnish my own PLL without having to modify the MIG-generated code.  That was an option on the Virtex-5 -- at least when I last generated a MIG controller for it.

0 Kudos
Teacher eteam00
Teacher
11,801 Views
Registered: ‎07-21-2009

Re: Addendum #3 - ambiguity in UG388 v2.3

Jump to solution

what I really would like to see is an option to furnish my own PLL without having to modify the MIG-generated code.

 

That's generally not a good idea for Spartan-6 designs using the hard MCB controller.  MIG understands the 'secret sauce' of the MCB-specific PLL and BUFPLL_MCB clock generation and distribution facilities.  Let MIG generate the design, and you can tinker with the MIG output to customise it.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Visitor sashuma
Visitor
11,795 Views
Registered: ‎07-22-2009

Re: Addendum #3 - ambiguity in UG388 v2.3

Jump to solution

OK, that makes sense -- don't want to mess with the secret sauce. :smileywink:

 

But I don't like editing generated code.  Bad things happen when someone reruns the core and doesn't realize edits were made post Coregen. 

 

It is also frustrating because my memory controller is several levels down from the top level and I was hoping the Spartan-6 and Virtex-5 versions would have the same port lists.  I'd like to make use of the PLL inside the core for my user clock, but aside from having to edit the code, I would have a clock going "uphill" in the hierarchy in the Spartan-6 version, going against our coding standard.:smileysad:

0 Kudos
Teacher eteam00
Teacher
11,791 Views
Registered: ‎07-21-2009

Further notes on the use of Spartan-6 MIG

Jump to solution

sashuma is on the verge of hijacking this thread (my thread, MY thread!), but some useful points are raised which are of (more or less) general interest.

 

But I don't like editing generated code.

 

Yes, but engineering isn't about what we like, it's about getting the job done, first and foremost.  In the case of MIG output (and this applies to all FPGA family targets, not just Spartan-6), code which can be customised is greatly preferred over code which is not customisable.  Building into MIG all the complexity and configurability needed by the design community would bloat MIG considerably, impede updates, and provoke an endless list of bug fix requests and feature requests -- and this ignores the corresponding burden of documentation for all the added knobs and dials incorporated into MIG.  Remember, MIG is already complex to the extent of all the different FPGA device families it must support.

 

So be grateful for customisable MIG output, and some documentation of why, how, where, and when to tweak the code.

 

It is also frustrating because my memory controller is several levels down from the top level and I was hoping the Spartan-6 and Virtex-5 versions would have the same port lists.

 

The memory controllers for Virtex 5/6 families and Spartan-6 are completely different.  The only common factor is that the core generator is called MIG for both Virtex-5/6 and Spartan-6.  Beyond that (and the graphic shell), it's highly likely there are no additional common factors of any great significance.

 

Bad things happen when someone reruns the core and doesn't realize edits were made post Coregen.

 

An unwritten law in engineering is:  if it isn't broken, don't fix it.  If your design generated with ISE 12.4 tools is working, you would be seriously foolish to update to 13.2 or 13.3 tools without a compelling reason.  If you do update your ISE synth toolset, then you will have to re-gen some (or all) of your cores -- I do not know enough of the details to write authoritatively on the subject.

 

If the design requirements have changed enough that a different memory controller configuration is needed, then re-running MIG is unavoidable.  Of course.  The not-too-simple-not-too-complex approach is the one I've demonstrated in this thread:  Maintain a clearly readable trail of the source code changes by incorporating an abundance of line-by-line comments -- e.g. '// DRAM_BOB change' -- and by commenting out (rather than deleting) lines of original source code which have been replaced.  This makes the task of replicating the optimisations or customisation manageable.

 

If the customised MIG output of (for example) version 3.6 is being replaced with output from MIG 5.3 (for example), there may be enough differences that the tweaks to the v 3.6 code may not be a drop-in fit to the v 5.3 code.  That's a chance you take.

 

I would have a clock going "uphill" in the hierarchy in the Spartan-6 version, going against our coding standard.

 

In the version of MIG which I am running, that's a given, whether you 'tweak' the MIG output code or not.  Reference (source) clock -- and global clocks for fabric logic -- are module ports at the top level, and MIG-generated code takes these clock signals several levels 'down' through the hierarchy of the MIG-generated code to the infrastructure module, where the reference clock is used to generate the global clocks.  This seems neither extraordinarly burdensome nor unusual, unless your coding standards prohibit anything but 'flat' (hierarchy-free) designs.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Teacher rcingham
Teacher
11,774 Views
Registered: ‎09-09-2010

Re: Addendum #3 - ambiguity in UG388 v2.3

Jump to solution
"It is also frustrating because my memory controller is several levels down from the top level and I was hoping the Spartan-6 and Virtex-5 versions would have the same port lists."

Even the Virtex-4 and Virtex-5 versions are unsubtly different!

------------------------------------------
"If it don't work in simulation, it won't work on the board."
0 Kudos
Observer abilashjoseph
Observer
9,448 Views
Registered: ‎11-25-2011

Re: Configuring clocks when using S6 MIG/MCB

Jump to solution

Hi

           My user input clock 50 MHz and memory clock is 200MHz what should be given as values of clock parameters

C5_MEMCLK_PERIOD

• Cx_CLKFBOUT_MULT
• Cx_DIVCLK_DIVIDE
• Cx_CLKOUT0_DIVIDE (for sysclk_2x)
• Cx_CLKOUT1_DIVIDE (for sysclk_2x_180)
• Cx_CLKOUT2_DIVIDE (for user clock)
• Cx_CLKOUT3_DIVIDE (for calibration clock)

Tags (1)
0 Kudos
Teacher eteam00
Teacher
9,444 Views
Registered: ‎07-21-2009

Re: Configuring clocks when using S6 MIG/MCB

Jump to solution

My user input clock 50 MHz and memory clock is 200MHz what should be given as values of clock parameters

 

If this is a Spartan-6 design, the only parameter to change (of the ones you listed) is Cx_CLKFBOUT_MULT.

 

MIG generated parameters for a 200MHz input clock.  If using a 50MHz input clock, multiply the MIG-generated Cx_CLKFBOUT_MULT parameter by 4.  For example:

 

Cx_CLKFBOUT_MULT original value (for 200MHz input clock) was 4

Cx_CLKFBOUT_MULT new value (for 50MHz input clock) should be 16

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Observer abilashjoseph
Observer
9,441 Views
Registered: ‎11-25-2011

Re: Configuring clocks when using S6 MIG/MCB

Jump to solution
Thank you for your answer but when i changed the Cx_CLKFBOUT_MULT value and impliment design the following error came.

PhysDesignRules:1859 - The computed value for the VCO operating frequency of PLL_ADV instance memc5_infrastructure_inst/u_pll_adv is calculated to be 3200.000000 MHz. This falls above the operating range of the PLL VCO frequency for this device of 400.000000 - 1000.000000 MHz. Please adjust either the input frequency CLKIN_PERIOD, multiplication factor CLKFBOUT_MULT or the division factor DIVCLK_DIVIDE, in order to achieve a VCO frequency within the rated operating range for this device.

0 Kudos
Teacher eteam00
Teacher
9,430 Views
Registered: ‎07-21-2009

Re: Configuring clocks when using S6 MIG/MCB

Jump to solution

Suggest you change PLL attribute CLKIN1_PERIOD (or maybe CLKIN2_PERIOD) in your code to reflect the 50MHz input.  If it was 5000 (for 200MHz input), it should be changed to 20000 (for 50MHz input).

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Observer abilashjoseph
Observer
9,426 Views
Registered: ‎11-25-2011

Re: Configuring clocks when using S6 MIG/MCB

Jump to solution
Hi I ve changed the C5_INCLK_PERIOD PLL attribute to 20000 but the same error still persist
0 Kudos
Teacher eteam00
Teacher
9,421 Views
Registered: ‎07-21-2009

Re: Configuring clocks when using S6 MIG/MCB

Jump to solution

I cannot see your code, so I cannot see what is incorrect in your code.  If you change a parameter and the error message is unchanged, then you clearly modified the wrong parameter.  Keep digging until you find the problem.

 

Also, note that I did not specify a parameter in my last post -- I specified an attribute.  Find the instantiation of the PLL_MCB in the MIG-generated code, and apply the attribute change.  That should correct the problem.  Then you can take your time reverse-engineering the MIG code to figure out the "clean" parameter chain change.

 

See UG382 Table 3-5 for a list of PLL attributes.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Observer glester
Observer
9,375 Views
Registered: ‎03-04-2009

Re: Addendum #3 - ambiguity in UG388 v2.3

Jump to solution

More on the business of furnishing your own PLL . .

 

Having reviewed the generated code for a 4xMCB implementation on a 6SLX150, I have to say I don't see much secret sauce there.  So I have to go back to my original conclusion, from many years ago, that the MIG clocking setup is just darned annoying.

 

Fortunately I don't have to use the MIG very often, as I'm usually setting up memory interfaces with the MPMC in a Microblaze environment, and although you do have to tweak your .mhs files a bit you can easily override the clock setup and insert your own PLL.  Where this differs from editing code generated by CoreGen is that the .mhs is not overwritten by the process of re-generating the Microblaze.

 

There is however a further problem with the MIG-generated code in a larger Spartan-6, in that it always instantiates one PLL per side.  According to UG388 this isn't necessary: "It is also possible to drive MCBs on both sides of the device from a single PLL. In this case, two BUFPLL_MCB blocks (one on each side of the device) must be driven by the shared PLL."  This again is simply annoying.

 

So for my money, the MIG clock choices really need to be "Differential", "Single-Ended" AND "External PLL".

 

Gerry L

 

 

 

0 Kudos
Observer glester
Observer
9,369 Views
Registered: ‎03-04-2009

Re: Addendum #3 - ambiguity in UG388 v2.3

Jump to solution

Bob,

 

Thoughtless of me not to mention this in my previous post, but many thanks for starting this thread in the first place.  Your contributions are always valuable and always very well thought out.

 

Gerry L

0 Kudos
4,382 Views
Registered: ‎10-04-2014

Re: Addendum #3 - ambiguity in UG388 v2.3

Jump to solution

Hello iam interfacing spartan 6 fpga lx16 csg324 when iam operating mcb of fpga iam getting ic temperature get increased to 60 deg celsius is this expected

0 Kudos