Tại sao tôi lại thấy một chú chó lạ Wech trên dòng dữ liệu cho một số logic 1?


15

Tôi đang cố gắng xây dựng một máy tính homebrew Z80 để giải trí cho máy tính và để tự dạy mình nền tảng của thiết kế điện tử. Để chứng minh khái niệm, tôi đã lắp ráp một hệ thống cơ bản trên bảng mạch thành công trong những tuần trước.

Nguyên mẫu hiện tại cực kỳ đơn giản. Tôi sử dụng một 4 MHz tinh điều khiển bởi một bộ dao động 74HCT04 Pierce như đồng hồ hệ thống, hai 74HCT573 chốt trong chế độ trong suốt ( LEcao) như một bộ đệm cho bus địa chỉ 16-bit, thêm hai 74HCT573 theo hướng ngược nhau kiểm soát bởi RDNOT RDnhư một dữ liệu hai chiều đệm xe buýt. Tôi đã gắn một EEPROM 100 ns AT28C256 (chỉ 16-KiB được giải mã) và hai chip SRAM 8-KiB 150 ns vào bus hệ thống. Tôi đã sử dụng 74HCT42 để tạo CStín hiệu và kết nối OEEEPROM ở mức thấp, WEcao, chỉ để lại một tín hiệu CS để điều khiển EEPROM.

Mọi thứ trên bánh mì đều ồn ào, nhưng hệ thống dường như hoạt động đầy đủ sau khi tôi hoàn thành mọi công đoạn. Bây giờ, nó có thể tìm nạp các hướng dẫn từ EEPROM, đọc và ghi dữ liệu từ / đến SRAM và nó có một cổng nối tiếp được tạo từ một chốt 74HCT573 khác, D0được kết nối với D0, LE(NOT (IOREQ NAND WR)), đầu ra đi ra Q1, nói cách khác, chỉ có một cổng đầu ra không có logic giải mã adrress. Tôi đã viết một chương trình điểm chuẩn chuyên sâu cho CPU / RAM và máy tính của tôi có thể đưa ra kết quả như mong đợi. Memdumps cũng cho thấy Z80 có thể đọc chính xác tất cả các byte từ EEPROM, vì vậy mọi thứ đều hoạt động.

Nhưng khi tôi cố gắng thăm dò D0pin của bus dữ liệu, tôi đã thấy một số "rãnh" lạ cho một số đầu ra logic 1 rõ ràng.

Một ví dụ về Weird Notches trên D0

và dường như chúng luôn xuất hiện trong một số logic 1 ngay sau khi CStín hiệu của EEPROM hoạt động, ví dụ, đây là một bản ghi của notch lạ được đặt trên tín hiệu CS EEPROM màu xanh.

Một Weird Notch chồng lên tín hiệu CS

Tôi đã cố gắng cách ly vấn đề, vì vậy tôi đã kết nối tất cả các chân CS của SRAM thành CAO, loại bỏ chúng khỏi hệ thống một cách hiệu quả và tôi đã viết một chương trình thử nghiệm đơn giản không có quyền truy cập bộ nhớ.

.org 0x00
    di

    xor a
loop:
    out (0x00), a
    inc a

    jp loop

Nhưng vấn đề là không thay đổi, các "notch" kỳ lạ vẫn luôn xuất hiện trong một số logic 1, chỉ sau MEMRQvà / hoặc (vì về cơ bản là một chip bây giờ) CS(màu xanh) xuống thấp.

Tất cả các chân CS của SRAM đều CAO, vì vậy hệ thống khá nhiều chỉ có chip AT28C256 EEPROM làm bộ nhớ và chốt là cổng đầu ra. Hệ thống này cũng có một lập trình viên trong hệ thống được tạo từ Atmega328p để lập trình lại EEPROM khi đang di chuyển trong một yêu cầu DMA, nhưng tôi không nghĩ đó là thủ phạm vì tôi đã xử lý tất cả dữ liệu và địa chỉ đầu ra của lập trình viên, và Tôi đã nhìn thấy các bậc thậm chí trước khi tôi thêm lập trình viên.

Một ví dụ khác về "rãnh"

Vì vậy, "các rãnh" phải được tạo trong chu kỳ tìm nạp opcode. Họ là ai?

