Simple (?) timing constraint for output pins
in [FPGA]
|
From: Torsten Landschoff on 1 Apr 2008 04:36 Hi *, I am driving a bunch of DACs each having its own SPI bus with a Virtex4 FPGA. The test design is up and running fine (generating a sine output via an DDC generator implemented on the fabric). Now I want to make sure it still works fine after the FPGA is stuffed with more control logic. The DACs have both setup and hold time requirements for the serial data input (SDI) vs. the serial clock (SCK). My .ucf file should tell par the following constraint: For i in 1 .. 15: sdi<i> must be valid 5 ns before the rising edge on sck<i> and stay valid for 15 ns I tried the following constraint: NET "dac8811_sdi<1>" OFFSET = OUT 5 ns VALID 15 ns BEFORE "dac8811_clk<1>" HIGH; ISE report these errors: Checking timing specifications ... ERROR:XdmHelpers:865 - For OFFSET specification "OFFSET=OUT 5000 pS VALID 15000 pS BEFORE dac8811_clk<1> HIGH" on net "dac8811_sdi<1>", the given clock net "dac8811_clk<1>" is a device output. The OFFSET must reference a clock input net. Great - but how do I work with clocks generated inside the FPGA? The sck signal is generated from an 100 MHz quartz using a digital clock manager (DCM_ADV) of the Virtex. ERROR:XdmHelpers:874 - OFFSET specification "OFFSET=OUT 5000 pS VALID 15000 pS BEFORE dac8811_clk<1> HIGH" on net "dac8811_sdi<1>" has a VALID duration. The VALID clause is not supported on OUT-type OFFSET specifications. So I can't model a hold time requirement of an external component? Any hints appreciated. Unfortunately, the documentation of ISE is not that helpful how something like this is modeled correctly. I am thinking about using the OFFSET AFTER constraint (the data is written on the falling edge anyway) but I had hoped that the timing analyzer will protect against the wrong frequency on the output clock as well. Greetings, Torsten
From: job on 1 Apr 2008 05:08 On Apr 1, 10:36 am, Torsten Landschoff <t.landsch...(a)gmx.de> wrote: > Hi *, > > I am driving a bunch of DACs each having its own SPI bus with a > Virtex4 FPGA. The test design is up and running fine (generating a > sine output via an DDC generator implemented on the fabric). > > Now I want to make sure it still works fine after the FPGA is stuffed > with more control logic. The DACs have both setup and hold time > requirements for the serial data input (SDI) vs. the serial clock > (SCK). > > My .ucf file should tell par the following constraint: > > For i in 1 .. 15: sdi<i> must be valid 5 ns before the rising edge on > sck<i> and stay valid for 15 ns > > I tried the following constraint: > > NET "dac8811_sdi<1>" OFFSET = OUT 5 ns VALID 15 ns BEFORE > "dac8811_clk<1>" HIGH; > > ISE report these errors: > > Checking timing specifications ... > ERROR:XdmHelpers:865 - For OFFSET specification "OFFSET=OUT 5000 pS > VALID 15000 > pS BEFORE dac8811_clk<1> HIGH" on net "dac8811_sdi<1>", the given > clock net > "dac8811_clk<1>" is a device output. The OFFSET must reference a > clock input > net. > > Great - but how do I work with clocks generated inside the FPGA? The > sck signal is generated from an 100 MHz quartz using a digital clock > manager (DCM_ADV) of the Virtex. > > ERROR:XdmHelpers:874 - OFFSET specification "OFFSET=OUT 5000 pS VALID > 15000 pS > BEFORE dac8811_clk<1> HIGH" on net "dac8811_sdi<1>" has a VALID > duration. The > VALID clause is not supported on OUT-type OFFSET specifications. > > So I can't model a hold time requirement of an external component? > > Any hints appreciated. Unfortunately, the documentation of ISE is not > that helpful how something like this is modeled correctly. I am > thinking about using the OFFSET AFTER constraint (the data is written > on the falling edge anyway) but I had hoped that the timing analyzer > will protect against the wrong frequency on the output clock as well. > > Greetings, Torsten The best you can do is to make sure to use the flip-flops in the IO Block (FFs in the PADs) for the last register used for each output. Why it is the best: Because you do not need to play with constraint file. FFs in PAD to PAD timing are fix and well specified by FPGA Vendor. Laurent http://www.amontec.com
From: Torsten Landschoff on 1 Apr 2008 05:59 On 1 Apr., 11:08, j...(a)amontec.com wrote: > The best you can do is to make sure to use the flip-flops in the IO > Block (FFs in the PADs) for the last register used for each output. > > Why it is the best: Because you do not need to play with constraint > file. FFs in PAD to PAD timing are fix and well specified by FPGA > Vendor. True, but changing the device will change the implicit timing constraints that I set by putting the FFs there. I would like to define the requirements explicitly. Also, while the time from the FF to the pad is well defined, I can't be sure how the routing delay from the DCM-generated clock to the pad will be. Thanks, Torsten
From: Torsten Landschoff on 1 Apr 2008 09:37 On 1 Apr., 10:36, Torsten Landschoff <t.landsch...(a)gmx.de> wrote: > My .ucf file should tell par the following constraint: > > For i in 1 .. 15: sdi<i> must be valid 5 ns before the rising edge on > sck<i> and stay valid for 15 ns Okay, I am getting better. I now have this constraint for the SDI (serial data in) of the DAC: TIMESPEC TS_DAC8811_SDI = FROM "FFS" TO PADS("dac8811_sdi<*>") 5 ns; This would do fine, as the serial clock is running with 50 MHz and I drive the pad on the falling edge. Therefore, if the pad finishes the transition after 0 ns to 5 ns in relation to the clock output, all is fine: Even if the transition takes 5 ns, the setup time will be reached, and if it is instantly, the hold time is still okay as it allows changing the data together the the falling clock. Now, this constraint is a bit too tight, as the clock output will also take a bit to change. Any way to model that in ucf? Thanks, Torsten
From: MM on 2 Apr 2008 01:22
"Torsten Landschoff" <t.landschoff(a)gmx.de> wrote in message news:ee7e1353-2896-4df0-b1dc-bc05315e9848(a)t54g2000hsg.googlegroups.com... > > Also, while the time from the FF > to the pad is well defined, I can't be sure how the routing delay from > the DCM-generated clock to the pad will be. The standard solution is to regenerate the output clock with a DDR register in IOB. Check the following link for how it can be done: http://www.xilinx.com/support/answers/15194.htm If you put your data output register in IOB as well you will have a well defined source-synchronous interface. Its timing will only get better in any future silicon... /Mikhail |