多核心與Hybrid Memory Cub

DDR的發展已經到了瓶頸。

當未來是多核心的時代，而極端多核的GPU+GDDR，
因為架構設計的不同，並不適用在一般的CPU中。

因此Intel與美光就合作了Hybrid Memory Cub
參考網頁
http://news.watchstor.com/new-products-133848.htm
及美光網站說明
http://www.micron.com/products/hybrid_memory_cube.html


剛發表沒多久，三星就趕緊加入。
http://spiderman186.pixnet.net/blog/post/81270473-2011-10-09-%E7%9C%81%E9%9B%BB70%25%EF%BC%81%E7%BE%8E%E5%85%89%E3%80%81%E4%B8%89%E6%98%9F%E6%94%9C%E6%89%8B%E8%A3%BD%E5%AE%9Adram%E6%9C%80%E6%96%B0

所以現在變成了開放式介面規格。 

美光、三星是混合記憶體立方體聯盟(Hybrid Memory Cube Consortium，簡稱HMCC)的創始會員，將與開發夥伴Altera Corporation、Open Silicon, Inc.和Xilinx, Inc.密切合作，加速推出一系列相關技術。 HMCC一開始將著手定義技術規格，以便讓產品應用於大型網路、工業產品以及高效能運算等領域。 
 

那DDR4應該就死.....了。

DDR4的發展動態

稍稍研究了DDR3及DDR4的進展，作一點資料小整理。


可參考網頁
http://spiderman186.pixnet.net/blog/post/65916849-2011-06-30-ddr4%E6%9C%80%E6%96%B0%E6%8A%80%E8%A1%93%E8%A7%A3%E8%AE%80



重點在DDR3的多點總線到DDR4的點對點技術

DDR4 內存將會擁有兩種規格。其中使用Single-endedSignaling信號( 傳統SE信號)的DDR4內存其傳輸速率已經被確認為1.6～3.2Gbps，而基於DifferentialSignaling( 差分信號技術)技術的DDR4內存其傳輸速率則將可以達到6.4Gbps。由於通過一個DRAM實現兩種接口基本上是不可能的，因此DDR4內存將會同時 存在基於傳統SE信號和微分信號的兩種規格產品。其中AMD公司的PhilHester先生也對此表示了確認。預計這兩個標準將會推出不同的芯片產品，因 此在DDR4內存時代我們將會看到兩個互不兼容的內存產品。感覺似乎又要回到當年DDR內存與RAMBUS內存分庭抗禮的情形了。

    金邦曾透漏：承襲以往內存產品的發展走向，DDR4內存不外乎朝著高容量、高頻、低功耗發展。它的規格可能在DDR4 2133～DDR4 4266，工作電壓也將下降至1.0V～1.2V左右。這意味著DDR4內存在如此高頻率、低電壓的條件下運行，將需有更好的外部硬件設備來配合，否則容 易造成內存數據遺失現象，以及消費者常遇到的兼容性問題。

依據目前JEDEC公佈的數據看來，DDR4內存的每個內存信道只會支持一條內存模塊，內存控制器將採用點對點技術，將取代目前DDR3內存採用的多點 總線技術。如此一來，系統內存條的數量和容量都將受限制。因此在考慮如何增加系統內存數量與容量方面，將是DDR4內存後續生產在技術和成本方面需要重點 考慮的地方。

因為記憶體容量的限制，要讓DDR4規格好到達到足以取代DDR3，會是很困難的事。另外因為PC的CPU大廠已經內建DRAM-Controller，要說服AMD及Intel去支援DDR4，我想不會這麼簡單。

此處另外可以參考網頁

http://news.watchstor.com/new-products-133848.htm

有提到DDR3的封裝進展(這是另一種技術的發展)

Intel和美光（Micron）的点子则是将多个DRAM芯片堆叠在一起，通过一个逻辑处理层（CPU处理意义上的，不是DRAM制造层面）用来做缓冲和路由，使得DRAM的总带宽得到极大提高，功耗几乎保持不变。此逻辑处理层是这种“夹心饼干”式内存的关键，解决了堆叠多层芯片一个很重要的问题:如何将针脚“连”至每层。这种逻辑路由层混合DRAM的技术自然得名为"Hybrid Memory Cube"。

