Peter Alfke's SPDT Switch Debouncer

Hello Peter,

I have a small code snippet:

U_IBUF_Key1: IBUF port map(I => InKey1, O => Key1);
U_OBUF_Key1: OBUF_S_2 port map(I => Key1, O => InKey1);
Key1Out <= Key1;

U_IBUF_Key2: IBUF port map(I => InKey2, O => Key2);
U_OBUF_Key2: OBUF_S_2 port map(I => Key2, O => InKey2);
Key2Out <= Key2;

I think, it describes the schematic proposed by you in your article
"Six Easy Pieces (Non-Synchronous Circuit Tricks)" from 04/02/2003. I
have a copy of ISE 7.1.03 and I have a copy of Synpicity Synplify 8.1.
I tried to synthesize and implement the proposed code snippet. Both
synthesis tools generate warning about combinatorial loops existence,
but still generate output files. In time it comes to implementation the
ISE during map phase prints the following error message and fails the
implementation:

MapLib:661 - LUT2 symbol "N_14_i" (output signal=N_14_i) has input
signal "U_IBUF_Key2" which will be trimmed. See the trim report for
details about why the input signal will become undriven.

Trim report states the following:

The signal "InKey1" is unused and has been removed.
The signal "InKey2" is unused and has been removed.
The signal "U_IBUF_Key2" is unused and has been removed.
The signal "U_IBUF_Key1" is unused and has been removed.

We invented the following hack, effectively adding register between
IBUF and OBUF.
U_IBUF_Key1: IBUF port map(I => InKey1, O => Key1);
process (Clk) begin
	if rising_edge(Clk) then
		Key1Reg <= Key1;
	end if;
end process;
U_OBUF_Key1: OBUF_S_2 port map(I => Key1Reg, O => InKey1);
Key1Out <= Key1;

U_IBUF_Key2: IBUF port map(I => InKey2, O => Key2);
process (Clk) begin
	if rising_edge(Clk) then
		Key2Reg <= Key2;
	end if;
end process;
U_OBUF_Key2: OBUF_S_2 port map(I => Key2Reg, O => InKey2);
Key2Out <= Key2;

Now the project can be synthesized and implemented, but the circuit is
not asynchronous any more.

What is the trick in the starting idea? Are we missing some secret word
in VHDL source or some mysterious command line switch during synthesis
and implementation? Is there any way to avoid message about
combinatorial loops, since it kind irritating?

With best regards,
Vladimir S. Mirgorodsky

<v_mirgorodsky@yahoo.com> wrote in message 
news:1123934096.377073.5060@z14g2000cwz.googlegroups.com...
> Hello Peter,
>
> I have a small code snippet:
>
> U_IBUF_Key1: IBUF port map(I => InKey1, O => Key1);
> U_OBUF_Key1: OBUF_S_2 port map(I => Key1, O => InKey1);
> Key1Out <= Key1;
>
> U_IBUF_Key2: IBUF port map(I => InKey2, O => Key2);
> U_OBUF_Key2: OBUF_S_2 port map(I => Key2, O => InKey2);
> Key2Out <= Key2;
>
> I think, it describes the schematic proposed by you in your article
> "Six Easy Pieces (Non-Synchronous Circuit Tricks)" from 04/02/2003. I
> have a copy of ISE 7.1.03 and I have a copy of Synpicity Synplify 8.1.
> I tried to synthesize and implement the proposed code snippet. Both
> synthesis tools generate warning about combinatorial loops existence,
> but still generate output files. In time it comes to implementation the
> ISE during map phase prints the following error message and fails the
> implementation:
>
> MapLib:661 - LUT2 symbol "N_14_i" (output signal=N_14_i) has input
> signal "U_IBUF_Key2" which will be trimmed. See the trim report for
> details about why the input signal will become undriven.
>
> Trim report states the following:
>
> The signal "InKey1" is unused and has been removed.
> The signal "InKey2" is unused and has been removed.
> The signal "U_IBUF_Key2" is unused and has been removed.
> The signal "U_IBUF_Key1" is unused and has been removed.
>
> We invented the following hack, effectively adding register between
> IBUF and OBUF.
> U_IBUF_Key1: IBUF port map(I => InKey1, O => Key1);
> process (Clk) begin
> if rising_edge(Clk) then
> Key1Reg <= Key1;
> end if;
> end process;
> U_OBUF_Key1: OBUF_S_2 port map(I => Key1Reg, O => InKey1);
> Key1Out <= Key1;
>
> U_IBUF_Key2: IBUF port map(I => InKey2, O => Key2);
> process (Clk) begin
> if rising_edge(Clk) then
> Key2Reg <= Key2;
> end if;
> end process;
> U_OBUF_Key2: OBUF_S_2 port map(I => Key2Reg, O => InKey2);
> Key2Out <= Key2;
>
> Now the project can be synthesized and implemented, but the circuit is
> not asynchronous any more.
>
> What is the trick in the starting idea? Are we missing some secret word
> in VHDL source or some mysterious command line switch during synthesis
> and implementation? Is there any way to avoid message about
> combinatorial loops, since it kind irritating?
>
> With best regards,
> Vladimir S. Mirgorodsky
>

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

On 13 Aug 2005 06:40:21 -0700, v_mirgorodsky@yahoo.com wrote:

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

Peter Alfke wrote:
> 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
<paste>
> austin wrote:
>> Of course we test the new software.  In fact, we are adding test cases,
>> and whole new test requirements with every service pack that goes out.
>> 
>> Austin

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

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