HiFive Unleashed Documentation is Here

The team here at SiFive have been busy writing and have now released documentation specific to the HiFive Unleashed on the website.

Freedom U540-C000 Manual
HiFive Unleashed Getting Started Guide
HiFive Unleashed Schematics

Here at SiFive, we take documentation seriously and have been working to improve our offering. The Freedom U540-C000 Manual and Getting started guide are of particular importance because they represent the first documents released under a new, internally developed, documentation flow which gives us improved capabilities in both documentation generation and publication.

It is still a work in process, so please let us know if you find any mistakes.


“115200 baud” not “15200Hz”

On Linux, I think the console on the FTDI port is port1 (it was ttyUSB1 on my system) not /dev/…path…/*port0 but I can’t test that right now…

Yup. on modern versions of Ubuntu, it’ll show up as both /dev/serial/by-path/port0 and as /dev/ttyUSB0.

On Red Hat/CentOS, port0 (ttyUSB0) is the JTAG interface not the console. The console is ttyUSB1.

1 Like

Hi, nice manual! :slight_smile:
So far I’ve noticed the following small errors and omissions in the FU540 manual v1p0:

Chapter 1, Introduction

  • “and is a(n) 16-way set-associative cache.” <- this should probably be “a 16…”

Chapter 2, List of Abbreviations and Terms

  • ChipLink could be added

Chapter 6, Boot process

  • “Then, the entire contents of this partition, the FSBL, are downloaded into the L2 LIM at address 0x0800_0000. Execution then branches to the FSBL.” -> are there any size size limits?

Chapter 13, UART

  • txdata.full is marked as RW. Is this intended? What effects do writes of a one vs. a zero into the the full flag have?

Chapter 18, OTP

  • “serial_n = read_otp_word(i+);”, s/i+/i+1/, i guess?

Chapter 20, DDR Subsystem

  • “The DDR Subsystem is ready to service memory accesses at base address
    0x0800_0000.” <-- This should probably be 0x8000_0000.

Chapter 6, Boot process

  • The paragraphs about flash-based boot modes have phrases like “When the core is running at 33.3 MHz, this means 8.3 MHz. At 1 GHz, this means exactly 10 MHz.”, but section 6.5.4 (SD Card Bit-Banged x1) simply says “Set the QSPI controller to 20 MHz.”, without considering different speeds of coreclk.
    As far as I understand it, the QSPI block can’t run at 20MHz if coreclk runs at 33.33… MHz, and consequently tlclk at 16.66… MHz. So, how does ZSBL configure the QSPI clock in this case?

Chapter 12, Platform DMA Engine

  • “Indicates that the channel is is in use. Setting this clears all of the chanel’s Next registers.” (simple typo)

I think I found a documentation/silicon bug:

Chapter 13 (UART) says: "The input clock is the bus clock tlclk. The reset value of the register is set to div_init, which is tuned to provide a 115200 baud output out of reset given the expected frequency of tlclk."
And indeed div_init=289 seems to be the reset value, but it doesn’t give 115200 baud, but 57600 baud. If f_in was hfclk=33.333MHz, we’d get f_baud = 33333333 / (289 + 1) = 114942 ≈ 115200; but f_in is tlclk=hfclk/2, so the baud rate is halved as well.
I tested this with boot mode 1 (jump to SPI flash) and some code that prints text on the UART and either sets the divisor to 289 or not at all; the result was the same in both cases, I had to configure the FTDI to 57600 baud to read the output correctly.

ZSBL does seem to set the divisor to the right value to get 115200 baud.

Firstly, thanks for your detailed comments on the spec. We have not posted here, but we have been including your corrections for the next revision.

As to your specific concern wrt. the UART, you are correct that tlclk is the clock which is divided by div_int. You may also be correct that the reset value is 289 (I’ve not checked). However, the chip has a TLCLKSEL pin which allows you to set tlclk to either hfclk or hfclk/2, so there is no way to pick a value on reset that works for all cases. The ZSBL inspects this pin when it configures div_int on power up.

Thanks for your effort!

Ok, I didn’t know about TLCLKSEL, as it isn’t mentioned in Chapter 7 (Clocking and Reset). The block diagram for PRCI only shows a fixed “/2” between coreclk and tlclk.

Here are a couple minor Documentation errata for the FU540-c000-v1.0 document:

  • Section 4.1 references Section 3.1.1 but I think it intended to reference section 4.1.1.

  • There is no description of how to use the DTIM. Presumably it is the same method as for the ITIM but this is never explicitly stated.

Want to ask developers a couple of questions:
1 Why Altium was used for developing of the schematics (not open software, i.e. KiCAD)?
2 Which license are schematic files published under?

Thanks for the feedback.

The DTIM is simpler than ITIM. It’s not a usable as a cache at all, it is just a scratchpad memory with a fast access time for the core that has it.

Page 11 "4× E51 RISC‑V cores " should be “1x E51 RISC-V core”

Thanks! The design is in fact 4x U54 cores and 1xE51. This will be fixed in the next release of the document.

Table 57 in section 13.2 indicates div_width=20 for both instances of the UART.

Table 66 in section 13.9 shows the div field as bits 15:0, while the description says “Baud rate divisor. div_width bits wide.” If Table 57 is correct then this field should be bits 19:0.

Are there any mechanical drawings of the board and/or CPU?



A description of the layout of the L2 Zero Device memory region (0x0a00_0000:0x0bff_ffff) seems to be missing.

Presumably it matches the layout of the L2 LIM region (0x0800_0000:0x9ff_ffff) shown in Figure 5 but this is never explicitly stated.

Can you please confirm if this is the case?


The LIM and the zero device are not the same. The LIM is directly backed by a fixed amount of SRAM controlled by the L2 way enable register. The zero device is a device which … returns 0s on read and discards writes. However, the zero device is cached, so you can use way locking on the L2 to prevent eviction and turn it into a scratchpad.

The description of the PRCI hfxosccfg register in table 12 in chapter 7 is missing a description for bit 31, which I assume should just be described as Reserved.

The same applies to bits 31:25 for the ddrpllcfg1 and gemgxlpllcfg1 registers in tables 15 and 17 respectively, and bits 31:6 for the devicesresetreg in table 19.