VHDL: Đặt tên và giải thích kiến ​​trúc

Lưu ý: Tôi đang sử dụng ISE của Xilinx và có một bo mạch đồ họa để làm việc (với các công tắc và đèn, v.v.) và cho đến nay tôi đã hack một số dự án đơn giản. Đồng thời tôi đang đọc một số hướng dẫn để xây dựng nền tảng cho những gì tôi đang làm.

Tôi đã thấy các thực thể khác nhau và kiến ​​trúc của chúng được đề cập trong các tài liệu tham khảo mà tôi đã trải qua, nhưng việc đặt tên thường khó hiểu. Thường thay vì "kiến trúc rtl của .." hoặc "cấu trúc kiến ​​trúc của ..." tôi sẽ thấy "kiến trúc foo của ..." hoặc thậm chí "kiến trúc trúc của ..."

Tôi nhận ra (muộn màng) rằng tên kiến ​​trúc cũng tùy tiện như cách đặt tên thực thể, mặc dù có các hướng dẫn kiểu gợi ý các quy ước đặt tên nhất quán hơn có thể được sử dụng để tránh vấn đề này. Điều này dẫn tôi đến một vài câu hỏi:

• Nhìn vào một thực thể, làm thế nào người ta có thể xác định mô hình kiến ​​trúc thực tế đang được sử dụng mà không có gợi ý từ tên kiến ​​trúc? RTL, hành vi, cấu trúc ... chúng có vẻ khá giống với mắt người học của tôi (giả sử các ví dụ tôi đã thấy thực sự được đặt tên chính xác). Một ví dụ đơn giản nhưng rõ ràng sẽ hữu ích ở đây (hoặc một con trỏ tới một).

• Nếu chỉ định nhiều kiến ​​trúc cho một thực thể (mà tôi hiểu là có thể), bạn chỉ cần cung cấp cho kiến ​​trúc các tên khác nhau trong cùng một tệp hoặc ...?

• Các tên kiến ​​trúc có bị giới hạn trong một thực thể nhất định không (có nghĩa là có bất kỳ vấn đề nào với "không gian tên" bằng cách sử dụng cùng một tên kiến ​​trúc trên nhiều thực thể) không?

Chỉnh sửa: và một cái nữa:

• Có vẻ như có một sự khác biệt giữa RTL và hành vi, nhưng như đã đề cập ở trên, tôi không thực sự nhìn thấy nó trong các ví dụ tôi đã thấy (thường tôi chỉ thấy một kiến ​​trúc được xác định). Là một kiến ​​trúc phổ biến hơn so với những kiến ​​trúc khác?

Những gì tôi đang tìm kiếm là một dự án đa thành phần đơn giản nhưng toàn diện (các thành phần nhỏ), được viết bằng cách sử dụng các thực tiễn tốt nhất (đặt tên đúng, không phải tất cả được nhồi nhét vào một tệp, v.v.) nhưng tôi vẫn chưa tìm thấy. Tôi thấy các dự án mẫu được chế tạo đúng cách rất hữu ích để chiếu sáng các nguyên tắc cơ bản và thực hành tốt nhất. Nếu bạn biết về một dự án ví dụ như vậy, tôi cũng rất biết ơn về một con trỏ đến đó. (Nếu không có gì khác, có lẽ một khi tôi nhận ra điều này, tôi có thể chia sẻ một trong những thứ của riêng mình ...)

Nhìn vào một thực thể, làm thế nào người ta có thể xác định mô hình kiến ​​trúc thực tế đang được sử dụng mà không có gợi ý từ tên kiến ​​trúc?

Bạn không thể - khi nó được khởi tạo hoặc cấu hình , kiến ​​trúc có thể được chỉ định (nếu có nhiều hơn một lựa chọn) hoặc mặc định sẽ được chọn cho bạn.

