Clock Edge notation

thutt wrote:

NET clk_pin TNM_NET = clk_ref_grp;
TIMESPEC TS01 = PERIOD : clk_ref_grp : 20.00 : PRIORITY 1; # 50.00
MHz

I'm quite curious about your timing constraint information. I spent
time on the weekend trying to find out how to do that, but the Xilinx
docs, IMHO, are just as bad as their software -- and I couldn't find
anything useful.

Where did you find this information about 'NET clk_pin'? To what do
you add it? In the VHDL? In the user constraints? I try to avoid
All the statements are in the .ucf file.
The "clk_pin" is just the name of the signal attached to the 50MHz clock
oscillator, specified in a pin constraint in usual way:
NET "clk_pin" LOC = "C9" | IOSTANDARD = LVCMOS33 ;
The constraint just tells that this is a 50MHz clock. I don't know exactly
how it works (and I'll certainly read the two links provided by Jochen), I
just copied the first one from a fpgaarcade source code (asteroids, if I
remember).

I made the second (75MHz) by myself, recalculating timings with the ratio of
50 to 75 (the difference in frequency). clk_pll is the name of an internal
signal clock, not a physical pin. I'm not really sure that using "TS01"
twice is a good practice, I have to learn about it.

using ISE as much as possible, so please tell me what document you
found this information in, and then I think I can extrapolate to how
to control the command line programs (which I drive from a Makefile).
I found it in the source code of an fpgaarcade game. You will find similar
things in many xilinx projects (for example the default picoblaze project,
flashed into the board as a factory default and downloadable from the xilinx
site): this is what's inside it's .ucf file:

NET "clk" LOC = "C9" | IOSTANDARD = LVTTL;
# Period constraint for 50MHz operation
NET "clk" PERIOD = 20.0ns HIGH 50%;

75MHz? On a Spartan 3E board? What pin is that? Do you have the
UCF name?
The spartan fpga has some "DCM" units (digital clock managers) which will
generate almost any frequency you need, starting from a given clock source
(50MHz in our case). A dcm will multiply then divide the frequency in a very
flexible way.

You can create an instance for a dcm by running the "Core Generator" under
the ISE/Accessories program group or, inside ISE, by adding a source file to
the project then selecting "IP Coremanager" instead of, for example, a new
..vhd file).

You then select "fpga features and design" then "clocking" then the fpga
family then "single DCM_SP, then "customize".

The clock manager can simply shift the input clock by 90, 180, 270 degrees
or generate a different frequency. For the latter, you should check the box
"CLKFX" (it is a pin on the drawn component on the screen). You input the
osc clock (50MHz) and the desired output frequency, then the gui will
calculate the parameters and tell if it could be done or not.

For example, the zx-badaloc project runs at 85MHz generated by a dcm with
*17 multiply then /10 divide (50*17/10 = 85).

You can easily obtain a 300MHz clock by multiplying by 6 the 50MHz input
clock.

Then, the gui generates a "component" and a wrapper to be placed in the
project. I remember I've had problems launching from inside ISE so I prefer
starting the core manager from the start menu, as described above. The
wrapper for my 85MHz clock was:

COMPONENT pll
PORT(
CLKIN_IN : IN std_logic;
CLKFX_OUT : OUT std_logic;
CLKIN_IBUFG_OUT : OUT std_logic;
CLK0_OUT : OUT std_logic;
LOCKED_OUT : OUT std_logic
);
END COMPONENT;

then the "connections" to my signals:

-- PLL
mainpll: pll PORT MAP(
CLKIN_IN => clk_pin, -- oscillatore clock 50MHz
CLKFX_OUT => clk_pll -- clock sintetizzato 85MHz
);

Ciao!
Alessandro
 
"Alan Fitch" <alan.fitch@spamtrap.com> wrote in message
news:NsCdneUOYfz0SFXVnZ2dneKdnZydnZ2d@posted.plusnet...
Ken Cecka wrote:
Hi All,

