Innovative microprocessor architecture

[tonyvandinh]

Mod tonyvandinh định giúp cho bên nào vậy ? Mấy vụ tranh cãi về patent thường kéo dài và tạo ra nhiều công ăn việc làm phết.

Bên nào thắng, bạn mình cũng có tiền để đãi anh em đi nhậu . Hắn giầu quá rồi không biết mấy cái lẻ tẻ này, hắn có chịu làm không. Hiện giờ thì hắn đang đại diện cho TSMC để kiện tụng mấy hãng khác. Về patent gì thì mình không rõ nhưng một năm lương của hắn thu về gần 1 triệu USD. Có bạn giầu nhưng cũng chỉ xẻ được tí xíu khi hắn mở tiệc thôi. Bận làm tiền cho nên không mấy khi thấy mở tiệc

[tonyvandinh]

Tôi xin đính kèm bài dưới đây về HLS và Dynamic Reconfigurable Processor để các bạn tìm hiểu thêm.

[lntran]

Hi các bác,

Cám ơn bác Tony gửi paper để mọi người cùng thảo luận. Tiếc là cái paper này viết về compiler là cái mình không biết nên chẳng giám nói gì. Mình chủ yếu làm ASIC design và computer architecture thôi. Nhưng mình cũng cố gắng đưa vài ý kiến về phần cứng. Loại reconfigurable processor này là loại có thể coi là thế hệ thứ nhất sử dụng kỹ thuật switching context phát triển khoảng sau năm 2000. Cái patent của mình viết tận năm 2005 nên kiện bọn này chắc không được rồi. Loại này ngày trước thiết kế ra để xử lý tín hiệu như video... và chưa đủ mềm dẻo để chạy các ứng dụng cho CPU. Loại này hiệu suất cao hơn CPU hay DSP thì chẳng cần bàn, có điều làm sao để chạy các ứng dụng thông thường thôi. Hướng phát triển compiler cho C chạy trên cấu trúc này cũng là một hướng hay. Có người còn làm compiler để chuyển từ C sang Verilog để nạp thẳng lên FPGA nữa. Mình không có chuyên môn nên chỉ có thể nói đây là một hướng phát triển khác.

Mình làm theo hướng thay đổi kiến trúc phần cứng để chạy cho các phần mềm hiện thời. Nếu có thể làm compiler cho vi xử lý này thì quá tuyệt với nhưng mình chỉ hi vọng làm Database driver cho chip mà thôi. Driver này là một thư viện các lệnh SQL. Nó cũng tương tự như DirectX hay OpenGL cho GPU vậy. Driver viết bằng machine code nên chẳng cần compiler gì hết.

Nhân tiện mình nói về kinh nghiệm tiếp xúc với bọn VC. Bác ITX nói cũng phải nói chuyện công nghệ với bọn này nhiều khi giống đàn gẩy tai trâu, nói chuyện về tiền thì OK. Nhưng nếu chỉ đem business plan đến thì xem ra vẫn không được. Bọn này cũng nói cần prototype, kiểm tra hiệu suất nhưng làm mấy cái đó đâu có dễ trừ khi mình có vài triệu. Thêm một cái nữa là mình chỉ biết thiết kế phần cứng thôi, không làm được driver nên cuối cùng mình tạm thời dẹp nó lại để khi khác tính tiếp. Hiện giờ mình đang làm test chip cho con này và sẽ fabricate (chung với vài design khác nữa nên không mất tiền). Để đơn giản mình chỉ làm 4 core 16 bits. Mỗi core có 8 ALU. Điều quan trọng nhất của test chip chỉ là để chứng minh kiến trúc hoạt động chính xác thôi. Thiết kế của mình không sử dụng clock mà dùng kiểu asynchronous pipeline nên FPGA prototype không chính xác lắm (nếu làm chính xác như thiết kế thì không được). Nhưng mình cũng định làm một FPGA có nguyên tắc hoạt động tương tự. Khi nào làm xong mình sẽ thư nói chuyện lại vói bọn VC sau thế nào.

[tonyvandinh]

Hi các bác,

Cám ơn bác Tony gửi paper để mọi người cùng thảo luận. Tiếc là cái paper này viết về compiler là cái mình không biết nên chẳng giám nói gì. Mình chủ yếu làm ASIC design và computer architecture thôi. Nhưng mình cũng cố gắng đưa vài ý kiến về phần cứng. Loại reconfigurable processor này là loại có thể coi là thế hệ thứ nhất sử dụng kỹ thuật switching context phát triển khoảng sau năm 2000. Cái patent của mình viết tận năm 2005 nên kiện bọn này chắc không được rồi. Loại này ngày trước thiết kế ra để xử lý tín hiệu như video... và chưa đủ mềm dẻo để chạy các ứng dụng cho CPU. Loại này hiệu suất cao hơn CPU hay DSP thì chẳng cần bàn, có điều làm sao để chạy các ứng dụng thông thường thôi. Hướng phát triển compiler cho C chạy trên cấu trúc này cũng là một hướng hay. Có người còn làm compiler để chuyển từ C sang Verilog để nạp thẳng lên FPGA nữa. Mình không có chuyên môn nên chỉ có thể nói đây là một hướng phát triển khác.

