Large industrial grade storage support and power consumption control on SOM

[Cenwei_Liu]

Hi community,

We have an application which need at least 128GB industrial grade storage and low power consumption. We would like to use SOM to shorten development cycle.

1) 128GB industrial grade storage

This storage need not to be removeable but considering market availabity, development cycle and cost, SDXC will be the best choice. However, SOM spec read it only support SDHC and up to 32GB storage.

We search Xilinx forum and found the following post:

http://forums.xilinx.com/t5/Zynq-All-Programmable-SoC/Booting-Zynq-from-a-64GB-SD-Card/td-p/555049

It reads:  "boot from SDXC, with primary partitions formatted as FAT, and use custom FSBL that supports exFAT"

Can anyone please help confirm if this solution will work or not?

We also need to know the SDXC access speed if custom FSBL works. >5MB/s write and >10MB/s read access throughput is desired.

2) Power consumption control'

Zync-7000 has three power mode listed as below:

We are wondering how shall we program in LabVIEW to enable these power modes?

Thanks!

[Cenwei_Liu]

http://forums.xilinx.com/t5/Zynq-All-Programmable-SoC/SD-SDIO-amp-card-controller-Query/td-p/490818

In the above link it reads:

"I've been using 64GB SD cards, by having a small FAT partition.

FSBL and U-boot are in a QSPI, then the Linux root fs is read from the FAT partition on the SD card.     The rest of the SD card is currently ext2fs, but we might switch to exFAT; even with exFAT, the small FAT partition will remain.

This large partition is only used under Linux, the bootloaders can't see it."

In another thread:

http://forums.xilinx.com/t5/Embedded-Development-Tools/Zynq-and-SDHC-card/td-p/268328

Someone says: "It seems there's no support from Xilinx for doing this either, they basically expect you to use their FSBL, which is pretty slow at SDcard access, or linux."

I don't know how slow FSBL would be, but I will need >5MB/s write and >10MB/s read SD access performance.

Please help with this problem. I believe the solution will also be applicable to other cRIO systems.

Thanks!

[tannerite]

Hi Cenwei_Liu,

1. SDXC uses exFAT by default. I am not an expert in filesystems (I would recommend posting to the NI Linux Real-Time Community for deeper questions); however, Windows does not allow you to format a disk that is larger than 32 GB as FAT32 even though the FAT32 filesystem supports large sizes than that.

To circumvent this, I downloaded a third-party Windows-based tool from the web to format an SDXC (Panasonic SDXC Class 10, MLC) with FAT32. I then inserted into the SOM's Reference Carrier Board and was able to write and read from the card. I did the same process but with formatting the SDXC card with the ext3 filesystem that is supported on NI Linux Real-Time. I was also able recognize, read, and write to disk without issue. There are no hardware limitations that I am aware of that prevents using an SDXC card.

The reason we state that only SD and SDHC is supported is because our Real-Time development team has not tested and vetted that this works without issue. That being said, I was able to enumerate the drive and read/write to disk. I would recommend using the ext3 filesystem since it is journaled. Neither FAT32 or ext3 were designed for solid-state storage though we have used this fine in the past with USB drives on CompactRIO. For instance, the file table for FAT32 does not get wear-leveled. If you are creating a deleting a lot of files that causes changes to the file table, a vulnerability of FAT32 is that you will eventually "wear out" the file table.

Here is my successful enumeration of the SDXC card:

You also posted about the FSBL and U-Boot. If you are needing to boot from an SDXC (or any SD) media, that is not possible on the SOM. There are bootstrapping options that are set in the hardware that prevent this. We also do not support modifying the FSBL or U-Boot in any way. Zynq is very configurable by itself, but once you develop a product around it, it constrains the configurability of Zynq -- this is the case here.

2. Though the Zynq-7000 series has low power states as you mentioned; however, National Instruments does not allow you to enable or disable these states through software or hardware. If you are concerned about power consumption of the SOM, one way we can get to a lower power consumption state is to load a blank, compiled bitfile onto the FPGA fabric. I believe one of the main reasons power states are not allowed on any of our CompactRIO or Single-Board RIO products is due to maintaining determinism with the RTOS.

Depending on the application, another option is to have your carrier board power down the SOM when it is not needed. This would allow you to boot the SOM every X minutes or hours to take meausrements or perform a task if you are concerned about minimal power dissipation.