I'm trying to set up a testbench, and for various reasons, I'd like to
have
a package which contains some global signals and some procedures which
can
be used to control those signals. When I try to do this, it is crashing
fuse (the xilinx simulation compiler). This may simply be a bug in
their
compiler, but I thought I'd ask here first to see if the code I'm using
is
correct. I've boiled it down to the minimal test case copied below. If
the "sig <= '1'" line is commented out, it compiles, but with that line
included, fuse crashes.

Ken

LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;

PACKAGE pkg IS
SIGNAL sig : STD_LOGIC;
PROCEDURE proc;
END pkg;

PACKAGE BODY pkg IS
PROCEDURE proc IS
BEGIN
sig <= '1';
END proc;
END package BODY pkg;

ENTITY ent IS
END ent;

USE WORK.pkg.ALL;

ARCHITECTURE model OF ent IS
BEGIN
PROCESS
BEGIN
proc;
END PROCESS;
END;


Obviously a crash is bad :-( but your code is incorrect. Any signals
which are read or assigned in a procedure in a package must be on the
parameter list. So you need

LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;

PACKAGE pkg IS
SIGNAL sig : STD_LOGIC;
PROCEDURE proc (signal s : out std_logic);
END pkg;

PACKAGE BODY pkg IS
PROCEDURE proc(signal s : out std_logic) IS
BEGIN
s <= '1';
END proc;
END package BODY pkg;

ENTITY ent IS
END ent;

USE WORK.pkg.ALL;

ARCHITECTURE model OF ent IS
BEGIN
PROCESS
BEGIN
proc(s => sig);
END PROCESS;
END;


regards
Alan

--
Alan Fitch
Doulos
http://www.doulos.com
One solution is to have the procedure declared inside the architecture: this
way you can access all the signals without having to pass them. The downside
is that your architecture code won't be as neat as you'd like.

Regards,
Alvin.
 
"Tarique" <invalid@gmail.com> wrote in message news:gajlu3$ulk$1@aioe.org...
Can anyone please help me fix the error ? I am trying to compile the code
with Modelsim PE Student Edition 6.4
and i am getting an error :
# Compile of test.vhd failed with 1 errors.

vcom -work work -2002 -explicit F:/new/test.vhd
Model Technology ModelSim PE Student Edition vcom 6.4 Compiler 2008.05 Jun
30 2008
-- Loading package standard
** Error: F:/new/test.vhd(2): near "EOF": syntax error

This is the code :-


entity Counter_1 is end;
library STD;
use STD.TEXTIO.all;

architecture Behave_1 of Counter_1 is
-- declare a signal for the clock ,type BIT , initial Value '0'
signal Clock : BIT := '0' ;
-- declare a signal for the count Type INTEGER , initial value 0
signal Count : INTEGER := 0 ;
begin
process
begin -- process to generate a clock
wait for 10 ns; -- a delay of 10 ns is half the clock cycle
Clock <= not Clock;
if ( now > 340 ns ) then wait; end if; -- stop after 340 ns
end process;
-- process to do the counting ,runs concurrently with the other processes

process
begin
-- wait until the clock goes from 1 to 0
wait until ( Clock = '0');
-- now handle the counting
if ( Count = 7 ) then Count <= 0;
else Count <= Count + 1;
end if ;
end process;

process (Count) variable L: LINE ;
begin -- process to print
write (L, now); write (L , STRING'("Counter = "));
write (L, Count); writeline(output , L);
end process;
end;


Regards
Tarique
Add the following statement at the end
end Behave_1;

The structure of an architecture is of the form...
architecture Arbitray_Name_Of_Architecture of Entity_Name is
-- signal names here
begin
end Arbitray_Name_Of_Architecture;

KJ
 
"M. Norton" <remillard@gmail.com> wrote in message
news:c4089f8a-f734-4926-bba2-75439557dd0b@z72g2000hsb.googlegroups.com...
Hello,

In the past, the companies where I worked had less stringent needs for
verification. Quite often being able to use the product on the bench
was sufficient, or slightly more formal simulation results with test
vectors and viewing testbench results in the wave editor manually were
sufficient.

However, my current employer deals with a number of certification
authorities (e.g. the FAA) that impose a rigid audit of processes and
procedures for complex electronic hardware. These strictures have
been tightening over the past several years as they discovered just
how complex these devices can get! It seems to me now that this
company could stand to work with more formalized verification
engineers working hand in hand with the DUT development engineers,
rather than leaving the verification til the end to be banged out
quickly.

So, I'm trying to find a place to get started with this topic. I've
read a white paper by Ben Cohen on transactional verification
performed in HDL which seems interesting. I like the idea of being
able to stay within VHDL for the verification without having to add on
a lot of 3rd party tools. I know there are some languages out there
like SystemVerilog but do not know much about them. I'm not really
sure how all of these fit into a broad depiction of verification, and
how that might apply to our specific devices.

Does anyone have some pointers on where to get started with
structured, formalized verification, without any marketing hype from
tool and language vendors? I need to find a way to get a grounding so
I can make my own assessments of the value of the tools and languages.

Thanks for any help folks can provide.

Best regards,
Mark Norton
I would suggest you start by reading the free Verification Cookbook from
Mentor (http://www.mentor.com/products/fv/_3b715c/). This cookbook describes
a comprehensive structured test environment. Although they use
SystemVerilog(OVM/AVM)/SystemC(AVM only) you can do a lot of these
techniques in VHDL albeit with a "bit more" programming effort.

Other suggestion is to look at training companies like Doulos and Synthwork,
they have special VHDL verification courses were they discuss techniques
like constrained random(CR), transaction level modelling(TLM), some
functional verification, bus functional models etc.

I would also suggest you look into assertions. Unfortunately getting a PSL
license for most VHDL simulators is not going to be cheap (to put it
mildly), however, the verification benefits you get from assertions is
huge. The next step would be to use a proper formal tool ($$$) like
Solidify/0-in and many others and forget about creating stimuli altogether
:). If you can't afford a PSL license then look into the free OVL
assertion/monitors library.

You can also have a look at SystemC which luckily is not so expensive (at
least not in the case of Modelsim PE). SystemC allows you to easily add
C/C++ models to your environment, gives you access to TLM2, Object
Orientation, transaction recording and Constrained Random. Mixing VHDL and
SystemC is (at least in Modelsim) very simple.

Good luck,

Hans
www.ht-lab.com
 
"m" <martin.usenet@gmail.com> wrote in message
news:605b3515-30e0-429e-9026-661af118f029@k36g2000pri.googlegroups.com...
Researching the use of "ext".

I found this in the list archives:

-- zero extend STD_LOGIC_VECTOR (ARG) to SIZE,
-- SIZE < 0 is same as SIZE = 0
-- returns STD_LOGIC_VECTOR(SIZE-1 downto 0)
function EXT(ARG: STD_LOGIC_VECTOR; SIZE: INTEGER) return
STD_LOGIC_VECTOR;
The 'ext' function is a part of the std_logic_arith package. This package
was created by Synopsys and is not a standard. The package you should be
using is numeric_std which is an IEEE standard. The function you would use
there is called 'resize'.

Not clear on which direction the extension happens. Does it add zeros
on the left or right of ARG?
Plus you could have yet other questions if you apply some mental numeric
interpretation to the number (i.e. x"FF" being '255'...or should it be '-1'?
What happens with the sign bit?

If you use numeric_std's 'resize' function instead you will have to
explicitly tell it whether it should be treated as an unsigned number or a
signed number. If it is signed, and the number is negative then the sign
bit will get padded on to the left, if the number is positive, or if you
said to treat the vector as an unsigned number then 0 will be padded on to
the left. At first the extra typing will seem annoying, but it actually is
worth the little bit of extra effort.

BTW, picked-up a copy of "The designer's guide to VHDL" as
recommended. It sort of covers "others" (my prior question) in the
more general sense, however it doesn't seem to let you know that you
can use it by itself (i.e.: other => '0') .
Not by itself because 'others' refers to anything that has not been already
explicitly handled. But it can't no that unless it knows how big the target
of the assignment is. I'm not sure if that's what you meant by 'use it by
itself' or not, just guessing.

"ext" is not covered anywhere. At least I can't find it in the
index. There's a reference to "Zero extension" but nothing in those
pages about "ext".
Maybe it doesn't cover std_logic_arith...which is just as well, numeric_std
is the preferred way, std_logic_arith has some issues if you use it.

KJ
 
"Alan Fitch" <alan.fitch@spamtrap.com> wrote in message
news:-dSdnel0yufQdX3VRVnygQA@posted.plusnet...
Tricky wrote:
On 29 Sep, 11:06, Alan Fitch <alan.fi...@spamtrap.com> wrote:
Tricky wrote:

As a point to note, Modelsim doesnt always delete transactions.
Consider the following:
process
begin
a <= false, true after 1000 ns;
wait for 500 ns;
a <= false;
wait;
end process;
The 2nd assignment to "a" should remove the first timed assignment,
but in modelsim it doesnt, so the simulation runs for 1000ns but "a"
does not become true at 1000 ns. I have raised this with Mentor but
they say this is how they have chosen for their simulator to work.
Afaik, this wont happen in Active HDL.
I don't understand your comment. The second assignment *does* remove the
transaction at 1000 ns, that's why a does not become true. 500 ns is
earlier than 1000 ns. Modelsim is correct,

regards
Alan

--
Alan Fitch
Douloshttp://www.doulos.com

But why does the simulation continue, when it should halt at 500ns?

Hallo Tricky,
I had a look at the LRM (sections 8.4 and 12.6) and it looks like you're
correct, the simulation should stop at 500 ns.

I tried Modelsim and Cadence Incisive, and both simulate to 1000 ns. I
tried Aldec, and that simulates to 500 ns.

regards

Alan

--
Alan Fitch
Doulos
http://www.doulos.com
I've done something similar in the past with Modelsim, and when I do
"run -all" it stops, but if I do "run xxx ns" it runs for that amount of
time. ("It stops" is for cases like this, where there are no more scheduled
events.)

JTW
 
Hi Martin,

Finally got an answer for you on this. This is indeed a bug in the Quartus
extractors; your test case was helpful in tracking down this problem.
Apparently the extractor guys had been looking for a problem like this but
hadn't been able to isolate it until now. A Software Problem Report has
been filed and this should be addressed in a future version of Quartus or a
service pack.

Regards,

Paul Leventis
Altera Corp.

"Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message
news:6GGIa.34485$RM6.474195@news.chello.at...
Since Leonardo is not longer available from Altera I'm trying to use
Quartus
for synthesis. But I get a different output with Quartus. I tracked the
problem down and now my qustion is: Is it a bug or sloopy written VHDL?

The problem is setting output to tristate. See following VHDL code: I
asumed
that it is ok when the databus (d) is set to 'Z' in state 'idl' and this
will not change when changing state to 'rd1'. This was ok with Leonardo.
But
with Quartus I have to set d to 'Z' again in every state. What is the
correct VHDL code?

Martin

process(clk, reset, din, mem_wr_addr, mem_rd, mem_wr)
begin
if (reset='1') then
state <= idl;
a <= "ZZZZZZZZZZZZZZZZZZZ";
d <= "ZZZZZZZZ";
....
elsif rising_edge(clk) then
case state is
when idl =
a <= "ZZZZZZZZZZZZZZZZZZZ";
d <= "ZZZZZZZZ";

if (mem_rd='1') then
a <= din(16 downto 0) & "00";
nram_cs <= '0';
ram_access <= '1';
i := ram_cnt;
nrd <= '0';
state <= rd1;
elsif (mem_wr='1') then
...
when rd1 =
d <= "ZZZZZZZZ"; -- this line is necessary in Quartus but
NOT in Leonardo
i := i-1;
if (i=0) then
state <= rd2;
mem_din(7 downto 0) <= d;
a(1 downto 0) <= "01";
i := ram_cnt;
end if;

when rd2 =
d <= "ZZZZZZZZ"; -- same as in rd1
i := i-1;
if (i=0) then
...

--------------------------------------------------------
JOP - a Java Processor core for FPGAs now
on Cyclone: http://www.jopdesign.com/cyclone/
 
Hi,
Have a look at Ben Cohen's book. That's my choice. Please visit
http://www.vhdlcohen.com

HTH,
Ajeetha

http://www.noveldv.com


vhdl_uk@yahoo.co.uk (MACEI'S) wrote in message news:<fdfcada5.0307081038.6f1c5d22@posting.google.com>...
Can anyone tell me good books or web sites related to following.
1. MAKE file for VHDL ( XILINX)
2. Implementation of Coding using FPGA

Rgds

MACIE
 
Sorry , I changes my code to Input .......
So please read SR_DATA_IO_int (13 downto 0) as Input (13 downto 0)

Cheers

Isaac


Allan Herriman <allan_herriman.hates.spam@agilent.com> wrote in message news:<0ccqgvs49b23uhvhb8g5j2hbfeika71kui@4ax.com>...
On 9 Jul 2003 11:00:32 -0700, fpga_uk@yahoo.co.uk (Isaac) wrote:

Yes ALLAN I am Sure I am using different bits


E.g

This VHDL code I tried but in PAR file no pin assignment for signal 13 to 7

process(CLK_2X,SR_ADDR_IO_int,SR_DATA_IO_int,SR_IRD_int,SR_IWR_int,SR_IVCS_V3_int)
begin
if RISING_EDGE(CLK_2X) then
if SR_IVCS_V3_int = '0' then
if SR_IWR_int = '0' then
if SR_ADDR_IO_int = "001100" then
LED_V3_int <= SR_DATA_IO_int(13 downto 7);
end if;
end if;
end if;
end if;
end process P_SRAM2LED;


It's hard to say exactly what's going on, because you didn't include
the right bits of VHDL (i.e. the signal declarations).
Which signal is related to the "INPUT" signal in your first post?

The only signal is likely to be of type std_logic_vector is
SR_ADDR_IO_int, and that is only six bits long. Hmmm, the error
messages indicated that the six least signficant bits of INPUT were
used.
Do you have an assignment like:
SR_ADDR_IO_int <= INPUT(5 downto 0);
anywhere in your code?

You also might want to fix the sensitivity list.

Regards,
Allan.
 
Alan Fitch wrote:

I personally don't think it should be a warning, as it's quite legal
to declare null vectors
I agree.

A bad assignment to a null vector will cause other errors.
A null vector declaration alone is innocuous.

If one bit is 0 to 0 then
no bits must be 0 to -1

Let's see:
-------------------

entity null_string is
end null_string;

architecture sim of null_string
is
constant null_vec : std_logic_vector := "";
constant one_vec : std_logic_vector := "0";
constant two_vec : std_logic_vector := "00";

begin

what : process is
begin
report "null_vec is "& integer'image(null_vec'left)
& " to "& integer'image(null_vec'right);
report " one_vec is "& integer'image( one_vec'left)
& " to "& integer'image( one_vec'right);
report " two_vec is "& integer'image( two_vec'left)
& " to "& integer'image( two_vec'right);
wait;
end process what;