Chắc bạn chưa nghiên cứu về HLS đấy thôi. Kỹ thuật này chỉ mới nổi lên từ 5-6 năm nay. Vẫn còn nhiều người còn đang tìm hiểu về nó. Nhìn thoáng qua thì chỉ đoán nó là compiler tại vì đường vô là C/C++/systemC. HLS là kỹ thuật tổng hợp và nếu google "high level synthesis", bạn có thể tìm hiểu thêm. Đây là công cụ cho kỹ sư RTL không phải cho phần mềm. Nếu có thắc mắc, tôi có thể giải thích thêm.

[hithere123]

Chào bác lntran,

Em lờ mờ hiểu cái bác định nói tới tuy nhiên vẫn cần bác clarify một số điểm, mong bác giúp:

- Bác nói tới nhược điểm của multi-core và đa số chương trình thông thường không tận dụng được kiến trúc này (ý trong bài viết đầu tiên của bác). Em hiểu thế này: multi-core bác nói tới ở đây là cấu trúc gồm nhiều (ALU + thanh ghi) những vẫn share memories (program mem + data mem) hoặc (code mem + data mem). Có đúng không ạ? Một chương trình thường sẽ được nạp vào program mem hoặc code mem. Vậy nếu muốn tận dụng sức mạnh của multi-core thì cần phân nhiệm (do người lập trình quyết định) nhưng thực chất là vẫn share chung mem và bus nên nó chỉ thực sự nhanh nếu multi-core có mem riêng.

- Ý tưởng của bác là cứng hóa phần phân nhiệm này. Nói chung là một kiến trúc cho phép tối ưu hóa tài nguyên phần cứng (dùng hết công suất), giảm tối đa nguyên nhân chạy châm trong các bước như yêu cầu truy cập bus, lấy code từ mem lên … kiểu như khi boot up chương trình, tự động các lệnh sẽ được load về các (thanh ghi + ALU) sẵn sàng cho bước tiếp theo trong khi đang thực hiện bước hiện tại (và cái này là được cứng hóa). Có đúng không ạ?

Vì em mới lờ mờ nên diễn đạt chưa thật rõ ràng, (uC có cách xử lý hơi khác) nên các bác ném đá nhẹ tay.

Về patent thì em e là làm loãng topic nên sẽ có ý kiến với các bác sau, đợi bác lntran nói hết patent của bác ấy đã.

Thân mến.

[tonyvandinh]

Nói chơi vậy thôi chứ patent pé tiết gì. Tin tức ở đây đăng đầy trên mạng. Gẩy google một cái thì mất mấy năm mới đọc hết được. Chỉ có cái là phải hiểu tiếng ăng lê và có căn bản suy nghĩ một chút xíu là mạnh xác tìm hiểu. Cái chính là có thực hành được hay không trên thực chất hoặc trên simulation. Nếu muốn mọi người tin là mình đã làm rồi thì nên gắn thêm hình ảnh hoặc một vài samples. A picture is worth a thousand words (hình ảnh diễn tả nhiều chi tiết hơn cả 1000 chữ) .

[lntran]

Hi các bác,

Để trả lời bác Hithere123, viết chơi một bài và parallelism cho processor. Mình không lấy từ sách vở nào, nhưng muốn tìm hiểu các bác có thể đọc được từ rất nhiều nguồn.

Kiến trúc parallelism đơn giản nhất là pipeline. Cái này chắc các bác biết hết rồi. Người ta chia một công việc thành nhiều phần, và các phần này có thể chạy đồng thời. Pipeline processor chính là chia các lệnh thành nhiều stage như Instruction fetching, Decode, Execution, Memory access, write back. Nhờ việc chia nhỏ này mà tần số đồng hồ tăng lên rất cao. Điển hình của loại này là Pentium VI của Intel sử dụng đến hơn 30 stage đạt tốc độ gần 4 GHz. Tuy nhiên tăng quá nhiều stage cũng là một vấn đề. Thứ nhất tần số cao đồng nghĩa với công suất tiêu thụ điện lớn. Diện tích chip cũng tăng lên rất lớn do các flipflop. Latency để thực hiện các lệnh này cũng tăng lên rất nhiều. Chính vì vậy khi xuất hiện các lệnh nhảy, người ta phải sử dụng branch prediction để có thể pre-fetch lệnh tiếp theo. Trong trường hợp miss pre-fetch, tất cả các stage chạy lỗi phải bị loại bỏ điều này làm chậm toàn bộ vi xử lý. Lý do khiến kiến trúc Pentium VI bị loại bỏ chính vì nó chạy quá nóng, và hiệu suất thật sự không cao hơn so với kiến trúc dùng ít pipeline stage hơn. Loại vi xử lý chạy pipeline mỗi lệnh trong một clock còn được gọi là scalar processor.

