Forum Discussion

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

problem about altlvds PIN assignment!

I want to use the altlvds megafunction to receive 500Mbps data(width=1),and the deserialization factor is 2.But now I face a strange problem:

if i use verilog to implement the function and assign the pins in assignment editor(stratixii EP2S180F1508C3 for example):

rx_in I/O Standard LVDS Yes

rx_inclock Clock Settings rx_inclock Yes

rx_inclock I/O Standard LVDS Yes

rx_out Virtual Pin On Yes

rx_inclock Virtual Pin On Yes

the rx_in will be automatically assigned to c3 and c4 (differential) and I can get perfect result in modelsim.

But if change rx_inclock to the factual pins ,ie:

rx_inclock Location PIN_Y3 Yes

the rx_in will be automatically assigned to c3 and c4 (differential) but i can't get correct result in modelsim(se 6.5).

Could anyone give me some suggestion where i made the mistake?thanks!

6 Replies

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

    Since the pin-location matters, I assume you're doing a timing simulation instead of a functional? (I'm not a big fan of timing sims, but that's another post altogether). So what's probably changes is the timing.

    Now, the altlvds is Hard IP, so I doubt it's timing values have changed, but going into the core it may have. When you say you don't get correct results, what does that mean? Are bits not aligned or are you getting incorrect data or Xs or a hard error?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    yes,I'm doing a timing simulation,and i mean getting incorrect data(whatever i input (1/0) i can only get 0),timing values have changed?What do you mean?

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

    By timing issue I meant with another place and route, the delays to outputs will vary and your outputs might not line up anymore. That's not the issue if you're seeing all 0s though. You may want to submit an SR to get someone to look at it. Is the PLL locking?

    Also might want to search the forums for discussions about doing timing sims. I find very few designers do these nowadays, as they tend to waste time and not find any issues that can't be uncovered with RTL sims and static timing analysis. Of course you're looking for a reason rather than "don't do that", but thought it was worth mentioning.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    What do you mean when you mention submit an SR? to whom?You mean timing sim is not worth doing? But from RTL sim you can only see if it is implemented as what you think,you can't tell the accurate timing.From my opinion,isn't timing sim static timing analysis?

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

    Go to www.altera.com and go to Support-> My Support. You can file a Service Request there. That's how to get an engineer to look at the issue, where this is just a board for people to help each other and bounce ideas around.

    And no, a timing sim is not static timing analysis. Static timing analysis is a bound analysis of all your delays in relation to your clocks. For example, if you have a 100Mhz clock, then your data delay can be anywhere between 0-10ns and the transfers will occur all right(I'm ignoring clock skew, but static timing analysis does a full-analysis of clock skew).

    Timing sims are just a single number. For example, most timing sims are with the slow model, so let's say your data path was modeled as 12ns. You would not get an error in the sim, unless your testbench actually failed because the data transfer occurred one cycle later. The only time timing sims give errors is if they violate the micro-setup/hold of the destination register, which means the data has to change within a ~50ps window around the clock.

    A good example would be across a bus. Let's say the entire bus delay was 12ns, and your testbench won't fail because it still sees all the data come over together. But in hardware they're going to be worst case 12ns, but might be a lot faster. So let's say some paths are 9ns. If your clock edge occurs at time 10ns, then these shorter paths have already transferred their data while the longer paths have not. Your timing sim would not catch this, but static timing analysis would.