Forum Discussion
Altera_Forum
Honored Contributor
16 years agoThanks for the response Rysc.
Sorry for the vaugness of my post. I am truly lost when it come to timequest. Previously I have been using the classic timing analyzer and only placing constraints on a design when they were nessesery. So if the FPGA gave my the timing by default I wouldn´t do anything. Anyway, I´m now working on a new design where another team will do another part of the design so I want to learn timequest and learn how to fully constrain a design as it´s about time I learned and also when another team are involved its probably vital that my part of the design is constrained. In the classic timing analyzer I seem to remember that Quartus would present me with the setup times for the worst case paths and I also had the option to place a constraint for the setup time. In Timequest I can only view the setup time using the -report_timing command when a constraint is already in place? The interface I am currently trying to constain is a parallel interface between the PowerPC 440GX and the FPGA. The Power PC is bus master and the interface consists of a 32 bits data bus, 32 bit address bus various control lines (CS, Write enable, output enable, parity). All lines change in a selectable sequence but the changes on the input signals always occur on the rising edge of the clock leaving the PPC. So in an attempt to learn timequest, I have been attempting to constain this interface, hopefully by doing this I can understand the basics and therefore have less problems constraining the remainder of the design. So one contraint nessesery is the set_input_delay constaint? What I understand from reading the documentation is that this constraint specifies the data arrival time with respect to the clock. In order to intelligently place the values in this constaint, I understand that I need to obtain the delay values on the PCB tracks in order to know if the data or clock are likely to arrive at different times? If for example I see that the track for the clock is slightly longer than for the data and that the clock will arrive lets say 2ns before the data then I should place a constraint as follows for each port: set_input_delay -add_delay -min -clock [get_clocks {PPC_GLUE_PER_CLK}] -2.000 [get_ports {PPC_GLUE_PER_DATA[0]}] Please let me know if I am way of the mark with the above statement. So what confused me about Rysc´s reponse to the intial post was that he gave by way of example placing a constraint of 4ns for the max and -2ns for the min. Is this basically saying that there can be a difference of 6 ns between the arrival of the clock and the data? and that timequest must deal with that and meet the setup and hold times for them? In my case, all inputs on this particular interface come from the Power PC and once the intial timing values are calculated then they should not change. i.e. If by analyzing the track delays I see that the clock will arive 2ns before the data bits and 1 ns before the address bits, 3 ns before CS etc, then I should put only the set_input_delay max constraint, which would be valid for both the max and the min? By placing these constraints, it allows timequest to meet setup and hold times, which the user cannot constrain directly? Is this true to say. I really appreciate the help you guys give, hopefully a push in the right direction will help to to understand the basics Many thanks for the help. EDIT: Perhaps I should add that the frequency of the clock is 66 MHz. I previously implemented this interface without constraining it on a different design. I used the falling edge of the clock in my design, while the PPC asserted all its signals of the rising edge. The FPGA gave the the timing I required and in the end i didnt constrain it.