clock problem

[Database Administrator]

Hi,
I have a design which is supposed to run fine at 200mhz according to
xilinx ise, but when i load the design to the fpga and try to run it
at 200 mhz, it doesn't run correctly and generates false results.
Behavioral simulation works correctly, and also weird thing is when i
use a slower clock, fpga gives the correct results,too. Fpga is a
virtex4sx35, and 100mhz clock is generated by a programmable clock
chip and i use dcm to get a 200mhz clock. I am kind of a new fpga
programmer and this is the first time i have seen a problem like this,
usually ise gives a timing error, but this time according to ise,
everything is perfect.
this is the timing constraint i use:
NET clka period = 10 ns;
clka is fed to the dcm.
Thanks.

[Database Administrator]

o0o0ozd@gmail.com wrote:
> Hi,
> I have a design which is supposed to run fine at 200mhz according to
> xilinx ise, but when i load the design to the fpga and try to run it
> at 200 mhz, it doesn't run correctly and generates false results.

Which report are you looking at? XST gives a maximum clock speed
estimate after synthesis, something like this:

"Timing Summary:
---------------
Speed Grade: -4

Minimum period: 3.781ns (Maximum Frequency: 264.480MHz)
Minimum input arrival time before clock: 1.269ns
Maximum output required time after clock: 5.531ns
Maximum combinational path delay: No path found"

This is only a guess because it doesn't take into account the routing
delays (it can't, because at this point the design hasn't been routed yet).

What you need to look at is the post place and route report. There
should be a list of all timing constraints in your design there (the one
you manually entered and there should be an auto-generated one for the
2x clock out of the DCM) and if they have been met. Something like this:

"------------------------------------------------------------------------------------------------------
Constraint | Check | Worst Case |
Best Case | Timing | Timing
| | Slack |
Achievable | Errors | Score
------------------------------------------------------------------------------------------------------
TS_clk = PERIOD TIMEGRP "plk" 6 ns HIGH | SETUP | 0.600ns|
5.400ns| 0| 0
50% | HOLD | 3.076ns|
| 0| 0
------------------------------------------------------------------------------------------------------


All constraints were met."

If this report also says the 200Mhz-constraint is met, then it should
work in reality as well.

The only other potential problem I can think of is that there are timing
problems in the interface to the outside world. If you don't use the
flipflops inside the IOBs for inputting and outputting data, the delays
from the final flipflop to the IO-pin can be quite large and are not
taken into account for timing analysis unless you specify
OFFSET-constraints for the IO-signals. So it could be that the design
inside the FPGA is running fine, but the transfer from/to the outside
world is the problem.

I suggest you set the "Pack I/O Registers Into IOBs" option to "Yes" in
the synthesis settings ("Xilinx Specific Settings" section, you might
have to switch the view to "Advanced" to see it) and see if that changes
anything.

HTH,
Sean

--
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...

[Database Administrator]

On Nov 12, 11:55*am, Sean Durkin wrote:
> o0o0...@gmail.com wrote:
> > Hi,
> > I have a design which is supposed to run fine at 200mhz according to
> > xilinx ise, but when i load the design to the fpga and try to run it
> > at 200 mhz, it doesn't run correctly and generates false results.
>
> Which report are you looking at? XST gives a maximum clock speed
> estimate after synthesis, something like this:
>
> "Timing Summary:
> ---------------
> Speed Grade: -4
>
> * *Minimum period: 3.781ns (Maximum Frequency: 264.480MHz)
> * *Minimum input arrival time before clock: 1.269ns
> * *Maximum output required time after clock: 5.531ns
> * *Maximum combinational path delay: No path found"
>
> This is only a guess because it doesn't take into account the routing
> delays (it can't, because at this point the design hasn't been routed yet).
>
> What you need to look at is the post place and route report. There
> should be a list of all timing constraints in your design there (the one
> you manually entered and there should be an auto-generated one for the
> 2x clock out of the DCM) and if they have been met. Something like this:
>
> "------------------------------------------------------------------------------------------------------
> * Constraint * * * * * * * * * * * * * * * *| *Check *| Worst Case |
> Best Case | Timing | * Timing
> * * * * * * * * * * * * * * * * * * * * * * | * * * * | * *Slack * |
> Achievable | Errors | * *Score
> ------------------------------------------------------------------------------------------------------
> * TS_clk = PERIOD TIMEGRP "plk" 6 ns HIGH * | SETUP * | * * 0..600ns|
> *5.400ns| * * * 0| * * * * * 0
> * *50% * * * * * * * * * * * * * * * * * * *| HOLD * *| * * 3.076ns|
> * * * * | * * * 0| * * * * * 0
> ------------------------------------------------------------------------------------------------------
>
> All constraints were met."
>
> If this report also says the 200Mhz-constraint is met, then it should
> work in reality as well.
>
> The only other potential problem I can think of is that there are timing
> problems in the interface to the outside world. If you don't use the
> flipflops inside the IOBs for inputting and outputting data, the delays
> from the final flipflop to the IO-pin can be quite large and are not
> taken into account for timing analysis unless you specify
> OFFSET-constraints for the IO-signals. So it could be that the design
> inside the FPGA is running fine, but the transfer from/to the outside
> world is the problem.
>
> I suggest you set the "Pack I/O Registers Into IOBs" option to "Yes" in
> the synthesis settings ("Xilinx Specific Settings" section, you might
> have to switch the view to "Advanced" to see it) and see if that changes
> anything.
>
> HTH,
> Sean
>
> --
> My email address is only valid until the end of the month.
> Try figuring out what the address is going to be after that...

