FPGARelated.com
Forums

Question on timing constraints

Started by Paul Boven October 21, 2008
Hi everyone,

My Spartan-3A DSP kit has grown an Analog/Digital converter (AD9218 dual 
10bit 65MS/s) on its SystemAce port (the EXP connectors were a bit too 
much of a hassle to solder).

And I'm running into all kinds of funny timing issues, so I'd like to 
once again ask for a little help.

I run the on-board 125MHz clock through a DCM to get a 62.5MHz clock. 
This clock goes out of a pad towards the sampler, and the bits come back 
from the sampler. But, depending on rather unrelated changes in my VHDL, 
sometimes I get perfect samples showing the sine output from my signal 
generator, and sometimes there are all kinds of 'jaggies' indicating 
that I'm catching some bits either too late or too early.

But I also get 'Xst:2169 HDL ADVISOR - Some clock signals were not 
automatically buffered by XST with BUFG/BUFR resources', and "Route:455 
- CLK Net:adc_clk_OBUF may have excessive skew because 1 clk pins and 1 
non_clk pins failed to route using a clk template'

As an aside, pet peeve: why do the Xilinx error messages never tell you 
*which* clock is not getting a BUFG, or *which* clock ended up on a 
SideBufg - it's always "Some clock"

How would one properly specify the timing constraints for something like 
this? The examples the constraint guide seem to assume that both clock 
and data arrive at the FPGA from an external source, instead of the FPGA 
clocking such a source.

The Xilinx documentation is great at explaining which menu item to click 
or what syntax to use to specify timing constraints, but I'm looking for 
something that tells me what these things actually -mean-. Any pointers 
greatly appreciated.

Regards, Paul Boven.
hello,

I think you have a timing issue. are you using FPGA to generate a
62.5MHz clk to the AD9218 and then use the same clock to latch the
sampler data inside FPGA? if so, you need properly constraint this
clock in your design. can you send me your top file so that I can help
you figure out how to constraint this clock?

I agree with you. Xilinx user constraint guide is written like a law,
not convincing people, sometimes, just confusing people..

adam


On Oct 21, 8:53 am, Paul Boven <p.bo...@xs4all.nl> wrote:
> Hi everyone, > > My Spartan-3A DSP kit has grown an Analog/Digital converter (AD9218 dual > 10bit 65MS/s) on its SystemAce port (the EXP connectors were a bit too > much of a hassle to solder). > > And I'm running into all kinds of funny timing issues, so I'd like to > once again ask for a little help. > > I run the on-board 125MHz clock through a DCM to get a 62.5MHz clock. > This clock goes out of a pad towards the sampler, and the bits come back > from the sampler. But, depending on rather unrelated changes in my VHDL, > sometimes I get perfect samples showing the sine output from my signal > generator, and sometimes there are all kinds of 'jaggies' indicating > that I'm catching some bits either too late or too early. > > But I also get 'Xst:2169 HDL ADVISOR - Some clock signals were not > automatically buffered by XST with BUFG/BUFR resources', and "Route:455 > - CLK Net:adc_clk_OBUF may have excessive skew because 1 clk pins and 1 > non_clk pins failed to route using a clk template' > > As an aside, pet peeve: why do the Xilinx error messages never tell you > *which* clock is not getting a BUFG, or *which* clock ended up on a > SideBufg - it's always "Some clock" > > How would one properly specify the timing constraints for something like > this? The examples the constraint guide seem to assume that both clock > and data arrive at the FPGA from an external source, instead of the FPGA > clocking such a source. > > The Xilinx documentation is great at explaining which menu item to click > or what syntax to use to specify timing constraints, but I'm looking for > something that tells me what these things actually -mean-. Any pointers > greatly appreciated. > > Regards, Paul Boven.
On Oct 21, 7:53 am, Paul Boven <p.bo...@xs4all.nl> wrote:
> Hi everyone, > > My Spartan-3A DSP kit has grown an Analog/Digital converter (AD9218 dual > 10bit 65MS/s) on its SystemAce port (the EXP connectors were a bit too > much of a hassle to solder). > > And I'm running into all kinds of funny timing issues, so I'd like to > once again ask for a little help. > > I run the on-board 125MHz clock through a DCM to get a 62.5MHz clock. > This clock goes out of a pad towards the sampler, and the bits come back > from the sampler. But, depending on rather unrelated changes in my VHDL, > sometimes I get perfect samples showing the sine output from my signal > generator, and sometimes there are all kinds of 'jaggies' indicating > that I'm catching some bits either too late or too early. > > But I also get 'Xst:2169 HDL ADVISOR - Some clock signals were not > automatically buffered by XST with BUFG/BUFR resources', and "Route:455 > - CLK Net:adc_clk_OBUF may have excessive skew because 1 clk pins and 1 > non_clk pins failed to route using a clk template' > > As an aside, pet peeve: why do the Xilinx error messages never tell you > *which* clock is not getting a BUFG, or *which* clock ended up on a > SideBufg - it's always "Some clock" > > How would one properly specify the timing constraints for something like > this? The examples the constraint guide seem to assume that both clock > and data arrive at the FPGA from an external source, instead of the FPGA > clocking such a source. > > The Xilinx documentation is great at explaining which menu item to click > or what syntax to use to specify timing constraints, but I'm looking for > something that tells me what these things actually -mean-. Any pointers > greatly appreciated. >
> Regards, Paul Boven.
Until you provide timing constraints, you will continue to get erratic results. Use the clock-to-data-out time of your sampler to derive constraints for the data and clock relationships. Also make sure that you are using the IOB registers to capture the data; this will minimize timing problems due to design dependent routing. The Xilinx documentation provides enough examples to convey the meaning of the timing constraints. Are you using a UCF file to supply the constraints? Darol Klawetter
----- Original Message ----- 
From: "Paul Boven" <p.boven@xs4all.nl>
Newsgroups: comp.arch.fpga
Sent: Tuesday, October 21, 2008 1:53 PM
Subject: Question on timing constraints