Nếu chỉ định nhiều kiến ​​trúc cho một thực thể (mà tôi hiểu là có thể), bạn chỉ cần cung cấp cho kiến ​​trúc các tên khác nhau trong cùng một tệp hoặc ...?

Bạn đặt cho họ những cái tên khác nhau. Nó không phải nằm trong cùng một tệp (trên thực tế VHDL quan tâm ít hơn nhiều so với bạn nghĩ về những gì trong tệp nào)

Các tên kiến ​​trúc có bị giới hạn trong một thực thể nhất định không (có nghĩa là có bất kỳ vấn đề nào với "không gian tên" bằng cách sử dụng cùng một tên kiến ​​trúc trên nhiều thực thể) không?

Chúng được "gắn" vào một thực thể, vì vậy có thể được sử dụng lại.

Tôi thường sử dụng a1như kiến ​​trúc của mình cho mọi thứ có thể tổng hợp như

• rtl ngụ ý cấp thấp hơn (cho nhiều độc giả) hơn tôi viết tại.
• behavioural thường ngụ ý không tổng hợp (với một số độc giả)
• synth được sử dụng bởi trình tổng hợp cho mô hình của nó (nếu không tôi đã sử dụng nó)

a1 cho đến nay đã không xung đột và không gây nhầm lẫn;)

Nếu tôi thực sự có nhiều kiến ​​trúc, tôi có xu hướng đặt tên cho chúng bằng lời nói (ví dụ hard_multipliersvà lut_multiplierscho một bộ lọc khởi tạo - hoặc không - các khối MUL18).

Rất thường bạn chỉ có một kiến ​​trúc, vì vậy nó không thành vấn đề. Tên thực thể tốt là quan trọng hơn nhiều.

Có vẻ như có một sự khác biệt giữa RTL và hành vi, nhưng như đã đề cập ở trên, tôi không thực sự nhìn thấy nó trong các ví dụ tôi đã thấy (thường tôi chỉ thấy một kiến ​​trúc được xác định). Là một kiến ​​trúc phổ biến hơn so với những kiến ​​trúc khác?

Đó là lịch sử - bạn đã không sử dụng để có thể tổng hợp mã "hành vi" (tại một thời điểm bao gồm những thứ như thêm!) - vì vậy bạn đã tạo một phiên bản RTL để thêm các trình bổ sung và tương tự. (Đó là theo tôi hiểu - Tôi đã viết mã hành vi (và vẫn có thể tổng hợp) kể từ khi tôi bắt đầu VHDLing vào khoảng năm 1999!)

Dưới đây là các loại kiến ​​trúc:

Hành vi:

Ghi chú chung:

• Theo truyền thống không có quyền thừa kế (chỉ có một tệp, không có thành phần nào được khởi tạo) mặc dù điều này khác nhau giữa các công cụ.
• Rất nhanh để mô phỏng.
• Hành vi tín hiệu được xác định.
• Khi hành vi chỉ được sử dụng để mô phỏng, nó có thể chứa mã không tổng hợp được. Hành vi dự định tổng hợp phải tự nhiên được tổng hợp.

Ghi chú cụ thể của Xilinx

• Nói chung các mô hình trình tạo lõi là các tệp .vhd tiền tổng hợp

Cấu trúc:

Định nghĩa chung

• Chỉ khởi tạo các thành phần và nối chúng lại với nhau (phân cấp).
• Chậm để mô phỏng hơn hành vi.
• Không có định nghĩa hành vi tín hiệu thực sự ở cấp cao nhất.
• Chỉ mã tổng hợp.

Xilinx ghi chú xpecific

• Các mô hình máy phát lõi không tính đến thời gian.
• Nói chung các mô hình trình tạo lõi khởi tạo danh sách mạng tổng hợp sau

Trên đây về cơ bản là hai động vật chính truyền thống của kiến ​​trúc. Rất phổ biến một định nghĩa "hỗn hợp" được sử dụng, trong đó có các thuộc tính của cả hai.

RTL:

