Là một đồ họa khả thi cho một dự án như vậy?


12

Tôi hiện đang làm việc trên Super OSD - một dự án hiển thị trên màn hình. http://code.google.com.vn/p/super-osd có tất cả các chi tiết.

Hiện tại tôi đang sử dụng MCU của DSPIC để thực hiện công việc. Đây là một DSP rất mạnh (40 MIPS @ 80 MHz, hoạt động một chu kỳ ba thanh ghi và một đơn vị MAC) và quan trọng là, nó đi kèm trong một gói DIP (vì tôi đang sử dụng bảng mạch để tạo mẫu cho nó.) Tôi ' Tôi thực sự nhận được từng chút hiệu năng cuối cùng khi chạy OSD - chip có khoảng 200ns hoặc 10 chu kỳ trên mỗi pixel ở giai đoạn đầu ra, do đó, mã phải được tối ưu hóa rất nhiều trong phần này (vì lý do này, nó sẽ luôn được ghi vào hội,, tổ hợp.)

Bây giờ tôi đang xem xét sử dụng một FPGA cho điều này bởi vì kiến ​​trúc song song của một con chip như vậy, có thể có một chương trình logic đơn giản chạy OSD. Những thứ như vẽ các đường và mã thuật toán sẽ được xử lý bởi MCU, nhưng đầu ra thực tế sẽ được thực hiện với một FPGA. Và một số điều đơn giản như cài đặt pixel hoặc vẽ các đường ngang và dọc tôi muốn tích hợp vào FPGA, để cải thiện tốc độ.

Tôi có một số câu hỏi:

  1. Nó sẽ có giá cao hơn đáng kể? Giá rẻ nhất mà tôi tìm thấy là ~ 5 bảng mỗi cái và DSPIC là 3 bảng mỗi cái. Vì vậy, nó sẽ có giá cao hơn, nhưng bao nhiêu?
  2. DSPIC phù hợp với gói SO28. Tôi không muốn đi lớn hơn SO28 hoặc TQFP44. Hầu hết các gói đồ họa mà tôi từng thấy đều có các gói BGA hoặc TQFP> 100, hiện không phải là một lựa chọn, do kích thước cắt và khó khăn trong việc tự hàn chúng.
  3. Làm thế nào nhiều hiện tại được sử dụng bởi một FPGA? Giải pháp DSPIC hiện đang tiêu thụ khoảng 55mA +/- 10mA, hiện tại vẫn ổn. Một FPGA sẽ tiêu thụ nhiều hay ít? Là nó có thể thay đổi, hoặc nó là khá nhiều tĩnh, như DSPIC?
  4. Tôi cần ít nhất 12KB bộ nhớ đồ họa để lưu trữ đồ họa OSD. Do các GPU có loại bộ nhớ này có sẵn trên chip hay chỉ có sẵn với các chip ngoài?

Câu trả lời:


7

Về nguyên tắc đây là ứng cử viên tốt cho thiết kế dựa trên nền tảng đồ họa. Về yêu cầu của bạn:

quảng cáo 1. Nhiều khả năng FPGA sẽ đắt hơn, bao nhiêu tùy thuộc vào thiết bị bạn chọn. Thoạt nhìn, Spartan 3 nhỏ nhất từ ​​Xilinx (XC3S50AN) sẽ đủ để thực hiện nhiệm vụ này (~ 10 £ từ Farnell). Tôi nghĩ rằng bạn có thể giả định đây là ranh giới trên cho chi phí (nó có RAM 56kB bên trong, vì vậy nó cần nhiều hơn bạn cần). Bạn có thể tìm thấy thiết bị rẻ hơn từ việc cung cấp Xilinx hoặc đối thủ của họ Altera và Lattice.

quảng cáo 2. Gói này là một vấn đề khó khăn, tôi cũng không thấy FPGA có dấu chân nhỏ hơn. Tuy nhiên, có lẽ bạn có thể sử dụng thiết bị CPLD (để tranh luận, CPLD là các GPU nhỏ) có thể ở gói nhỏ hơn (PLCC hoặc QFN). Về mặt tích cực, chúng sẽ rẻ hơn (thậm chí là một đô la) ở mặt tiêu cực rất có thể sẽ không có RAM bên trong. Với CPLD có lẽ bạn sẽ cần chip SRAM bên ngoài.