Tôi có một vài giả thuyết:

  1. Không có gì sai, nó chỉ gây ra bởi tính toàn vẹn tín hiệu xấu của các bảng mạch và nó sẽ tự động biến mất trong một PCB được thiết kế tốt và tách rời . Breadboard có tất cả các loại vấn đề toàn vẹn tín hiệu: không khớp trở kháng, phản xạ, điện dung ký sinh, nhiễu xuyên âm, EMI / RFI. Các dây xe buýt dài chạy trên các bảng có khả năng làm cho vấn đề trở nên nghiêm trọng hơn.

    Nếu đó là sự thật, bạn có thể giải thích bản chất của "rãnh" không? Hiện tượng này có một tên trong EE? Tôi đã nhìn thấy nhiều phần vượt quá và đổ chuông trước đây, nhưng chưa bao giờ thấy "rãnh". Và tại sao tôi chỉ nhìn thấy nó ở một số cấp độ logic?

  2. Thời gian. Có thể là một "thời gian giải quyết" ngắn của đầu ra EEPROM hoặc các mạch logic khác đang gây ra hiệu ứng kỳ lạ này trên xe buýt?

  3. Quạt ra. Có lẽ xe buýt dài thu hút rất nhiều dòng điện và có điện dung cao nên đầu ra EEPROM gặp khó khăn khi lái xe buýt cao? Và có lẽ đầu dò dao động cũng đang tải xe buýt?

  4. Sự tranh chấp xe buýt, hoặc các lỗi logic khác gây ra một cái gì đó để kéo bus dữ liệu. Tôi không nghĩ sao? Các thành phần khác trên xe buýt bị cô lập và tôi không thể thấy làm thế nào một AT28C256 EEPROM hoặc một chốt có thể làm điều này. Nhưng tôi đoán nó vẫn có thể xảy ra do lỗi nối dây hoặc do sự cố bên trong bị ẩn trong bảng mạch.

Cập nhật: Tôi đã sử dụng tách tụ và lọc tụ điện trên bảng từ đầu. Tôi đã sử dụng khá nhiều tụ điện tách 0,1 uF trên các bo mạch và CPU thậm chí còn có cả tụ điện 0,1 uF và 0,01 uF để tách rời. Hệ thống hiện tại có 8 bảng, mỗi bảng có hai tụ nhôm 4,7 uF trên cả hai đường ray để lọc cục bộ. Ngoài ra, năng lượng thu được từ devboard có tụ điện tantalum 200 uF. Nhưng như tôi đã nói, vấn đề là ở đây.

Mặc dù vậy, tôi không chắc là nó có đủ hay không, đặc biệt là khi xem xét khó khăn khi đặt 104 tụ gần chip trên bảng. Có lẽ thêm nhiều có thể sửa chữa nó?

Điều tôi quan tâm là nguyên nhân cốt lõi của vấn đề, nếu nó có thể được xác nhận đơn giản là vấn đề cố hữu của việc tách rời không đủ hoặc tính toàn vẹn tín hiệu kém trên bảng điều khiển, tôi có thể ngừng cố gắng lãng phí thời gian để khắc phục sự cố hoặc lo lắng về vấn đề này vì thiết kế cuối cùng sẽ là một PCB. Nhưng tôi không chắc.

Cảm ơn.

Update2: Trong tâm trí của tôi, tôi tin rằng nhận xét của Bruce Abbott đã đưa ra câu trả lời chính xác và vấn đề đã được giải quyết! Mặc dù tôi không thể kiểm tra nó cho đến ngày mai. Thủ phạm là làm mới DRAM của Z80, xem câu trả lời của riêng tôi để biết chi tiết. Hiện tại, không có câu trả lời mới nào là cần thiết và tôi sẽ chấp nhận câu trả lời của chính mình khi tôi xác nhận giải pháp. Nếu nó không hoạt động, tôi sẽ cập nhật câu hỏi. Cảm ơn sự giúp đỡ của mọi người.


Tôi chỉ thấy chỉnh sửa của bạn. Tôi tin rằng nó sẽ là lý tưởng nếu bạn nhìn vào các thông số kỹ thuật và ghi chú thiết kế / ứng dụng cho các bộ phận mà bạn đang sử dụng. Có thể có các thành phần mà bạn đang thiếu ngoài việc tách tụ điện cho thiết bị của bạn. Bạn có chắc chắn rằng bạn đã theo dõi mọi thông số kỹ thuật? Đó là một bài tập nguyên nhân gốc rễ tốt. Ngay bây giờ, câu hỏi của bạn là không thể trả lời mà không có sơ đồ mạch.
KingDuken