RTL những gì thực sự được đưa vào FPGA vào cuối ngày. Vì vậy, đây là mã tổng hợp xác định hành vi của hệ thống và được tạo thành từ một hệ thống phân cấp mã:
Các lớp dưới cùng sẽ được tổng hợp theo hành vi, trong đó độ cứng của hành vi tín hiệu được xác định và các mức trên sẽ là cấu trúc, trong đó các thành phần hành vi được gắn với nhau để tạo ra một "sơ đồ khối" cấp cao nhất nếu bạn muốn.

Trên nhiều kiến ​​trúc:

Kiến trúc có thể là tất cả trong một tệp hoặc trong nhiều tệp. Điều quan trọng duy nhất là thực thể được biên dịch trước và kiến ​​trúc được sử dụng được chỉ định.

Cuốn sách này rất tiện dụng và chi tiết loại điều này khá tốt.

Không có quy tắc cứng và nhanh về cách mọi thứ nên được thực hiện theo cách có các mô hình hành vi và cấu trúc riêng biệt hoặc chỉ trộn chúng. Thông thường trong các thiết kế phần sụn lớn (hoặc trong các tập đoàn lớn nơi mã được chia sẻ và sử dụng lại), rất hữu ích để phân biệt giữa hai để đơn giản hóa các vấn đề, tuy nhiên vào cuối ngày, mọi thứ sẽ phù hợp với bạn.

Trước hết, các thiết kế kiến ​​trúc trong thế giới thực không thể được phân loại chặt chẽ như thế. Tại sao lại giới hạn bản thân? Bạn có thể muốn khởi tạo các thực thể khác và kết nối chúng theo "cấu trúc", nhưng thêm một quá trình hoặc gán đồng thời ở đây và ở đó để thêm một số logic "rtl" và có thể sử dụng một số mẫu mã hóa "hành vi" để trình tổng hợp tìm ra một số các chi tiết mà bạn không quan tâm (như thêm mà không cần khởi tạo cụ thể một bộ cộng với các tham số diện tích / đường ống / hiệu suất), tất cả trong cùng một kiến ​​trúc.

Quan trọng hơn, bạn phải hiểu những gì có thể tổng hợp trong các công nghệ asic / fpga hiện tại và những gì không, và điều này không liên quan đến mô hình kiến ​​trúc.

Một thực thể có thể được thực hiện theo nhiều cách, thậm chí cho phép các hành vi hơi khác nhau, do đó bạn có thể có nhiều kiến ​​trúc cho cùng một thực thể. Ngoài ra, bạn có thể có một kiến ​​trúc chỉ mô phỏng (thường không tổng hợp được) có thể mô phỏng nhanh hơn phiên bản "thực", có thể có ích khi kiểm tra toàn bộ các thiết kế lớn. Bạn sẽ đặt cho những cái tên kiến ​​trúc này giúp bạn nhớ những gì làm cho chúng khác biệt với những cái khác, và chỉ đơn giản là bhv / str / rtl thường không đủ hoặc chính xác, dựa trên bản chất lai của các thiết kế trong thế giới thực.

Về các câu hỏi cụ thể của bạn, khai báo kiến ​​trúc được gắn với một tên thực thể, do đó không có vấn đề về không gian tên với các kiến ​​trúc cùng tên cho các thực thể khác nhau. Chỉ cần sử dụng các tên khác nhau cho kiến ​​trúc cho cùng một thực thể.

Kiến trúc có thể nằm trong các tệp khác nhau, bạn chỉ cần đảm bảo rằng khai báo thực thể được biên dịch trước.

Bạn có thể chọn kiến ​​trúc nào sẽ sử dụng khi khởi tạo thực thể hoặc sử dụng các câu lệnh cấu hình. Nếu bạn không, mặc định là 'thường' kiến ​​trúc cuối cùng mà trình biên dịch đã thấy cho một khai báo thực thể nhất định.