抛去时钟因素，谈用到百分之多少没意义，你把频率降到50M，自然可能用到百分之90
--
FROM 111.192.247.*

不要光看lut，BRAM，DSP用得多的话也会影响布线
【 在 canoeheu 的大作中提到: 】
: V7-980，lut用48%，其他各种资源很少，但是就是布线不通过，说拥堵指数6。查网上说lut超50%可能布不下，不知道为什么？50%都布不下，还要多余的50%干什么呢？
--
FROM 221.217.88.*

这种情况一般就是逻辑架构设计不合理，或者是一些关键路径上的写法不对。 你可以先试试删除所有debug信号，看看能不能编译过去
--
FROM 117.91.137.*

你误解我意思了。我们曾经碰到过一个项目，4×12lane数据的收发，我们用sv的语言才开始将所有数据定义在一起，后来发现程序加到一定的程度在布线阶段经常出现拥塞，编不过去。后来偶然将这4×12lane的数据变成12lane一个模块，然后在外层在调用4次，从问题不再。除此而外还需要注意bram的宽度，以及有没有扇出特别大的信号，有没有可能加到全局时钟网络上。还有需要注意约束，x家有的软核，里面约束不够。这些事我们碰到的问题，需要一点点的去试

  
【 在 canoeheu (独木舟) 的大作中提到: 】
:
:  架构算法用的X家自己白皮书里的架构
:  【 在 linuxlee 的大作中提到: 】
:  : 这种情况一般就是逻辑架构设计不合理，或者是一些关键路径上的写法不对。 你可以先试试删除所有debug信号，看看能不能编译过去  
--
FROM 223.104.146.*

我的bram宽度就是64，深度15000左右，
也降不下来了，
而且十几个通道，
就是ram这里读，写的路径route延时大，
怎么办？
各项资源倒是都没超过50%。

【 在 linuxlee 的大作中提到: 】
: 你误解我意思了。我们曾经碰到过一个项目，4×12lane数据的收发，我们用sv的语言才开始将所有数据定义在一起，后来发现程序加到一定的程度在布线阶段经常出现拥塞，编不过去。后来偶然将这4×12lane的数据变成12lane一个模块，然后在外层在调用4次，从问题不再。除此而外还需要注意bram的宽度，以及有没有扇出特别大的信号，有没有可能加到全局时钟网络上。还有需要注意约束，x家有的软核，里面约束不够。这些事我们碰到的问题，需要一点点的去试
:  
--
FROM 221.219.170.*