Honored Contributor
Honored ContributorAll I can say really is welcome to University Program IP cores. For the DE1-SoC board we use for teaching, I've ended up rewriting the majority of the IP cores for the DE1-SoC computer design because the quality and reliability of the IP cores provided is simply appalling.
Getting a non-null pointer in Nios doesn't mean anything about the external hardware, it just means that there is a base address defined in the board support package. Even if you didn't connect the external pins of the IP core, you would still get a non-null pointer. As for the PLL not having a reset, it will likely not cause a problem. It just means it can't be reset after a loss of lock, not ideal, but functional. To be honest all of the Altera and Terasic sample designs don't bother with the reset either, so clearly they pay a lot of attention in there designs. If you haven't already, make sure you set timing constraints on the IO pins for the SPI. You could be getting timing issues on the SPI lines. You can check this by analysing the lines with an oscilloscope. You could also try not using the PLL at all. Assuming Nios is running from a 50MHz clock, feeding a 50MHz clock into the clock pin of the accelerometer core will give an SPI rate of 3.125MHz which is within the 5MHz limit for the AXDL345. Fewer random bits of Avalon-MM fabric will probably help. --- As an alternative, scrap that core entirely. The "SPI 3 Wire Serial" core in Qsys (Interface Protocols/Serial), is one of the few cores that does seem to work properly in my experience. If you set it to: - data width: 16 - clock phase: 1 - clock polarity: 1 - shift direction: MSB first - number of slaves: 1 - spi clock rate: 1000000 (1MHz) Leave the rest of the parameters as default values. You won't need a separate PLL. Just connect it to the same clock as the Nios processor. It has an internal clock divider. From a code stand point, you would now simply send 16 bit data words from Nios that are: "((read << 15) | (address << 8) | (data))".