6
Một cách để giúp phân tách các vấn đề EMI / nguồn khỏi các vấn đề xung nhịp / logic là thử sử dụng đồng hồ tần số chậm hơn, ví dụ 0,5 MHz hoặc 1 MHz. Nếu trục trặc kỳ lạ đi từ 250ns đến 1us, thì nó dựa trên hoạt động của bộ xử lý. Nếu nó vẫn còn khoảng 250ns, thì đó có thể là sự cố EMI / nguồn. Bạn có điện trở kéo lên / xuống trên xe buýt (đây có thể là phản ứng ba trạng thái) không?
W5VO

1
Hãy xem và xem liệu bảng dữ liệu của bộ xử lý đề xuất / đề xuất bất kỳ điện trở kéo lên hoặc kéo xuống trên bus dữ liệu. Điều đó sẽ giúp giảm cơ hội trục trặc từ hoạt động ba trạng thái. Nếu bạn đã thêm một hướng dẫn "inc a" khác vào chương trình của mình, có lẽ bạn có thể tìm ra hướng dẫn nào gây ra sự cố.
W5VO

1
"... hai 74HCT573 khác ở hai hướng ngược nhau được điều khiển bởi RD và KHÔNG RD dưới dạng bộ đệm bus dữ liệu hai chiều." - có lẽ điều này? Vui lòng cung cấp một sơ đồ mạch hiển thị các tín hiệu điều khiển.
Bruce Abbott

5
Tôi nghi ngờ nguyên nhân là do việc làm mới ở cuối mỗi chu kỳ M1 (tìm nạp opcode). Cần phải xem chính xác cách bạn tạo CS và bộ đệm bus dữ liệu cho phép.
Bruce Abbott

Câu trả lời:


13

Cảm ơn sự giúp đỡ của mọi người. Tôi tin rằng Bruce Abbott đã đưa ra câu trả lời chính xác.Tôi đang đăng bài từ giường của mình và tôi không thể kiểm tra nó cho đến ngày mai, nhưngPhân tích dưới đây được xác nhận, khi ông đề cập đến từ "refresh", tôi nghĩ vấn đề đã được giải quyết. Tôi biết làm thế nào Z80 làm mới bộ nhớ, nhưng hoàn toàn quên nó trong những ngày trước.

... Hai 74HCT573 khác ở hai hướng ngược nhau được điều khiển bởi RD và KHÔNG RD dưới dạng bộ đệm bus dữ liệu hai chiều. "- có thể đây? Vui lòng cung cấp sơ đồ mạch hiển thị các tín hiệu điều khiển.

Tôi nghi ngờ nguyên nhân là do việc làm mới ở cuối mỗi chu kỳ M1 (tìm nạp opcode). Cần phải xem chính xác cách bạn tạo CS và bộ đệm bus dữ liệu cho phép.

- Bruce Abbott

Bộ đệm dữ liệu hai chiều được điều khiển bởi RDNOT RDNếu RDhoạt động thấp, bộ đệm sẽ truyền dữ liệu tới CPU, nếu không, nếu RDở mức cao, điều đó có nghĩa là ghi / xuất, bộ đệm điều khiển bus.

bộ đệm dữ liệu hai chiều

Tuy nhiên, Z80 thực hiện đọc bộ nhớ để làm mới DRAM ngay sau khi tìm nạp opcode. Lần này, RDHIGHmặc dù đó là một hoạt động đọc, khiến bộ đệm để lật hướng và lái xe buýt, kết quả là một ganh đua xe buýt. Vì vậy, các "notch" kỳ lạ sẽ luôn xuất hiện trong chu kỳ làm mới DRAM, nhưng không phải là đọc / ghi bộ nhớ thông thường hoặc I / O. Điều này giải thích tại sao "notch" sẽ luôn xuất hiện, nhưng chỉ đối với một số người, và không phải tất cả các logic 1.

Sơ đồ thời gian tìm nạp opcode Z80

Hơn nữa, SRAM không cần được làm mới để làm mới DRAM hoàn toàn vô dụng trong hệ thống của tôi và sự tranh chấp xe buýt này sẽ không làm hỏng bất kỳ hướng dẫn hoặc dữ liệu nào, làm cho hệ thống có vẻ đầy đủ chức năng.