end sim;

--VSIM 1> run
--# ** Note: null_vec is 0 to -1
--# ** Note: one_vec is 0 to 0
--# ** Note: two_vec is 0 to 1

------------------------

I suppose that null vectors are rare as signals
but null vector constants and variables are necessary to make
clean vector functions.


--Mike Treseler
 
Hi, Mike,

Could please enlighten me on your usage

integer'image(null_vec'left)

What's it doing? Is image the function that Ben Cohen provides on his CD
with his books?

What is integer' doing? type casting?

Have I been asleep, or why don't I know about this from all of my reading.

Please advise, and thank you.

Clyde

Mike Treseler wrote:

Alan Fitch wrote:


I personally don't think it should be a warning, as it's quite legal
to declare null vectors

I agree.

A bad assignment to a null vector will cause other errors.
A null vector declaration alone is innocuous.

If one bit is 0 to 0 then
no bits must be 0 to -1

Let's see:
-------------------

entity null_string is
end null_string;

architecture sim of null_string
is
constant null_vec : std_logic_vector := "";
constant one_vec : std_logic_vector := "0";
constant two_vec : std_logic_vector := "00";

begin

what : process is
begin
report "null_vec is "& integer'image(null_vec'left)
& " to "& integer'image(null_vec'right);
report " one_vec is "& integer'image( one_vec'left)
& " to "& integer'image( one_vec'right);
report " two_vec is "& integer'image( two_vec'left)
& " to "& integer'image( two_vec'right);
wait;
end process what;

