FPGA interface to AT328p debouncing

[kpow8050]

Hey guys, my first time posting on EEVBlog. I am having problems interfacing an AT328p to an FPGA. The FPGA runs at 3.3 V logic levels, so I required a voltage level shifter between the MCU and the FPGA to drop the voltage from 5 V to 3.3 V. I'm using a push pull voltage follower (NPN and PNP) transistor (see attached diagram) to achieve this and it works well up to 1 MHz, with a rise and fall time of around 20 ns which is more than enough for my application. The problem arises when trying to send a square wave from the AT328 to the FPGA, in this case I have 1 pin connected to the clock input of a shift register on the FPGA and another pin for data. With a single pulse from the AT328 i get multiple shifts on the register in the FPGA. Its not behaving at all stable and seems to give random results (1 clock pulse from the AT328p translates to about 5+ clock pulses on the FPGA shift register). The waveform looks fine on the scope. I'm dumbfounded by this problem, as I've thought of everything and I can't seem to find the cause.

Previously before implementing the NPN/PNP level shifter I was using a resistor voltage divider to drop the voltage from the AT328, that was yielding better results in terms of less bounce (2+ clock pulses for every 1 clock pulse from the AT328). I initially though the bounce was due to a slow rise time (it was around 2 us) hence why I switched to using a transistor level shifter, however as evidenced the shorter rise time causes more clock bounces. Does anyone have insight, is this a normal problem with FPGAs? I can provide scope waveforms etc if required.

Thanks

[BrianHG]

I don't get it.  Why aren't you using a simple resistor divider?
You can try 74LV/LVC logic.  It has 5v tolerant inputs and can run at 3.3v

Also, you seem to be using the Altera simple logic gate equivalent instead of writing HDL code and using a synchronous clock.  With a clocked FPGA, it would be possible to software remove signal bounce on slow input signals.

Also, depending on the chosen FPGA, there are slew rate settings and IO standard settings for each IO pin which may help.  IE, switch the IO from LVTTL to LVCMOS may change the trigger threshold point.

[kpow8050]

Thanks for the suggestions. I originally was using a resistor divider, then decided to change it because I thought the rise time was too slow. The rise time was limited by the RC constant due to the gate capacitance of the FPGA. I guess I could have used smaller resistors but didn't want them burning up.

I will try changing the IO to LVCMOS and see if that helps. If not I will play with the IO settings and report back

Cheers

[BrianHG]

You also have a logic bomb with your 'IN_REG_STORE_SIG'.  It will only occasionally pulse or function randomly within each compile and may potentially pulse for no reason during an increment while you will never know how wide that pulse will end up being.

FPGAs really perform well with clocked synchronous designs and you only reserve piping signals through an FPGA in such an asynchronous/combinational logic method in really controlled circumstances and only when you know what you are doing.

[kpow8050]

SOLVED!

I tried using LVCMOS and no difference, so I tried using your suggestion for a synchronous design. To achieve this I used a D flip flop to gate the 'COMMS_CLK' using the FPGA clock source (25 MHz). The flip flop is reset once the 'COMMS_CLK' goes low. I tested the design in hardware and its working perfectly now.

Thanks for the help

[Scrts]

SOLVED!

I tried using LVCMOS and no difference, so I tried using your suggestion for a synchronous design. To achieve this I used a D flip flop to gate the 'COMMS_CLK' using the FPGA clock source (25 MHz). The flip flop is reset once the 'COMMS_CLK' goes low. I tested the design in hardware and its working perfectly now.

Thanks for the help

I recommend disconnecting the input from Flip-Flop CLRN. Use it for Reset instead.

I suggest you use the conventional 2FF synchronization: https://www.edn.com/synchronizer-techniques-for-multi-clock-domain-socs-fpgas/

Now once you bring in that signal into 25MHz clock domain, make an edge detector and use it as a clock enable for 25MHz clock while sampling input data. The input data should also be synchronized through 2FF sync.

[BrianHG]

SOLVED!

I tried using LVCMOS and no difference, so I tried using your suggestion for a synchronous design. To achieve this I used a D flip flop to gate the 'COMMS_CLK' using the FPGA clock source (25 MHz). The flip flop is reset once the 'COMMS_CLK' goes low. I tested the design in hardware and its working perfectly now.

Thanks for the help

That is still a flawed implementation and not synchronous as you are using the async clr on the flipflop and there are other quality and stability issues elsewhere.
But if it works for you and you are not changing your design, it can work.  But I would not sell this as a product which needs to work in the field over many FPGA devices.

[kpow8050]

SOLVED!

I tried using LVCMOS and no difference, so I tried using your suggestion for a synchronous design. To achieve this I used a D flip flop to gate the 'COMMS_CLK' using the FPGA clock source (25 MHz). The flip flop is reset once the 'COMMS_CLK' goes low. I tested the design in hardware and its working perfectly now.

Thanks for the help

I recommend disconnecting the input from Flip-Flop CLRN. Use it for Reset instead.

I suggest you use the conventional 2FF synchronization: https://www.edn.com/synchronizer-techniques-for-multi-clock-domain-socs-fpgas/

