Peter Alfke's SPDT Switch Debouncer

Jeez...

I do wonder about this high level language stuff sometimes - with schematic capture draw two 2 i/p nand gates. connect the output of each one to an input of the other. Connect the pole of the switch to earth. connect each of the other outputs to the free input of each nand gate. Also pull up that input to Vcc via a 10k resistor. Take the output from the appropriate nand gate. Sorted. In hardware terms it is a set-reset flipflop.

Slurp

Hello Slurp,

I am not looking for solution for this issue, since we get the problem solved in different way, but still solved. I am trying to learn synthesis tools and the ways how to work with tools in effective way. Since Peter Alfke published his article he managed to synthesize and implement this part of design and I am wondering about the way he did it.

With best regards, Vladimir S. Mirgorodsky

The schematic you saw in the article was almost definitely not the result of synthesis. It was drawn in a schematic tool and exported to edif to be input to the mapper directly. Your problem is most probably not inferring the right IO. I doubt if there are any LUTs generated by the schematic you're looking at. You should investigate the output of synthesis tool to see what components it generated and see if they look anything like the schematic. Synthesis tools are not very good at generating non-trivial IO functionality. You'll probably have to learn have to set some properties on your components.

That is really my concern. I checked the resulting EDIF and I found there input and output buffers, connected exctly the same fashion, like in schematic. The problem actually caused by the mapper throwing out the IBUF from the netlist and rendering InKey1 and InKey2 pins as unused.

I thought of this circuit, drew it with a pencil on a piece of paper, and analyzed it in my head. And I bredboarded it many years ago, without using any synthesis tool. I know it works, but I have not tried to sneak it past the security guards in the newer tools. Who claims that progress is always moving forward ? Peter Alfke

Hi Vladimir, The circuit's being optimised away because the 'tool' doesn't understand that there's stuff outside the chip. It can't understand the output is current limited, so it thinks your circuit can be optimised away. If you make the outputs tri-state-able, and drive the tri-state line to turn them on from something the 'tool' doesn't optimise away, you'll have more success. Maybe. Have fun! Syms.

Probably a silly question, but shouldn't a Xilinx published circuit be part of the test cases used by Xilinx, in all their new software releases ?

-jg

-snip-

Jim,

Not necessarily.

Better test cases are the hundreds of real projects from our customers that better represent the majority of the features being used.

Austin

Jim, what do you suggest: Whenever somebody in Xilinx suggests an application, all software is put onhold until the new idea has passed all software? Or: Whenever somebody in Xilinx suggests an application, it may not be published until it has passed all software implementations?

The specific idea in this thread is over 30 years old, and had been proven in many TTL designs, but had not been synthesized, because synthesis did not exist at its birth.

Nevertheless, I have gone back and made some circuit ideas more synthesis-friendly... Peter Alfke

Peter, If it was me, I would not take Austin's stance, that 'too simple' circuits somehow exclude themselves from the test suites..

Nor the approaches above [no smileys?], but I'd apply some "common sense", and try and ensure that ideas are both tested, and continue to be tested, as software iterates - rather a more pro-active, parallel approach, than the ON-OFF your and Austin's replies suggested. -jg

Jim, I really agree with you (sorry for the missing smileys). On one hand it is embarrassing when an old hand describes a proven circuit, and the younger crowd finds that it "doesn't work". On the other hand, I think that, especially with such a simple and peripheral circuit, it would be nice if engineers retained some basic understanding of physics and circuitry.

I have a running battle with people who think the X at the latch output (or flip-flop Q when the set-up time is violated) is an undefined, in-between mysterious level, instead of just an unknown (but physically real) state. Or with people who try to analyze metastability with logic simulation tools.

Designers should realize that real digital signals are High or Low (and rarely in-between), while 0 and 1 and X are just convenient abstractions that work most of the time, but not always. But I try my best not to become a cranky old fart. Hell, I am still proud of that cheap de-bouncing trick! Peter

With the thread " ISE 7.1 'improvements' plus meandering.... " Jim probably suggested to put more entries in a regression suite that is hopefully run before each ISE release/service pack...

"Symon" schrieb im Newsbeitrag news:4300f5c3$0$18648$ snipped-for-privacy@news.sunsite.dk...

not maybe. for sure. I use special wires called 'always1' those are driven to 1 always but in the way that XST doesnt guess that. Those wire are useful to keep stuff from being optimized aways.

another option would be create a hard macro, there things are more persistant

Antti

Uwe,

I understand. Most regression test suites are huge designs intended to cover as much ground as possible. Adding in a debounce ciruit as a separate test isn't productive. Now having one "goofy" suite with ALL of the strange and wonderful test cases that are three lines or less would be useful....

Something to work towards.

Austin

Can you show us your way to define 'always1'?

Thanks

Hi Uwe,

there are many ways.

Austin Lesea schrieb:

Especially as synthesis software tends to break with some parameter being unusually small.

- ISE over a couple of versions could not handle designs that had no inputs. (The error message suggested that the design were to large)

- The ISE schematic flow had a problem with vectors of length 1.

- Magma Design Automations VHDL parser could not handle empty records in one version.

- I saw a - non commercial - partition based placer fail on all single gate circuits because do-while was used instead of while-do

And so on.

These cases are not likely to show up in manual designs, but are actually very likely when working with circuit generators.

I am doing synthesis research at an university and I always test extremely small cases first because the test cases are easy to come up with and show problems with programming that can hide in larger examples.

Kolja Sulimma

Kolja,

Good points.

Austin