end sim;

--VSIM 1> run
--# ** Note: null_vec is 0 to -1
--# ** Note: one_vec is 0 to 0
--# ** Note: two_vec is 0 to 1

------------------------

I suppose that null vectors are rare as signals
but null vector constants and variables are necessary to make
clean vector functions.

--Mike Treseler
 
Thanks...

I guess there are features in VHDL 93 that I have not been aware of. I'll have
to read up and give them a try.

CRS

Mike Treseler wrote:

Clyde R. Shappee wrote:
Hi, Mike,

Could please enlighten me on your usage

integer'image(null_vec'left)

It an integer, the left index of the vector.

What's it doing? Is image the function that Ben Cohen provides on his CD
with his books?

No. Standard VHDL. Supported by all the sim and synth tools I have tried.

What is integer' doing? type casting?

No. It's a built in VHDL "attribute" , a kind of function.

Have I been asleep, or why don't I know about this from all of my reading.

A lot of the cool parts of VHDL-93 were neglected, because
they didn't work with every version of every tool.
They now work with most versions of most tools, so
feel free to use them.

-- Mike Treseler
 
adarsh arora escribió:
can u tell me from where i will get free downloadable softwares for
VHDL/verilog simulation and synthesis , SPICE ,IC Station...... with
free licences.
waiting for ur help
http://ghdl.free.fr
 