Now once you bring in that signal into 25MHz clock domain, make an edge detector and use it as a clock enable for 25MHz clock while sampling input data. The input data should also be synchronized through 2FF sync.

Thanks for the suggestion. I will try implementing a 2FF sync for the input signals. Although the current design works (albeit not the correct way, I will add a checksum to hopefully catch most of the errors that happen). I need to keep the 25 MHz clock free running, as I have another logic circuit using that clock for a PLL between a swept laser beam and polygon mirror to sync the scan lines. I'm still a noob when it comes to FPGAs, mostly used to doing everything with discrete logic chips (74 series) so I guess I'm kind of treating the FPGA like a logic breadboard.

[kpow8050]

SOLVED!

I tried using LVCMOS and no difference, so I tried using your suggestion for a synchronous design. To achieve this I used a D flip flop to gate the 'COMMS_CLK' using the FPGA clock source (25 MHz). The flip flop is reset once the 'COMMS_CLK' goes low. I tested the design in hardware and its working perfectly now.

Thanks for the help

That is still a flawed implementation and not synchronous as you are using the async clr on the flipflop and there are other quality and stability issues elsewhere.
But if it works for you and you are not changing your design, it can work.  But I would not sell this as a product which needs to work in the field over many FPGA devices.

Noted. Would using a 2FF sync as suggested by Scrts solve the stability issue? I guess I still have a lot to learn about FPGAs, in the future I may convert it over to HDL but I enjoy making the circuits with discrete logic components. Luckily its not for a commercial application just a hobby project, but would still like to learn the proper ways of doing things nonetheless 

[BrianHG]

I know that what 'Scrts' shows is a little advanced and you do not need to go that far.

I would say choose a HDL and begin to learn.  I personally like SystemVerilog or Verilog.  Just like VHDL, they are languages which are designed to describe your circuit using formulas / boolean math.

I would also say learn how to use the simulator included with Quartus, Modelsim.  It is an industry standard also available with Lattice FPGAs and Xilinx FPGA and can handle SystemVerilog and VHDL.  IE, learn to work there and then put your HDL code into Quartus where you would just need to define the final IOs, then you will have far less trouble adapting to other vendor's FPGAs as only the final steps will differ.

I have many Verilog beginner to advanced sample codes on this site.  More of the later ones include Modelsim test-benches, though, those are a little more complex.  NOTE: A testbench is a piece of HDL code which in your case would simulate what the ATMEAG IOs would be feeding your schematic/main HDL code including additional clock and other peripherals, and, Modelsim would follow those instructions and plot a logic analyzer scope of what your HDL fpga design is doing over time.  Modelsim basically contains a built in compiler like Quartus, but, it compiles and simulates your design within a second making code edits and debugging quick.  It is also possible to set Quartus to send your complete design to Modelsim after a compile, but, I consider working like this backwards unless you are specifically debugging an IO timing issue which a complete design.

Google for websites which give you example verilog/vhdl code to see what feels more to your liking.

[kpow8050]

I had a bad experience from coding in VHDL back in undergrad EE days. I found it relatively un-intuitive due to inherently parallel nature of things. Its not so simple as writing code in C or Java. I might give Verilog a try as you suggested, as I've also heard it is more intuitive compared to VHDL. Is there a reason why doing FPGAs in block/circuit style is not preferred?

[BrianHG]

My transition was from C to Verilog, then the more capable but backwards compatible SystemVerilog.

Look on google, but you might be able to start here: https://www.chipverify.com/systemverilog/systemverilog-tutorial

Note that the image schematic you created is only a few a number of lines longer that the first example they provide once you understand the data types and how the synchronous 'always @ (posedge clk) begin .... end' is doing.

Also look here: https://www.chipverify.com/verilog/verilog-introduction

[BrianHG]

And what the '<=' 'non-blocking' statement does inside the 'always @ (posedge clk) begin... ...end' and how it relates to a synchronous design.  (I realize I keep on forgetting to add the 'non-')

Here is an explanation I dished out during the development of an 8bit GPU here on EEVblog:
https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg2767312/#msg2767312

It includes 3 simple equivalent codes and visual illustrations in that post.
Though the rest of the 119 pages eventually leads to a GPU with accelerated geometry drawing unit with windows and multi-modes.

[Bassman59]

And what the '<=' blocking statement does inside the 'always @ (posedge clk) begin... ...end' and how it relates to a synchronous design.

The <= assignment guy is non-blocking.

You know that. Just trying to make sure the OP groks it.

[BrianHG]

And what the '<=' 'non-blocking' statement does inside the 'always @ (posedge clk) begin... ...end' and how it relates to a synchronous design.  (I realize I keep on forgetting to add the 'non-')

Here is an explanation I dished out during the development of an 8bit GPU here on EEVblog:
https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg2767312/#msg2767312

It includes 3 simple equivalent codes and visual illustrations in that post.
Though the rest of the 119 pages eventually leads to a GPU with accelerated geometry drawing unit with windows and multi-modes.

LOL, in that 1 post of mine, you have already been given enough knowledge to replicate and improve your existing design serial shift loader with just a few more lines of code.