Loại thứ hai cũng rất đơn giản là vector processor. Loại này được thực hiện bằng cách tăng số lượng bit trên các thanh ghi, ALU để có thể đồng thời xử lý 2 hay nhiều dữ liệu một lúc. Ví dụ thanh ghi tăng lên 128 bit để có thể xử lý đồng thời 4 dữ liệu 32 bit hoặc 2 dữ liệu 64 bit. Loại này được dùng cho MMX và SSE với kiến trúc của Intel, Cell processor của IBM, và tất cả GPU. Nhược điểm của kiến trúc này là có bao nhiêu chương trình sử dụng dữ liệu dạng vector. Đối với graphic thì đây là điều đương nhiên không phải bàn nhưng các chương trình thông thường thì không sử dụng.

Loại thứ ba rất thông dụng với các vi xử lý thông thường là superscalar. Loại này cho phép chạy nhiều hơn một lệnh trong một clock. Để làm được việc này người ta sử dụng một vài ALU đặt song song nhau. Bộ điều khiển phải phân tích sự phụ thuộc của các lệnh và trong trường hợp chúng độc lập, người ta sẽ nạp chúng lên các ALU khác nhau. Đây chính là lý do kiến trúc loại này có thể chạy nhiều hơn một lệnh trong 1 chu kỳ. Nhược điểm căn bản nhất của kiến trúc này là làm sao phân tích được sự phụ thuộc lẫn nhau của nhiều lệnh trong 1 instruction window. Cho đến hiện nay vi xử lý của Intel chỉ có thể tăng đến 4way superscalar tức là chạy tối đa 4 lệnh. Phần điều khiển của superscalar rất lớn và phức tạp, tiêu thụ rất nhiều công suất, và tạo nên nhiều critical path làm giảm tần số làm việc. Thêm vào đó việc chạy 4 lệnh chỉ là lý thuyết, thực tế phụ thuộc và chương trình. Cho đến hiện nay designer dừng lại ở 4way superscalar.

Để loại bỏ phần điều khiển quá kinh khủng của superscalar processor, người ta đề xuất kiến trúc VLIW (Very Long Instruction Word). Với kiến trúc này sự phụ thuộc của các lệnh được tính toán trước bằng compiler. Các lệnh không phụ thuộc sẽ được nhập chung lại thành một lệnh dài đẩy lên một loạt các ALU để chạy đồng thời. Các lệnh phụ thuộc sẽ được nạp theo thứ tự và khi ALU không có lệnh người ta sử dụng NOP (No operation). Nhược điểm của loại này là compiler thường kém hiệu quả trong việc phân tích sự độc lập dữ liệu do những lệnh điều kiện. Nhưng nó lại rất phù hợp với việc xử lý dữ liệu khi các giải thuật đã được cố định, và việc xử lý các sample khác nhau độc lập lẫn nhau. Chính vì vậy kiến trúc VLIW được sử dụng cực kỳ phổ biến cho DSP. Vi xử lý thông thường dùng VLIW architecture là Itanium nhưng xem ra hiệu suất chạy của loại này tương đối kém. Một chip điển hình trong loại này nữa là transmeta. Chip này nổi tiếng với việc tiêu thụ điện năng thấp và rẻ tiền (size nhỏ). Một trong những nguyên nhân là do loại bỏ được phần controller của superscalar.

Intel đã từng quảng cáo về kiến trúc hyperthreading. Loại này thực chất là việc nhân đôi register pool và Instruction Fetching Unit để có thể chạy 2 thread cùng một lúc. Trong trường hợp 1 thread ngừng chạy ví dụ chờ dữ liệu từ memory, hay do sự phụ thuộc về lệnh mà không tận dụng hết 4 ALU, thread thứ 2 có thể chạy. Loại này có nhược điểm làm chip càng nóng và tiêu thụ điện rất lớn. Chip Pentium VI vốn đã rất nóng, khi áp dụng kỹ thuật này lại càng nóng dữ dội. Ngoài ra kiến trúc này tạo nên hiện tượng cold cache ảnh hưởng nặng đến hiệu suất hoạt động. Đó là do 2 thread cùng dùng chung 1 cache. Khi một thread tạm ngừng và thread sau chạy, nó sẽ đưa dữ liệu của nó lên cache và loại bỏ dữ liệu của thread thứ nhất. Và khi thread thứ nhất chạy, nó lại loại bỏ dữ liệu của thread thứ 2. Mất dữ liệu trên cache ảnh hưởng cực lớn đến hiệu suất hoạt động.

