Clock Edge notation

Mine used a barrel shift in the feedback to get a gain that increased with
the
size of the error. Had to do that to get a quick lock and still be able
to
chase the reference. The reference was derived from a quad encoder on the
mechanical media path. The PLL had to adjust a process to keep a certain
number
of events between encoder pulses. All in all, it was a pretty nasty
problem
because of the dynamics and limited resolution of the encoder.

Kevin Neilson wrote:

Mine used a barrel shift in the feedback to get a gain that increased with
the
size of the error. Had to do that to get a quick lock and still be able
to
chase the reference. The reference was derived from a quad encoder on the
mechanical media path. The PLL had to adjust a process to keep a certain
number
of events between encoder pulses. All in all, it was a pretty nasty
problem
because of the dynamics and limited resolution of the encoder.

Kevin Neilson wrote:

Mine used a barrel shift in the feedback to get a gain that increased with
the
size of the error. Had to do that to get a quick lock and still be able
to
chase the reference. The reference was derived from a quad encoder on the
mechanical media path. The PLL had to adjust a process to keep a certain
number
of events between encoder pulses. All in all, it was a pretty nasty
problem
because of the dynamics and limited resolution of the encoder.

Kevin Neilson wrote:

Mine used a barrel shift in the feedback to get a gain that increased with
the
size of the error. Had to do that to get a quick lock and still be able
to
chase the reference. The reference was derived from a quad encoder on the
mechanical media path. The PLL had to adjust a process to keep a certain
number
of events between encoder pulses. All in all, it was a pretty nasty
problem
because of the dynamics and limited resolution of the encoder.

Kevin Neilson wrote:

Mine used a barrel shift in the feedback to get a gain that increased with
the
size of the error. Had to do that to get a quick lock and still be able
to
chase the reference. The reference was derived from a quad encoder on the
mechanical media path. The PLL had to adjust a process to keep a certain
number
of events between encoder pulses. All in all, it was a pretty nasty
problem
because of the dynamics and limited resolution of the encoder.

Kevin Neilson wrote:

Hi all.

I was actually thinking about digital PLLs recently when I was doing
investigation on analog PLLs.

Can someone describe the basic parts and operation of a DPLL?
Essentially these are the components I figured would be needed and this
is how the operation might work, I'd appreciate comments....

It would appear, however, that I can get the Global Signals to work as
inputs. But when I do, then I loose an I/O. That doesn't seem right. Like
buying a three input OR gate and only being able to use two of the inputs at
any one time.

Brad

"Ray Andraka" <ray_at_andraka.com> wrote in message
news:3F134720.D19A8BCA_at_andraka.com...
Mine used a barrel shift in the feedback to get a gain that increased with
the
size of the error. Had to do that to get a quick lock and still be able
to
chase the reference. The reference was derived from a quad encoder on the
mechanical media path. The PLL had to adjust a process to keep a certain
number
of events between encoder pulses. All in all, it was a pretty nasty
problem
because of the dynamics and limited resolution of the encoder.

Kevin Neilson wrote:


I like that idea. Actually, I recalled that mine had a time-varying gain,
but it was much simpler. The gain was high before lock, and after locking,
the gain switched to something lower. The gain was just implemented by
left-shifting the output from the loop filter (which was just a comb or
moving-average filter), so the gain could only be powers of two. Does the
barrel shifter you describe increase the order of the loop? That probably
makes it a lot harder to describe mathematically. I would have liked to do
an analysis of mine, but of course I didn't have time, and for my
application stability was much more important than lock time so I didn't
really have to optimize it.
-Kevin

Hello, I have attached a portion of code for a binary to bcd counter, 20
bits parallel input, and a 24 bit BCD output parallel. Although internally
it converts it to serial to go through the conversion. I'm attempting the
shift and add three (if greater than or equal to 5) method, but I am
having
some problems. It works great on the simulator (Aldec Active HDL) and I
can
synthesize it but when I put it on the chip I'm getting some odd things. I
am using 16 input toggle switches and i debounced pb switch as a load
switch, and my outputs are LEDs. When I set this up on the board my
outputs
go as follows:

