Re: MAX V CPLD Reset and OE

Altera_Forum · ‎10-30-2017

Hi Guys,

I have a problem with the RESET and OE.

I noted the MAX V CPLD has assigned pin 44 as DEV_CLR and pin 43 as DEV_OE. I have set pin 44 as my global reset in my design.

However, after checking the output by logic analyzer, it looks like the reset was not working at all, and I have also checked the schematic by the using Netlist Viewer, the reset is connected to DATAD or DATAB on every DFF.

I'm wondering if I miss some setting for the reset? Could you please help me figure it out?

Thanks!

Altera_Forum · ‎10-31-2017

I would suggest not using the DEV_CLRn and DEV_OE Pins as these are used during configuration. Try changing the Reset and OE pins to other GPIO and then check. When not using the DEV_CLRn it should be tied high.

Altera_Forum · ‎10-31-2017

DEV_CLRn and DEV_OE are dedicated configuration pins. You may refer to Max V Pin Connection Guidelines for the information of these 2 pins:

https://www.altera.com/en_us/pdfs/literature/dp/max-v/pcg-01012.pdf

Altera_Forum · ‎10-31-2017

--- Quote Start ---

I would suggest not using the DEV_CLRn and DEV_OE Pins as these are used during configuration. Try changing the Reset and OE pins to other GPIO and then check. When not using the DEV_CLRn it should be tied high.

--- Quote End ---

Hi eapenabrm,

I try to use another I/O as a reset.

However, I still face the same problem. I try to change the reset to both high and low, however, the output keeps as same.

do you have any idea about the problem?

Thanks!

Altera_Forum · ‎11-01-2017

--- Quote Start ---

Hi eapenabrm,

I try to use another I/O as a reset.

However, I still face the same problem. I try to change the reset to both high and low, however, the output keeps as same.

do you have any idea about the problem?

Thanks!

--- Quote End ---

Could you post your VHDL/Verilog code. I think the issue may lie how you have assigned and used the reset in the code. If setting a normal GPIO as reset still doesn't work, then the problem may most likely be with the code. You did mention that the Reset is connected to Data pin on the Flops. That is incorrect. For reset to work, it should ideally be connected to the Reset/Rst pin on the DFF and not on the Data pins. Please post your code, will need to take a look at what you're trying to do here.

-Abr

Altera_Forum · ‎11-01-2017

--- Quote Start ---

Could you post your VHDL/Verilog code. I think the issue may lie how you have assigned and used the reset in the code. If setting a normal GPIO as reset still doesn't work, then the problem may most likely be with the code. You did mention that the Reset is connected to Data pin on the Flops. That is incorrect. For reset to work, it should ideally be connected to the Reset/Rst pin on the DFF and not on the Data pins. Please post your code, will need to take a look at what you're trying to do here.

-Abr

--- Quote End ---

Hi Abr,

Thanks so much for your help!

Could you help see attached my code and also a clip of the schematic after synthesis?

Thanks!

-Ke

Altera_Forum · ‎11-02-2017

--- Quote Start ---

Could you post your VHDL/Verilog code. I think the issue may lie how you have assigned and used the reset in the code. If setting a normal GPIO as reset still doesn't work, then the problem may most likely be with the code. You did mention that the Reset is connected to Data pin on the Flops. That is incorrect. For reset to work, it should ideally be connected to the Reset/Rst pin on the DFF and not on the Data pins. Please post your code, will need to take a look at what you're trying to do here.

-Abr

--- Quote End ---

HI Abr，

Thanks so much for your help, I think I may found the problem, it is because my setting of Quartus is wrong!

Thanks!!!!!!!

Altera_Forum · ‎11-05-2017

Hi ,

Just looked at your code and now i know why the reset is connected to the Data port . Well, there are a couple of issues with the RTL. I don't think its got to do with any Quartus tool settings as the default setting works for most designs.

1. Reset

You've used synchronous reset, ie, Reset is also clocked. This type of reset is tricky to implement and tends to give reset issues. If you're using a system-wide POR (Power-On Reset) you will have to use Asynchronous reset, so that the reset will clear all registers to a known state before the arrival of the clock. In your code, the reset is dependent on the clock pulse, so a POR will not occur. The logic will have to wait till the clock stabilizes from the PLL and then only you can apply the reset. This will lead to reset synchronizing issues between blocks.

** Reset signals are always false-paths in the timing analysis. If you use synchronous reset, then it will also be added into the clock path and will cause timing failures.

Please change your always blocks from


always@(negedge / posedge clock)
if (!reset)

to


always@(negedge clock or negedge reset)
always@(posedge clock or negedge reset)  - IF you want to implement Active Low reset
  if (!reset)
  else
  if()
  end // else
  end //if (reset)  
end //always

2. You are clocking data/signals on both edges of the clock in your block. This will give rise to sync issues. Its always better to have your logic in a single block clock either on posedge or negedge alone and not both. There are cases where you will use both edges, aka , in DDR type designs. For all other purposes, use only one clock edge.

Please make these changes and run the synthesis again. This should solve the reset and clock issues.

-Abr