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定義。