FPGA, SoC, And CPLD Boards And Kits
FPGA Evaluation and Development Kits
6307 Discussions

Problems with DEV_CLRN and PINs, MAX10

PedroJServian
Novice
304 Views

Hi colleagues,

 

I have been dealing with a problem with a design I have made for my 10M08 FPGA. My program have a "PWM treatment" design that gets some PWM signals from a microcontroller and makes a process of minimum pulse and deadband pulse to generate an adequate signal for an inverter. Then, those outputs signals come to an AND condition so the pulses are generated in fiber optics if the MCU gives me a ENABLE signal, there is no fault and there is not a power down. 

Then I have a design that detects if the feedback from the driver of the IGBTs that I switch with these PWM signals get the appropiate feedback from the Driver. The logic from the driver is that when a rising edge or falling edge of light comes to the receiver it transmit a pulse (no light), if the pulse last more than 1,5us, there is a shotcircuit in the IGBT.

What I have been struggling when I have tested the model is that ONLY at the beggining, these errors of the IGBTs are generated and after watching some testpoints I have seen that this error is generated when the DEV_CLRn is putting in HIGH so the registers are loaded based on the manual but the output pulses are in low position as the enable signal is not given so I don't get why am I getting this error because then I clear the error with a PROGRAMMED input RESET from the MCU and the error is cleared as it doesn't have any sense (there is no commutation of the pulses). This DEV_CLRn pin is set as the "special" use in the project configuration but I don't use this pin in my design. What  I would like to know is why this fault is generated when it is a "ghost" fault as the pulses are off.

I would very pleased if you could help me.

 

Thank you in advance.

 

Pedro

0 Kudos
4 Replies
FvM
Honored Contributor II
254 Views

When DEV_CLRn isn't used in your design, you should disable global device clear function in Device & Pin settings. If you already did, your issues can't be related to DEV_CLRn level.

 

Problems at startup may be caused by weak-pullup of FPGA IO pins in unconfigured state that cause a high level during start-up if no external pull-down resistors of sufficient strength are connected.

0 Kudos
AqidAyman_Intel
Employee
161 Views

Thanks @FvM for the input shared.


May I know if there is any more questions on this?


0 Kudos
PedroJServian
Novice
75 Views

@FvM 

Thank you very much for your response. I recognise that I feel a little bit confused with all the configuration pins that are used in our design. I show you the schematic we have for our FPGA. 

cap_fpga.PNG

The pins that are rounded with red colour go/come to/from MCU. As you can see, we route the pins of CONF_DONE, nSTATUS (THAT WE ARE NOT USING), DEV_CLRn (pin 121) (routed to the MCU as an output from MCU and input to FPGA and USED). Also, we use the DEV_OE as an input from the power up device we use to feed the electronic components. Currently we are using DEV_OE as USER pin input but I'm not sure if I should use it as DEV_OE predetermined function.

I would very pleased if you could help me with this issue. Basically what I'm doing with this FPGA is obtaining PWM signals from a microcontroller (red ring from pins 38-58) and then I have designed some VHDL instances to process those signals (only if I input pin of ENABLE pwm from MCU is high) and make the PWM pulses to have a minimum pulse and dead time (IT's used for three-phase inverters to not short-circuit the bus). In order to detect a short-circuit from the semiconductors I obtain some feedback signals (green rings) from the drivers of the semiconductors that I compare with the PWM processed signals that I have triggered and I output(green rings) that I compare in a "error" designed instance and I give an error to the MCU though the pin 17. The output signals of processed PWM goes to TX of fiber optics and the feedback comes from RX of fiber optics. 

When I have tested the design I have seen that the "error" instance gives me an error of all the PWM signals when I write the DEV_CLRn signal from MCU to FPGA the output signals (in tri-state) have an small distrubance (I don't remmember the voltage but maybe like 200-300mV but they are in tri-state) that I guess that makes the error instance to recognise a rising/falling edge (what I used to detect errors) and because I'm not getting anything from feedback, I give an error. Then I clear it and this error doesn't appear anymore, only when the DEV_CLRn is given. 

What I would like to implement is the following:

  1. When the MCU and FPGA is before and during powering up, the outputs that goes to the TX fiber optics must have a value that does not trigget the IGBTs so I would need that the output be forced to 0 when the FPGA is not even getting the DEV_CLRn from the MCU and then, before I enable the PWM from the input pin.
  2. Help me with the policy I must follow to ensure the different CLR_N of the project. Now, when the PCB is powered up, the power up pin 122 goes to the FPGA but it's used as user refined (I have put it in the design as condition to trigger the pulses but I'm not sure about this position). Then, when the DEV_CLRn is written to High is when the program from .pof is loaded to the registers and starts working the FPGA but I obtain that initial error in all the pulses. Then I have a user-defined pin that enters the design and clears the different instances

I would apprecite if you could give me a feedback about the policy I'am following and the source of the error I obtain at the DEV_CLRn. I will continue to make some changes during this end of week and next one so I will be informing you.

 

Have a nice day,

Pedro

 

 

0 Kudos
AqidAyman_Intel
Employee
98 Views

I hope the previous response was sufficient to help you proceed. As we do not receive any response from you on the previous question/reply/answer that we have provided. Please login to ‘https://supporttickets.intel.com/s/?language=en_US’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.


0 Kudos
Reply