Loại cuối cùng mình giới thiệu là multi-core processor. Loại này chính là kiểu multi processor được thu nhỏ đưa vào trong một chip. Đơn giản, ngày xưa nhiều processor được kết nối với nhau, trên cùng một board, ngày này nhiều core kết nối với nhau trên cùng một die. Các processor này chia sẻ dữ liệu với nhau thông qua share memory kiểu UMA (Uniform Memory Access), NUMA (NonUniform Memory Access), Hay gửi dữ liệu trực tiếp qua các channel. Loại này hay nhất phải kể đến Tilera processor.

Bác Hithere123 làm về controller nên mình cũng muốn bàn một chút. Các loại điều khiển máy giặt, lò vi sóng này thì bác chẳng cần dùng bất kỳ kỹ thuật gì mình kể trên cả. Controller quan trọng là đơn giản, tiện dụng, rẻ tiền, và ổn định. Vì vậy người ta hay tích hợp bên cạnh controller một vài ADC, DAC, timer, communication (ví dụ RS232...), ROM, RAM... Nói tóm lại một chip đủ làm tất cả. Bản thân con controller này có khi chỉ có 8 bit, kiến trúc cực kì đơn giản, chẳng có cache, hay cái gì phức tạp hết. Người ta thường sử dụng mấy công nghệ cổ lỗ sỹ để chế tạo vì loại này ổn định cao lại rẻ tiền.

@ bác Tony: không phải cái gì cũng có thể chia sẽ được đâu bác ạ. Mình có thể nói lý thuyết, phân tích kiến trúc, còn bác muốn lấy design của mình thì sorry. Tương tự bác có thể kiếm được vô vàn tài liệu về kiến trúc MIPS, Cell nhưng họ cũng đâu có cho bác design. Về chuyện hình vẽ, mình cũng sẽ đưa các hình vẽ kiến trúc vi xử lý lên dần và phân tích với mọi người. Kiến thức của mình cũng là học từ mọi người xung quanh, sách, báo, và trên mạng nên việc bác thấy trên mạng có nhiều nguồn hay hơn cũng là bình thường. Nếu bác thấy mình viết vô bổ, just ignore my thread.

Cheers

[quoc_thaibk]

Một lời comment (nói vô nhỏ thôi)
Các anh khi viết thì nếu có dùng tiếng anh thì để kèm 1mở ngoặc dịch thô cho từ đó của các anh được không, Ngôn ngữ nó cảm ngữ cảnh nên người ngoài muốn đọc cũng không dễ dàng lắm.
Cảm ơn các anh nhiều.

[hithere123]

Bác Hithere123 làm về controller nên mình cũng muốn bàn một chút. Các loại điều khiển máy giặt, lò vi sóng này thì bác chẳng cần dùng bất kỳ kỹ thuật gì mình kể trên cả. Controller quan trọng là đơn giản, tiện dụng, rẻ tiền, và ổn định. Vì vậy người ta hay tích hợp bên cạnh controller một vài ADC, DAC, timer, communication (ví dụ RS232...), ROM, RAM... Nói tóm lại một chip đủ làm tất cả. Bản thân con controller này có khi chỉ có 8 bit, kiến trúc cực kì đơn giản, chẳng có cache, hay cái gì phức tạp hết. Người ta thường sử dụng mấy công nghệ cổ lỗ sỹ để chế tạo vì loại này ổn định cao lại rẻ tiền.

Quả đúng vậy bác ạ, mấy cái ứng dụng đấy thì MCU 8-bit là đủ rồi, mấy cái xe điện của Trung Quốc vẫn dùng chạy ầm ầm. Tuy nhiên cái dự án em đang tham gia có chút đặc thù nên dùng 32-bit, và cũng cần xử lý data một chút.
Thôi bác tiếp tục đi, mấy cái hiểu của em ở mức “high level” như bác nói ở trên không đi đến đâu rồi, đợi đến lúc bác để cập tới mức “Flip-flop” chắc em mới tham gia được. Hì

Thân mến.

[tonyvandinh]

không phải cái gì cũng có thể chia sẽ được đâu bác ạ. Mình có thể nói lý thuyết, phân tích kiến trúc, còn bác muốn lấy design của mình thì sorry. Tương tự bác có thể kiếm được vô vàn tài liệu về kiến trúc MIPS, Cell nhưng họ cũng đâu có cho bác design. Về chuyện hình vẽ, mình cũng sẽ đưa các hình vẽ kiến trúc vi xử lý lên dần và phân tích với mọi người. Kiến thức của mình cũng là học từ mọi người xung quanh, sách, báo, và trên mạng nên việc bác thấy trên mạng có nhiều nguồn hay hơn cũng là bình thường. Nếu bác thấy mình viết vô bổ, just ignore my thread.

hm chụp mũ hay nhỉ. Có suy bụng ta ra bụng người không?

[lntran]

Hi các bác,

Hôm nay mình giới thiệu sâu hơn về vi xử lý của mình nhé. Sau đây là mô hình vi xử lý.