quảng cáo 3. Mức tiêu thụ hiện tại của GPU và CPLD phụ thuộc nhiều vào thiết kế được lập trình. Tuy nhiên, có khả năng tốt là thiết kế đồ họa và đặc biệt là CPLD sẽ tiêu thụ ít hơn giải pháp hiện tại của bạn.

quảng cáo 4. FPGA có loại bộ nhớ bên trong, CPLD chắc chắn là không. Điều này có thể được giải quyết bằng chip sram bên ngoài (hoặc hai). Ví dụ:

| SRAM 1 | <-> | CPLD | <-> | uC |
| SRAM 2 | <->

Theo cách sắp xếp như vậy trong khi uC đang ghi vào SRAM 1, CPLD sẽ hiển thị dữ liệu từ SRAM 2. CPLD sẽ có thể xử lý đồng thời cả hai tác vụ.

Tất nhiên bạn cũng có thể giải quyết vấn đề này theo các cách khác:
1) sử
dụng thiết bị uControll nhanh hơn (ví dụ ARM) 2) sử dụng thiết bị với một số loại vải lập trình và uC bên trong (ví dụ FPSLIC từ Atmel, tuy nhiên tôi chưa bao giờ sử dụng các thiết bị đó và tôi biết rất rõ ít về những cái đó)

Từ chối trách nhiệm tiêu chuẩn -> vì thiết kế là vấn đề mở, với nhiều ràng buộc và giải pháp khả thi, bất cứ điều gì tôi viết ở trên có thể không đúng với trường hợp của bạn. Tôi tin rằng nó là giá trị kiểm tra các tùy chọn, mặc dù.


4

Bạn có thể sử dụng CPLD chứ không phải là một đồ họa, chẳng hạn như một trong các bộ phận Altera MAX II. Chúng có sẵn trong các gói QFP44, không giống như các GPU. Chúng thực sự là các GPU nhỏ, nhưng Altera phát huy khía cạnh đó. CPLD có một lợi thế so với hầu hết các GPU ở chỗ chúng có bộ nhớ cấu hình trên chip, các GPU thường yêu cầu chip flash ngoài. Dĩ nhiên, có những CPLD khác, nhưng tôi thích MAX II.

Không thể nói mức tiêu thụ hiện tại sẽ là bao nhiêu, vì nó phụ thuộc vào tốc độ xung nhịp và lượng logic thực sự được sử dụng.

Các GPU thường có số lượng bộ nhớ trên chip hạn chế mà bạn có thể sử dụng, nhưng bạn sẽ cần bộ nhớ ngoài với CPLD.

Một tùy chọn khác sẽ là chip XMOS , nhưng chip nhỏ nhất (XS1-L1) nằm trong gói QFP64. Nó có nhiều RAM trên chip - 64k.


2

1) Có, đồ họa sẽ đắt hơn. Bản thân chip không chỉ đắt hơn mà còn cần bộ nhớ Flash để lưu trữ chương trình. FPGA + Flash có thể là gấp 3 lần chi phí chỉ bằng DSPIC ... khoảng 10 đô la cho một GPU nhỏ và 3 đô la cho Flash nhỏ.

2) Chúng có thể tồn tại, nhưng tôi không thực sự biết về bất kỳ loại GPU nào không phải là bề mặt. Hầu hết trong số họ có thể là QFP hoặc BGA.

3) FPGA có thể sẽ kéo khoảng 3 lần dòng điện mà DSPIC làm, nhưng điều đó có thể tăng hoặc giảm tùy thuộc vào tính năng bạn sử dụng. FPGA có nhiều tính năng có thể tăng sức mạnh. Nhưng mong đợi ít nhất 150 mA.

4) Các GPU thường có khối RAM bên trong chúng. Tất cả, ngoại trừ các GPU nhỏ nhất nên có nhiều bộ nhớ.