> Hi everyone, > > My Spartan-3A DSP kit has grown an Analog/Digital converter (AD9218 dual > 10bit 65MS/s) on its SystemAce port (the EXP connectors were a bit too > much of a hassle to solder). > > And I'm running into all kinds of funny timing issues, so I'd like to once > again ask for a little help. > > I run the on-board 125MHz clock through a DCM to get a 62.5MHz clock. This > clock goes out of a pad towards the sampler, and the bits come back from > the sampler. But, depending on rather unrelated changes in my VHDL, > sometimes I get perfect samples showing the sine output from my signal > generator, and sometimes there are all kinds of 'jaggies' indicating that > I'm catching some bits either too late or too early. >
Paul, OK, I guess your 62.5M clock is coming from a bufg, right? Make the clock that goes to your ADC by using the output IOB's DDR registers with the clock connected to the DDR's clock, D1 <= '1' and D2 <= '2'. Also, make sure that the data from the ADC is clocked into your design using the FFs in the IOBs where the data comes in. This way your clock out and clock in are quite tightly constrained and the P&R variability should disappear. There are also delay elements in the input IOBs that are there to provide the 'zero hold time' feature. You may or may not want to adjust whether these are used after thinking about your timing. Good luck, Syms.
On Tue, 21 Oct 2008 14:53:37 +0200, Paul Boven <p.boven@xs4all.nl>
wrote:

>Hi everyone, > >My Spartan-3A DSP kit has grown an Analog/Digital converter (AD9218 dual >10bit 65MS/s) on its SystemAce port (the EXP connectors were a bit too >much of a hassle to solder). > >And I'm running into all kinds of funny timing issues, so I'd like to >once again ask for a little help.
Symon is right about making sure you use the FFs in the IOBs where appropriate. Just one further tip: the .mrp Mapper report file contains the information about which FFs/registers were pushed into the IOBs (in a section near the end). It isn't always what you expect, and it can take some fiddling to persuade the tools you want IOB registers. For example; some devices need a separate tri-state register per bit of output and an active low tristate signal. Also, you may need to attach "keep" attributes to signals, and/or "equivalent-register-removal" attributes set to "no" to specific signals to prevent the tools from helpfully removing redundant registers... - Brian
"Symon" <symon_brewer@hotmail.com> wrote in message 
news:gdllcb$1su$1@aioe.org...
> connected to the DDR's clock, D1 <= '1' and D2 <= '2'. Also, make sure > that
D'oh, D2 <= '0' !
Hi Symon, everyone,