Vi xử lý này bao gồm một một mảng processing element (PE) ( ở đây mình chỉ vẽ 16, có thể tăng lên đến 1024 hoặc hơn), LSU, IFU, caches, và IO controller. IFU lấy lệnh từ bên ngoài thông qua LSU, cache, và IO controller, sau đó nạp lên Processing Elements (PE) theo một Instruction network (đường màu đỏ). Sau khi nạp lệnh, các ALU, và 8 kết nối của PE sẽ được cấu hình tạo nên một dataflow network. Dữ liệu từ bên ngoài thông qua cache, đưa vào array và được xử lý theo một flow. Nhiều PE có thể cùng chạy một lúc nếu dữ liệu của nó xuất hiện.

Phần hoạt động cụ thể của từng đơn vị mình sẽ trình bày sau nhưng mình muốn phân tích một chút về kiến trúc này.

1. Các PE giống hệt nhau và thiết kế đơn giản. Hiện nay với những thiết kế chứa hàng trăm triệu transistor, người thết kế đã không thể thiết kế, và kiểm tra tốt (design gap). Số lượng transistor tăng lên khoảng 40% năm trong khi đó năng lực thiết kế chỉ tăng khoảng 20% năm nhờ sử dụng lại các thiết kế có sẵn. Khả năng verify còn tệ hơn. Với kiến trúc này ta chỉ thiết kế một PE nhỏ đơn giản (mình sẽ trình bày sau), và replicate ra toàn bộ array.

2. Tiêu thụ công suất thấp. Vói công nghệ mới hiện nay, công suất tiêu thụ chủ yếu không phải do các mạch logic mà vì việc truyền dữ liệu trên các đường kết nối (lớn hơn hàng trăm lần). Kiến trúc này có đặc điểm locality. Các PE chỉ kết nối đến các PE khác xung quanh và đường kết nối ngắn. Thêm vào đó PE không phải tốn công suất cho phần controller nếu nó chạy các lệnh trong vòng lặp (phần lớn thời gian). Sau khi PE nạp lệnh trong vòng lặp, nó sẽ sử dụng lệnh này trong suốt một khoảng thời gian dài, và không thay đổi. Phần controller của các processor thông thường là một trong những phần tiêu thụ công suất cao nhất. PE không sử dụng clock (mình sẽ nói sau) trong khi đó clock tiêu thụ khoảng 40% công suất toàn bộ mạch điện. Do không sử dụng clock, PE sẽ hoàn toàn nghỉ khi không chạy và không cần đến clock gating technique. Do thời gian chạy dữ liệu trong vòng lặp lâu, ta có thể sử dụng power gating technique để tắt toàn bộ những PE không hoạt động mà không ảnh hưởng gì đến hiệu suất hệ thống (giảm leakage current).

3. Mặc dù có thể lên đến hàng nghìn PE, chỉ có một số PE được phép lấy dữ liệu từ bộ nhớ. Các PE khác lấy dữ liệu từ PE xung quanh. Chính vì vậy băng thông kết nối với bộ nhớ có thể giảm tắc nghẽn. Bên cạnh đó toàn bộ các PE chỉ chạy một thread duy nhất nên dữ liệu trao đổi cũng giảm đi rất nhiều. Bên cạnh đó kiến trúc này cho phép chương trình có thể load/store nhiều dữ liệu cùng lúc (mình sẽ giải thích sau). Cho đến bây giờ mình không biết bất kì một kiến trúc vi xử lý nào khác load/store nhiều hơn 1 dữ liệu (không kể kiểu vector, hay DSP vì dữ liệu hoàn toàn độc lập). Nếu bác nào biết chỉ cho mình, mình xin cám ơn.

4. Và đương nhiên cấu trúc này có tiêu chí quan trọng nhất là hiệu suất cao, nhưng lại chạy 1 chương trình duy nhất. Trong một vòng lặp, mỗi lệnh được nạp lên 1 PE và dữ liệu sẽ được xử lý theo một flow (tương tự như kiểu pipeline). Nhiều PE có thể cùng chạy khi chúng cùng có dữ liệu đầu vào.

Khi khác mình sẽ trình bày cấu trúc của từng phần.

Cheers.

[lntran]

Hi các bác,

Hôm qua đội tuyển Đức đá bóng hay quá các bác nhỉ. Mình trước được đào tạo ở Đức nên bây giờ "Uống nước nhớ nguồn" vẫn yêu nước Đức, yêu người Đức lắm. ICH LIEBE DEUTSCHLAND. Mình không thích bóng đá, chỉ yêu có mình đội Đức thôi. Bây giờ ở Mẽo rồi mà vẫn yêu Deutchland hơn.

Hôm nay tranh thu viết thêm một chút, mong được các bác chia sẻ. Hôm nay mình nói về IO controller, cache, Load/Store Unit (LSU), và Instruction Fetching Unit (IFU).

