Wiki

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
resources:fpga:docs:axi_fan_control [27 Mar 2019 10:39] – added temp parameters, sergiu arpadiresources:fpga:docs:axi_fan_control [12 Oct 2021 16:50] (current) – Edit title & cosmetic changes Iulia Moldovan
Line 1: Line 1:
-      +====== AXI Fan Control IP Core ====== 
-====== Fan Control IP Core ====== + 
-The [[https://github.com/analogdevicesinc/hdl/tree/axi_fan_control/library/axi_fan_control|axi_fan_control]] IP core is a software programmable fan controller.+The [[https://github.com/analogdevicesinc/hdl/tree/master/library/axi_fan_control|axi_fan_control]] IP core is a software programmable fan controller. \\ 
 +Its purpose is to control the fan used for the cooling of a Xilinx Zynq Ultrascale+ MPSoC without the need of any external temperature sensors. \\ 
 +To achieve this, the IP core uses the PL SYSMONE4 primitive to obtain the PL temperature via the DRP interface. Based on the temperature readings it then outputs a PWM signal to control the fan rotation accordingly. The tacho signal coming from the fan is also measured and evaluated to ensure that the RPM is correct and the fan is working properly. 
  
 +===== Block Diagram =====
  
-==== Block Diagram ==== 
 {{:resources:fpga:docs:axi_fan_control_1.svg| AXI Fan Control block diagram}} {{:resources:fpga:docs:axi_fan_control_1.svg| AXI Fan Control block diagram}}
-  
  
-====== Introduction ====== 
-The purpose of this IP core is to control the fan used for the cooling of a Xilinx Zynq Ultrascale+ MPSoC without the need of any external temperature sensors. To achieve this, the IP core uses the PL SYSMONE4 primitive to obtain the PL temperature via the DRP interface. Based on the temperature readings it then outputs a PWM signal to control the fan rotation accordingly. The tacho signal coming from the fan is also measured and evaluated to ensure that the RPM is correct and the fan is working properly. 
  
 +===== Configuration Parameters =====
  
-==== Configuration Parameter ==== 
 ^ Name ^ Description ^ Default Value^ ^ Name ^ Description ^ Default Value^
-| ''PWM_FREQUENCY_HZ'' | Frequency of the PWM signal | 5000   +| ''PWM_FREQUENCY_HZ'' | Frequency of the PWM signal | 5000 [Hz] 
-| ''THRESH_PWM_000  ''Temperature threshold 0x8f5e (5°C) | +| ''ID''ID of the core instance 0 | 
-| ''THRESH_PWM_025_L'' | Temperature threshold | 0x96f0 (20°C)+| ''INTERNAL_SYSMONE'' | Determines the source of the temperature information. ''0'' Means temperature is read from 'temp_in' port | 0 | 
-| ''THRESH_PWM_025_H'' | Temperature threshold | 0xa0ff (40°C)+| ''AVG_POW'' | Specifies the number of tacho measurements (''2^AVP_POW''before averaging them. 7 is the highest value possible | 7 
-| ''THRESH_PWM_050_L'' | Temperature threshold | 0xab03 (60°C)+| ''TACHO_TOL_PERCENT'' | Tolerance of tacho thresholds when evaluating measurements | 25 [%] | 
-| ''THRESH_PWM_050_H'' | Temperature threshold | 0xb00a (70°C)+| ''TACHO_T25 '' | Nominal tacho period at 25% PWM | 1470000 | 
-| ''THRESH_PWM_075_L'' | Temperature threshold | 0xb510 (80°C)+| ''TACHO_T50 '' | Nominal tacho period at 50% PWM | 820000 | 
-| ''THRESH_PWM_075_H'' | Temperature threshold | 0xba17 (90°C)+| ''TACHO_T75 '' | Nominal tacho period at 75% PWM | 480000 | 
-| ''THRESH_PWM_100  '' | Temperature threshold | 0xbc9b (95°C)|+| ''TACHO_T100'' | Nominal tacho period at 100% PWM | 340000 | 
 +| ''TEMP_00_H'' | Temperature threshold below which PWM should be 0% 5 [°C] 
 +| ''TEMP_25_L'' | Temperature threshold above which PWM should be 25% 20 [°C] 
 +| ''TEMP_25_H'' | Temperature threshold below which PWM should be 25% 40 [°C] 
 +| ''TEMP_50_L'' | Temperature threshold above which PWM should be 50% 60 [°C] 
 +| ''TEMP_50_H'' | Temperature threshold below which PWM should be 50% 70 [°C] 
 +| ''TEMP_75_L'' | Temperature threshold above which PWM should be 75% 80 [°C] 
 +| ''TEMP_75_H'' | Temperature threshold below which PWM should be 75% 90 [°C] | 
 +| ''TEMP_00_L'' | Temperature threshold above which PWM should be 100% | 95 [°C] |
  
  
-==== Signal and Interface Pins ====+===== Signal and Interface Pins ====
 ^ Interface ^ Pin ^ Type ^ Description ^ ^ Interface ^ Pin ^ Type ^ Description ^
 |              | ''tacho'' | ''input'' | Tacho generator input | |              | ''tacho'' | ''input'' | Tacho generator input |
 |              | ''pwm'' | ''output'' | PWM control signal | |              | ''pwm'' | ''output'' | PWM control signal |
-|              | ''irq'' | ''output'' | Interrupt signal | +|              | ''irq'' | ''output'' | Interrupt signal, level high| 
-| ''s_axi '' | **AXI Slave Memory Map interface** |||+| ''temp_in ''   | **Input bus for use with System Management Wizzard IP** ||
 +| ''s_axi ''   | **AXI Slave Memory Map interface** |||
 |              | ''s_axi_aclk'' | ''input'' | AXI clock | |              | ''s_axi_aclk'' | ''input'' | AXI clock |
 |              | ''s_axi_aresetn'' | ''input'' | AXI reset | |              | ''s_axi_aresetn'' | ''input'' | AXI reset |
  
  
-==== Register Map ====         +===== Clocking =====
-{{page>:resources:fpga:docs:hdl:regmap##Fan Controller (axi_fan_control)&nofooter&noeditbtn}} +
  
-==== Clocking ==== 
 The IP core runs on the AXI clock and requires a frequency of 100MHz. The IP core runs on the AXI clock and requires a frequency of 100MHz.
  
  
-==== Theory of Operation ==== +===== Theory of Operation =====
-The main features of this IP core are its independent operation and the fact that it does not require an external temperature sensor. All of the mechanisms contained inside the core are controlled by a state machine, so that they do not depend on the software in case the software fails. The state machine uses the temperature it reads from the SYSMONE4 primitive to decide the correct PWM duty-cycle. The temperature thresholds and hysteresis are defined in the hardware and cannot be modified by the software.+
  
 +The main features of this IP core are its independent operation and the fact that it does not require an external temperature sensor. All of the mechanisms contained inside the core are controlled by a state machine, so that they do not depend on the software in case the software fails. The state machine uses the temperature it reads from the SYSMONE4 primitive or via the "temp_in" bus to decide the correct PWM duty-cycle. The temperature thresholds and hysteresis have defaults set in hardware and can be modified by the software. The INTERNAL_SYSMONE paramater is used to set the temperature values source, 0 when reading from temp_in and 1 when instantiating the internal SYSMONE primitive.
  
-=== Running independently === + 
-The hardware can operate with minimal input from the software. Because by default the IP core starts IN-RESET, the software must write 0x1 to the REG_RSTN register to bring up the hardware. In order to activate the interrupts the software must also write to the IRQ_MASK register. At this point the hardware starts operating and a minimal feedback is provided.+==== Running independently ==== 
 +The hardware can operate with no input from the softwarethe IP core starts working after the bitstream is loadedwithout the need to be brought out of reset. In order to activate the interrupts the software must write to the IRQ_MASK register. At this point the hardware starts operating and a minimal feedback is provided.
  
 There are 9 temperature intervals defined in the hardware as below: There are 9 temperature intervals defined in the hardware as below:
Line 54: Line 62:
 {{ :resources:fpga:docs:axi_fan_control_pvm_vs_temp.svg | PWM vs Temperature}}  {{ :resources:fpga:docs:axi_fan_control_pvm_vs_temp.svg | PWM vs Temperature}} 
  
-Five of these intervals have only one possible duty-cycle and four of them can have either of the neighbouring values. After reset the PWM duty-cycle will start as 100%. The state-machine will begin reading the temperature from the SYSMONE4 primitive and will decide on the PWM duty cycle depending on which interval the value matches. The PWM duty-cycle will only change when the temperature enters one of the five intervals with a single PWM duty-cycle, in the other four the previous duty-cycle will be maintained. In these intervals its value will depend on whether the temperature is rising or falling. The temperature thresholds can be redefined using the parameters+Five of these intervals have only one possible duty-cycle and four of them can have either of the neighbouring values. After reset the PWM duty-cycle will start as 100%. The state-machine will begin reading the temperature and will decide on the PWM duty cycle depending on which interval the value matches. The PWM duty-cycle will only change when the temperature enters one of the five intervals with a single PWM duty-cycle, in the other four the previous duty-cycle will be maintained. In these intervals its value will depend on whether the temperature is rising or falling. The temperature can be reconfigured by the software
  
-The temperature is obtained from the PL SYSMONE4 primitive and consists of a 16 bit raw value. This value can also be accessed by the software using the TEMPERATURE register however the reading is done periodically and overwrites the register so only the most value will be available. In order to keep the IP as light as possible, the value obtained from the SYSMONE4 primitive is used as raw, it is not converted to Celsius. In order to convert to Celsius the following formula needs to be used:+The temperature is obtained from the PL SYSMONE4 primitive as a 16 bit raw value or from the temp_in bus as 10 bit. This value can also be accessed by the software using the TEMPERATURE register however the reading is done periodically and overwrites the register so only the most value will be available. In order to keep the IP as light as possible, the temperateure values obtained are used as raw, it is not converted to Celsius. In order to convert to Celsius the following formula needs to be used:
  
 +//Internal SYSMONE4 primitive: //
 //Temperature [C] = (ADC × 501.3743 / 2^bits) – 273.6777// //Temperature [C] = (ADC × 501.3743 / 2^bits) – 273.6777//
-[[https://www.xilinx.com/support/documentation/user_guides/ug580-ultrascale-sysmon.pdf|ug580]]+[[xilinx>support/documentation/user_guides/ug580-ultrascale-sysmon.pdf|ug580]] 
 + 
 +//Reading from temp_in: // 
 +//Temperature [C] = (ADC *20 - 11195) / 41//
  
 There are five configurations described in the hardware, each with a corresponding tacho period +/- 25% tolerance. There are five configurations described in the hardware, each with a corresponding tacho period +/- 25% tolerance.
Line 78: Line 90:
  
  
-=== Software control and customization === +==== Software control and customization ==== 
-The software can request a different PWM duty-cycle by using the provided registers. All of the values inside the PWM/TACHO registers are in clock-cycle periods. It can also provide different tacho parameters if it wants to continue to evaluate the tacho signal. The PWM period can be read from the PWM_PERIOD register and is by default 20000.+ 
 +The software can overwrite the temperature thresholds and the tacho values if needed. The TEMP_00_H -> TEMP_100_L registers can redefine the temperature intervals and the TACHO_25 -> TACHO_100 registers can also be used to redefine tacho values if a different fan is installed. In this case the TACHO_*_TOL registers must also be written in orded to provide tolerances. They must be calculated by the software as % of the nominal value //(i.e. 20% of 10000 = 2000)//.  
 + 
 +The software can also set a custom PWM duty-cycle by using the provided registers. All the values inside the PWM/TACHO registers are in clock-cycle periods. The software can provide custom tacho parameters for that desired PWM if it wants to continue to evaluate the tacho signal. The PWM period can be read from the PWM_PERIOD register and is by default 20000.
  
 //i.e. 5KHz -> 20000 * 10 ns = 200 us// //i.e. 5KHz -> 20000 * 10 ns = 200 us//
  
-The software may request a different PWM duty-cycle if needed by writing to the PWM_WIDTH register. The new value must be greater or equal to the value selected by the hardware and less or equal to the PWM period. The software can use the PWM_WIDTH and PWM_PERIOD registers in order to make sure the new value is valid.+The new PWM value must be greater or equal to the value selected by the hardware and less or equal to the PWM period. The software can use the PWM_WIDTH and PWM_PERIOD registers in order to make sure the new value is valid.
  
 After requesting a new duty-cycle there is a 5 second delay during which the hardware waits for the fan rotaion speed to stabilize. The software will then have to provide parameters for the tacho signal in order for the hardware to be able to evaluate it. To do this the software will have to write the TACHO_PERIOD and TACHO_TOLERANCE registers in that order. The software can read the TACHO_MEASUREMENT register to obtain the new tacho period and derive the tolerance value from it. After requesting a new duty-cycle there is a 5 second delay during which the hardware waits for the fan rotaion speed to stabilize. The software will then have to provide parameters for the tacho signal in order for the hardware to be able to evaluate it. To do this the software will have to write the TACHO_PERIOD and TACHO_TOLERANCE registers in that order. The software can read the TACHO_MEASUREMENT register to obtain the new tacho period and derive the tolerance value from it.
  
-A mearsurement is performed by averaging 128 consecutive tacho perdiod measurements. The time needed to finish a measurement depends on the frequency of the signal.+A mearsurement is performed by averaging 2^AVP_POW consecutive tacho perdiod measurements. The time needed to finish a measurement depends on the frequency of the signal.
  
 The software can now use this register to read the new tacho pediod and then write it to the TACHO_PERIOD register. Then it can write a tolerance value to the TACHO_TOLERANCE register. The hardware will only start to monitor the tacho signal when the tolerance is provided. The software can now use this register to read the new tacho pediod and then write it to the TACHO_PERIOD register. Then it can write a tolerance value to the TACHO_TOLERANCE register. The hardware will only start to monitor the tacho signal when the tolerance is provided.
  
  
-=== Interrupts ===+==== Interrupts ===
 The fan controller supports interrupts to both inform the software of any possible errors and also to facilitate the control of the core. There are four interrupt sources: The fan controller supports interrupts to both inform the software of any possible errors and also to facilitate the control of the core. There are four interrupt sources:
   *The ''PWM_CHANGED'' interrupt is generated at the end of the 5 second delay after a PWM duty-cycle change request. The request can come either from the software or from the hardware   *The ''PWM_CHANGED'' interrupt is generated at the end of the 5 second delay after a PWM duty-cycle change request. The request can come either from the software or from the hardware
Line 99: Line 115:
   *The ''TACHO_ERR'' interrupt is generated when the tacho signal either fails to stay within its designated frequency interval or does not toggle at all for 5 seconds.   *The ''TACHO_ERR'' interrupt is generated when the tacho signal either fails to stay within its designated frequency interval or does not toggle at all for 5 seconds.
  
 +
 +===== Register Map =====   
 +     
 +{{page>:resources:fpga:docs:hdl:regmap##Fan Controller (axi_fan_control)&nofooter&noeditbtn}}
 +
 +{{navigation HDL User Guide#ip_cores|IP cores#hdl|Main page#tips|Using and modifying the HDL design}}
resources/fpga/docs/axi_fan_control.1553679549.txt.gz · Last modified: 27 Mar 2019 10:39 by sergiu arpadi