Rejestry konfiguracyjne dla magistrali LPC w Poulsbo System Controller Hub (US15W)

Question

Mamy system oparty na karcie Atom Z510/Intel SCH US15W Q7 (z systemem Debian Linux). Musimy przesłać bloki danych z urządzenia na niskim poziomie. Pin Count Bus. O ile wiem, ten mikroukład nie zapewnia urządzeń DMA, co oznacza, że ​​procesor musi odczytywać dane po bajcie w pętli oprogramowania. (Sterownik urządzenia faktycznie wykonuje to za pomocą instrukcji "rep insb" x86, więc pętla jest faktycznie zaimplementowana przez CPU, jeśli dobrze rozumiem.)

Jest to daleki od optymalnego, ale powinno być możliwe uzyskanie szybkości transferu 14 Mb/s. Zamiast tego możemy ledwo zarządzać 4 Mb/s przy transakcjach na magistrali nie bliżej niż 2 us od siebie, nawet jeśli każdy odczyt do urządzenia slave jest wykonywany w 560ns. Nie wierzę, że winę ponosi inny ruch w autobusie, ale nadal prowadzę dochodzenie.

Moje pytanie brzmi:

Czy ktoś wie, czy są jakieś rejestry konfiguracyjne na SCH które mogłyby wpłynąć na taktowanie magistrali LPC?

Nie mogę znaleźć żadnych przydatnych informacji na temat urządzenia na stronie internetowej Intela, ani też nie zauważyłem niczego w kodzie jądra Linuksa, który wydaje się manipulować przy takich rejestrach (ale jestem noob, gdy dojdzie do Linuksa Kernel rzeczy.)

Nie jestem ekspertem x86, więc dobrze byłoby wiedzieć o innych czynnikach, które mogą wejść w grę lub o innych "historiach wojennych" związanych z tym urządzeniem.

Edytuj: Znalazłem datasheet. Nie widziałem w tym niczego, co wyjaśniałoby to zachowanie, ale badam możliwość mapowania naszego urządzenia jako oprogramowania układowego, ponieważ cykle magistrali oprogramowania układowego nie mają takich samych opóźnień.

Answer 1

W celu zapisania, rozwiązaniem było zmodyfikowanie oprogramowania układowego FPGA, tak aby rejestr danych wejściowych/wyjściowych układu scalonego był odwzorowany na cztery sąsiednie adresy, a sterownik zmodyfikowany w celu wykonania 32-bitowych instrukcji inb/outb. Chociaż SCH nie implementuje 32-bitowych operacji odczytu/zapisu LPC, wynikiem są 4 operacje back-to-back 8-bitowe, po których następuje taki sam czas martwy, jak poprzednio, z pojedynczym bajtem, co oznacza, że ​​średnia wynosi 1us na bajt. Nie idealne, ale wciąż podwojenie przepustowości.

Okazuje cykle oprogramowania było szybsze, ponieważ przenosi SCH 64 bajtów w czasie od oprogramowania układowego - po 64 bajtów nie jest taki sam odstęp 1.4us, wskazujący to opóźnienie za transakcję urządzenia. Wykorzystanie tego może być nieco szybsze niż powyższe rozwiązanie, jednak kompromis jest ograniczony do 64 bajtów, a każdy bajt zajmuje więcej czasu (680ns IIRC) z powodu dodatkowych cykli wymaganych do odczytu oprogramowania układowego.