Cadence SCH复制器件报错ORCAP-1658、ORCAP-1746、ORDBLL-1125、ORDBLL-1055的原因及解决方法

探讨了在Cadence软件中复制SCH文件时遇到的报错问题,并提供了一种通过编辑器件逻辑符号来触发软件真正执行更新操作的解决方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 

自己整理了库文件用于平常设计使用,但是偶尔会遇到从原来的SCH中复制电路到新的SCH中时报错的情况,报错的代码如上所示几种。

空闲的时候做了试验来探究问题的原因,因为不太懂代码也看不到底层代码逻辑,因此这里只是给出推断和解决方法。

这个问题是很奇怪的,明明是同一个路径的逻辑封装,只是在两个SCH中,互相复制却会报错?

cadence不知道什么原因将两个SCH中的同样库文件路径的器件认为是不同的版本,于是有冲突,这个我没有去深究原因,可能与版本之间转换或者其他操作导致cadence认为有区别,但是我们在软件上能看到的似乎并没有什么明显的区别。

针对复制报错这个问题,网上通常给出的方法是在Design Cache中将报错的器件进行update操作,或者replace操作,但是往往并没有效果,原因我大概推测了一下,无论是update还是replace,如果还是同样的路径,实际上这个操作可能并未真的执行,只是进行了比较判断,除非是器件确实不一样才会更新,因此看似更新了,实际软件并未更新这些器件。

如果将库文件重新换个文件夹,将两个SCH中报错的器件全部重新按照这个新的路径update或者replace,似乎是可行的,也就是说,更换路径,cadence会真的执行更新操作,将对应的器件更新或替换。

按照这个思路,我又做了几种尝试,且将这两个SCH命名为A和B,库文件命名为C,路径为D盘根目录,冲突的器件有C0402、R0402、E0402三种,有些人使用的版本打开SCH后并不会直接链接库文件,如果cadence因为不知名的原因把A和B中的这几种同路径同库文件的器件认为是两种不同的版本,那么就会冲突报错!

我将A和B复制了一份为AA和BB,先打开A和B,互相复制会报错,在cache中执行update或replace,问题依旧。调用库文件C,将新的C0402添加到A和B中,该操作可行,再将刚添加的器件在A和B之间复制,同样报错,问题是这是我刚从同一个库文件中调用的器件啊?为何报错了呢?我推测,调用的器件因为和cache中以前的器件同路径同库文件,因此会被当前SCH归类为同一版本,所以放到SCH中的那一刻,这个器件已经变了版本,跟随了当前SCH中的cache中器件属性!

如前所述,update和replace显然没有执行真正的更新操作,更换库文件路径重新指向库文件进行update或replace是可行的,那还有什么方法能真正实现更新操作呢?

可以进行如下操作,找到SCH中报错的同类型的器件中的任意一个,右键选择edit part,对逻辑符号的value或者位号进行移动,再移回原位,然后关闭,cadence会认为你更新了器件的逻辑符号,在弹出的框中选择update all,这样会执行真正的更新操作,cadence会逐一更新重新链接库文件

 

 

 

 实际我等于并未更改器件,仅仅是利用了软件这一更新操作,之后A和B之间互相复制这个类型的器件就不会报错,不要关闭cadence,打开之前复制的另一份AA和BB,此时AA和BB无需执行上述操作,对应的器件可以成功复制了,由此可见,最关键的问题还是cadence没有主动去链接对应的库文件,当然如果cadence没有把这些器件认为是不同版本也不会报错。

同样要对每种类型的器件都这样操作才能消除所有的报错,无法让cadence同时重新更新所有的器件的链接关系。但是问题至少算是清晰了一些,不至于胡乱操作。

不过这个问题应该是cadence的一个BUG,大概cadence是为了提高速度,cache的update和replace是比较后发现不同才更新,但是这个不同显然没有包括这里报错的所谓版本不同,这个信息没有进行比较,被忽略了,但是复制器件的时候,cadence又会对逻辑符号版本进行检查,同器件不同版本就报错,这似乎就有了矛盾。

 如上是我今天的探究及实验所述,未必完全准确,应该有些参考价值。如有其他见解欢迎回复,谢谢!

### Cadence Design Rule Check (DRC) 中 ORCAP-1829 错误的解释与解决方法 尽管当前提供的引用并未直接提及 `ORCAP-1829` 的具体描述或原因,但可以通过分析其他类似的 DRC 错误来推测其可能的原因解决方案。 #### 可能的原因 通常情况下,Cadence 设计工具中的 DRC 错误会涉及电气连接、元件属性设置不当或其他违反设计规则的情况。对于未明确说明的错误码(如 `ORCAP-1829`),可以参考以下常见问题类别: 1. **元件封装缺失** 如果某个元件缺少对应的 PCB 封装定义,则可能导致类似 `ERROR(ORCAP-2434)` 的警告[^2]。这种问题也可能扩展到其他错误码中。 2. **非法字符检测** 当元件属性字段(例如 PCB 脚印名称)包含不被支持的特殊字符时,可能会触发类似于 `ERROR(ORCAP-36071)` 的错误[^4]。这表明某些输入数据不符合预期格式。 3. **网络别名冲突** 若存在多个具有相同功能却命名不同的信号网路(nets),则会引发短路风险提示 (`WARNING(ORCAP-1589)`) 或更严重的验证失败情况[^5]。 基于上述背景信息以及一般性的电路板布局原则,以下是针对潜在 `ORCAP-1829` 问题的具体建议措施: #### 解决方案 为了有效应对未知编号的设计违规事项并确保项目顺利推进,请尝试执行下列操作之一或者组合应用它们视具体情况而定: 1. **审查所有受影响对象及其关联参数** - 使用软件内置报告生成功能获取详尽列表展示哪些地方存在问题所在位置坐标等细节以便快速定位目标区域进行修正处理. 2. **确认零件库配置无误** - 对每一个出现问题记录里的组件逐一核查是否存在遗漏指定必要选项比如焊盘形状尺寸方向旋转角度等等因素影响最终装配效果. 3. **标准化文本录入习惯杜绝违禁符号混入其中** - 特别注意避免在任何需要手动填写的地方加入诸如句号逗号括弧之类容易引起误解的内容项从而减少不必要的麻烦发生几率. 下面给出一段简单的 Python 脚本用于批量替换文件内的特定字符串作为辅助手段帮助清理不良数据源实例演示如下所示: ```python def replace_illegal_chars(file_path, old_char='.', new_char='_'): with open(file_path, 'r') as file : content = file.read() updated_content = content.replace(old_char,new_char) with open(file_path,'w') as file: file.write(updated_content) ``` 通过运行此函数可自动将选定文档里所有的"."替换成下划线("_")形式达到统一标准目的同时降低再次遭遇同类事件可能性极大程度上提高了工作效率减少了返工次数提升了整体质量水平.
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值