FPGARelated.com
Forums

Glitch on Articx7

Started by joshuablanco 8 years ago3 replieslatest reply 8 years ago93 views

Hi, i need to watch a "glitch" in a simple combinational circuit, i'm simulating in ISE_14, but i don't achieve watch it, i know that i need to understand three concepts "translate, map and place and route " but i can't make it, could somebody help me? sorry by my english

[ - ]
Reply by martinthompsonOctober 7, 2016

What do you mean by "watch"? (And more to the point why do you *need* to do this?  Is it an educational exercise?


Anyway, if you mean 'see the waveform glitching as it would in a specific FPGA' then you should be able to achieve this by 

* Creating a suitable asynchronous design

* synthesise, translate, map, PAR

* Generate and run a post-place-and-route simulation (which should have all the delays included in it)


If you just want to simulate how an async circuit will appear in general, you can add some appropriate delays to a behavioural simulation.


For example, something like this should create an oscillator:


signal sig : std_ulogic := '0';


sig <= not sig after 1 ns;


[ - ]
Reply by asserOctober 7, 2016

A "glitch" is a product of a bad design. Therefore, it would not be afforded during "translate, map and place and route ". If a real glitch is buried in the project, then probably it would not be found in the resulting configuration running, may be thanks to the logic optimization.  But the intentional glitch can be put in the project. For example, if a complex logic control like the heavy decoder output is logically mixed with the clock signal to a counter. Then such a counter counts slightly differently than a good counter does.


[ - ]
Reply by martinthompsonOctober 7, 2016

I'm not sure a glitch is a product of bad design.  I would say that good design means that the (inevitable glitches) do not matter.

Glitches will happen in all designs - the real world is full of non-matched delays and each one of the signals going to a LUT will have a different delay, so the output of the LUT will inevitably glitch.  "translate, map, par" can do little about this.  Their job is to ensure  that the glitches do not cause the logic to function differently to what was described in the HDL.

Good design means:

* ensuring that these signals are not used as inputs to edge-triggered circuits (like the clock pin of a flipflop), 

* that signals are sampled at a guaranteed-stable point.  This can be assured by the correct use of timing constraints - the tools know the delays, and your requirement and can then ensure that the delays all add up to leave you with a little margin in hand (or tell you when they fail!)