Giải pháp: thực hiện (RD AND REFRESH)(NOT (RD AND REFRESH). Trong lần sửa đổi tiếp theo, tôi cũng nên kiểm tra BUSACKđể đảm bảo bộ đệm dữ liệu không lái xe buýt trong quá trình vận hành DMA.

Cập nhật: Tôi có thể xác nhận vấn đề và giải pháp. Sử dụng WRNOT WRthay vào đó đã khắc phục sự cố, như được hiển thị trong sơ đồ mới( đừng làm điều này! Điều này cũng sai, xem Cập nhật 2 ).

Sơ đồ mới (sai)

Các dạng sóng trông bình thường bây giờ!

Dạng sóng mới, cho thấy vấn đề được sửa chữa.

Update2: Các sơ đồ trên cũng bị hỏng, nếu bạn là người đọc câu trả lời này, đừng sử dụng nó! Nếu giả sử xe buýt là WRkhi RDtín hiệu không hoạt động là đủ xấu, thì giả sử xe buýt là RDkhi WRkhông hoạt động thậm chí còn tồi tệ hơn. Tôi đã sử dụng chương trình trước để thử nghiệm ban đầu, vì vậy hệ thống có vẻ hoạt động, nhưng nó đã bỏ lỡ một vấn đề nghiêm trọng.

Trong chu kỳ ghi bộ nhớ, CPU Z80 sẽ bắt đầu lái xe buýt trước khi WR hoạt động ở mức thấp, tại thời điểm này, bộ đệm dữ liệu vẫn đang truyền dữ liệu về phía CPU, rất tiếc, tạo ra sự tranh chấp giữa xe buýt.

Sơ đồ thời gian đọc / ghi bộ nhớ Z80

Bruce Abbott là chính xác: tốt hơn là luôn luôn sử dụng RDWRtín hiệu độc lập để kiểm soát từng bộ đệm, thay vì đảo ngược một bộ đệm.

Ví dụ,

Sơ đồ mới (đã sửa, nhưng DMA chưa được xử lý, bạn nên xử lý việc đó.

Nó hoạt động hoàn hảo bây giờ.

Và cuối cùng, một lần nữa, sơ đồ trên là một sự đơn giản hóa, người ta cũng nên kiểm tra BUSACKđể đảm bảo bộ đệm dữ liệu không lái xe buýt trong quá trình vận hành DMA.


6
Bạn có thể cân nhắc sử dụng / WR thay vì đảo ngược / RD để kích hoạt bộ đệm trên. Bằng cách đó, bus dữ liệu sẽ không hoạt động trừ khi đang đọc hoặc ghi thực tế.
Bruce Abbott

8

Đảm bảo rằng bạn có các tụ tách rời thích hợp trên tất cả các IC của bạn. Một gốm 100nF từ nguồn đến mặt đất trên mỗi IC giữ cho các dây dẫn của nó càng ngắn càng tốt và điện phân ESR thấp nói 100uF trên bảng mạch trên đường ray điện.


Có vẻ là giải pháp cho rất nhiều bất ổn cho IC kỹ thuật số :)
KingDuken

4
@KingDuken Hoàn toàn và một chút chủ đề nóng đối với tôi, một người bạn của tôi đã bị sa thải một lần vì đã bỏ lỡ một lần. Gây ra rất nhiều bất ổn trong một máy xử lý tiền mặt, rất tiếc.
RoyC

2
Việc tách rời rất quan trọng, nhưng nó không phải là câu trả lời cho mọi thứ. Rõ ràng là từ dạng sóng mà nó dường như không liên quan ở đây.
pericynthion

4

Tôi thấy hai khả năng ở đây:

1) D0 bị trist

Bất cứ điều gì đã khiến D0 chuyển sang tristate (chế độ trở kháng cao) và sau đó kéo xuống ở đâu đó trong mạng D0 sẽ làm giảm điện áp xuống (hằng số thời gian được xác định bởi điện trở kéo xuống và điện dung ký sinh của IC và dấu vết). Bản chất theo cấp số nhân của dạng sóng là một dấu hiệu mạnh mẽ cho thấy đường truyền không bị điều khiển bởi thứ gì đó mạnh mà thay vào đó là lực kéo xuống tương đối yếu.

Hãy thử thêm một điện trở kéo xuống dòng khác và kiểm tra xem dạng sóng theo cấp số nhân có nhanh hơn không.

Hãy nhớ rằng đây không hẳn là một vấn đề và xe buýt của bạn có thể hoạt động hoàn toàn tốt với điều này.

2) Ganh đua

Giả thuyết của bạn # 4. Cũng có khả năng D0 được rút ngắn thành một dòng logic khác. Tôi thấy điều này là không thể, vì trong trường hợp này bạn sẽ không thấy dạng sóng theo cấp số nhân với hằng số thời gian tương đối dài như bạn thấy bây giờ. Bạn có thể thăm dò các mạng khác trong mạch của mình để tìm kiếm một dạng sóng giống hệt nhau, cho biết bạn có một đoạn ngắn.

Chúc may mắn!

PS - đây không phải là vấn đề toàn vẹn tín hiệu, độ rộng xung quá dài cho điều đó

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.