Peter Alfke's SPDT Switch Debouncer

Peter Alfke wrote:

> 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

Peter Alfke <peter@xilinx.com> wrote:
> 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

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...

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

"Symon" <symon_brewer@hotmail.com> schrieb im Newsbeitrag 
news:4300f5c3$0$18648$14726298@news.sunsite.dk...
> 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.
>

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 Bonnes wrote:

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



> Peter Alfke <peter@xilinx.com> wrote:
> 
>>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
> 
> 
> 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...
> 

Antti Lukats <antti@openchip.org> wrote:
> "Symon" <symon_brewer@hotmail.com> schrieb im Newsbeitrag 
> news:4300f5c3$0$18648$14726298@news.sunsite.dk...
> > 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.
> >

> 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

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

Thanks
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

"Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> schrieb im 
Newsbeitrag news:ddt4t2$809$1@lnx107.hrz.tu-darmstadt.de...
> Antti Lukats <antti@openchip.org> wrote:
>> "Symon" <symon_brewer@hotmail.com> schrieb im Newsbeitrag
>> news:4300f5c3$0$18648$14726298@news.sunsite.dk...
>> > 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.
>> >
>
>> 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
>
> Can you show us your way to define 'always1'?
>
> Thanks
> -- 
> Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Hi Uwe,

there are many ways.

1 use fixed value IO pin as input
2 a 0 pin, 0 lut variant is to use alwaays1 <= not(SEL1 and SEL2) where SEL1 
are SEL2 are outputs from BSCAN primitive
3 just use inverse of the pattern compare result to some 'known' never true 
signal set, this is application dependant

Antti

PS I just tried to implement the SPDT switch as proper hard and also as 
'locked/constrained' soft macro, and failed in both cases because of Xilinx 
tools bugs. So the 'always1' approuch is possible the only useable at the 
moment, unless 8.1 update fixes the issues, I do not belive the issues could 
be fixed in 7.1 service packs.

Austin Lesea schrieb:

> 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.

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

> Austin Lesea schrieb:
> 
> 
>>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.
> 
> 
> 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
> 
>