Yes, we have. One approach we had success with was one that used a DDS type
setup where the increment value got bumped up/down depending on the phase of the
accumulator vs the reference. Works quite well as long as the reference is
fairly stable. In our case we needed to track a mechanical system which had a
fairly high variance on the reference, so we wound up putting a lot of extra
crap on the design to improve the transient response without it going into
oscillation. Still lots smaller than doing a digital equivalent of an analog
PLL though.

Jason Berringer wrote:

Hello guru's

I was wondering if anyone has ever attempted a phase lock loop in digital
before (specifically VHDL). I'm looking for some examples or pointers on
trying to build one for a low frequency range of 200 Hz to 200 kHz. I would
appreciate any comments or suggestions. Google didn't get me very far, so if
you know of any app notes, etc. please let me know.

Thanks,

Jason
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
 
My all-digital PLL was similar and worked very well. My reference clock and
system clock were pretty stable so I didn't do a lot of analysis. I just
designed the loop with a small gain, so it took a bit to lock on (which
wasn't a problem in my application) but once it was locked it was very
stable and didn't oscillate. The only problem with the low gain is that it
took forever to lock in the simulation, so I made an adjustable loop gain so
I could kick it up for simulations and see it lock faster (although it rung
a bit before locking.)
-Kevin

"Ray Andraka" <ray@andraka.com> wrote in message
news:3F131077.9C3A8039@andraka.com...
Yes, we have. One approach we had success with was one that used a DDS
type
setup where the increment value got bumped up/down depending on the phase
of the
accumulator vs the reference. Works quite well as long as the reference
is
fairly stable. In our case we needed to track a mechanical system which
had a
fairly high variance on the reference, so we wound up putting a lot of
extra
crap on the design to improve the transient response without it going into
oscillation. Still lots smaller than doing a digital equivalent of an
analog
PLL though.

Jason Berringer wrote:

Hello guru's

I was wondering if anyone has ever attempted a phase lock loop in
digital
before (specifically VHDL). I'm looking for some examples or pointers on
trying to build one for a low frequency range of 200 Hz to 200 kHz. I
would
appreciate any comments or suggestions. Google didn't get me very far,
so if
you know of any app notes, etc. please let me know.

Thanks,

Jason

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
 
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:

My all-digital PLL was similar and worked very well. My reference clock and
system clock were pretty stable so I didn't do a lot of analysis. I just
designed the loop with a small gain, so it took a bit to lock on (which
wasn't a problem in my application) but once it was locked it was very
stable and didn't oscillate. The only problem with the low gain is that it
took forever to lock in the simulation, so I made an adjustable loop gain so
I could kick it up for simulations and see it lock faster (although it rung
a bit before locking.)
-Kevin

"Ray Andraka" <ray@andraka.com> wrote in message
news:3F131077.9C3A8039@andraka.com...
Yes, we have. One approach we had success with was one that used a DDS
type
setup where the increment value got bumped up/down depending on the phase
of the
accumulator vs the reference. Works quite well as long as the reference
is
fairly stable. In our case we needed to track a mechanical system which
had a
fairly high variance on the reference, so we wound up putting a lot of
extra
crap on the design to improve the transient response without it going into
oscillation. Still lots smaller than doing a digital equivalent of an
analog
PLL though.

Jason Berringer wrote:

Hello guru's

I was wondering if anyone has ever attempted a phase lock loop in
digital
before (specifically VHDL). I'm looking for some examples or pointers on
trying to build one for a low frequency range of 200 Hz to 200 kHz. I
would
appreciate any comments or suggestions. Google didn't get me very far,
so if
you know of any app notes, etc. please let me know.

Thanks,

Jason

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
 
Hi,
Please check VHDL FAQ. Xilinix Webpack with Modelsim, SympanyEDA are few to name.

HTH,
Ajeetha
http://www.noveldv.com

a <a@a.com> wrote in message news:<beukeb$aql1@noticias.madritel.es>...
adarsh arora escribió:
can u tell me from where i will get free downloadable softwares for
VHDL/verilog simulation and synthesis , SPICE ,IC Station...... with
free licences.
waiting for ur help
http://ghdl.free.fr
 
Thomas Stanka wrote:
Mike Treseler <mike.treseler@flukenetworks.com> wrote:

If I have constants and functions to share between processes,
I use the default "work" library, as this is much less trouble
and more portable than naming and maintaining my own library.


I don't think that this is very portable. If you reuse your code, you
have to be very careful about constant names, there might be more
packages including a constant with a specific name. Eg. you use a
library bus_master and a library bus_slave, you don't have to care
about constants names with the same name for master and slave IP.
Yes, there could be name conflicts, but this
would be discovered at compile time and is easily
corrected in the source file being edited.

The upside is that all the developers can CVS to/from
a single directory and compile with a very simple make procedure.

I agree that this scheme might become difficult
for a large number of developers.


-- Mike Treseler
 
"Ray Andraka" <ray@andraka.com> wrote in message
news:3F134720.D19A8BCA@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
 
"Ray Andraka" <ray@andraka.com> wrote in message
news:3F134720.D19A8BCA@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
 

Welcome to EDABoard.com

Sponsor

Back
Top