Most of the designs we've been working with up until now have been synchronous which means
they operate on the same clock signal. However, you might run across cases where you
need to sample an asynchronous signal or work with something that's operating on a completely
different clock signal.
This might cause a problem known as meta stability in this episode we'll take a look at
what that is and what you can do to avoid it.
Let's take a look at our basic D flip flop. We'll assume that this flip flop
registers data on the rising edge of a clock pulse.
So let's look closely at that edge. As it turns out,
the input signal needs to be held at its intended value sometime before the sampling
clock edge. The amount of time that the input D.
Needs to be held steady before the clocking event is known as the setup time.
The signal must also be held at that level for some time after the clock edge for the output
to be stable. This is known as the whole time.
So long as the input does not change within the setup and hold Windows,
the output queue will update to reflect the registered value and is guaranteed to be steady.
However, if d changes within the setup or hold Windows, that is a timing violation,
this could potentially cause the D flip flop to not latch the input signal properly and enter
into a meta stable state here. The output of the flip flop is unknown for some
indeterminate amount of time. Usually the output will quickly reach a stable
state but this meta stable output could produce incorrect signals and values for your design
depending on how long it takes for the voltage to settle.
Note that a glitch or short pulse within the set up or hold time is also a violation which
can cause mental stability. Most setup and hold times are on the order of
nanoseconds. You can't guarantee that meta stability will
occur with the timing violation as it's probabilistic.
The best you can do is calculate the mean time between failures to get an idea of how likely
it will occur. We won't get into that calculation as that's a
more advanced topic.
Additionally, you likely won't be able to see this meta stability on an oscilloscope as this
only occurs on the flip flops inside the F P G. A most F p G A s have some logic and buffers
between flip flop outputs and physical pins.
That means a meta stable output would simply look like a level change on the pin.
However, if you were to monitor this pin and record the meta stable output over and over,
you would see that the level change occurs at different times due to the probabilistic nature
of the meta stability.
If we look at the data sheet, we can see the listed setup and hold times for our HX one K.
Device. However, note that like the propagation delays.
These are only given for signals coming from a physical pin.
Internal times aren't given. So we have to assume that the place and route
tool will ensure everything meets timing interestingly enough,
the setup time is negative. This means that your signal change can actually
arrive slightly after the clock edge and still be okay.
Colin O'Flynn has an excellent article where he demonstrates medicine ability by registering a
divided clock signal and then delaying the clock by some varying amount.
You can see his test set up here. He uses a 48 MHz clock signal to drive the flip
flops signal and clock line.
The signal line is divided to 24 MHz so the rising and falling edges can both be sampled.
He then carefully adjusts the clock phase until they set up or hold.
Time violation occurs. You can see his results here if there is no
violation. The data out signal looks clean.
However, when there's a meta stable event, the data outline will lag in its transition for
some random amount of time. I tried to replicate this experiment however,
you have to undervolt the F. P. G. A. To make the meta stable events more visible.
It turns out that I need to disorder a few parts to control the core voltage.
While I could definitely do that, I did not want to risk hurting my only I stick as I know
that obtaining them right now is quite difficult if you are working with asynchronous
signals or across clock domains. The standard fix is to add a second flip flop
to the sampling chain. While this won't completely remove meta
stability, it will lower the impact and chances of it occurring on the final output.
Even if the first flip flop experiences meta stability, the second flip flop will sample
that unknown state and have a better chance of producing a stable state.
Note that this does introduce a delay in your design as it now takes an extra clock cycle for
the input value to appear on the output. Sometimes you might even see three or more flip
flops chained together to really reduce the chances of meta stability.
Using a chain of flip flops like this to reduce meta stability is known as a synchronizer.
Here's a simple flip flop example where the input might be an asynchronous signal to create
a synchronizer, we will define a new register element, I'll call it pipe zero.
Then we use a non blocking assignment to register the input signal to the pipe register.
We add another line to register the contents of the pipe register to the output register.
And that's it In our designs. Up until now,
we've been mostly working in a single clock domain.
That means all of our logic and flip flops were clocked from a single source,
which was the 12 MHz oscillator on the ice stick.
For me, however, you might run into instances where something else is using a separate clock
that is not phase aligned to your system. Clock a clock domain is all of the logic that
is clocked from a single clock signal or a divided version of that clock.
Let's pretend that clock one is generated by some external sensor.
It could be a five megahertz spy signal and we can't guarantee that it's phase aligned with
our internal system clock which we'll call clock too.
We want to sample the input data to use it in calculations.
So we create a circuit like this. However as we just showed this boundary between
the two clock domains is dangerous as there's a chance meta stability could occur.
This situation is known as clock domain crossing and it can cause a lot of headaches.
Meta stability is random and may or may not cause bugs.
That can be very difficult to track down.
Generally the solution to this is to create a synchronizer circuit in the receiving clock
domain as I've shown here. This will reduce the likelihood of medicine
ability in most cases to keep your designs simple, especially if you're just starting out
you'll likely want to avoid crossing clock domains, keep your designs synchronous in one
clock domain as much as possible. In earlier episodes we made simple clock
dividers that looked something like this. Our 12 MHz clock fed into a simple circuit that
divided the clock and then we used that signal to drive the rest of our design at a slower
rate. This is fine when you're just starting out and
learning to work with F P G A S. However, it's considered bad design the logic
and flip flops can potentially introduce delays and now you've technically created a separate
clock domain. You want to avoid driving clock inputs with
outputs from other flip flops.
I want to thank Patrick Lehman for showing me a much better way to create a clock divider here,
is that better clock divider? We give a max clock count as a parameter,
much like we did before. However, note that instead of a divided clock
output, we now have this tick output. We use this built in log base two ceiling
function to figure out how many bits our counter needs to be the key here.
Is that rather than producing a divided clock, the tick signal goes high for one clock cycle
at the end of the count and then the counter starts over again the always block continuously
increments the counter and resets the counter whenever tick is high,
which happens when the counter reaches the modular parameter value.
Here is an example of this divider in simulation, the modular parameter set to 120.
So whenever count reaches 119, the tick line goes high for a single clock pulse and here's
how we use this new divider. This is the one hurts blinking led example,
we saw way back in the beginning of the series we inst and she ate the clock divider rather
than use the output to feed the sensitivity list.
We simply perform a conditional check for that tick line to be high prior to performing our
action. In this case we just toggle the led.
This method keeps everything perfectly synchronous with our main clock and we don't
have to worry about meta stability. I'll post a link to this example and a better
way to do button D bouncing in the description. Feel free to look through them and try them out
on your own. F P G A A Fife O or first in first out is
another great tool when working across clock domains.
You might also know it as a Q. It's a way to use a chunk of memory to pass
data between a sender and a receiver. Let's say we have a FIFA with two elements
already stored. The sender writes another piece of data to the
Fife. Oh which gets stored behind the other two the
receiving process can a synchronously read data from the Fife.
Oh this pulls the element at the front of the Fife O.
Off. And the others slide down.
There are a few rules to follow when creating or working with a Fife.
Oh these are the big ones to remember. Elements are red in the order that they are
written to the Fife. Oh any element that has been read is removed
from the Fife. Oh you'll need a way to check to see if the
fifpro is empty and full as you don't want to read from an empty Fife.
Oh and you don't want to write to a full Fife. Oh, if you do,
you could break the Fife o or unintentionally overwrite parts of memory.
Let's look at the diagram of the block memory in the data sheet.
Again, you'll notice that the block RAM for the ice 40 has two different clock inputs,
a read clock and a right clock. This allows us to read and write to and from
the block RAM in separate clock domains. As a result,
we can build some logic around this memory to create an asynchronous Fife.
Oh, such cues are very helpful as they allow you to pass data between clock domains.
You could, for example, take samples from a sensor and store the results in a Fife.
Oh, a separate microcontroller could then read the results from the Fife.
Oh, using its own clock domain. However, creating a Fife oh,
that's resistant to medicine ability issues can be a little tricky lucky for us,
digital design experts have created robust FIFA's for us to use.
Here's one example by Clifford cummings in his 2002 paper to the synopsis users group.
While he mentions that there's a second FIFA design that won an award.
I recommend sticking with this first design. I highly recommend reading through this paper
to see how Clifford created this design on page nine.
You'll see a block diagram of the Fife. Oh, you can see how logic is built around the
dual ported block RAM to construct the Fife Oh, notice that he uses to synchronizer circuits to
pass read and write addresses between the two clock domains scroll down some more and you can
see that source code has been graciously provided for us to use.
Your challenge is to implement this Fife Oh, in very log and then write a test bench to show
that it works. Here's an example of my simulation,
you can see that I write the values 012 and three to the Fife Oh,
when I read them I get 012 and three on each read clock cycle and notice that the two clock
frequencies are different.
The read empty line goes high whenever the Fifpro is empty and if I fill up the Fife oh,
the right full line goes high and the Fifpro ignores any values given after that.
When I read out the values, you can see that nothing after hex F is given.
Since the FIFA was full at this point, you should have most of the basic building blocks.
You need to start creating your own designs in an F P G.
A while this concludes the introductory portion of the series.
I'd like to spend the next two episodes talking about a fun topic and that is soft core
processors.
I'm going to show you how to use an existing Risk five implementation and get it running on
the Ice stick. Will then modify the design to include a custom
hardware peripheral Happy hacking.