Questions tagged «optimization»

12
在开发和调试阶段禁用优化真的是一个好习惯吗?
我已经阅读了C语言中的《编程16位PIC单片机》,书中有这样的肯定: 但是,在项目的开发和调试阶段,最好禁用所有优化,因为它们可能会修改所分析代码的结构,并使单步执行和断点放置成为问题。 我承认我有些困惑。我不知道作者是因为C30评估期而这么说还是真的是一个好习惯。 我想知道您是否实际使用此做法,为什么?

5
LTSpice自动化
我有一个电池供电的升压转换器,除了几种电池类型(各种电压/内部电阻)。由于我正在模拟(相对)大量的运行时间,因此模拟文件变得相当可观,更不用说要花一些时间了。我想使LTSpice自动化,以便可以以编程方式更改组件值,并重新运行仿真并捕获数据(电压或电流之类的值)。我知道: WAV文件可用于从程序输入/输出数据 该程序可以从命令行运行 到目前为止,我最好的选择似乎是将两种选择与我自己的代码/脚本结合使用,以达到我的目标的方式,但是我只是想知道是否已经有更好的方法了。 有没有人使LTSpice自动化,或者是否知道有(为制造商还是由第三方)为其编写的任何自动化API? 理想情况下,我希望有一个求解器,以便为它提供所需的参数,并尝试各种组件值,直到找到满足约束条件的“最佳”解决方案为止。

2
如何在VHDL中指定“无关”信号?
在逻辑设计课程中,我们都了解到可以最小化逻辑功能,例如通过使用卡诺图或Quine-McCluskey算法。我们还了解到“ Do n't Care”值增加了最小化的可能性。 例如拿一个注册文件。该write_address和write_data信号时,并不真正重要write_enable信号'0'。因此,应为它们分配“无关”值,以允许在驱动这些信号的逻辑中进行更多优化(即不在寄存器文件本身中)。 为了使综合工具有更多空间进行可能的优化,在VHDL中指定此类“无关”值的正确方法是什么? 到目前为止,我发现以下可能合适的方法。但是我不确定每个方法的优缺点是什么: 根本不分配信号。这似乎可以工作。但是我发现,当您想定义某种“不做任何操作的常量”时,它是行不通的record,因为需要完全指定记录常量(至少Modelsim告诉我了)。 所述std_logic_1164包定义的值'-' -- Don't care对std_ulogic。看起来这是一个明确的“无关”的语义正确选择,但我从未见过在任何地方使用它(除非在不相关的VHDL-2008 case?构造中)。 Modelsim使用该值'X'显示未定义的信号。但是我不确定综合工具是否将显式'X'分配理解为“无关紧要”。 这是一个过于简化的代码段,用于澄清,其中我已使用初始化了无关信号'-'。 正如你所看到的,信号control.reg_write_address可以有3个不同的值:"----",instruction(11 downto 8);和instruction(3 downto 0);。现在,如果'-'将其解释为“无关紧要”,我希望可以将其合成为2输入多路复用器。如果我使用(others => '0')而不是初始化信号'-',则该工具将不得不生成3输入多路复用器。 library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; package mytypes is type control_signals_t is record write_enable : std_logic; write_address : std_ulogic_vector(3 downto 0); read_address : std_ulogic_vector(3 downto 0); end record; …

3
如何确定使用最多资源和面积的FPGA设计区域?
我正在做一个大型FPGA设计,并且我非常接近当前使用的FPGA的资源限制,即CSG225封装中的Xilinx LX16。 该设计几乎也已经完成,但是目前它已不再适合FPGA。我可以关闭零件使其适合,但是我需要减少资源使用量才能完成设计并使其符合时序和尺寸要求。 我想知道我们的报告中是否有任何工具可以帮助我确定设计中哪些部分消耗的资源最多。我的设计未分区,而是划分为大约十二个或更多的VHDL模块。 Xilinx时序报告非常棒,但是现在我需要知道在节省空间方面我能得到最好的回报。 我也很难告诉我我将要用尽哪种类型的资源,或对那些资源有什么影响。 另一个烦人的是,随着设计的扩大,用于满足时序要求的组件开始出现故障,因为它们的放置不再理想。 当前,我使用“放置后和路线静态”时序报告,并使用SmartXplorer。我正在使用设计策略来优化时序。 在关闭我的设计的一部分以使其适合之后,下面是一些结果: 切片寄存器利用率:42%切片LUT利用率:96%完全使用的LUT-FF对的数量:38%这是否意味着我对寄存器比较轻,但对门的使用却很繁重? 是否有工具可帮助开发人员针对区域进行优化,或者至少使他们对自己的代码有更深入的了解? 更新: 查看了模块级别的利用率后,我发现我在整个地方都有小的胶水异步fifo,大约占所有LUT的30%。我将它们用作高速总线的跨时钟域胶水。我应该能够消除这些问题,因为时钟紧密相关。(120 MHz输入,通过DCM产生100 MHz和200 MHz)

