Clock Switching in VHDL/ Actel igloo nano device

[cory...@gmail.com]

Hello fellow VHDL programmers,

I am working on a project that involves clock redundancy.

I have two 25 MHz clock inputs coming into an FPGA. These clocks are from two different oscillators.

I am looking to design a clock switching circuit that will by default run all the logic off the first 25 MHz clock, but if this clock somehow goes down(mechanical failure etc...) then the logic will then switch to using the other 25 MHz clock.

Basically I have the idea that Clk 1 monitors Clk 2 and Clk 2 monitors Clk1 but not entirely sure how I can get this working 100% glitch free.

Has anyone ever done this sort clock redundancy circuit in vhdl before?


Thanks
for any insight.

[GaborSzakacs]

This is a design issue, not necesarily a VHDL issue.
It sounds something like the Xilinx BUFGMUX, but the
tricky part is to design a system that is not glitchy
and yet is guaranteed to switch when one clock input
stops altogether. I seem to recall that the BUFGMUX
will get stuck in some circumstances if a clock stops.

-- Gabor

[Andy]

Actel Igloo parts do not have a bufgmux (xilinx).

The OP might be able use a variation on the flancter circuit to switch the clocks glitchlessly.

I must be sounding like a broken record by now, always suggesting uses for this cool little circuit.

Andy

[Cory Shol]

Yes there is a Bufgctrl in Xilinx devices but you are right about that it wont switch if one clock stops. You can implement the BUFGctrl in a different mode that would switch but it would not guarantee glitchless.

I have developed more logic design in Xilinx then in Actel/Microsemi FPGA's. I don't know if there is a bufgmux/bufgctrl in these Actel devices.

Yes you are right it is more of a design issue. I tried something like below but this will only work if the clocks have a fixed relationship and are off by at least 180 degree phase. Otherwise you have to sample at least twice the speed of the clocks to get the correct sampling. I was wondering if there is any synchronous/asynchronous combination i could use to get this done.

process(clk_main) --CLK Mezz DETECTOR
begin
if(rising_edge(clk_main)) then
clk_mezz_1 <= clk_mezz;
clk_mezz_2 <= clk_mezz_1;
clk_mezz_3 <= clk_mezz_2;
if((clk_mezz_3 ='1' and clk_mezz_2 ='0') or (clk_mezz_3 ='0' and clk_mezz_2 ='1')) then -- Rise or Falling edge
clk_mezz_enable <= '1';
else
clk_mezz_enable <= '0';
end if;
elsif(falling_edge(clk_main)) then

end if;
end process;

process(clk_mezz) --CLK Main DETECTOR
begin
if(rising_edge(clk_mezz)) then
clk_main_1 <= clk_main;
clk_main_2 <= clk_main_1;
clk_main_3 <= clk_main_2;
if((clk_main_3 ='1' and clk_main_2 ='0') or (clk_main_3 ='0' and clk_main_2 ='1')) then -- Rise or Falling edge
clk_main_enable <= '1';
else
clk_main_enable <= '0';
end if;
end if;
end process;

[Cory Shol]

Wow this might work, this looks interesting.

Thanks

Cory

[GaborSzakacs]

The point I was making is that xilinx has given a stab at this design,
and at least on their first pass didn't make it bullet-proof. I'm
not that familiar with the flancter circuit, but if it is similar to
the Xilinx design, it may also fail to switch away from a stopped
clock. The problem lies in using a circuit that needs an edge from
both clocks in order to completely switch. Switching from one
running clock to another is not too hard. Generally you have a flop
that waits for a rising edge of the current clock and goes high.
That gets ORed with the clock to keep it high until another flop
sees a rising edge of the second clock causing the selection to change
over without a glitch. The problem with this approach is that if
your first clock stopped low, you never get that first rising edge
and you need some fallback method to switch the clock, say a time-out
in cycles of the second clock that forces the switchover.

-- Gabor

[1999o...@gmail.com]

I'm curious as to where the requirements for this came from, I don't know much about reliability, but I would assume that an FPGA has lower MTBF figures than an oscillator?

[Cory Shol]

On Thursday, March 21, 2013 11:25:46 AM UTC-5, 1999o...@gmail.com wrote:
> I'm curious as to where the requirements for this came from, I don't know much about reliability, but I would assume that an FPGA has lower MTBF figures than an oscillator?

I work in the railway industry. We do a lot of redundant work on safety critical products. This typical application is adding a complete redundant mezz board to a system for extra reliability. This extra board provides another clock and another way of controlling the gigabit ethernet in the system.

[GaborSzakacs]

As with most redundant systems, you can get into more trouble because
twice the hardware has twice the chance of failure. Have you considered
that there could be more than one failure mode for the oscillator?
Obviously an oscillator could die, the resulting output frequency go
to zero or near zero, and you could say OK, the one running fastest
must be working right. But what if there is a crack in the crystal
that causes one oscillator to suddenly go to a much higher frequency?
Unless you have a third timebase, now you're more likely to use the
bad oscillator. Does your Igloo have an internal oscillator for
a "third opinion?"

-- Gabor

[Dave Higton]

In message <2d008b9c-8d66-46fe...@googlegroups.com>

Quartz crystals don't by any means have the best reliability. The
rest of the oscillator circuit will be excellent, normally.

Anyone who works with quartz crystals will have come across units
that "lost their activity".

Dave