thank you for your reply.
I am looking at the post place and route report.
PERIOD analysis for net "Inst_dcm4/CLK2X_BUF" derived from NET
"Inst_dcm4/CLKIN_IBUFG_OUT" PERIOD = 10 ns HIGH 50%
Best Case Achievable 4.999 ns.

and I will still check the IOB option but I use another clock(pci
clock) to transfer the data. Basically, I have a tree-search algorithm
which has to run fast(200mhz) and i have another slow algorithm which
transfers the result through pci. I have a 2-ff synchronizers in
between. Data is 128-bit long and i use 32-bit registers to send it.
Design works at 100mhz, used to work at 150mhz when the logic was
smaller. Bits in the middle change faster than the bits at the both
ends of the 128-bit number, and these middle bits are the wrong ones.
I have nothing so any comment,hint, reply is appreciated.

[Database Administrator]

o0o0ozd@gmail.com wrote:

> and I will still check the IOB option but I use another clock(pci
> clock) to transfer the data. Basically, I have a tree-search algorithm
> which has to run fast(200mhz) and i have another slow algorithm which
> transfers the result through pci. I have a 2-ff synchronizers in
> between. Data is 128-bit long and i use 32-bit registers to send it.
> Design works at 100mhz, used to work at 150mhz when the logic was
> smaller. Bits in the middle change faster than the bits at the both
> ends of the 128-bit number, and these middle bits are the wrong ones.
> I have nothing so any comment,hint, reply is appreciated.