IO controller này bao gồm một Memory controller (ví dụ DDR3 controller), và một PCI express controller. Đây là một thiết kế chuẩn có thể sử dụng IP library mà không cần sửa đổi gì. Các IO pin có tốc độ cao hơn nhiều tốc độ chạy thực sự bên trong chip nên người ta luôn sử dụng kiến trúc SERDES (Serialize/Deserialize) Có nghĩa là phải chuyển dữ liệu song song với tốc độ thấp bên trong chip, sang dạng serial với tốc độ cao bên ngoài chip. Ví dụ tốc độ cao nhất của DDR3 là 1.6GHz, băng thông gồm 128 pin. Bác có thể chọn dữ liệu chạy bên trong là 400 MHz, 512 bit. Nếu bác nhìn vào hình kiến trúc của mình đưa hôm trước, Bác có thể sử dụng 8 band cache với mỗi band 64 bit. Dữ liệu được đọc, ghi đồng thời và các band cache một cách song song.

Bây giờ mình nói tiếp về cache. Thiết kế về cache cũng là một thiết kế bình thường giống như các cache của vi xử lý khác. Có một số điểm nhỏ mình viết ra đây. Trong vi xử lý này chỉ có 1 lớp cache thay vì 2 lớp như các vi xử lý hiện nay. Nguyên nhân của nó là vì bên trong mỗi PE đã có thể lưu trữ 16 dữ liệu (tương tự như có 16 register nhưng thực sự không có. Register file có diện tích lớn nên nếu thực sự đưa 16 Register cho mỗi PE thì không biết chip sẽ lớn đến đâu), mỗi dữ liệu 64 bit. Nếu có 1024 PE thì array đã có thể lưu trữ đến 128KB dữ liệu, và các dữ liệu này liên tục được tính toán nên không cần đến cache level1 nữa. Cache được chia làm các band. Điều này giúp cho việc đọc ghi dữ liệu trên các band khác nhau có thể diễn ra song song. Kiểu này các vi xử lý của AMD đều có áp dụng. Trong kiến trúc này số lượng band của cache có thể tăng lên tương đối lớn 8, hoặc 16. Điều này đảm bảo array PE có thể đọc ghi nhiều dữ liệu đồng thời.

IFU dùng để nạp lệnh cho PE. Nguyên tắc nạp lệnh như sau: Mỗi PE có một địa chỉ xác định tương ứng với vị trí của nó trong Array (theo trục X, và Y). Các lệnh đều có chứa một trường địa chỉ. IFU sẽ đẩy lệnh vào Instruction network và các router (không được vẽ trên hình) sẽ gửi các lệnh này đến PE dựa trên trường địa chỉ của lệnh. Nói ngắn gọn, các lệnh này sẽ được gửi từ trên xuống đến đúng địa chỉ trục Y, thì chuyển sang gửi sang ngang, đến địa chỉ trục X, và gửi và PE. Mỗi PE có một Instruction buffer có thể lưu trữ đến 8 lệnh. Về nguyên tắc việc tăng băng thông (tăng số bit) của Instruction network là một việc rất dễ dàng vì các lệnh gửi lên PE hoàn toàn độc lập nhau, nhưng thực tế điều này không quá quan trọng. PE array phải xử lý rất nhiều dữ liệu trong vòng lặp nên chạy rất tốn thời gian. Đối với database application, dữ liệu đương nhiên rất lớn. Chính vì vậy ta có thể từ từ nạp lệnh. Một điều cần phải lưu ý là do thời gian PE chạy dữ liệu rất lâu nên IFU có thể đã nạp đầy Instruction buffer và cần phải dừng lại. Chính vì vậy IFU cũng không thể sử dụng clock để nạp lệnh, mà phải dùng kiểu asynchronous pipeline tương tự như xử lý dữ liệu trong PE. Mình sẽ viết về asynchronous pipeline cụ thể hơn khi nói về PE. Các bác có thể hiểu đơn giản, chưa đầy thì nạp, đầu rồi thì tạm dừng. Mặc dù PE của mình sử dụng hai lệnh "Branch", "Merge" (tương tự như multiplexor, demultiplexor) để thay thế cho các lệnh nhảy, nhưng cũng không thể thay thế hoàn toàn. Nếu sử dụng DLL, hay đối với các lệnh nhảy quá xa thì "Branch", "Merge" không dùng được. Để thực hiện các lệnh này, trước hết IFU gửi vào PE array giá trị địa chỉ lệnh hiện thời. Sau khi tính toán lại địa chỉ lệnh mới PE sẽ gửi lên LSU để load "dữ liệu" nhưng không phải vào PE array mà vào IFU. Điều này cho phép IFU nạp lệnh từ bất kì đâu. Theo mình biết kiến trúc CUDA không cho phép thực hiện của Dynamic Instruction Fetching này nên không hỗ trợ DLL, functional pointer, class...