Symon wrote:
> ----- Original Message ----- > From: "Paul Boven" <p.boven@xs4all.nl>
>> I run the on-board 125MHz clock through a DCM to get a 62.5MHz clock. This >> clock goes out of a pad towards the sampler, and the bits come back from >> the sampler. But, depending on rather unrelated changes in my VHDL, >> sometimes I get perfect samples showing the sine output from my signal >> generator, and sometimes there are all kinds of 'jaggies' indicating that >> I'm catching some bits either too late or too early.
> OK, I guess your 62.5M clock is coming from a bufg, right? Make the clock > that goes to your ADC by using the output IOB's DDR registers with the clock > connected to the DDR's clock, D1 <= '1' and D2 <= '0'. Also, make sure that > the data from the ADC is clocked into your design using the FFs in the IOBs > where the data comes in. This way your clock out and clock in are quite > tightly constrained and the P&R variability should disappear. > There are also delay elements in the input IOBs that are there to provide > the 'zero hold time' feature. You may or may not want to adjust whether > these are used after thinking about your timing.
The 62.5MHz is generated in the FPGA, first by a DCM and now simply by a clocked FF, and then goes into a BUFG that I had to instantiate. Adding the BUFG made the thing a whole lot more stable already, and took care of the original 'jaggies' problem I mentioned. The trick to clock a DDR output register to replicate the clock on an output pad is very neat, and should prevent the whole 'could not be routed by a clock template' problem. I'm not sure yet whether the input IOBs are clocking in the data directly, I will try and find out through the FPGA editor. If not, I'll add an extra level of registers, I guess. It also seems that I have quite a bit of jitter [1] on my sampling clock, which makes it unsuitable for undersampling the input signal (at around 120MHz) as I originally planned. I'll try and have a look at it with a faster oscilloscope to see whether the FPGA is causing this jitter. An external clock oscillator might have been a better idea. [1] http://www.xs4all.nl/~epboven/S3ADC-jitter.png Regards, Paul Boven.
Paul Boven <p.boven@xs4all.nl> writes:

> I'm not sure yet whether the input IOBs are clocking in the data > directly, I will try and find out through the FPGA editor. If not, > I'll add an extra level of registers, I guess.
I don't know if you've come across this, but I've found in the past (ISE9.1) that the extra level of regs *has* to go in the top level for them to be packed into the IOs. I spent a while putting the extra level into the module that needed them, with no effect :( Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
On Tue, 28 Oct 2008 08:55:12 +0000, Martin Thompson
<martin.j.thompson@trw.com> wrote:

>Paul Boven <p.boven@xs4all.nl> writes: > >> I'm not sure yet whether the input IOBs are clocking in the data >> directly, I will try and find out through the FPGA editor. If not, >> I'll add an extra level of registers, I guess. > >I don't know if you've come across this, but I've found in the past >(ISE9.1) that the extra level of regs *has* to go in the top level for >them to be packed into the IOs. I spent a while putting the extra >level into the module that needed them, with no effect :(
I have never done that. I have had to spend some time adding attributes "IOB", "keep" and "equivalent-register-removal" to the appropriate signals, but it worked with the registers where I wanted them. Admittedly I didn't try it in 9.1, but it worked in 7.1 and 10.1. (though 10.1 needed changes to the addributes required; I always had a suspicion it wasn't working correctly in 7.1 but didn't pin the issue down closely enough for a webcase) Oddly the values for "keep" are "true" and "false", but for equivalent-register-removal the values are "yes" and "no"... See for example http://www.xilinx.com/support/answers/21699.htm I'm not arguing against putting the registers at the top level; if it works portably it may be simpler than pushing a piece of string with attributes. - Brian
Hi guys
I'm a newbie in the fpga world, i'm studying for myself and the xilinx
documentation is not helping in anything.

I faced exactly the same problem as Simon