7
简化许多窗口比较器
我有8个热敏电阻,必须确保每个热敏电阻都在温度窗口内。它们都具有相同的窗口,我不在乎哪个或多少在有效范围内,我只需要知道它们是否都在(相同)窗口内即可。这将是仅基于硬件的解决方案,因此ADC读取的软件排序是不可能的。 我目前最好的解决方案是使用一堆比较器IC,并为每个热敏电阻实现一个单独的窗口比较器。为了优化解决方案,我可以使用多个四极管比较器,每一个都具有漏极开路输出,以便可以将它们全部连接起来。当然,从本质上讲,它是相同的电路。我可以使一次基准电压/触发电压缓冲,然后提供给所有比较器。 我确实很愚蠢,只是简单地抛出一堆比较器来解决这个问题。我不确定是否还有更好的方法,我主要是在尝试优化电路板空间。您知道一些创意方法吗?例如,选择所有热敏电阻的最小/最大电压,并使用单个窗口比较器(编辑:c的两个比较器),恕我直言,IMHO会导致更大的解决方案,因此不是一个好答案,我在此仅出于启发目的。 编辑:我知道基于软件的解决方案将是最好的。这就是为什么我一开始就提到它的原因,以防止所有人提出它。用这种方法定义问题的原因是,这是一个安全电路,除软件监视器外,规格要求我实施仅硬件的解决方案。因此,基于软件的解决方案已经存在,我“只是”需要找到实现基于硬件的最佳方法。

10
获得整数mod 10和整数除数10的最快方法?
如果硬件不支持模数或除法运算,则需要更多的CPU周期来通过软件模拟模数/除法。如果操作数为10,有没有更快的方法来计算除法和模数? 在我的项目中,我经常需要计算整数模数10。特别是,我正在PIC16F上工作,需要在LCD上显示一个数字。有4位数字可支持,因此对模数和除法功能(软件实现)有4个调用。也就是说,如下所示: digit = number % 10; // call to an expensive function number /= 10; // call to an expensive function somehow_lit_segments(); digit = number % 10; // call to an expensive function number /= 10; // call to an expensive function somehow_lit_segments(); digit = number % 10; // …

4
为什么GCC编译器会省略一些代码?
我不明白为什么GCC编译器会在保留附近绝对相同的代码的同时删掉部分代码? C代码: #define setb_SYNCO do{(PORTA|= (1<<0));} while(0); ISR(INT0_vect){ unsigned char i; i = 10; while(i>0)i--; // first pause - omitted setb_SYNCO; setb_GATE; i=30; clrb_SYNCO; while(i>0)i--; // second pause - preserved clrb_GATE; } LSS的相应部分(汇编文件,由编译器创建): ISR(INT0_vect){ a4: 1f 92 push r1 a6: 0f 92 push r0 a8: 0f b6 in r0, 0x3f …
9 avr  c  avr-gcc  optimization  gcc 


1
虽然优化了循环
我的微控制器程序中有以下代码: // Wait for ADC conversion to complete while ( ( ADCSRA && _BS( ADSC ) ) == _BS( ADSC ) ) {} ADCSRA是一个寄存器,它将在模拟转换完成后更改其值,而我想等一下。该位指示转换完成。 查看生成的汇编代码,将整个循环替换为一条指令: in r24, 0x06 ; ADCSRA 读取了该寄存器,但尚未测试其值! 如何更改C ++代码以指示编译器继续重新检查寄存器,而又不会不必要地延迟程序? 我使用avr-gcc工具链。 编辑: 我更改了代码,如下所示(Thnx:lhballoti): while ( ( ADCSRA & _BS( ADSC ) ) == _BS( ADSC ) ) …
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.