LSU của mình về chức năng chỉ đọc ghi dữ liệu, nên không có nhiều đặc biệt. Nó thực chất là nhiều bộ LSU đặt cạnh nhau cho phép chạy song song. Lệnh được nạp lên LSU cũng chia thành hai loại single instruction và repeated instruction tương tự như đối với PE. Single instruction là loại nạp lệnh 1 lần, chạy một lần rồi nạp tiếp lệnh sau. Repeated instruction là loại nạp 1 lệnh 1 lần, chạy nhiều lần. Single instruction dùng để chạy các lệnh ngoài vòng lặp, và repeated instruction dùng để chạy các lệnh trong vòng lặp. Mình sẽ nói cụ thể về hai loại lệnh này sau. Về nguyên tắc việc đọc ghi dữ liệu phải được thực hiện theo thứ tự nếu không sẽ gây ra data hazard. Ví dụ nếu như trong chương trình yêu cầu đọc dữ liệu A, rồi ghi dữ liệu vào A dữ liệu mới, mà bác lại ghi vào A dữ liệu mới trước rồi mới đọc ra thì dữ liệu sẽ bị sai. Chính vì vậy các lệnh load/store khi đưa lên LSU cũng phải được xác định thứ tự thực hiện như trong chương trình. Nhưng nếu chạy đúng thứ tự thì chỉ có thể ghi đọc được 1 dữ liệu trong 1 lúc và điều này ảnh hưởng rất nặng đến hiệu suất vi xử lý đặc biệt nếu dùng cho database application. Chính vì vậy ở đây mình dùng một tiểu xảo tương tự như cách làm superscalar processor tức là phần tích sự phụ thuộc của các lệnh load/store. Nếu các lệnh này đọc ghi vào 2 vùng địa chỉ khác nhau (độc lập) thì thứ tự không quan trọng. Chúng ta biết là Data hazard xảy ra trong 3 trường hợp Read After Write (RAF), Write After Write (WAW), and Write After Read (WAR). Trong tất cả các trường hợp cần phân tích đều có lệnh Write. Lệnh Write chỉ có thể thực hiện khi dữ liệu cần ghi, và địa chỉ cần ghi đã có. Trong khi đó việc phân tích sự phụ thuộc chỉ cần địa chỉ của lệnh Write là đủ. Trong hầu hết các trường hợp việc tính toán địa chỉ của lệnh Write được thực hiện sớm hơn rất nhiều dữ liệu cần write. Chính vì vậy ta có thể phân tích sự phụ thuộc từ rất sớm và có thể đọc ghi dữ liệu một cách đồng thời. Về nguyên tắc hầu hết các lệnh đọc ghi dữ liệu là độc lập với nhau (vì nếu không độc lập nhau thì ta có thể trao đổi dữ liệu bên trong array, không cần đưa ra ngoài memory) nên hầu hết các lệnh load/store chạy song song. Nhưng trong trường hợp có sự phụ thuộc thì kiến trúc này vẫn chạy đúng. Ở đây có thể nói mình áp dụng tốt Amdahl's law "Chạy nhanh nhất trong những trường hợp thông thường, và chạy đúng trong những trường hợp đặc biệt".

Nhân tiện nói vui với các bác một chút về vấn đề data coherency (data hazard). Đây là một trong những obstacle lớn của kiến trúc multi-core. Vì kiến trúc của mình chạy single thread, và việc phân tích sự phụ thuộc ở mức Instruction level nên đơn giản hơn kiến trúc multi-core khá nhiều. Có thể nói như thế này, nếu không áp dụng data coherency thì có thể xảy ra data hazard và dữ liệu chạy sẽ bị sai. Nhưng nếu áp dụng kỹ thuật này thì lại khá phức tạp, ảnh hưởng đến hiệu suất, và trường hợp này cũng không xảy ra thường xuyên. Theo mình biết Arm processor đã không sử dụng kỹ thuật data coherency cho kiến trúc dual core của họ, và yêu cầu người lập trình phải sử dụng 2 core này hoàn toàn độc lập.

@ bác nguyenchipon: cám ơn bác đã ủng hộ. Mình làm về Digital ASIC design, computer architecture, và cũng học lỏm được một chút về Analog IC design, hi vọng có thể trao đổi chia sẻ kiến thức với bác.

Cheers.

[lntran]

Hi các bác,

Cám on bác it4rb, và tất cả các bác đã ủng hộ. Mình thấy mảng ASIC design trên forum này có vẻ yên ắng hơn hẳn mấy mảng khác. Các bác cố gắng thảo luận nhiều lên cho vui. Trong bài viết của mình các bác thấy có gì chưa được rõ, xin cứ nêu ý kiến, mình sẽ trình bày kỹ hơn. Nếu các bác thấy mình phân tích có gì chưa đúng, hay có ý hay hơn, xin hãy nêu ra mình cám ơn.

