rtl编译ide
㈠ vhdl 生成rtl图的操作
编译一遍，点击菜单栏Tool—>Netlist Viewer—>RTL Viewer查看综合后生成的寄存器传输级结构
㈡ FPGA中软件编译器和硬件综合器区别是什么
软件编译器是把高级语言编译成可执行文件，比如二进制代码
典型编译器如C/C++编译器
硬件综合器是把RTL级别的硬件代码综合成网表文件。是一个具体优化+映射的过程，代表语言是verilog/VHDL,转换成网表netlist
Turbo C就可以的。编辑文本的时候可以用utraledit
至于vc++之类的我是不推荐初学者使用的
㈣ C语言如何调用delphi的rtl库函数
加这个编译符就可以了：{$LINK 'FSK.obj'}
关键问题是，C语言中的内存管理不想用C的库函数realloc和calloc，而是想使用delphi的库函数AllocMem，ReAllocMem，FreeMem。因为，这些rtl函数在delphi的主程序中也会使用到，所以何必又要去联编C的Lib。
说明一下版本，delphi是7.0，bcc是那个免费的bcc 5.5.1
不调用库函数的obj联编没有一点问题。
声明不用你操心，用哪个函数是链接器的事儿，跟编译器没关系
简单的说，就是在.pas中写个与c语言库符号表中malloc/free等函数表示方式相同的形式，比如：
Delphi(Pascal) code
function _malloc(n: Integer): Pointer; cdecl; begin GetMem(Result, n); end;
在链接的时候，链接器就可以使用该符号链接了
例子可以看delphi提供的jpeg.pas单元，它就是链接到c语言编译的ijl库。新版本的delphi在source目录中直接就有源代码和.obj文件，老版本delphi在光盘目录中也能找到
没有想到如此刁钻的问题竟有如此巧妙的解法，太佩服了。
真的是融会贯通的编译器和连接器的道理才能想得出来。
㈤ 求nios II ide 的使用方法 我在网上找不到啊
Nios Development Board Reference Manual, Stratix II Edition
在使用Nios II SDK Shell试运行./restore_my_flash时，发现restore_my_flash会区分目录名的大小写，因此使用Nios II SDKShell时最好注意大小写一致。
restore_my_flash.pl为perl脚本，可以直接修改后直接执行。
restore_my_flash不能正常取得命令行参数，但这不影响恢复出厂设置的操作，因为restore_my_flash可以不依靠命令行参数来 执行。
最好不要移动NiosII的安装目录，例如restore_my_flash就会从目录名中提取内容生成需要的文件名。
恢复出厂设置需 要.sof和.flash两个文件，估计.sof用于生成最小的nios系统，以便将.flash文件下载到Flash中。 (restore_my_flash提示使用J24 JTAG连接器，该连接器是用于配置StratixII器件的。)
Creating Multiprocessor NiosII Systems Tutorial
在standard设计的基础上修改了Nios II系统，又添加了两个Nios II处理器及各自的定时器、共享互斥锁、消息缓冲区。编译、运行和调试了hello_world_multi程序。
给我的感觉是：
SOPC Builder中设置的NiosII的Reset和Exception地址很重要；
QuartusII生成的编程文件中包含有NiosII处理器的 复位地址；
NiosII IDE的编译会生成绝对地址的代码和数据；
NiosII IDE通过NiosII处理器中的jtag_debug_mole重定向程序的执行地址；
上电或复位后，NiosII处理器从复位地址(通常指 向Flash)处执行Boot Loader，将程序拷贝到Ram中并在Ram中执行；
Exception地址确定了程序拷贝到Ram中的位置，Exception地址的低位总是 0x20，NiosII处理器跳转到Ram执行时先执行低位地址为0x00的指令(用于初始化指令cache)，之后执行低位地址为0x20处的系统启动代码。
Nios II多处理器设计的注意点：
不支持SMP(对称多处理)，只支持不对称的(每个处理器执行不同的程序)；
处理器之间可以不共享资源；
同一程序存储器中的各处理器的代码空间不能重合(通过Reset和Exception地址实现)；
共享数据存储器最好用硬件共享互斥锁 结合软件操作的方式来实现，不支持纯硬件的共享方式(如果软件不使用硬件互斥锁，仍然会有访问冲突)，纯软件的共享方式有使用限制并且较复杂；
软件 共享互斥锁只适用于同一处理器的不同进程之间共享资源；
Nios II HAL library不支持共享外设(涉及中断处理、外设输入数据的处理等)，Altera建议由固定的处理器管理相应的外设，其他处理器要使用该外设可以通过 消息缓冲区的方式；
不同于单处理器设计，多处理器设计一定要明确规定每个组件的总线连接点；
只要由不同的处理器访问，两个组件可以有相同的地址；
由设计人员保证各处理器使用的代码空间是足够的、不发生覆盖的；
多处理器的软件的运行、调试可以一起或分别启动、终止，NiosII 5.0暂不支持一起暂停、再继续，“一起”不是“同时”。
Nios II Flash Programmer User Guide
关键点在于：
Quartus II的Programmer只支持FPGA和配置器件；
Flash Programmer只支持CFI接口的Flash或EPCS配置器件，但可烧入配置文件、软件代码和任意数据；
使用Flash Programmer需要生成Target Board及生成Flash Programmer可编程逻辑设计，并在实际项目SOPC Builder流程中指定该Target Board；
Boot-Copier Program是Nios II IDE自带的，当软件代码位于Flash或EPCS中时由Flash Programmer自行使用，不同的是对Flash而言Boot-Copier Program放在Flash中，对EPCS而言Boot-Copier Program放在EPCS serial flash controller包含的on-chip ROM中；
上电或复位时，Nios II从Boot-Copier Program开始执行(不论是Flash或EPCS)，这要求SOPC Builder流程中指定复位地址为Flash或EPCS serial flash controller。
Simulating Nios II Embedded Processor Designs
仿真NiosII设计包括三种方式：“NiosII IDE Debugger + Signal Tap II + 物理板”的软硬件联调方式；“NiosII IDE Debugger +指令集仿真器ISS”的软件调试方式(ISS可对部分组件建模)；使用ModelSim-Altera进行的RTL级的功能仿真方式(可以调试处理器及其 外设之间的交互情况)。本文针对RTL级仿真方式。
存储器的初始化：含有软件代码的存储器都应被初始化，不论是片上还是片外存储器；软件代码相关的存储器初始化文件由NiosII IDE编译软件时生成。
JTAG UART和PIO在SOPC Builder中都可设置仿真选项，ModelSim-Altera还可根据仿真选项调出UART交互终端窗口。
需要在SOPC Builder中设置ModelSim的路径和使能Simulation，之后SOPC Builder会生成仿真用的ModelSim项目文件、ModelSim宏命令、UART等组件的初始化文件。
需要在Nios II IDE中为System Library属性打开“ModelSim only,no hardware support”开关，这样在编译软件时才会生成代码相关的存储器初始化文件，但生成的代码不含启动代码(指令和数据Cache没有初始化、BSS段也不清除)，以便加速仿真。因此，如果要下载代码到硬件板，必须关掉“ModelSim only,no hardware support”开关并且重编译，以便生成完整的代码。
在Nios II IDE中以NiosII ModelSim方式运行(需设置ModelSim的路径)，将使ModelSim编译setup_sim.do并接管后续的仿真运行工作。
较重要的ModelSim宏(SOPC Builder生成)：s、w、jtag_uart_drive。
一定要从Nios II IDE运行ModelSim，jtag_uart_drive宏才能正常运行。其他仿真步骤都可单独使用ModelSim打开该项目，在执行完setup_sim.do后运行。
应该可以在SOPC Builder生成TestBench文件后修改该文件，以便进行Nios II和片上其他逻辑的联合仿真。(因为是SOPC Builder生成的TestBench文件，并没有在Quartus II中生成，所以不一定是完整的片上设计的TestBench文件。)
Avalon总线
NIOS和NIOS II都使用了Avalon总线，这是一种交换式架构的片内总线；
该总线形式和PCI、ISA等板间互连总线的最大区别在于：主从设备之间有紧密耦合关系。Avalon总线架构中，由硬件设计人员通过SOPC Builder规定互连的主从设备(包括数据、控制信号、片选、地址的互连)，不连接的设备之间是互相看不到的。
每个Avalon主设备端有多路复用器，用来从多个从设备的数据总线中选择当前要访问的数据——这也是“交换”的含义所在。可见多路复用器的接口引 线相当多，这只能在连线资源丰富的FPGA内实现。所以说，Avalon总线架构是适用FPGA设计的。片外的交换式总线也有，但都是串行接口的，主要是 为了降低PCB布线难度，如：PCI Express、以太网等。由于，Avalon总线架构中所有设备没有实现全互连，也就不存在“全交换”。但即使这样，不同的主设备访问不同的从设备也是 可以同时的、并发的。
每个Avalon从设备都有仲裁器，仲裁各主设备的访问，确保访问周期的完整性和正确性。我们可以认为访问周期是“原子”的，即不被其他主设备破坏的。
软件对共享资源的访问，通常要求一个序列的多个访问不能被其他CPU打断，这不是“原子”级的访问周期设计能保证的，这也是SOPC Builder中提供了硬件共享互斥锁的由来。
各CPU上运行的软件都可对某个硬件共享互斥锁进行SET和TEST操作，以争取对资源的占用能力。由于对硬件共享互斥锁的访问周期是“原子”，所以硬件共享互斥锁能保证多CPU设计中软件级别的共享资源互斥访问。
NIOS II设计的灵活性是我感兴趣的主要原因。只要有足够的逻辑资源余量，NIOS II的设计是可以不断更新的，设计人员不用为自己的设计能力、CPU版本的升级担心，这放开了我们的“思维”约束。
㈥ 如何使用C++Builder编译Delphi使用Obj文件
一直以来，Delphi 都可以用命令行 dcc32 ProjectName.dpr 对项目进行编译链接，非常方便，Delphi对项目文件的参数配置处理的很简单，便于阅读处理起来也很直观，编译的中间文件也很简单(dcu,dcp)。
而C++Builder就没那么幸运了，因为包含了C++的特征，各种编译的中间文件：lib,obj,res,map,tds。后来新版又增加了一些预编译文件：ilc,ild,ilf,...,pch,#00,...等等等等，各种搜索路径(Include Path,Library Path,Browse Path...)，要是用bcc32及ilink32手工进行编译链接，命令的参数都足够写上大半天。幸好，在旧版C++Builder中，如果要用命令行编译BCB项目，只要将bpr文件转换为mak文件，再使用make命令进行编译链接也比较方便，不需要过多的处理：
[plain] view plainprint?
bpr2mak -oProject1.mak Project1.bpr
make -fProject1.mak
自从Delphi/C++Builder开始使用 MSBuild* 编译系统后(好像是RAD Studio 2006开始，具体忘记了)，Delphi项目在保存为dpr的同时，也会保存一份dproj的项目文件，dpr依旧沿用旧格式，dproj 则以MSBuild规范以XML格式保存，除了可以用旧方式命令行编译dpr外，也可以用：
[plain] view plainprint?
msbuild.exe /t:Rebuild /p:Config=Debug ProjectName.dproj
进行编译，但msbuild必须设定一些环境变量，RAD Studio自带了一个命令行工具已经做好了这些，其实就是设定了以下几个环境变量($(BDS)in svars.bat)：
[plain] view plainprint?
@SET BDS=C:EmbarcaderoRAD Studio7.0
@SET BDSCOMMONDIR=C:UsersPublicDocumentsRAD Studio7.0
@SET FrameworkDir=C:WindowsMicrosoft.NETFrameworkv2.0.50727
@SET FrameworkVersion=v2.0.50727
@SET FrameworkSDKDir=
@SET PATH=%FrameworkDir%;%FrameworkSDKDir%;%PATH%
@SET LANGDIR=EN
C++Builder则又更杯具了一些，bpr2mak.exe工具已经没有了，所以只能采用MSBuild进行命令行编译。更加杯具的是，随着Delphi和BCB被多次转卖收购，新版本的发布似乎总会有各种各样的Bug，比如手头的RAD Studio 2009进行命令行编译，Delphi正常，BCB则报出超过100个错误，类似如下：
[plain] view plainprint?
C:EmbarcaderoRAD Studio7.0BinCodeGear.Cpp.Targets(2175,3): error : Error: Unresolved external '__fastcall Strhlpr::UnicodeFree(System::UnicodeString&)' referenced from C:EMBARCADERORAD STUDIO7.0LIBDEBUGVCLE.LIB|ustring
C:EmbarcaderoRAD Studio7.0BinCodeGear.Cpp.Targets(2175,3): error : Error: Unresolved external 'Typinfo::BooleanIdents' referenced from C:EMBARCADERORAD STUDIO7.0LIBDEBUGVCLE.LIB|vclinit
检查了一下发现编译过程(bcc32.exe)没有问题，只是在ilink32.exe链接过程中报错，在IDE中打开此项目进行编译，查看Message->Output窗口，比较两者的ilink32命令行参数，发现两者有两个地方有明显差异，一个是IDE生成的命令中没有类似 C:EmbarcaderoRAD Studio7.0libENdebug 的路径(指的是EN这个目录，去除上面rsvars.bat中的@SET LANGDIR=EN 就可以避免产生这样的搜索路径) ，但是虽然这个目录不存在，也应该不至于导致出错。第二个差异是缺少了rtl.bpi和vcl.bpi的附加obj参数，解决办法是在$(BDS)in目录中找到 CodeGear.Cpp.Targets 文件，用记事本打开，搜索字符“memmgr.lib“，在前面加上"rtl.bpi;vcl.bpi" (用;分隔，不含引号)，一共有两处要修改。或者查找 "c0w32"，在后面加上 "rtl.bpi;vcl.bpi"，只有一处修改 —— 因为IDE的命令行中 rtl.bpi vcl.bpi是在c0w32和memmgr.lib中间的。—— （注意：在XE2中，加在c0w32后面已经不管用了，编译会报另一个错误VCL.BPIW.OBJ不存在，Targets文件有很大变化，可能参数的位置变动过了，导致与其他参数混在一起，所以还是加到memmgr.lib处更加合理）。
一些组件包比如DevExpress的Package，没有dproj或者cproj 项目文件，只能通过IDE进行转换，但坑爹的是bpk在好几个版本以前(CRS 2007?)已经不支持bpk项目，根本打不开也谈不上转换了，但它其实是一个make文件，可惜用make命令编译还是要出错，不想去研究了。总之，BCB永远活在Delphi的阴影下。
㈦ QuartusII 13.1编译verilog后生成的RTL视图，看不懂
因为你的A是四位的，四位数字要加四位数字效率才高。
你要知道quartus是要最后载入到板子上的，你compile以后的东西是以板子用起来最方便为准，你的code只是个依据
㈧ Quartus 12.0RTL时提示did not specify an EDA simulation tool
点击菜单
assignments/settings
在弹出的界面按下图选EDA tool settings/simulation
然后在tool name下拉框中选择你要用的仿真工具，典型的如Modelsim。
㈨ 如何在命令行中使用intel c++编译器，并使用openmp和mkl来编译自己的程序，并运算
1、icc
Intel C/C++编译器接受遵守ANSI C/C++ , ISO C/C++ standards,GNU inline ASM for IA-32 architecture标准的输入。与linux下常用的gcc兼容并支持更大的C语言扩展，包括源文件、命令行参数、目标文件。不支持gcc的inline方式的汇编。例，f.c
#include<stdio.h>
int main(int argc, char* argv[]){
printf("Hello\n");
return 0;
}
编译：icc -c f.cpp -o f.o
链接：icc f.o -o f
运行：./f
注意，编译与链接都由icc来完成，icc常用命令行参数：
-o 输出文件命名
-I include路径
-L lib路径
-l 包含的lib名
-c 仅生成目标文件(*.o),不链接
-On n=0,1,2,3 编译器优化选项，n=0关闭编译器优化，n=3使用最激进的优化
-c99[-] 打开/关闭 c99规范的支持
详细的请参照icc的manpage.
2、ifort
Intel Fortran编译器支持F77/90/95标准并与CFV(Compaq Visual Fortran)兼容。例，f.f90
program f
print *, "Hello"
stop
end
编译：ifort -c f.f90 -o f.o
链接：ifort f.o -o f
运行：./f
编译与连接同样由ifort来完成，ifort常用命令行参数：
-o 输出文件命名
-I include路径
-L lib路径
-l 包含的lib名
-c 仅生成目标文件(*.o),不链接
-On n=0,1,2,3 编译器优化选项，n=0关闭编译器优化，n=3使用最激进的优化
-std90 使用F90标准编译
-std95 使用F 95标准编译
-f77rtl 编译使用F77运行方式的代码（用于解决特殊问题）
These options optimize application performance for a particular Intel? processor or family of processors. The compiler generates code that takes advantage of features of the specified processor.
Option
Description
tpp5 or G5 Optimizes for Intel? Pentium? and Pentium? with MMX? technology processors.
tpp6 or G6 Optimizes for Intel? Pentium? Pro, Pentium? II and Pentium? III processors.
tpp7 or G7 Optimizes for Intel? Pentium? 4, Intel? Xeon?, Intel? Pentium? M processors, and Intel? Pentium? 4 processors with Streaming SIMD Extensions 3 (SSE3) instruction support.
On Intel? EM64T systems, only option tpp7 (Linux) or G7 (Windows) is valid.
About tpp:
http://www.ncsa.illinois.e/UserInfo/Resources/Software/Intel/Compilers/9.0/main_for/mergedProjects/copts_for/common_options/option_tpp567_g567.htm
https://wiki.ke.e/display/SCSC/Compilers+and+Libraries
Intel Fortran Compiler Options: http://geco.mines.e/guide/ifort.html
Intel(R) Fortran Compiler Options: http://www.rcac.pure.e/userinfo/resources/common/compile/compilers/intel/man/ifort.txt
ifort编译器提供了非常多的优化参数
$ ifort --help | more 查看就可以
也可以定位到某个参数
$ifort --help | grep -5 '-mkl'
-5表示显示查找到的行及下面5行的内容。
3、Intel MKL数学库针对Intel系列处理器进行了专门的优化，主要包含的库有：
基本线形代数运算(BLAS)
向量与向量、向量与矩阵、矩阵与矩阵的运算
稀疏线形代数运算
快速傅立叶变换(单精度/双精度)
LAPACK(求解线形方程组、最小方差、特征值、Sylvester方程等)
向量数学库(VML)
向量统计学库(VSL)
高级离散傅立叶变换
编译:
icc multi.c -I/opt/intel/mkl/include –L/intel/mkl/lib –lmpi_ipf –o multi
4、MPI程序编译
消息传递接口(MPI)并行程序设计模型程序的编译命令。例，f.c
include<stdio.h>
#include<mpi.h>
main(argc,argv)
int argc;
char *argv[];
{
char name[BUFSIZ];
int length;
MPI_Init(&argc,&argv);
MPI_Get_processor_name(name, &length);
printf("%s: hello world\n", name);
MPI_Finalize();
}
编译与连接均使用mpicc,参数与mpicc中定义的编译器相同，这里与icc相同。
mpicc –c hello.c –o hello.o
mpicc hello.o –o hello
运行使用mpirun 命令，将运行需要的节点定义在文件中并在-machinfile中制定。
文件: nodelist
node1
node1
node2
node3
运行：
$mpirun –machefile nodelist –np 4 ./hello
node1: hello world
node1: hello world
node2: hello world
node3: hello world
5、32位向64位的移植
32位程序到64位移植中应注意的常见问题：
数据截断：
由于long类型变量的运算（赋值、比较、移位等）产生。long定义在x86上为32bits,而在ia64上为64bits.容易在与int型变量运算时出现异常。
处理方法：尽量避免不同类型变量间的运算,避免将长度较长的变量赋值到较短的变量中，统一变量长度可以解决这个问题。简单的对于32位转移到64位可以将所有long定义转换为int定义。