Timing Constraints for I/O

[netturan]

I've recently started to explore the world of FPGA and it has really been a productive journey so far. I've been writing HDL designs and going through different resources so far. Now that I've got my first FPGA I've decided to test my design finally. I've been reading about how I need to look into more details regarding timing and I wanted to know what exactly do I need to make sure that my design works.

My design has a communication interface that takes in commands at a faster clock and sends triggers to my design to execute it. For this, I have written up a 2ff synchronizer that toggles every time a command is to be executed. For this, I'm using the JTAG internal access available on my FPGA, when the JTAG FSM goes into the UPDATE state a signal in the primitive goes high which I use as a trigger to toggle a 'sync' signal through a synchronizer. When this toggle is observed by the internal entity it loads the data that had been shifted into the primitive ( Something I read up about clock domain crossing, don't know much). I haven't handled such a design before so I've been reading up about STA and closure .etc


Keeping this in mind what should be my goal while writing timing constraints?

 

[KlausST]

Hi,

I wanted to know what exactly do I need to make sure that my design works.

Even without timing constraints the compiler will make your design to work.

But if you (your application) requires to keep some timing, you have to tell the compiler about it.

Example:
* Blinking a LED with 1Hz. .. will work in either case, since even in worst case the FPGA is way faster.

* but if you want to access to an external SRAM with 50 million write cycles per second...you need to ensure proper SRAM timing.

So you have to read the SRAM datasheet, find out the timing requiremt and tell the compiler about it.

Now the compiler will translate your design to meet the desired function, then it will test whether the "compiled solution" will meet the timing requirements. If not, it will run a new complation with some optimisation to meet your timing requirement. Maybe it has to do a lot of compile runs. In best case it finds a suitable solution, otherwise it will tell you that it is impossible to meet the timing requirements. And it will tell you which path does not meet the requirement.

****

Usually one of the first things when you start an FPGA design is to decide the requirements. Not only functional, but also with timing.
And as so often. Requirements need to be very clear. Phrases like "a faster clock" won´t work.

Klaus

 

[netturan]

Hi,

Even without timing constraints the compiler will make your design to work.

But if you (your application) requires to keep some timing, you have to tell the compiler about it.

Example:
* Blinking a LED with 1Hz. .. will work in either case, since even in worst case the FPGA is way faster.

* but if you want to access to an external SRAM with 50 million write cycles per second...you need to ensure proper SRAM timing.

So you have to read the SRAM datasheet, find out the timing requiremt and tell the compiler about it.

Now the compiler will translate your design to meet the desired function, then it will test whether the "compiled solution" will meet the timing requirements. If not, it will run a new complation with some optimisation to meet your timing requirement. Maybe it has to do a lot of compile runs. In best case it finds a suitable solution, otherwise it will tell you that it is impossible to meet the timing requirements. And it will tell you which path does not meet the requirement.

****

Usually one of the first things when you start an FPGA design is to decide the requirements. Not only functional, but also with timing.
And as so often. Requirements need to be very clear. Phrases like "a faster clock" won´t work.

Klaus

By "faster clock" I meant the the μC I'm using to send data has a 32MHz clock and I'm planning to run my fpga at a clock below 5MHz.

 

[KlausST]

Hi,

I'm planning to run my fpga at a clock below 5MHz.

Why? I don´t recommend this unless your application is very power consumtion sensitive.

Most FPGAs are happy with 100MHz+. If you internally want to use slower clock then use a divider to generate a clock_enable.

Mind: It´s easy t generate slower clocks (_enable) but it is more difficult to generate a higher frequency clock. You need a PLL for this.
Faster clocks just have the disadvantage of higher current consumption. But they give more flexibility.

Klaus

added: and with using the microcontroller clock you are automatically "synchronous", no need for a complicated clock domain crossing.