Mình có xin lỗi trước mọi người là mình viết các từ chuyên môn bằng tiếng Anh từ trước rồi. Vì mình không học mấy thứ này ở VN nên từ chuyên môn dịch ra tiếng Việt mình không biết, nếu dịch không đúng có khi khiến các bác hiểu sai, ví dụ TLB (Translation Lookup Table) mình chẳng biết dịch ra tiếng Việt là gì. Một phần nữa là mình quên dùng từ tiếng Anh rồi ví dụ như Cache mà dịch ra là Bộ nhớ đệm thì nghe cứ sao sao. Hơn nữa viết bằng tiếng Anh thì ai đọc cũng hiểu, và không hiểu sai.

Mấy hôm nay bận quá mình chưa viết tiếp được.

Cheers.

[hithere123]

Mình thấy mảng ASIC design trên forum này có vẻ yên ắng hơn hẳn mấy mảng khác. Các bác cố gắng thảo luận nhiều lên cho vui. Trong bài viết của mình các bác thấy có gì chưa được rõ, xin cứ nêu ý kiến, mình sẽ trình bày kỹ hơn. Nếu các bác thấy mình phân tích có gì chưa đúng, hay có ý hay hơn, xin hãy nêu ra mình cám ơn.

Chào bác lntran,

Mấy hôm nay em cũng bận quá, nên tranh thủ đợi xem bán kết 2, vào ủng hộ bác tí đây.

ASIC design ở Việt Nam mình vẫn còn mới bác ạ, nhất là khi nói về các vấn đề ở mức "concept design", cộng thêm, cũng không có nhiều người làm liên quan đến lĩnh vực này nghĩ rằng có thảo luận về ASIC design trên một diễn đàn viết bằng tiếng Việt. Em hy vọng sự nhiệt tình của bác sẽ làm nhiều người biết đến diễn đàn và sẽ tham gia thảo luận trong thời gian tới.

Em đọc bài của bác thì thấy rằng cốt lõi ý tưởng của cấu trúc này chính là mạng PE. Nó thay thế ALU trong cấu trúc thông thường phải không bác? Em làm thiết kế số chủ yếu là hướng điều khiển nhiều hơn ví dụ như thay vòng điều khiển điện áp tương tự bằng số chẳng hạn (như thế sẽ giảm được một pin dùng làm chức năng compensation ngoài) nên tiếp cận vấn đề bác nêu với background không chuẩn lắm. Vậy nên, nếu bác thấy câu hỏi ngu ngơ thì bác kiên trì clarify nhé.

Đợi các bài tiếp theo của bác, và cũng mong Mr. Paul đoán đúng trận này . Trận trước đội Đức của bác phát xít quá, đập Achen của em te tua.

Thế bác nhé, gửi bác lời chào may mắn.

[lntran]

Hi các bác,

Cám ơn bác Hithere123 đã ủng hộ. Hôm nay mình sẽ viết tiếp về PE (phần quan trọng nhất). Nhưng trước hết nghe bác Hithere123 nói về ASIC design mình xin góp vài ý kiến.

Ở VN có lẽ nghĩ đến digital ASIC design là nghĩ đến verilog code, synthesize... Điều này đúng nhưng chưa đủ đâu. Làm đúng functionality là điều quan trọng bậc nhất, nhưng còn có một số mặt khác nữa, ví dụ công suất tiêu thụ, performance, reliability (due to process variations)... Để thiết kế những mạch chạy tốc độ cao, công suất thấp, và độ ổn định cao, không thể chỉ biết viết verilog code được. Để thiết kế những mạch như vậy phải hiểu từ mức hệ thống cho đến mức layout (thậm chí cả technology nữa), tức là vừa phải nhìn thấy cây, vừa phải cả rừng. Ngày xưa designer không quan tâm nhiều đến technology nhưng bây giờ đã khác. Mình hoàn toàn không làm về technology, cũng không biết cụ thể họ làm sao, nhưng mình vẫn biết rõ những technique họ làm ảnh hưởng thế nào đến design. Nói vậy thôi nhưng các bác đừng có sợ ASIC. Các bác cứ làm việc trong lĩnh vực này một thời gian, có thêm kinh nghiệm là biết hết.

Bác Hithere123 đang làm về controller mình giới thiệu bác đọc quyển "Computer Organization and Design Hardware Software Interface". Quyển này là bible trong ngành computer architecture đó. Nhưng quyển này viết ở mức thấp (ý mình nói mức thiết kế như RTL chẳng hạn) nên dễ hiểu. Đọc xong quyển này bác thừa sức thiết kế một processor đơn giản. Còn một quyển bible nữa là "Computer Architecture a Quantitative Approach". Quyển này viết ở mức kiến trúc hơi trìu tượng. Quyển này cần có kiến thức và kinh nghiệm một chút mới nên đọc, nhưng làm việc ở mức cao thì không thể không biết.

Cheers.