Sign in

username:

password:



Not a member?

Search Comp.Arch.FPGA



Search tips

fpga by Keywords

Altera | ASIC | CPLD | Cyclone | DCM | DDR | DSP | Ethernet | ISE | JTAG | Linux | LVDS | Microblaze | ML310 | Modelsim | NIOS | OPB | PCI | Quartus | RocketIO | SDRAM | Spartan | Spartan3 | SRAM | Stratix | Verilog | VHDL | Virtex | Virtex-4 | Virtex-II | Xilinx | XST

Ads

See Also

DSPEmbedded SystemsElectronics

Comp.Arch.FPGA | Essential hazards in CPLD's?

There are 4 messages in this thread.

You are currently looking at messages 0 to 4.

Essential hazards in CPLD's? - Preben Mikael Bohn - 2003-10-31 11:58:00

Hi NG, are essential hazards avoided in
CPLD-designs?

If for example I were to design a counter with a subsequent comparator 
in a CPLD, would I be sure that I got no glitches in the output from my 
comparator? Or would I have to filter the output before I used it in 
other part of the CPLD?

Best regards Preben




Re: Essential hazards in CPLD's? - Mike Treseler - 2003-10-31 12:45:00

Preben Mikael Bohn wrote:
> Hi NG, are essential hazards avoided in CPLD-designs?

They can be.

> If for example I were to design a counter with a subsequent comparator 
> in a CPLD, would I be sure that I got no glitches in the output from my 
> comparator? 

If you use synchronous design and do
static timing analysis, your outputs
won't glitch.

  -- Mike Treseler



Re: Essential hazards in CPLD's? - Peter Alfke - 2003-10-31 12:50:00

If you implement a binary counter and compare its
output against another
binary value, there is no way on this earth to avoid combinatorial
glitches, no matter what technology or circuit design you use.  The
classical solution to this problem is to Gray-code the counter, so that
only one bit changes at a time.
Of course, you can also re-synchronize the comparator output and thus
suppress all combinatorial glitches...

Peter Alfke
========================================
Preben Mikael Bohn wrote:
> 
> Hi NG, are essential hazards avoided in CPLD-designs?
> 
> If for example I were to design a counter with a subsequent comparator
> in a CPLD, would I be sure that I got no glitches in the output from my
> comparator? Or would I have to filter the output before I used it in
> other part of the CPLD?
> 
> Best regards Preben
______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.

Re: Essential hazards in CPLD's? - Preben Mikael Bohn - 2003-10-31 14:13:00

Peter Alfke wrote:
> If you implement a binary counter and compare its output against another
> binary value, there is no way on this earth to avoid combinatorial
> glitches, no matter what technology or circuit design you use.  

I thought so... :-/

 > The
> classical solution to this problem is to Gray-code the counter, so that
> only one bit changes at a time.

Ah... Of course... Only problem is that I guess this requires a higher 
macro-cell count and my current design is already at the limit (and 
there are many counters in it :-)).

> Of course, you can also re-synchronize the comparator output and thus
> suppress all combinatorial glitches...

I guess this is the best/"cheapest" way to do it. Thank you for the info.

Best regards Preben

______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.