Tôi có một dự án tiêu thụ 34 macrocells của Xilinx Coolrunner II. Tôi nhận thấy tôi có một lỗi và theo dõi nó xuống:
assign rlever = RL[0] ? 3'b000 :
RL[1] ? 3'b001 :
RL[2] ? 3'b010 :
RL[3] ? 3'b011 :
RL[4] ? 3'b100 :
RL[5] ? 3'b101 :
RL[6] ? 3'b110 :
3'b111;
assign llever = LL[0] ? 3'b000 :
LL[1] ? 3'b001 :
LL[2] ? 3'b010 :
LL[3] ? 3'b011 :
LL[4] ? 3'b100 :
LL[5] ? 3'b101 :
3'b110 ;
Lỗi là rlevervà lleverrộng một bit, và tôi cần chúng rộng ba bit. Tôi ngớ ngẩn quá. Tôi đã thay đổi mã thành:
wire [2:0] rlever ...
wire [2:0] llever ...
Vì vậy, có đủ bit. Tuy nhiên, khi tôi xây dựng lại dự án, sự thay đổi này đã tiêu tốn của tôi hơn 30 macrocell và hàng trăm điều khoản sản phẩm. Bất cứ ai có thể giải thích những gì tôi đã làm sai?
(Tin vui là giờ đây nó mô phỏng chính xác ... :-P)
BIÊN TẬP -
Tôi cho rằng tôi thất vọng vì khoảng thời gian tôi nghĩ rằng tôi bắt đầu hiểu Verilog và CPLD, điều gì đó xảy ra cho thấy tôi rõ ràng không có hiểu biết.
assign outp[0] = inp[0] | inp[2] | inp[4] | inp[6];
assign outp[1] = inp[1] | inp[2] | inp[5] | inp[6];
assign outp[2] = inp[3] | inp[4] | inp[5] | inp[6];
Logic để thực hiện ba dòng đó xảy ra hai lần. Điều đó có nghĩa là mỗi 6 dòng Verilog tiêu thụ khoảng 6 macrocell và 32 thuật ngữ sản phẩm mỗi dòng .
EDIT 2 - Theo đề xuất của @ ThePhoton về công tắc tối ưu hóa, đây là thông tin từ các trang tóm tắt do ISE sản xuất:
Synthesizing Unit <mux1>.
Related source file is "mux1.v".
Found 3-bit 1-of-9 priority encoder for signal <code>.
Unit <mux1> synthesized.
(snip!)
# Priority Encoders : 2
3-bit 1-of-9 priority encoder : 2
Vì vậy, rõ ràng mã được công nhận là một cái gì đó đặc biệt. Thiết kế vẫn đang tiêu thụ tài nguyên to lớn, tuy nhiên.
EDIT 3 -
Tôi đã tạo một sơ đồ mới chỉ bao gồm mux mà @thePhoton khuyên dùng. Tổng hợp sản xuất sử dụng tài nguyên không đáng kể. Tôi cũng đã tổng hợp các mô-đun được đề xuất bởi @Michael Karas. Điều này cũng tạo ra việc sử dụng không đáng kể. Vì vậy, một số sự tỉnh táo là phổ biến.
Rõ ràng, việc tôi sử dụng các giá trị đòn bẩy đang gây ra sự bối rối. Nhiều hơn để đến.
Chỉnh sửa cuối cùng
Thiết kế không còn điên rồ. Tôi không chắc chắn những gì đã xảy ra, tuy nhiên. Tôi đã thực hiện rất nhiều thay đổi để thực hiện các thuật toán mới. Một yếu tố góp phần là 'ROM' gồm 111 phần tử 15 bit. Điều này tiêu thụ một số lượng lớn các macrocell nhưng rất nhiềuvề các điều khoản sản phẩm - gần như tất cả những điều khoản có sẵn trên xc2c64a. Tôi tìm kiếm cái này nhưng không nhận thấy nó. Tôi tin rằng lỗi của tôi đã được ẩn bằng cách tối ưu hóa. 'Đòn bẩy' mà tôi đang nói đến được sử dụng để chọn các giá trị từ ROM. Tôi đưa ra giả thuyết rằng khi tôi triển khai bộ mã hóa ưu tiên 1 bit (bị vỡ), ISE đã tối ưu hóa một số ROM. Đó sẽ là một mẹo khá khó, nhưng đó là lời giải thích duy nhất tôi có thể nghĩ ra. Tối ưu hóa này làm giảm việc sử dụng tài nguyên một cách rõ rệt và khiến tôi mong đợi một dòng cơ sở nhất định. Khi tôi sửa bộ mã hóa ưu tiên (theo chủ đề này), tôi đã thấy chi phí hoạt động của bộ mã hóa ưu tiên và ROM trước đây đã được tối ưu hóa và chỉ dành riêng cho bộ mã hóa này.
Sau tất cả những điều này, tôi đã rất giỏi về macrocell nhưng đã làm cạn kiệt các điều khoản sản phẩm của tôi. Một nửa số ROM là một thứ xa xỉ, thực sự, vì nó chỉ là 2 phần của nửa đầu. Tôi đã loại bỏ các giá trị âm, thay thế chúng ở nơi khác bằng một phép tính đơn giản. Điều này cho phép tôi giao dịch macrocell cho các điều khoản sản phẩm.
Hiện tại, điều này phù hợp với xc2c64a; Tôi đã sử dụng 81% và 84% macrocells và các điều khoản sản phẩm tương ứng. Tất nhiên, bây giờ tôi phải kiểm tra nó để đảm bảo nó làm những gì tôi muốn ...
Cảm ơn ThePhoton và Michael Karas đã hỗ trợ. Ngoài sự hỗ trợ về mặt đạo đức mà họ cho vay để giúp tôi giải quyết vấn đề này, tôi đã học được từ tài liệu Xilinx ThePhoton đăng và tôi đã triển khai bộ mã hóa ưu tiên do Michael đề xuất.
|thay vì ||.