Những người khác đề cập đến CPLD. Nếu bạn cẩn thận phân vùng thiết kế của mình, bạn có thể chuyển một số hoạt động nhỏ nhưng tốn kém vào CPLD. Nó sẽ giống như một bộ đồng xử lý nhỏ.


2

Giải pháp rẻ nhất với đường cong học tập thấp nhất sẽ là chuyển sang bộ xử lý có công suất cao hơn, rất có thể là ARM.

Lập trình một FPGA / CPLD trong VHDL / Verilog là một đường cong học tập khá dốc đến từ C đối với nhiều người. Họ cũng không phải là bộ phận quá rẻ.

Sử dụng ARM có khả năng tốt có thể là LPC1769? (cortex-M3) bạn cũng có thể thay thế PIC18 trong thiết kế của mình.

Đối với vấn đề thông qua lỗ, miễn là bạn có thể nhận được SoC trong gói loại QFP pin bị lộ, chỉ cần lấy một số bộ điều hợp này để lấy mã pin cần thiết cho việc tạo mẫu của bạn.


Anh ấy đang sử dụng một DSPIC, không phải PIC18.
Leon Heller

2
Anh ta đang sử dụng cả hai, nhìn vào sơ đồ trong tài liệu mà anh ta liên kết. PIC18 đang chạy các nút / giao diện và nói chuyện với DSPIC qua I2C. DSPIC chỉ xử lý video.
Đánh dấu

1

Xu hướng của tôi sẽ là sử dụng một cái gì đó để đệm thời gian giữa bộ xử lý và màn hình. Có phần cứng có thể hiển thị toàn bộ khung hình video mà không cần sự can thiệp của bộ xử lý có thể tốt, nhưng có lẽ quá mức cần thiết. Tôi sẽ đề nghị rằng sự thỏa hiệp tốt nhất giữa độ phức tạp của phần cứng và phần mềm có lẽ là tạo ra thứ gì đó có hai hoặc ba thanh ghi dịch chuyển 1024 bit độc lập (hai bit trên mỗi pixel, để cho phép màu đen, trắng, xám hoặc trong suốt) và một phương tiện chuyển đổi giữa chúng. Để PIC tải lên một thanh ghi thay đổi, và sau đó phần cứng bắt đầu dịch chuyển cái đó ra trong khi nó đặt cờ để PIC có thể tải cái tiếp theo. Với hai thanh ghi thay đổi, PIC sẽ có 64us trong khoảng thời gian được thông báo rằng thanh ghi thay đổi có sẵn và thời gian tất cả dữ liệu phải được dịch chuyển. Với ba thanh ghi thay đổi,

Lưu ý rằng trong khi một FIFO 1024 bit sẽ tương đương với hai thanh ghi dịch chuyển 1024 bit, và trong CPLD, một FIFO chỉ tốn một macrocell mỗi bit, cộng với một số logic điều khiển, trong hầu hết các loại logic khác, hai bit của thanh ghi dịch chuyển sẽ rẻ hơn một chút của FIFO.

Một cách tiếp cận khác là kết nối CPLD với SRAM và tạo một hệ thống con video đơn giản với điều đó. Về mặt thẩm mỹ, tôi thích việc tạo video nhanh chóng và nếu ai đó tạo ra các chip đăng ký thay đổi 1024 bit giá rẻ thì đó là cách tiếp cận tôi thích, nhưng sử dụng SRAM bên ngoài có thể rẻ hơn so với sử dụng một GPU có đủ tài nguyên để tạo nhiều thanh ghi dịch chuyển 1024 bit. Đối với độ phân giải đầu ra của bạn, cần phải đồng hồ hóa dữ liệu ở mức 12M pixel / giây hoặc 3MBytes / giây. Có thể sắp xếp mọi thứ để cho phép dữ liệu được đồng hồ ở tốc độ lên tới 10mbps mà không gặp quá nhiều khó khăn bằng cách xen kẽ các chu kỳ bộ nhớ; mẹo lớn nhất sẽ là ngăn ngừa hỏng dữ liệu nếu xung đồng bộ hóa không đến vào thời điểm chính xác dự kiến.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.