Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

Constraining Nios Design

Hi there,

I have some constraining issues. I already read some stuff about it and how to use the TimeQuest Analyzer and all this, but I'm still not getting along. At least I got all my clocks constrained, but not slack free.

My Nios design is based on the Standard Ethernet Design Example from Altera. I added some stuff (DMA, another PLL ...) and all of it seams to works quite nicely. But in TimeQuest I get timing violations with some of my clocks and have lots of unconstrained ports and paths. What confuses me, the design example it self doesn't seam to be properly constraint as well. But I read, I really should constrain, well, everything.

So what can I do now? I'd like to constrain my design properly, but how.

First: What about the unconstrained ports? I can't set all of them as false paths, can I? How do I get the values to constrain them (from, to, time)? Same thing for unconstrained paths!?

Second: I have negative Setup, Hold and Recovery slack for some clocks. With "Report Timing" I already got a report, but I can't figure out how to set up the constraint. What clock and node do I have to use (Launch, Latch, From, To ???).

One other thing: My system is clocked by a PLL clock, master_pll.clk[1]. One component uses clk[0] and clk[2] of this PLL as well. In the "Report Clocks" report in TimeQuest only clk[1] of this PLL is shown, though. And in "Ignored Constraints/Create Generated Clock" this clk[1] shows up as well. What does that mean? What do i have to do about that?

Lots of questions, i guess not very precise ones eighter, but I'm clue less.

So any help appreciated :).

rico

6 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I would first start with contraining your I/O. All the other violations could be coming as a result of your I/O not being constrained. Whether you can cut those I/O depends on what they are. As a general rule of thumb if your I/O will operate under any skew/delay then typically you can cut them, otherwise you'll need to constrain them. So if it was say a PIO connecting to a push button or LED then that would be safe to cut, if it was a high speed interface then you *must* constrain it.

    So the question is, what interfaces are showing up in your unconstrained I/O list?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Ok thanks, sounds like a good way to start. I had a CPU reset and some push button i set as false path now. But there are still a lot of signals I can't determine what they are actually for. I descripted it in the following paragraph, but it might be easier to just lock at the table. So i attached a zip file with the unconstrained input and output paths. Could you tell me what these signals are for? How I do i get the constrain timing for the ones i cant set as false paths?

    Thanks very much.

    Then there are a lot of signals coming from "altera_reserved_tdi" and "altera_reserved_tms" going to some jtag stuff and a sld_hub:auto_hub. No idea what that is!? Another big chunk is something called fsd (16bit width) going to my flash tristate bridge|tcm_data_in_req. ideas on that? And then there is some ethernet signals enet_mdio to some req_data_rd and enet_rx_dv as well as enet_rxd(4bit) going to soe auto_generated|input_cell_l/h.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Those JTAG constraints can be found in the Quartus II templates menu (open your .sdc file, click the edit toolbar-->templates, then dig around the SDC section and you should find what you need for the JTAG interface).

    I wouldn't worry about the paths within the FPGA for now since those are most likely caused by some of your I/O not be constrained. For example, focus on getting fsd constrained (I'm assuming that's your bidirectional tri-state data signal) and less on the logic it is connected to. With bidirectional signals you need to specify input and output constraints, if I remember correctly this is done with the --add_delay argument for the additional direction.

    I would take a look at some existing design examples and see how they are constrained. Don't just blindly copy and paste the constraints over since they are board specific, but that should give you an idea of what to do.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    BadOmen,

    I have a Nios II design similar to the bup design found in CIII 3c120 Ethernet Standard design. For those set_input_delay and set_output_delay constrains applied to ext_flash input and output signals such as fsm[a], fsm[b] and etc, how can I determine the value of its delay? Do I always need to create a virtual clock or I can reference to osc clk as shown

    set_output_delay -clock [ get_clocks clkin_50 ] 2 [ get_ports {fsm_a

    [*]} ]

    set_input_delay -clock [ get_clocks clkin_50 ] 2 [ get_ports {fsm_d

    [*]} ]

    Is the delay '2' determined by clkin_50? What if I have an osc clk of 125MHz?

    Thanks
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    I highly recommend that link to Rysc's wiki page on TQ Daixiwen posted.

    In general having only one output and one input constraint for your I/O will not provide enough information. For outputs I use the device setup and hold requirements of the off-chip device along with board skews and other things that need to be in the equation. Inputs should be based on the clock-to-out time of the off-chip device as well.

    To answer your question about the '2' that should be based on the Tsu, Th, Tco as well as board delays (and skews). The delays should reference a clock so whatever off-chip clock you use for the SSRAM is the one that you want to make those constraints relative to. This should become more clear once you read Rysc's document.