- Tanner

[tannerite]

As for the read/write speeds, we list that in the manual:

- Tanner

[Cenwei_Liu]

Hi Tanner,

Your answer helps a lot!

There are two more questions I want to confirm:

1. Why does writing a blank bitfile onto the FPGA lead to low power consumption? Does this action shut down FPGA actually?

2. Does the ARM cores always running at maximum clock in RTOS? That means they are always consuming maximum power. While it is now allowed to shun down one core, it is possible to reduce CPU clock as specified by Xilinx? If yes, can we do it programmatically?

Thanks!

Cenwei

[tannerite]

Hi Cenwei,

1. Writing a 'blank' bitfile to the FPGA means there is a minimal amount of logic on the fabric and that logic is not toggling. The main power consumption on the FPGA is due to both the amount of logic on the FPGA, and the toggle rate of that logic.

As you probably notice, compiling a blank bitfile takes some amount of time to compile and is not instantaneous -- this is due to some backend VHDL that is always present, but is not accessible. For instance, routing EMIO signals.

So having a blank bitfile means that the FPGA is not running any LabVIEW FPGA code, which leads to lower power consumption.

2. As you screenshotted, the TRM states that you can change the clock values. This is something that you can do by hitting the necessary registers during run-time or changing an environmental variable in U-Boot before boot but National Instruments does not support this. All testing and verification with both hardware and software have been done with the shipping settings and U-Boot configuration; therefore, we cannot recommend changing these settings.

- Tanner

[Cenwei_Liu]

Hi Tanner,

Now we understand the reasons behind. You are very helpful. Thanks a lot!

Cenwei

[tannerite]

Cenwei,

It would be helpful to understand what power consumption you are wanting to hit. It may be out of the ballpark of what the SOM is capable of, but it may be well within reason. Our maximum power numbers are assuming you are fully exercising the FPGA, and using LVDS outputs which burn a lot of power at the driver. If you are not using LVDS outputs (or a relatively small number) and are not exercising the FPGA, this power number drops dramatically.

I believe when the system is idling and no I/O is used, the minimum power consumption is around 2 W. We expect most customers to fall in the 3 W to 5-6 W operating range.

- Tanner

[Cenwei_Liu]

Hi Tanner,

Desired power consumption is less than 1W on average. 3W+ would be a big challenge since we have to take some measures to reduce power consumption. We will use some I/Os like UART, SD, ethernet, and some DIOs for several ADCs. Data throughput should be around 2MB/s or 500kS/s in total. We also need to use FPGA for signal processing and I guess FPGA usage won't be low. The system is not going to be on all the time, thus we want to be able to get the SOM into sleep mode whenever possible.

Our competition is in-house custom hardware which is also based on Zync-7020, but it should be able to control sleep and CPU clocking. Another competition is an ARM+DSP solution which consumes just a few hundred mW, but it is not a preferred solution as the customer do not like DSP.

Shutting down the SOM would be a choice to control power consumption but we are worried about the wake-up time. 1 or 2 seconds might be OK but it feels like the SOM needs more than 15 seconds to boot up, which is unacceptable.

Thus we are still trying to figure out if there is a way to put it into sleep mode and wake it up with external daughter board. We'd appreciated it if you have any good ideas.

Thanks!

Cenwei

[Spex]

Hi Cenwei,

What is the duty cycle and frequency of the wake/sleep events for this application?  Do you need to wake up based on time, or an external trigger?

If the frequency of wake events is low (to account for the 15+ second boot time) and significant sleep time is allowed between wake events, then 1W average power seems very feasible.  If you are looking for frequent wake/sleep events, then using the carrier board to shut down/boot the SOM isn't a viable option. 

Other than the method of turning off the SOM between wake events, NI doesn't have any supported or tested mechanisms to put the Zynq into low power states.  There may be (NI unsupported) ways to manipulate the registers that you identified, but care would need to be taken to ensure processor is put to sleep in appropriate states and resumes operation successfullly.  Your customer would need to take responsibility for testing the robustness of their sleep/wake implementation.  This may be extremely difficult given the extent of NI implemented drivers on the SOM that would be impossible for the customer to test/diagnose/debug at low levels.

Regards,

spex