# Pipelining and clock frequency issue

1. Could you please explain me about pipelining in FPGA and how is it done in xilinx system generator design by adding registers and delays in a particular system design?

2. I have a system design in xilinx system generator. That design meets the timing constrain with 20ns (takes 50MHz clock frequency). However, the FPGA board I use is Virtex 4. It offers 100 MHz (10ns) clock at pin B15. I set 20ns as the FPGA clock period and pin B15 in the System generator token. I was able to generate HDL netlist without any error. However, I wasn't able to get any outputs from the FPGA after I downloaded the bitstream from xilinx ISE. I was wondering it would be the issue with the frequency of the FPGA borad and my design as my design meets only 50MHz NOT 100MHz.

1. My design:

I was not able to upload the picture. I designed a system to generate UWB signal.

1. For this design I only managed to reached maximum of 50MHz(20 ns) of clock frequency by adding registers and delay blocks in between the inputs and outputs. I was not able to reduced the time constrain below 20 ns. Because when I tried to reduce it to 10 ns (attempting to reach 100MHz) by increasing the amount of delays I ended up with an error "Resource overmapped", as shown below (Figures are not the same,but similar).

elected Device : 4vfx12ff668-10

Number of Slices: 6690 out of 5472 122% () Number of Slice Flip Flops: 20567 out of 10944 188%
Number of 4 input LUTs: 10072 out of 10944 92%
Number used as logic: 9969 Number used as Shift registers: 103 Number of IOs: 7 Number of bonded IOBs: 6 out of 320 1%
IOB Flip Flops: 2 Number of GCLKs: 2 out of 32 6%
Number of DSP48s: 33 out of 32 103% (
)

1. However my Virtex 4 FX12FF668 only offers 100MHz clk at pin B15 (i.e. FPGA clock period (ns) = 10 and Clock pin location = B15 ). I'm clueless for how to change it to 50MHz to suite my design and set it in the sys gen token.
• this is not a forum; keep the Answers box for answers. Please read the FAQ. Edit your question for better explanation. – Daniel Grillo Feb 28 '11 at 17:10
• @ sybreon: I really understand the pipelining very well from your explanation. Thank you so much. @ saar drimer and Martin Thompson: thank you so much for your replies too. Regarding my Question 2, I add more detail here below (I'm sorry for not explaining it earlier): Note that, I wanted to upload pictures for all explantions but couldn't as I'm still new comer for this forum. Finally, I really appreciate all your helps. In fact I'm getting more knowledge on digital designs from all your replies. – user3194 Feb 28 '11 at 23:24
• @akilan, if you give me the links to your information in a comment the users will often edit in your pictures for you, I understand the issue, maybe in a few upvotes you can do it yourself. – Kortuk Feb 28 '11 at 23:29

Your design will not function correctly if it runs at 100 MHz but is only spec'd (by the tools) to run at 50 MHz. If it does, then it's a one-off miracle that wouldn't work when you make a change and rerun the tools. Don't do it. Don't even do it if your clock is 100 MHz and the tools tell you the design can run at 99.5 MHz.

To solve your problem you can either write a simple 'divide by power of 2' clock divider to reduce the clock frequency (something like this in Verilog):

reg [n:0] count;

always @(posedge CLK_100) begin
count <= count + 1;
end

BUFG bg_0 (.I(count[m]), .O(CLK_DIV));


(where 'm' <= 'n' and 'bufg' is a global clock buffer, and must be used for synchronous designs) or use a Digital Clock Manager (DCM).

Hopefully that solves your pipelining issues as well unless you absolutely have to run the entire design at 100 MHz. Other than pipelining you can consider using FIFOs if you have part of the design running at 50 MHz and the other at 100 MHz, but you'll have to say a bit more about what you're doing to get more meaningful help here.

1. Pipelining can be seen as breaking up an operation that takes a long time (translate - long data path) into a number of smaller operations. Between each operation, you can put in a register to buffer the intermediate data and form pipeline stages. By carefully doing this, you can increase throughput of the operation.

2. You need to ensure that your design can move the data from input to output within the period - 10ns. Otherwise, there is no guarantee that the design will work correctly. Over-clocking your design may or may not work from time to time. You will need to decrease the data-path of your design.

3. One way to do this would be to increase the pipeline stages of your datapath. For example, if your previous design moves input A to output C in 20ns, you can insert a register B in-between. Then, it can move data from intput A to register B in 10ns and move data from register B to output C in 10ns. Effectively, you still move data from A to C in 20ns but your design can now be clocked with a 10ns period (100MHz).

A --------- (20 ns) --------- C

A -- (10ns) -- B -- (10ns) -- C

Regarding 2) you should set your clock frequency in the system generator setup to 10ns to match what is incoming. If you fail to meet timing then your design is not guaranteed to work - you either need to lower the incoming clock or improve the design until it does mpass the timing checks.

For early development work in the lab you can often get away with missing timing by a few hundred picoseconds, but not by 10ns! (And even if you get away with it in the lab, I certainly wouldn't ship a product which missed timing on that sort of constraint!)

If you're getting absolutely nothing from the FPGA I think you start with something simple - create a simple design that makes a counter and drives some pins with it - you should be able to watch them toggle with a 'scope - that will help you prove that the process of building bitstreams and loading them into the fpga is working - once you have those debugged then try something adventurous

• @ Taniwha: Thank you for your reply. Yes, I've tried with simple design before the big one. I just generated a sign signal and did DAC. Those all were able to be done with 100MHz clock and got the output from FPGA and tested in an oscilloscope. – user3194 Feb 28 '11 at 16:04