Hi all ,
quartus prime 16.0 standard & quartus prime standard 18.0.0
FPGA : arria 10 (10AX115N2F45E1SG)
For this subject, I have question :
for the software (16.0), if there is unused transceiver ( Suppose I only use one simplex rx), I need use the set_global_assignment -name PRESERVE_UNUSED_XCVR_CHANNLE ON; But from above link, I know this assignment will only be used for other unsed RX other than any TX channel;
(2) from the link : Why might I see an occasional high Bit Error Rate (BER) after... (intel.com)
for the software(18.0.0), if there is unused transceiver (Suppose I only use one simplex rx), I need use the set_global_assignment -name PRESERVE_UNUSED_XCVR_CHANNLE ON; there's risk for me that there is the same problem as (2)'link except for that I do not define the assignment for the unused TX channle which is corresponding to the used RX. (just because the software version in the limit)
So, from the above cases, if I only have software 16.0 and 18.0.0, it's better for me to use 16.0; If I want to use 18.0.0, I only chose the set_instance_assignment -name PERSERVE_UNUSED_XCVR_CHANNEL <PIN_NAME> for each unuse TX or RX channel and can not use the set_global_assignment -name PRESERVE_UNUSED_XCVR_CHANNLE ON just because if I use later one, I have no method to reject the assignment to the unused TX channel which corresponding to the unused RX channel. I do not know if I understand these assignments right or not, could someone give me some advice if I use these two software or would you please tell me the right instruction?
The first question you need to ask yourself is do you care and plan to use the un-used Tx channel in future.
- The preserve command is used to preserve the un-used transceiver channel to prevent the performance degradation over time
So, if you don't care about un-used Tx channel for future use plan
- Just remove the qsf preserve command and you can use back either Quartus v16.0 or v18.0
Else if you care about un-used Tx channel for future use plan
- You CANNOT use v16.0 as there is bug in v16.0 where the preserve command for Tx channel is not working.
- You MUST USE v18.0 together with the preserve command + workaround plan as mentioned in the KDB article
- set_instance_assignment –name PRESERVE_UNUSED_XCVR_CHANNEL ON –to <pin name>
- In cases where the unused transmitter may be used in the future and preservation is required, you can instantiate a minimum datarate, dummy simplex transmitter corresponding to the used simplex receiver. You can set a static 0x00 pattern on the Tx parallel port, and select minimum VOD.
Anyway, my personal opinion will be to upgrade to latest Quartus version if possible to avoid all these troublesome known issue in older Quartus version.
If I use 18.0.0,
1) for the unused tx and Rx channel, I use the preserve command
set_global_assignment -name PRESERVE_UNUSED_XCVR_CHANNEL ON, but this command will lead to the risk presented in the link2.
so the best method is that I use the set_instance_assignment -name PRESERVE_UNUSED_XCVR_CHANNEL ON -to <pin_name>
Q1 : If so, I want to know the way to use this command:
for example : for differential pins, rx0p(k20), rx0n(k21)
so for these two pins, I need to write the assignments which has two methods:
1) set_instance_assignment -name PRESERVE_UNUSED_XCVR_CHANNEL ON -to k20
2) set_instance_assignment -name PRESERVE_UNUSED_XCVR_CHANNEL ON -to k21
I only need to write one as 1).
I want to know which one is right?
Q2 : I want to know which pins I need to assignment ? All unused pins? If so, when I do this， I face the fitter error. If not, which unused pins I need to assign, could you provide some advice?
Error (175019) : Illegal constraint of HSSI_PMA_TX_BUF to the location HSSIPMATXBUF_1C5
Info (175028) : The HSSI_PMA_TX_BUF name(s) : UNUSED_RXTX_CLOCK_WORKAROUND_FITTER_INSERTED_PMA_TX_BUF1
Error (16234) : No legal location could be found out 1 considered location(s). Reasons why each location could not be used are summarized below :
Error (175003) : The HSSI_PMA_TX_BUF location is occupied (1 location affected)
Info (175029) : HSSIPMATXBUF_1C5, Already placed at this location : HSSI_PMA_TX_BUF UNUSED_RXTX_CLOCK_WORKAROUND_FITTER_INSERTED_PMA_TX_BUF0
I read back the 2nd KDB link again. I am sorry, I think I explained wrongly to you.
If your plan is to use v18.0 in Rx simplex only while preserve its corresponding Tx channel
- you should not preserve the Tx channel using the preserve qsf command since there is bug in v18.0 as mentioned in the KDB. So, remove all your preserve qsf command
- you should preserve the Tx channel using the workaround instead which is instantiate a minimum datarate, dummy simplex transmitter IP corresponding to the used simplex receiver. You can set a static 0x00 pattern on the Tx parallel port, and select minimum VOD.
You mean that I should not use any of the below assignment on quartus 18.0.0:
set_global_assignment -name PERSERVE_UNUSED_XCVR_CHANNELON
set_global_assignment -name PERSERVE_UNUSED_XCVR_CHANNEL <PIN_NAME>
And what's the workaround, I didn't find it, could you please provide more detail information?
Correct. Don't use the qsf preserve command due to v18.0 bug and instead just follow the workaround.
The workaround is stated in the 2nd KDB link that you shared in the forum post earlier. I just copy paste the content and show you again only.
- Basically the workaround required you to instantiate dummy NativePHY IP in Tx simplex mode
- Keep Tx VOD to min setting and then send 0 pattern to this dummy Tx simplex NativePHY IP to keep it active to preserve it rather than relying on the qsf preserve command
- Assign Tx channel to the Tx location of your used Rx simplex pin
Glad to your response.
But from the later compilation result, I found the problem can not resolve by the above assignment. Just because when I clear all the compilation content and add some new modules into my project, the transceiver works bad for one lane of one link( I have two links, each link @1 simplex Rx IP, four channel for each IP which use bonding mode) using new got pof file, and this case will not change no matter how many times I compiled using 18.0.
1) Compared to 18.0, if I use the same project (add some new modules), the transceiver work well using the pof compiled by 16.0 ( I didn't add any above assignment).
2) And I found that after compilation, if some logic unrelated to transceiver path in my project has timing slack problem, the transceiver can works well.
So, I think
1) maybe there's risk logic in my code, I can not make sure because some compilation result can work well.
2) maybe there's route and fitter problem, but from the report, I could't got any useful information for me to found them just because there is no warning information about transceiver and related transceiver logic has no timing issue. Could you provide me some advice for me to get more information about it?
For the transceiver, I only use its PMA part and fewer PCS part (enhance PCS, more PCS logic is writen by myself). And I check the lane error at the point closely to the IP OUT(parallerl data) (8B/10B decoder, M-PHY protocol, 10Gbps).
If the exact same design can works well in v16.0 then it's unlikely your design issue and most likely is v18.0 issue.
I don't have good answer to you other than pls move away from v18.0 if possible and upgrade to latest Quartus version that contains bug fix for previous Quartus version.
Is there a reason why you can't move to newer Quartus version ?
Because that if I want to use newest software, I need to apply for software installation.
Continue to above problem,
I found that the routing hotspots is different for the pof file got from V16.0 and V18.0, as follow two pictures :
From above two picture, the routing hotspots got from V16.0 is better compared to the one got V18.0 (many part exceeds 95%), I compared the advanced settings of these two version software:
For V16.0, it has "Synthesis migration checks for stratix 10 " and V18.0 has no this item;
For V18.0, it has "Allow Register Dupilation" and "Allow Register Merging" and V16.0 does not see these item (maybe it enable these defaultly)
For advanced fitter,
For V16.0, it has " i/o placement optimization" and " Spectra-Q physical Synthesis" and V18.0 has no these item;
For V18.0, it has " Allow register Dupilation" and "Allow Register Merging" and V16.0 has no these item(maybe it enable these defaultly).
Besides above difference, other item is same for V16.0 and V18.0.
So, For V18.0, I closed the "Allow register Dupilation" and "Allow Register Mergin" Item, but the routing hotspots change more worse.
Could you tell me the difference for the complication between V16.0 and V18.0, and is there solution for that I can got the routing hotspots (got V18.0) same as V16.0?
Quartus continue to enhance on its fitting algorithm and feature from version to version but I am not the right support agent to advise you on Quartus feature.
You can file new forum post mention about your latest finding then Intel will be able to assign Intel FPGA software team support agent to better advise you on the Quartus feature support and changes.
- Do take note in your new forum post, pls ensure you type in the right keyword mention about the fitting algorithm difference between Quartus version so that you forum thread can be routed to the right Intel software support agent to help you up