I'd suggest using an asynchronous FIFO for this. A synchronizer with
two flipflops ist fine for single control signals (at least most of the
time, but even then there's a whole lot of things to consider), but data
busses should be handled differently. The easiest method is just using a
FIFO, you can generate one that fits your needs with CoreGen and
instantiate it in your design.

So what I'd use is is a FIFO that you write to with 200MHz and read out
with 33MHz (or whatever your PCI clock is). You may need a little extra
logic (like a small state machine or something like that) to check the
control signals (FIFO full/empty and such), but it's not really a big
deal and a this is certainly a "clean" solution. Downside is you need a
few BRAMs, depending on how deep the FIFO needs to be. But you can just
generate one with CoreGen and how many it needs.

HTH,
Sean

--
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...

[Database Administrator]

In comp.arch.fpga,
o0o0ozd@gmail.com wrote:
> Hi,
> I have a design which is supposed to run fine at 200mhz according to
> xilinx ise, but when i load the design to the fpga and try to run it
> at 200 mhz, it doesn't run correctly and generates false results.
> Behavioral simulation works correctly, and also weird thing is when i
> use a slower clock, fpga gives the correct results,too. Fpga is a
> virtex4sx35, and 100mhz clock is generated by a programmable clock
> chip and i use dcm to get a 200mhz clock. I am kind of a new fpga
> programmer and this is the first time i have seen a problem like this,
> usually ise gives a timing error, but this time according to ise,
> everything is perfect.
> this is the timing constraint i use:
> NET clka period = 10 ns;
> clka is fed to the dcm.

This is a constraint for your 100MHz clock, but don't you need to add
a constraint for the 200MHz clock as well? (clkb period = 5 ns...)
ISE should also report what the maximum allowable clock is, what does
it say? (multiple clocks?)


--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

Always be sincere, even when you don't mean it. -Irene Peter

[Database Administrator]

On 12 Kasým, 17:45, Stef
wrote:
> In comp.arch.fpga,
>
> o0o0...@gmail.com wrote:
> > Hi,
> > I have a design which is supposed to run fine at 200mhz according to
> > xilinx ise, but when i load the design to the fpga and try to run it
> > at 200 mhz, it doesn't run correctly and generates false results.
> > Behavioral simulation works correctly, and also weird thing is when i
> > use a slower clock, fpga gives the correct results,too. Fpga is a
> > virtex4sx35, and 100mhz clock is generated by a programmable clock
> > chip and i use dcm to get a 200mhz clock. I am kind of a new fpga
> > programmer and this is the first time i have seen a problem like this,
> > usually ise gives a timing error, but this time according to ise,
> > everything is perfect.
> > this is the timing constraint i use:
> > NET clka period = 10 ns;
> > clka is fed to the dcm.
>
> This is a constraint for your 100MHz clock, but don't you need to add
> a constraint for the 200MHz clock as well? (clkb period = 5 ns...)
> ISE should also report what the maximum allowable clock is, what does
> it say? (multiple clocks?)
>
> --
> Stef * *(remove caps, dashes and .invalid from e-mail address to reply by mail)
>
> * Always be sincere, even when you don't mean it. -Irene Peter

Not sure either, but this is the constraint generated by ise:

PERIOD analysis for net "Inst_dcm4/CLK2X_BUF" derived from NET
"Inst_dcm4/CLKIN_IBUFG_OUT" PERIOD = 10 ns HIGH 50%

and it says:

Best Case Achievable is 4.999 ns.

for this constraint.

[Database Administrator]

On 12 Kasým, 15:05, Sean Durkin wrote:
> o0o0...@gmail.com wrote:
> > and I will still check the IOB option but I use another clock(pci
> > clock) to transfer the data. Basically, I have a tree-search algorithm
> > which has to run fast(200mhz) and i have another slow algorithm which
> > transfers the result through pci. I have a 2-ff synchronizers in
> > between. Data is 128-bit long and i use 32-bit registers to send it.
> > Design works at 100mhz, used to work at 150mhz when the logic was
> > smaller. Bits in the middle change faster than the bits at the both
> > ends of the 128-bit number, and these middle bits are the wrong ones.
> > I have nothing so any comment,hint, reply is appreciated.
>
> I'd suggest using an asynchronous FIFO for this. A synchronizer with
> two flipflops ist fine for single control signals (at least most of the
> time, but even then there's a whole lot of things to consider), but data
> busses should be handled differently. The easiest method is just using a
> FIFO, you can generate one that fits your needs with CoreGen and
> instantiate it in your design.
>
> So what I'd use is is a FIFO that you write to with 200MHz and read out
> with 33MHz (or whatever your PCI clock is). You may need a little extra
> logic (like a small state machine or something like that) to check the
> control signals (FIFO full/empty and such), but it's not really a big
> deal and a this is certainly a "clean" solution. Downside is you need a
> few BRAMs, depending on how deep the FIFO needs to be. But you can just
> generate one with CoreGen and how many it needs.
>
> HTH,
> Sean
>
> --
> My email address is only valid until the end of the month.
> Try figuring out what the address is going to be after that...

I have seen a similar comment before which says dont use synchronizers
for data buses.
I thought what is the big deal
we will see, i ll try the fifo tomorrow, thanks for the advice.

[Database Administrator]

On Nov 12, 8:45*pm, Stef
wrote:
> In comp.arch.fpga,
>
> o0o0...@gmail.com wrote:
> > Hi,
> > I have a design which is supposed to run fine at 200mhz according to
> > xilinx ise, but when i load the design to the fpga and try to run it
> > at 200 mhz, it doesn't run correctly and generates false results.
> > Behavioral simulation works correctly, and also weird thing is when i
> > use a slower clock, fpga gives the correct results,too. Fpga is a
> > virtex4sx35, and 100mhz clock is generated by a programmable clock
> > chip and i use dcm to get a 200mhz clock. I am kind of a new fpga
> > programmer and this is the first time i have seen a problem like this,
> > usually ise gives a timing error, but this time according to ise,
> > everything is perfect.
> > this is the timing constraint i use:
> > NET clka period = 10 ns;
> > clka is fed to the dcm.
>
> This is a constraint for your 100MHz clock, but don't you need to add
> a constraint for the 200MHz clock as well? (clkb period = 5 ns...)
> ISE should also report what the maximum allowable clock is, what does
> it say? (multiple clocks?)
>
> --
> Stef * *(remove caps, dashes and .invalid from e-mail address to reply by mail)
>
> * Always be sincere, even when you don't mean it. -Irene Peter

If you constrain the DCM input clock, it will automatically takes care
of the DCM derived clock's constraint i.e. 200MHz. You can check this
in the translate phase of design implementation.

-- vasu

[Database Administrator]

o0o0ozd@gmail.com wrote:

> I have seen a similar comment before which says dont use synchronizers
> for data buses.
> I thought what is the big deal

Basically, with the two-ff-synchronizer you're never sure when exactly
you'll get the result in the destination clock domain. Depending on when
the data comes in, you might or might not have to wait an additional
clock cycle. For single control or status signals this is usually
acceptable.

But if you have a data bus, it can happen that the delays for the bits
in that bus are different. So you might have another clock cycle of
latency on some bits but not on others, which obviously will cause problems.

What you can do is put a comparator in there that compares the
registered values behind the two synchronizer stages. Only if that
comparator finds the values are identical you generate a "valid" flag
that tells the other logic that the data is now stable and can be read.

But still there's a few things to consider there... When you use a FIFO,
everything's been taken care off and you don't have to worry about any
of those things.

The only thing you should make sure is that the inputs and outputs of
the FIFO should be registered. There shouldn't be any combinatorial
signals going into the data inputs and the outputs should be registered
as well before using them.

HTH,
Sean

--
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...

[Database Administrator]

On 12 Kasım, 18:14, o0o0...@gmail.com wrote:
> On 12 Kasým, 15:05, Sean Durkin wrote:
>
>
>
> > o0o0...@gmail.com wrote:
> > > and I will still check the IOB option but I use another clock(pci
> > > clock) to transfer the data. Basically, I have a tree-search algorithm
> > > which has to run fast(200mhz) and i have another slow algorithm which
> > > transfers the result through pci. I have a 2-ff synchronizers in
> > > between. Data is 128-bit long and i use 32-bit registers to send it.
> > > Design works at 100mhz, used to work at 150mhz when the logic was
> > > smaller. Bits in the middle change faster than the bits at the both
> > > ends of the 128-bit number, and these middle bits are the wrong ones.
> > > I have nothing so any comment,hint, reply is appreciated.
>
> > I'd suggest using an asynchronous FIFO for this. A synchronizer with
> > two flipflops ist fine for single control signals (at least most of the
> > time, but even then there's a whole lot of things to consider), but data
> > busses should be handled differently. The easiest method is just using a
> > FIFO, you can generate one that fits your needs with CoreGen and
> > instantiate it in your design.
>
> > So what I'd use is is a FIFO that you write to with 200MHz and read out
> > with 33MHz (or whatever your PCI clock is). You may need a little extra
> > logic (like a small state machine or something like that) to check the
> > control signals (FIFO full/empty and such), but it's not really a big
> > deal and a this is certainly a "clean" solution. Downside is you need a
> > few BRAMs, depending on how deep the FIFO needs to be. But you can just
> > generate one with CoreGen and how many it needs.
>
> > HTH,
> > Sean
>
> > --
> > My email address is only valid until the end of the month.
> > Try figuring out what the address is going to be after that...
>
> I have seen a similar comment before which says dont use synchronizers
> for data buses.
> I thought what is the big deal
> we will see, i ll try the fifo tomorrow, thanks for the advice.


I spoke too early, using fifo instead of synchronizers didn't solve my
problem. Although, it still returns incorrect results at 200 mhz,
there is some improvement. Before it didnt work at speeds higher than
100mhz, now after adding the fifo, it works at 180mhz clock speed.