1. Home
  2. Field-Programmable Gate Arrays
  3. Simple (?) timing constraint for output pins

Simple (?) timing constraint for output pins

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 must be valid 5 ns before the rising edge on sck and stay valid for 15 ns

I tried the following constraint:

NET "dac8811_sdi" OFFSET = OUT 5 ns VALID 15 ns BEFORE "dac8811_clk" HIGH;

ISE report these errors:

Checking timing specifications ... ERROR:XdmHelpers:865 - For OFFSET specification "OFFSET=OUT 5000 pS VALID 15000 pS BEFORE dac8811_clk HIGH" on net "dac8811_sdi", the given clock net "dac8811_clk" 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 HIGH" on net "dac8811_sdi" 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

Reply to
Torsten Landschoff
Loading thread data ...

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

formatting link

Reply to
job

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

Reply to
Torsten Landschoff

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

Reply to
Torsten Landschoff

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:

formatting link

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

Reply to
MM

done:

formatting link

Thanks for the pointer. I also found application note xapp265 about high speed data (de-)serialization.But it feel like a lot of overkill to use all this Xilinx magic to drive a simple 50 MHz SPI device...

After all I have a 5 ns window on the serial data line to set up the next bit - it can't be too hard to achieve this with a Virtex 4 while keeping the behavioural, portable VHDL design!?

Also, I fear that having a falling clock and changing the data line at the same instant could be too critical - I'd rather have the clock transition a bit before the data setup. (The DAC requires a hold time equal to the clock high period).

I placed the output FFs into the IOB, and I now meet the timing constraints defined below. But I don't know how long the clock takes to travel from the BUFG to the pad. Assuming that it takes 0 - 5 ns, all will be fine for my requirements.

Thanks for your suggestions!

Torsten

Reply to
Torsten Landschoff

I forgot to mention that we are going to connect the same DAC so a Spartan 3E as well, which I expect to have a slower timing (did not check though). Would be nice if we could just reuse the interface code. :)

Greetings, Torsten

Reply to
Torsten Landschoff

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.