BBA MVP

A short one, today.

While working on the DMA side of things, I didn’t think about non-DMA requests. 1,500 bytes are written during the BBA’s start-up sequence, which are set one-by-one. This became an issue once I realised that all addresses are on a two-byte boundary and completely ignored the BL#/BH# signals during a read or write operation. All of the logic assumed either a byte is access at a specific address or it isn’t. A collosal mistake on my part and something I should have seen coming, considering the PCI-like nature of the bus. After some restructuring, the BRAM module used to store both the G2 configuration and the DMA area of memory was rewritten to support Wishbone’s SEL signal. Internally the configuration memory was organised as bytes, with accesses being either one word at a time or a byte. DMA was assuming word-based access at all times and stored the memory as words. This used to be a single signal indicating access to one byte or both for the configuration memory. Seeing as though both the low and high byte could be accessed, this necessitated a mostly-trivial change that impacted all other instances of the BRAM module. After a day or two of debugging, it was working as intended.

One nice side-effect is that I no longer have a bunch of hacks in the design to accomodate what I should have done from the start. I updated the G2 bus details post a few days ago with byte transaction information. Reading the entry, I realised that I haven’t even discussed DMA transactions. I’ll try and remember to update it later this year, but it’s mostly the same as a 32-bit transaction except that the TR# line is asserted until 32 bytes of data have been written and that the last transaction’s address ends with a ‘1’. Another thing I haven’t yet explored is the ST# signal and I haven’t yet shown an example of an interrupt.

Anyway, below is a screenshot that exhibits that the NexGen library at least recognises the BBA, as indicated by the address displayed, the status of the ETD_GetEthAddr function, and the speed alongside the RTL’s MSR. Sending and receiving packets are not quite there, and won’t be for a while.

For the test code in simulation, there’s still a lot to go over to complete the same ETD_Init functionality. It’ll be a few more days of toil there, then it’s onto the KSZ8041TL emulation that could take a while.

The next step is to update the link status and mode when a connection is made. A few of the registers aren’t used (mostly the CardBus- and power management-related ones), which helps a little bit to cut down on the logic count. I’m also considering adding the same type of NOR for the BBA’s configuration as used on the real thing, but it may be expanded to a larger storage chip for more general settings that could be used to configure the adapter’s settings. Not really sure about that at the moment, just kind of writing out what I’m thinking.