This website uses cookies. By using this site, you consent to the use of cookies. For more information, please take a look at our Privacy Policy.
Home > FPGA Technical Tutorials > FPGA-Based Prototyping Methodology > Getting the design ready for the prototype > Prototyping power-saving features

TABLE OF CONTENTS

Xilinx FPGA FPGA Forum

Prototyping power-saving features

FONT SIZE : AAA

In most cases, the power mitigation of an SoC is implemented by the use of scripts  and control files outside of the RTL, in a language such as universal power format  (UPF). The result of running UPF controls with SoC synthesis and back-end are that  the RTL is modified and/or supplemented with extra circuitry. Generally, the  prototyping team receives the RTL before this power mitigation work has taken  place and it is still a pure description of the SoC function for prototyping purposes. 

However, with the growth in sophistication of SoC power mitigation techniques,  prototypers are sometimes asked if there is a way to test the RTL after the UPF and  similar controls have inserted power-down modes, data retention and clock control. 

Power modeling in FPGA is an interesting problem and not something that is easily  implemented. Some functions obviously do not make sense in the FPGA, for  example, the modeling of switching off the power to certain parts of the chip, but  there is merit in prototyping some of the other properties.  

It is possible to use the clock-gating features of synthesis tools to model some of the behavior, and careful use of PLLs can allow the frequency scaling features to be  implemented, but adjustment of the supply voltage would not give any benefit, nor  would the power monitoring of the core supply to the FPGA to determine power  consumption as this would not be representative, and even worse give misleading  results

However, it may be beneficial to use our prototype to model the power-control  system itself and for this we would need to create some extra RTL, which would  fool the power controls and the software into believing that the silicon was  responding as expected. We can indeed dynamically adjust the frequency via  internal or external PLLs. We could also mimic the expected responses of a voltage  change or the effects of turning-off sections of the design. This might be useful for  validating the software that controls such things but the complexity might far out  way the benefit. 

The model in its simplest mode would mimic the registers and interfaces seen in the  real world and implement the time delays we would expect for the real system.  However power gating sections of the design is more difficult as we would need to generate the impression that a section is powered down when the FPGA silicon  cannot actually be powered down. For example, we would need to implement clock  gating or other features to ensure that a section does not respond when it is meant to  be switched off. It would also be impossible to represent the random values that  might appear in SoC registers that are powered down because the FPGA registers  would not actually have been powered down and will still hold valid values, perhaps  masking an effect that would be very important to witness in the real sislicon. In  these examples we see that perhaps, modeling SoC power-down feature s in FPGA  might be more misleading than helpful. 

To implement these features would either require RTL modification to the real SoC  design (which is not ideal and should only be considered if really necessary) or the  use of the ability of the Xilinx® FPGA device to be reconfigured (partial bitstreams  with different INIT values may be loaded while the devices are operating, to  determine if the changes in the values affect the design). It is not the aim of this  book to explain partial reconfiguration, but further information can be found in the  references.

Recommendation: prototyping is intended for creating a functional model of an SoC for software validation and system-level integration of software and hardware,  pre-silicon. It performs this task best upon RTL which is delivered before it is  manipulated for power saving or test purposes.



  • XC2C384-7TQG144C

    Manufacturer:Xilinx

  • CPLD CoolRunner -II Family 9K Gates 384 Macro Cells 217MHz 0.18um Technology 1.8V 144-Pin TQFP EP
  • Product Categories: Industrial components

    Lifecycle:Active Active

    RoHS:

  • XC2C512-10FGG324I

    Manufacturer:Xilinx

  • CPLD CoolRunner -II Family 12K Gates 512 Macro Cells 128MHz 0.18um Technology 1.8V 324-Pin FBGA
  • Product Categories: Embedded - CPLDs (Complex Programmable Logic Devices)

    Lifecycle:Active Active

    RoHS:

  • XCS10XL-VQ100AKP

    Manufacturer:Xilinx

  • Xilinx QFP100
  • Product Categories:

    Lifecycle:Obsolete -

    RoHS: -

  • XC3S50-5TQG144C

    Manufacturer:Xilinx

  • FPGA Spartan-3 Family 50K Gates 1728 Cells 725MHz 90nm Technology 1.2V 144-Pin TQFP EP
  • Product Categories: FPGAs

    Lifecycle:Active Active

    RoHS:

  • XC3S50A-4FT256I

    Manufacturer:Xilinx

  • FPGA Spartan-3A Family 50K Gates 1584 Cells 667MHz 90nm Technology 1.2V 256-Pin FTBGA
  • Product Categories: FPGAs

    Lifecycle:Active Active

    RoHS: No RoHS

Need Help?

Support

If you have any questions about the product and related issues, Please contact us.