另可參考
http://gtrterry456.pixnet.net/blog/post/81473115-%E3%80%90%E7%96%91%E9%9B%A3%E9%9B%9C%E7%97%87%E3%80%91ddr4%E8%A8%98%E6%86%B6%E9%AB%94%E7%99%BC%E5%B1%95%E6%8A%80%E8%A1%93%E8%A7%A3%E6%9E%90

看看AMD方面的支援
未來AMD“Graphics Core Next”GPU將具備X86內存尋址特性，換句話說就是可以和CPU一樣調用系統內存，CPU通過MMU內存控制器訪問內存，而GPU則是通過IOMMU實現內存調用。這種新技術允許系統設備在虛擬內存中進行尋址，也就是將虛擬內存地址映射為物理內存地址，讓實體設備可以在虛擬的內存環境中工作，這樣可以幫助系統擴充內存容量，提升性能。所以未來將會受益於DDR4內存的高帶寬特性。

只是未必一定是使用DDR4才可以達到需求。

還有一件事是Mobile系統不需要太快的DRAM，只需要省電的DRAM

所以DDR4要在這一點上多下功夫， 或許還比較快平民化。

但是省電有省電用的Low Power DDR,

再加上DRAM廠的投資越來越貴，韓商想玩，日廠/台廠/美廠 可未必想玩
另外系統廠, CPU廠未必需要隨韓廠玩。

因此規格難定不說, 願意玩下去的廠商也不會太多。

在這個不景氣的年代，誰還在玩這個不賺錢的競速遊戲。


因此數年內DDR4要進的了大眾市場, 應該是非常困難的。

OpenRisc1200初解（四）

Debugging of Physical OpenRISC Targets

轉貼自http://opencores.org/openrisc,debugging_physical

Introduction

Physical implementations of OpenRISC systems can be debugged using a set of tools made available here at OpenCores.org. Whether simply poking registers in IP cores or debugging complex software executing on the processor, these tools provide a useful debugging capability. This section will outline how to setup the required tools, and perform debugging on a physical OpenRISC target.

OpenRisc1200初解（三）

如何去build GCC 4.5.1 for OpenRISC version 1.0 release candidate 1

首先要確認library中有 GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+.


先下載gcc-4.5.1-or32-1.0rc1.tar.bz2


然後解壓縮

進入目錄後使用./configure

可以確認各種狀況

GNU Multiple Precision Library (GMP) version 4.3.2 (or later)

Necessary to build GCC. If you do not have it installed in your library search path, you will have to configure with the --with-gmp configure option. See also --with-gmp-lib and --with-gmp-include. Alternatively, if a GMP source distribution is found in a subdirectory of your GCC sources named gmp, it will be built together with GCC.

MPFR Library version 2.4.2 (or later)

Necessary to build GCC. It can be downloaded from http://www.mpfr.org/. The --with-mpfr configure option should be used if your MPFR Library is not installed in your default library search path. See also --with-mpfr-lib and --with-mpfr-include. Alternatively, if a MPFR source distribution is found in a subdirectory of your GCC sources named mpfr, it will be built together with GCC.

MPC Library version 0.8.1 (or later)

Necessary to build GCC. It can be downloaded from http://www.multiprecision.org/. The --with-mpc configure option should be used if your MPC Library is not installed in your default library search path. See also --with-mpc-lib and --with-mpc-include. Alternatively, if an MPC source distribution is found in a subdirectory of your GCC sources named mpc, it will be built together with GCC.



其實還需要升級GLIBCXX　到　3.4.9
請參考另一篇文章

所有的library都完成升級後
configure才會過

這樣就可以完成使用make來作build的工作了

make
make check (如果有錯，可忽略)

OpenRisc1200初解（二）

下載openrisc的toolchain

可到http://opencores.org/openrisc,gnu_toolchain

 最簡當的方法就是直接對http://opencores.org/ocsvn/openrisc/openrisc/trunk/gnu-src/
用SVN來checkout

就可得到所有的openrisc toolchain的source file


如果需要The source for uClibc and Linux
 就用git來下載

uClibc and Linux kernel source

git clone git://git.openrisc.net/jonas/uClibc
git clone git://git.openrisc.net/jonas/linux

OpenRisc1200初解（一）

在http://opencores.org/download,or1k
下載了Or1ksim 0.4.0 stable release

然後到centos4.8及5.7中去作make的動作

依照文件上的說明
tar  jxf  or1ksim-0.4.0.tar.bz2
mkdir  builddir_or1ksim
cd  builddir_or1ksim