"Jason Berringer" <look_at_bottom_of_at_email.com> wrote in message
news:kJCVa.3413$Cx4.543634_at_news20.bellglobal.com...
Hello, I have attached a portion of code for a binary to bcd counter, 20
bits parallel input, and a 24 bit BCD output parallel. Although
internally
it converts it to serial to go through the conversion. I'm attempting
the
shift and add three (if greater than or equal to 5) method, but I am
having
some problems. It works great on the simulator (Aldec Active HDL) and I
can
synthesize it but when I put it on the chip I'm getting some odd things.
I
am using 16 input toggle switches and i debounced pb switch as a load
switch, and my outputs are LEDs. When I set this up on the board my
outputs
go as follows:

The attachment didn't come through. Can you just include some of the code
in the body, instead of an attachment?

Here is the code (after my text) instead of an attachment in case others
cannot read it.

It takes (or should take) 20 to 21 clock cycles to get the data from the
input to the output. I put a few numbers through the simulation the only
correct values are 0 and 1, all other tested were incorrect. I'm pretty
sure
it's a simple error that I'm not catching, I just can't see it at present.
Most of the stuff that I have done has been a bit more simple than this.
The
algorithm works from a sample I've seen (no code just an explanation).
Start
by shifting the most significant bit of your binary number into the least
significant bit of your "units" bcd value, when the number in the "units"
value is 5 or greater add 3 to it. Shift again, if the value is 5 or
greater
add 3 to it, the values will continue to spill over to the "tens",
"hundreds", "thousands", etc. You must add 3 to each of the bcd digits if
any is five or greater, by the last shift (same number of shifts as your
input binary value (in my case 20 bits)) you'll have the bcd
representation.
The example I mentioned above was for a microcontroller.

elsif rising_edge(clk) then

if shift_en_s = '1' then

bcd_value := bcd_value(22 downto 0) & ser_out_s;
bcd_out_s <= bcd_value;

if bcd_value(3 downto 0) >= "0101" then
bcd_value(3 downto 0) := bcd_value(3 downto 0) + "0011";
end if;

Does the following generate a gated clock?
if shift_en_s = '1' then

The following statement must be done before the rest. While simulators may
execute them in order, synthesized logic tends to execute them all at the
same time.


bcd_value := bcd_value(22 downto 0) & ser_out_s;
bcd_out_s <= bcd_value;

Does this generate a gated clock? Can you do it in traditional synchronous
logic form, where either the previous contents, or the contents with "0011"
added are loaded back in? (Also with the shift_en_s enable.)


if bcd_value(3 downto 0) >= "0101" then
bcd_value(3 downto 0) := bcd_value(3 downto 0) + "0011";
end if;

Gated clocks are especially hard in FPGA's.

Hi Jason,

First off, that's a pretty cool little algorithm... had to prove to myself
that it worked. ...

I'm not sure that I've found the problem with your code, ...

(0) I think the first problem is a lack of comments... uncommented code is
always wrong

(1) Process #3. I hate variables. Especially variables mixed with
signals...

you must be very disciplined when using variables (I only use
them in for loops...). So I honestly don't know what the code will
translate into, as you are assigning a value to variable, then assigning to
the variable to a signal, then changing the value of the variable.

Paul Leventis wrote:
Hi Jason,

First off, that's a pretty cool little algorithm... had to prove to myself
that it worked. ...

I'm not sure that I've found the problem with your code, ...

The best and quickest way to do both is to write a testbench an run a sim.
This quickly resolves all questions about how the langage works
and how the logic functions.

(0) I think the first problem is a lack of comments... uncommented code is
always wrong :-)

My favorite comments are a plain text description at the top of each
process about function and handshake protocols.
These can be collected at the top of the architecture after the
sim is working.

Detail comments at the end of line, can often be replaced by
by well-named statement labels, constants and variables.

(1) Process #3. I hate variables. Especially variables mixed with
signals...

Signals are the only way in and out of a process.

you must be very disciplined when using variables (I only use
them in for loops...). So I honestly don't know what the code will
translate into, as you are assigning a value to variable, then assigning to
the variable to a signal, then changing the value of the variable.

In the case referenced, the first value is exported to the signal at
the next clk and the second value is held by the variable until the next clk, if
it is needed.

This is not as complex as you think. Variables are stuck inside the process.
They only reach the entity ports if you make a signal assignment inside
the process. Synthesis will use a register to save the variable's *final* value.
only if this value is needed at the next clk.

Run a sim sometime, and watch the variables as you trace code.

-- Mike Treseler