>I run the on-board 125MHz clock through a DCM to get a 62.5MHz clock. >This clock goes out of a pad towards the sampler, and the bits come back >from the sampler. But, depending on rather unrelated changes in my VHDL, >sometimes I get perfect samples showing the sine output from my signal >generator, and sometimes there are all kinds of 'jaggies' indicating >that I'm catching some bits either too late or too early.
But in my case the on-board clock is 50MHz and i generate with DCM a 100MHz clock(clk) that goes in a BUFG. This clock goes to 2 pads(enca and encb) towards 2 ADC of 100MHz. Than i get the bits from the ADC in an IOB. Here is the important part of my top file: entity top is port ( clk2 : in STD_LOGIC; ada : in STD_LOGIC_VECTOR(9 downto 0); adb : in STD_LOGIC_VECTOR(9 downto 0); enca : inout STD_LOGIC; encb : inout STD_LOGIC); end top; architecture stm_top of top is signal clk : std_logic; --ad signal ada_sync : std_logic_vector(ada'high downto 0); signal adb_sync : std_logic_vector(adb'high downto 0); begin --This unit has a DCM where i get the 100MHz clock clkunit : entity work.clock_unit Port Map ( CLK_IN => clk2, CLK_SEL => cfgreg(1), RST => reset, CLK_OUT => clk ); enca <= clk; encb <= clk; data_sync : process(clk) begin if rising_edge(clk) then ada_sync <= ada; adb_sync <= adb; end if; end process data_sync; end stm_top; And here is the ucf part #------------------------------------------------------------------------- # Time Constraints #------------------------------------------------------------------------- NET "enca" FAST; NET "encb" FAST; NET "clk2" TNM_NET = "clk2"; TIMESPEC "TS_clk2" = PERIOD "clk2" 19.75 ns HIGH 50 %; NET "clk" TNM_NET = "clk"; INST "enca" TNM = "CLKAD"; INST "encb" TNM = "CLKAD"; TIMESPEC "TS_CLKAD_TO_CLK" = FROM "clk" TO "CLKAD" 9.1 ns; INST "ada<0>" TNM = "ADCA"; INST "ada<1>" TNM = "ADCA"; INST "ada<2>" TNM = "ADCA"; INST "ada<3>" TNM = "ADCA"; INST "ada<4>" TNM = "ADCA"; INST "ada<5>" TNM = "ADCA"; INST "ada<6>" TNM = "ADCA"; INST "ada<7>" TNM = "ADCA"; INST "ada<8>" TNM = "ADCA"; INST "ada<9>" TNM = "ADCA"; INST "adb<0>" TNM = "ADCB"; INST "adb<1>" TNM = "ADCB"; INST "adb<2>" TNM = "ADCB"; INST "adb<3>" TNM = "ADCB"; INST "adb<4>" TNM = "ADCB"; INST "adb<5>" TNM = "ADCB"; INST "adb<6>" TNM = "ADCB"; INST "adb<7>" TNM = "ADCB"; INST "adb<8>" TNM = "ADCB"; INST "adb<9>" TNM = "ADCB"; TIMEGRP "ADCA" OFFSET = IN 7 ns VALID 6.5 ns BEFORE "clk2" HIGH; TIMEGRP "ADCB" OFFSET = IN 7.4 ns VALID 6.5 ns BEFORE "clk2" HIGH; First question: How do i guarantee that the delay between clk and enca is the same as clk and encb? Second question: Why do I get 0 paths analyzed when i use this constraint? TIMESPEC "TS_CLKAD_TO_CLK" = FROM "clk" TO "CLKAD" 9.1 ns; And the last one: When I try to use the IOB register for the ada and adb signals, the 2 constraints "ADCA" and "ADCB" always falls, why do this happen? INST "adb_sync_0" IOB = TRUE; INST "adb_sync_1" IOB = TRUE; INST "adb_sync_2" IOB = TRUE; INST "adb_sync_3" IOB = TRUE; INST "adb_sync_4" IOB = TRUE; INST "adb_sync_5" IOB = TRUE; INST "adb_sync_6" IOB = TRUE; INST "adb_sync_7" IOB = TRUE; INST "adb_sync_8" IOB = TRUE; INST "adb_sync_9" IOB = TRUE; INST "ada_sync_0" IOB = TRUE; INST "ada_sync_1" IOB = TRUE; INST "ada_sync_2" IOB = TRUE; INST "ada_sync_3" IOB = TRUE; INST "ada_sync_4" IOB = TRUE; INST "ada_sync_5" IOB = TRUE; INST "ada_sync_6" IOB = TRUE; INST "ada_sync_7" IOB = TRUE; INST "ada_sync_8" IOB = TRUE; INST "ada_sync_9" IOB = TRUE; I'm wasting a lot of time in this problem and I haven't any progress. Thanks everyone