Manual mistakes?

I am starting to wonder about myself. I keep finding problems in the manual, could it really have these mistakes in it?

  1. The meaning of pllrefset is not in any table, but in section 6.5
    it discusses the default settings of the pllcfg register and
    states that pllrefsel defaults to 0x1, which means "input driven
    from external HFXOSC oscillator. Sadly, experimentation has
    established that this is inverted, Actually, pllrefsel has the
    following meaning: 0 = HF oscillator, 1 = xtal oscillator. I made
    sure of this by disabling the HF oscillator when I thought I was
    on the crystal, and all went well. Selected the HF oscillator as
    the PLL source and then turned it off, everything stopped.

  2. Something seems to be wrong with the PLL Q value. In order to get the
    divide value of 4 that I want, I need to use a value of 3 for Q, which
    is supposed to give me a divide value of 8. So either Q or R is off
    by a factor of 2. I suspect Q because if R were wrong, I would not
    expect the PLL to work.

  3. I wanted to see about getting good trim value for the 72 MHz oscillator,
    as with the default trim it seems to be closer to 94 MHz. In the process,
    I discovered problems in table 5.1, “FE310-G002 OTP Contents as
    Shipped.”

    Item BOOT at OTP address 0 has value 0x7f10106f, manual says
    it should contain 0x7f50106f

    It is supposed to be a jump to LAST FENCE, which (according to
    this same table) is at 0x000207f9. But I decode this instruction
    as a jump to an offset of 0x1FF0, 0r 8176. Sure enough, at that
    point one finds 0x0000_000F (fence), but then the rest of the code
    disagrees. Those OTP addresses are too large if they are hex, too
    small if they are decimal or octal. I stopped investigating here,
    suffice it to say I have no idea where to find HFROSC_TRIM.

I can’t help with the oscillator settings. Sadly, running code is likely to be a better reference in many cases than the manual.

However one thing I found with the -G000 is that reading the OTP is extremely unreliable (impossible, basically) when running at a high clock speed. 16 MHz is fine, 256 MHz definitely isn’t. I don’t know where the limit is.

Thanks for the information about the OTP speed restrictions. I was thinking of doing something with the OTP and I have now decided not to.

I’ll use the crystal oscillator, I’m sure that is bettter any way.

I see hfrosctrim mentioned in table 9 on page 27.

I can’t answer the others. In general, our IP-Core docs are much better than our Soc docs, as there aren’t enough independent reviewers for the Soc docs. I can file an internal doc bug report, and try to get the document updated.

Our bsp github.com/sifive/freedom-e-sdk is more likely to be correct than the docs, but this really only gives you register addresses and layouts. It doesn’t explain how stuff works.

Thanks, Jim. That’s all I’m trying to get, is some long-term improvement in the manual. Assuming you plan to continue to sell this SoC.

SiFive (excluding OpenFive) is an IP Core business. We only make SoCs because we can’t sell IP Cores if there is no software, and people can’t write software if there are no SoCs. We don’t actually sell the FU740 SoC and I doubt that we ever will. We just sell the eval boards that contain them. We want people buying SoCs from our customers, just like you don’t buy ARM chips from ARM, you buy them from ARM customers like Samsung, Qualcomm, and Apple. The market isn’t quite there for RISC-V SoCs yet though. I think Microsemi/Microchip is the only one selling a SoC with a SiFive core on it on the open market. This is the PolarFire part used on the Icicle Kit.

Anyways, SoC manual improvements would be good. I filed a bug report pointing at this forum thread.