../or1ksim-0.4.0/configure  --target=or32-uclinux

make  all

結果產生錯誤
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../cpu/or32 -I.. -I../cpu/common -I../cpu/or1k -I../cache -I../mmu -I../bpb -I../peripheral -I../tick -I../peripheral/channels -I../pm -I../pic -I../debug -I../vapi -I../support -I../cuc -I../port -I../argtable2 -g -O2 -g -Wall -Werror -O2 -DOR32 -MT rsp-server.lo -MD -MP -MF .deps/rsp-server.Tpo -c -o rsp-server.lo rsp-server.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../cpu/or32 -I.. -I../cpu/common -I../cpu/or1k -I../cache -I../mmu -I../bpb -I../peripheral -I../tick -I../peripheral/channels -I../pm -I../pic -I../debug -I../vapi -I../support -I../cuc -I../port -I../argtable2 -g -O2 -g -Wall -Werror -O2 -DOR32 -MT rsp-server.lo -MD -MP -MF .deps/rsp-server.Tpo -c rsp-server.c -fPIC -DPIC -o .libs/rsp-server.o
cc1: warnings being treated as errors
rsp-server.c: In function ‘rsp_remove_matchpoint’:
rsp-server.c:2233: warning: dereferencing type-punned pointer will break strict-aliasing rules
rsp-server.c: In function ‘rsp_insert_matchpoint’:
rsp-server.c:2313: warning: dereferencing type-punned pointer will break strict-aliasing rules
make[2]: *** [rsp-server.lo] Error 1
make[2]: Leaving directory `/home/strongleg/Project/OpenRISC/or32-build/or1ksim-0.4.0/debug'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/strongleg/Project/OpenRISC/or32-build/or1ksim-0.4.0'
make: *** [all] Error 2


根據
http://opencores.org/bug,view,1735
的說明
The last error here relates to or1ksim-0.4.0, the latest toolchain install script is using or1ksim-0.5.0rc2 and I'm quite sure these warnings have been resolved.

因此改下載
Or1ksim 0.5.0 release candidate 2

然後照上面的步驟在centos4.8上再作一次
make all　　--> 沒有錯誤
make check  --> 還是有錯，不與理會
make install  --> 在root下成功安裝　 or32-uclinux-sim
 
初步成功 

在centos5.7-64bits上再作一次 
也一切無誤

最後使用root帳號
make install 安裝 

安裝後產生三支執行檔
or32-uclinux-mprofile  
or32-uclinux-profile  
or32-uclinux-sim

在
/usr/local/bin

還有
or1ksim.a
or1ksim.so
在/usr/local/lib


or1ksim.h
在/usr/local/include




 

gcc 編譯器移植參考資料

GNU的GCC用的非常多了
但對一個要自行設計或維護CPU/DSP的人來說
一個客製化的GCC或說tool-chain就是非常需要了


參考陳教授的網站

http://ccckmit.wikidot.com/gcc:ref

GNU的GCC說明區
http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top

http://sp1.wikidot.com/gcccrosscompiler


http://gcc.gnu.org/onlinedocs/gccint/

wiki上的說明
http://en.wikipedia.org/wiki/GNU_Compiler_Collection

http://en.wikipedia.org/wiki/GNU_toolchain


跨平台編譯((CrossCompiler CrossCompiler))可參考
跨平台編譯小說明

http://sp1.wikidot.com/gcccrosscompiler

risc cpu @ systemc

risc cpu @ systemc
轉貼自http://funningboy.blogspot.com/2010/09/risc-cpu-systemc.html?showComment=1317181463530#c126477895408032611


因為原來在systemc-2.2.0的example下的risc_cpu
Compile後，run simulation，會有錯誤發生
所以作者將它修正後，提供下載

hi all, If you are interest in the CPU architecture design,i think the 'rsic cpu' is a good choice.It is a sample package in systemc example, but it contain some problems with multi-drive. What's the multi-drive, it means the multi inputs drive the same output. you can image the data in this point is unstable, it should be 1 or 0 or x.... ,so the compiler would confuse what's the data in it.Because in systemc is no wire definition, in 'sc_signal' declare it like the register or buffer design, it would keep the current data until the next trigger to change it's data. we use a very sample way to avoid it, to create a new module and change the declare of 'sc_signal' to 'sc_in' and 'sc_out' . all new packages and version is release in here please use this command to compile our package.

原作者修正問題後的Package下載點
https://sites.google.com/site/funningboy/c/2010_1003_risc_cpu.tar.gz?attredirects=0&d=1

使用以下指令去compile risc_cpu files
g++ *.cpp -I/usr/systemc/include -L/usr/systemc/lib-linux -o cpu -lsystemc

如果是64bits
g++ *.cpp -I/usr/systemc/include -L/usr/systemc/lib-linux64 -o cpu -lsystemc 


修正的方法
1 fix lists 1. multi drive example Error: (E115) sc_signal cannot have more than one driver: signal `STALL_FETCH' (sc_signal) first driver `PAGING_BLOCK.port_13' (sc_out) second driver `BIOS_BLOCK.port_6' (sc_out) In file: ..\..\src\sysc\communication\sc_signal.cpp:126 2. data cache miss the environment of dcache is unconnected, we replace it by mem architecture,that can be work on "lw,sw" commands 3. branch && jump conditions not work fix the program counter to jump && branch condition  

執行的方法
2. how to use

//1 use this command to load our asm code 2 icache file

perl assembler.pl test2.asm -code > icache

//2 use this command to get visible asm code

perl assembler.pl test2.asm  > view

//3 run and check

./cpu

OpenRisc_CPU全定制芯片设计方法

參考
http://www.shangshuwu.cn/index.php/OpenRisc_CPU%E5%85%A8%E5%AE%9A%E5%88%B6%E8%8A%AF%E7%89%87%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%B3%95

下次研究openrisc時有可參考的資料

劍橋大學

有不少CPU的資料

http://www.cl.cam.ac.uk/teaching/

Linux 在 IA32 上的記憶體管理

參考http://sp1.wikidot.com/linuxia32mmu


Linux 作業系統原本是在 IA32 (x86) 處理器上設計的，由於 IA32 具有 MMU 單元，因此大部分的 Linux 都預設支援虛擬記憶體機制。然而，在許多的嵌入式處理器中，並沒有 MMU 單元，於是有 Jeff Dionne 等人於 1998 年開始將 Linux 中的 MMU 機制去除並改寫，後來釋出了不具有 MMU 的 µClinux 版本。
曾經有一段時間，嵌入式的系統開發者必須決定應使用具有 MMU 的 Linux 或不具 MMU 的 µClinux，但是後來在2.5.46版的 Linux 中，決定將 µClinux 納入核心中，所以後來的 Linux 核心已經包含了 µClinux 的功能，可以選擇是否要支援 MMU 單元。
由於 Tovarlds 最早是在 IA32 (x86) 中發展出 Linux 作業系統的，因此 Linux 的記憶體管理機制深受 x86 處理器的影響。要瞭解 Linux 的記憶體管理機制，首先必須先理解 x86 的MMU 記憶體管理單元。

wiki可參考
http://zh.wikipedia.org/wiki/%E5%86%85%E5%AD%98%E7%AE%A1%E7%90%86%E5%8D%95%E5%85%83

Zet processor

http://zet.aluzina.org/index.php/Zet_processor


Zet processor is an open implementation of the so widely used IA-32 architecture (generally called x86). This project is very new but it can be synthesized in a configurable device such an FPGA or CPLD, or made as a custom ASIC. Five different FPGA boards are currently supported.

This project is quite complex and is in a very early stage of development. Only the 16-bit part (ie. the 8086/80186) is supported, see Zet status for more information. It can boot successfully MS-DOS 6.22, FreeDOS 1.1 and run Microsoft Windows 3.0 and other MS-DOS games. 

Good compiler website

從http://funningboy.blogspot.com/
挖來的

http://www.cis.upenn.edu/~cis570/schedule.html

http://web.cecs.pdx.edu/~mperkows/

http://web.cecs.pdx.edu/~mperkows/CLASS_574/index.html

http://www.cs.ucla.edu/~palsberg/

關於Cache的網站

http://blog.csdn.net/chinacodec/article/details/3408560
http://blog.csdn.net/chinacodec/article/details/3408591
http://blog.csdn.net/chinacodec/article/details/3408660
http://blog.csdn.net/chinacodec/article/details/3408673
http://blog.csdn.net/chinacodec/article/details/3408682
http://blog.csdn.net/chinacodec/article/details/3408686

http://en.wikipedia.org/wiki/CPU_cache


http://en.wikipedia.org/wiki/Cache_coherency