Clock Edge notation

[rickman]

ALuPin wrote:

Hi,

I have a question concerning the following phenomenon:

I have a signal which is registered by the following way:

entity xy is
port (...
DQS : inout std_logic_vector(15 downto 0);
);
end xy;

architecture zy of xy is
signal l_input_cell : std_logic_vector(15 downto 0);
begin

process(Reset, Clk)
begin
if Reset='1' then
l_input_cell <= (others => '0');
elsif rising_edge(Clk) then
l_input_cell <= DQS;
end if;
end process;
end zy;

When I simulated the design (I had changed a different design to my
own
VHDL style) I got different simulation results (functional simulation
Modelsim) with respect to the signal "l_input_cell".

Then I changed "rising_edge(Clk)" back to "Clk'event and Clk='1'" and
I got the same result as in the original design.

So why is there a difference at all?
Does the use of an INOUT port play any role ?

I can't say that the INOUT port would make a difference since you never
assign a value to DQS. But there is a difference between the two clock
edge descriptions. I don't recall how "rising_edge()" is defined, but
it is not the same as "Clk'event and Clk='1'". Even so, I would not
expect a difference in how the two operate unless CLK has values other
than '1' and '0'.

I belive "Clk'event and Clk='1'" will detect a transistion from *any*
value to '1' as a valid clock edge, while "rising_edge(Clk)" requires
the previous state to be '0' or possibly 'L'. Does you simulation allow
Clk to be undefined with a 'Z', 'U' or 'X'?


--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[sudha]

Hi

I wish you all a very happy and prosperous new year-2005.

I need one help from you regarding quadrature encoder.

we are using linear optical incremental encoder
(HEDS-9200 Q00) which gives 180 pulses/inch in my project.

i am implementing the the decoder/counter in my existing ACTEL FPGA
along with some other functinality.

can you please suggest me what would be the suggested minimim/maximum
clock freuency required to do so?


regards,

S.RANGA REDDY

Ray Andraka wrote:

You might do this as a single process. It would also be easier if
you made this synchronous. You need a
storage element to resolve the direction, which you have done with a
pair of counters. The direction
cannot be determined just by the current inputs, you need to know
what they were before the latest change
too. Normally a quadrature resolver uses a decoder circuit that then
drives a single up-down counter.
The following code should give you the idea. I've shortened
angle_ch_A to ain and same with b to save my
fingers. I just typed the code here, so I make no guarantees that
it'll compile without error. ain,
bin, index are the inputs from the encoder.


process(clk)
variable dir: std_logic_vector(1 downto 0)="00";
variable aold,bold: std_logic;
begin
if index = '1' then
angle<= (others=> '0');
else
if clk'event and clk='1' then
dir := (ain xor aold) & (bin xor bold);
aold:=ain;
bold:=bin;
case dir is
when "00" => --no change
moved <= 0; --leave cw output alone
when "01" => -- clockwise rotation
angle <= angle +1;
moved <= 1;
cw <= 1;
when "10" => --ccw rotation
angle <= angle - 1;
moved <= 1;
cw <= 0;
when "11" => -- this is an error condition...either a
bad sensor or rotation is faster than
clock
end case;
end if;
end if;
end process;




Asher C. Martin wrote:

Greetings,

My name is Asher and I am working on some VHDL code to control an
optical encoder (HEDS-9100) that will measure the angle that a
device
has rotated.

Anyhow, I wanted to know how to drive a signal with multiple
sources in
VHDL. Here are some technical details. I have two different
processes
one called "grab_ch_A_data: PROCESS (angle_ch_A)" that triggers on
the
EVENT that angle_ch_A changes and the other "grab_ch_B_data:
PROCESS
(angle_ch_B)" triggers on the event that angle_ch_B changes.

Inside the first process I am keeping track of whether or not the
device
is rotating clockwise or counter clockwise. KEY POINT: I have this
variable called "clockwise" in both processes and they both should
be
able to set "clockwise" to the direction of rotation. The
direction
depends on the current state of the input signals.

Could someone please help me out? I would really appreciate it.

(SEE ATTACHED CODE)

Best regards,

Asher

=>>=<<=>>=<<=>><<=>>=<<=>>=<<=
Asher C. Martin
805 West Oregon Street
Urbana, IL 61801-3825
(217) 367-3877
E-MAIL: martin2@acm.uiuc.edu
http://fermi.isdn.uiuc.edu
telnet://fermi.isdn.uiuc.edu
ftp://feynman.isdn.uiuc.edu
=>>=<<=>>=<<=>><<=>>=<<=>>=<<=


------------------------------------------------------------------------
-- Asher C. Martin
-- Robotics and Computer Vision Lab

LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_arith.all;

ENTITY angle IS

PORT
(
angle_ch_A : IN STD_LOGIC; --
CHANNEL A FROM OPTICAL ENCODER
angle_ch_B : IN STD_LOGIC; --
CHANNEL B FROM OPTICAL ENCODER
angle_ch_I : IN STD_LOGIC; --
CHANNEL I (HIGH WHEN 360 DEG.)
reset_switch : IN STD_LOGIC; -- IF ANGLE
GETS OFFSET THEN RESET THIS LINE
output_a : OUT INTEGER RANGE 0 TO
255; --STD_LOGIC_VECTOR(7 downto 0)
output_b : OUT INTEGER RANGE 0 TO
255; --STD_LOGIC_VECTOR(7 downto 0)
clockwise : INOUT STD_LOGIC
);

END angle;

ARCHITECTURE angle_architecture OF angle IS

SIGNAL a_counter : INTEGER RANGE 0 TO 255;
SIGNAL b_counter : INTEGER RANGE 0 TO 255;

BEGIN

-- THE FOLLOWING FIGURES OUT IF THE USER IS MOVING LEFT OR RIGHT
--direction: PROCESS ()
-- BEGIN

--END PROCESS direction;

-- THE FOLLOWING CODE EVALUATES WHAT IS HAPPENING TO CHANNEL A
grab_ch_A_data: PROCESS (angle_ch_A)
BEGIN

IF reset_switch = '0' THEN -- FOR TESTING WITH THE
PB_1 MAKE THIS ZERO FOR RESET

a_counter <= 0;

ELSIF (angle_ch_A'EVENT AND angle_ch_A = '1') THEN

a_counter <= a_counter + 1;

ELSE

a_counter <= a_counter;

END IF;

-- THE FOLLOWING FIGURES IF THE DIRECTION IS CLOCKWISE OR COUNTER
CLOCKWISE
IF (angle_ch_A = '1' AND angle_ch_B = '0')
THEN

clockwise <= '1';

ELSE

clockwise <= clockwise;

END IF;

END PROCESS grab_ch_A_data;

-- THE FOLLOWING CODE EVALUATES WHAT IS HAPPENING TO CHANNEL A
grab_ch_B_data: PROCESS (angle_ch_B)
BEGIN

IF reset_switch = '0' THEN -- W/ B_1 MAKE '0'
OTHERWISE KEEP '1'

b_counter <= 0;

ELSIF (angle_ch_B'EVENT AND angle_ch_B = '1') THEN

b_counter <= b_counter + 1;

ELSE

b_counter <= b_counter;

END IF;

-- THE FOLLOWING FIGURES IF THE DIRECTION IS CLOCKWISE OR COUNTER
CLOCKWISE
IF (angle_ch_A = '0' AND angle_ch_B = '1')
THEN

clockwise <= '0';

ELSE

clockwise <= clockwise;

END IF;

END PROCESS grab_ch_B_data;

-- THE CURRENT ANGLE IS NOW LOCATED AT "ANGLE_OUTPUT"
output_a <= a_counter;
output_b <= b_counter;

END angle_architecture;



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka

 

[sudha]

Hi

I wish you all a very happy and prosperous new year-2005.

I need one help from you regarding quadrature encoder.

we are using linear optical incremental encoder
(HEDS-9200 Q00) which gives 180 pulses/inch in my project.

i am implementing the the decoder/counter in my existing ACTEL FPGA
along with some other functinality.

can you please suggest me what should be the suggested minimim/maximum
clock freuency required to do so?


regards,

S.RANGA REDDY

Ray Andraka wrote:

You might do this as a single process. It would also be easier if
you made this synchronous. You need a
storage element to resolve the direction, which you have done with a
pair of counters. The direction
cannot be determined just by the current inputs, you need to know
what they were before the latest change
too. Normally a quadrature resolver uses a decoder circuit that then
drives a single up-down counter.
The following code should give you the idea. I've shortened
angle_ch_A to ain and same with b to save my
fingers. I just typed the code here, so I make no guarantees that
it'll compile without error. ain,
bin, index are the inputs from the encoder.


process(clk)
variable dir: std_logic_vector(1 downto 0)="00";
variable aold,bold: std_logic;
begin
if index = '1' then
angle<= (others=> '0');
else
if clk'event and clk='1' then
dir := (ain xor aold) & (bin xor bold);
aold:=ain;
bold:=bin;
case dir is
when "00" => --no change
moved <= 0; --leave cw output alone
when "01" => -- clockwise rotation
angle <= angle +1;
moved <= 1;
cw <= 1;
when "10" => --ccw rotation
angle <= angle - 1;
moved <= 1;
cw <= 0;
when "11" => -- this is an error condition...either a
bad sensor or rotation is faster than
clock
end case;
end if;
end if;
end process;




Asher C. Martin wrote:

Greetings,

My name is Asher and I am working on some VHDL code to control an
optical encoder (HEDS-9100) that will measure the angle that a
device
has rotated.

Anyhow, I wanted to know how to drive a signal with multiple
sources in
VHDL. Here are some technical details. I have two different
processes
one called "grab_ch_A_data: PROCESS (angle_ch_A)" that triggers on
the
EVENT that angle_ch_A changes and the other "grab_ch_B_data:
PROCESS
(angle_ch_B)" triggers on the event that angle_ch_B changes.

Inside the first process I am keeping track of whether or not the
device
is rotating clockwise or counter clockwise. KEY POINT: I have this
variable called "clockwise" in both processes and they both should
be
able to set "clockwise" to the direction of rotation. The
direction
depends on the current state of the input signals.

Could someone please help me out? I would really appreciate it.

(SEE ATTACHED CODE)

Best regards,

Asher

=>>=<<=>>=<<=>><<=>>=<<=>>=<<=
Asher C. Martin
805 West Oregon Street
Urbana, IL 61801-3825
(217) 367-3877
E-MAIL: martin2@acm.uiuc.edu
http://fermi.isdn.uiuc.edu
telnet://fermi.isdn.uiuc.edu
ftp://feynman.isdn.uiuc.edu
=>>=<<=>>=<<=>><<=>>=<<=>>=<<=


------------------------------------------------------------------------
-- Asher C. Martin
-- Robotics and Computer Vision Lab

LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_arith.all;

ENTITY angle IS

PORT
(
angle_ch_A : IN STD_LOGIC; --
CHANNEL A FROM OPTICAL ENCODER
angle_ch_B : IN STD_LOGIC; --
CHANNEL B FROM OPTICAL ENCODER
angle_ch_I : IN STD_LOGIC; --
CHANNEL I (HIGH WHEN 360 DEG.)
reset_switch : IN STD_LOGIC; -- IF ANGLE
GETS OFFSET THEN RESET THIS LINE
output_a : OUT INTEGER RANGE 0 TO
255; --STD_LOGIC_VECTOR(7 downto 0)
output_b : OUT INTEGER RANGE 0 TO
255; --STD_LOGIC_VECTOR(7 downto 0)
clockwise : INOUT STD_LOGIC
);

END angle;

ARCHITECTURE angle_architecture OF angle IS

SIGNAL a_counter : INTEGER RANGE 0 TO 255;
SIGNAL b_counter : INTEGER RANGE 0 TO 255;

BEGIN

-- THE FOLLOWING FIGURES OUT IF THE USER IS MOVING LEFT OR RIGHT
--direction: PROCESS ()
-- BEGIN

--END PROCESS direction;

-- THE FOLLOWING CODE EVALUATES WHAT IS HAPPENING TO CHANNEL A
grab_ch_A_data: PROCESS (angle_ch_A)
BEGIN

IF reset_switch = '0' THEN -- FOR TESTING WITH THE
PB_1 MAKE THIS ZERO FOR RESET

a_counter <= 0;

ELSIF (angle_ch_A'EVENT AND angle_ch_A = '1') THEN

a_counter <= a_counter + 1;

ELSE

a_counter <= a_counter;

END IF;

-- THE FOLLOWING FIGURES IF THE DIRECTION IS CLOCKWISE OR COUNTER
CLOCKWISE
IF (angle_ch_A = '1' AND angle_ch_B = '0')
THEN

clockwise <= '1';

ELSE

clockwise <= clockwise;

END IF;

END PROCESS grab_ch_A_data;

-- THE FOLLOWING CODE EVALUATES WHAT IS HAPPENING TO CHANNEL A
grab_ch_B_data: PROCESS (angle_ch_B)
BEGIN

IF reset_switch = '0' THEN -- W/ B_1 MAKE '0'
OTHERWISE KEEP '1'

b_counter <= 0;

ELSIF (angle_ch_B'EVENT AND angle_ch_B = '1') THEN

b_counter <= b_counter + 1;

ELSE

b_counter <= b_counter;

END IF;

-- THE FOLLOWING FIGURES IF THE DIRECTION IS CLOCKWISE OR COUNTER
CLOCKWISE
IF (angle_ch_A = '0' AND angle_ch_B = '1')
THEN

clockwise <= '0';

ELSE

clockwise <= clockwise;

END IF;

END PROCESS grab_ch_B_data;

-- THE CURRENT ANGLE IS NOW LOCATED AT "ANGLE_OUTPUT"
output_a <= a_counter;
output_b <= b_counter;

END angle_architecture;



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka

 

[Jonathan Bromley]

On 3 Jan 2005 00:38:08 -0800, "sudha" <sudharr@myw.ltindia.com> wrote:

Hi

I wish you all a very happy and prosperous new year-2005.

I need one help from you regarding quadrature encoder.

we are using linear optical incremental encoder
(HEDS-9200 Q00) which gives 180 pulses/inch in my project.

i am implementing the the decoder/counter in my existing ACTEL FPGA
along with some other functinality.

can you please suggest me what should be the suggested minimim/maximum
clock freuency required to do so?

180 pulses per inch, but how many inches per second?

Obviously the system clock period must be shorter than the minimum
expected time between encoder transitions. However, you will
certainly want to oversample the encoders - partly to deal with
any metastability issues in the input flip-flops, but mainly
because you should have some kind of glitch filter on the
inputs. I would suggest that 4x oversampling is the minimum.

When you say 180 pulses per inch, do you mean 180 transitions
per inch or 180 cycles per inch? Each complete cycle of the
encoder will give 4 transitions. Be sure to get this right.

For some applications it may be more interesting to know the
time of occurrence of encoder transitions. In this situation
you will need a much larger oversampling factor.

Finally, don't forget that various factors can cause jitter
or asymmetry in the encoder pulses. This can have the effect
of shortening the time between some transitions by a factor
of 2 or more, so that you need a higher clock frequency to
get reliable oversampling. A really smart encoder processor
can "learn" about this asymmetry, giving significantly
better accuracy for velocity measurements.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[sudha]

Hi

Thanks for ur reply.

these are my answers to your queries.

1.180 pulses per inch, but how many inches per second?

** count frequency : 100 Khz

2.Obviously the system clock period must be shorter than the
minimum expected time between encoder transitions. However,
you will certainly want to oversample the encoders - partly
to deal with any metastability issues in the input flip-
flops, but mainly because you should have some kind of
glitch filter on the inputs. I would suggest that 4x
oversampling is the minimum.

** since my count frequency is 100Khz i will get 2.5us as a
transition period. so my system clock period should be less
than 2.5us. so i decided to take a clock of >= 500Khz. please
correct me if i am wrong.

3.When you say 180 pulses per inch, do you mean 180 transitions
per inch or 180 cycles per inch?

** 180 cycles per inch.

right now i feel that single transition per cycle is sufficient for our
application. But we are giving the provision to have 2 or 4 transitions
per cycles also, if we need in future

iam even implementing the glitch filter at the input of the decoder to
avoid the spikes/Glitches on the quadrature inputs.

4.> Finally, don't forget that various factors can cause jitter

or asymmetry in the encoder pulses. This can have the effect
of shortening the time between some transitions by a factor
of 2 or more, so that you need a higher clock frequency to
get reliable oversampling. A really smart encoder processor
can "learn" about this asymmetry, giving significantly
better accuracy for velocity measurements.

do you think the implementation of digital filter can avoid this kind
of jitter or assymetry?

please reply me..

regards,

S.RANGA REDDY

Jonathan Bromley wrote:

On 3 Jan 2005 00:38:08 -0800, "sudha" <sudharr@myw.ltindia.com
wrote:

Hi

I wish you all a very happy and prosperous new year-2005.

I need one help from you regarding quadrature encoder.

we are using linear optical incremental encoder
(HEDS-9200 Q00) which gives 180 pulses/inch in my project.

i am implementing the the decoder/counter in my existing ACTEL FPGA
along with some other functinality.

can you please suggest me what should be the suggested
minimim/maximum
clock freuency required to do so?

180 pulses per inch, but how many inches per second?

Obviously the system clock period must be shorter than the minimum
expected time between encoder transitions. However, you will
certainly want to oversample the encoders - partly to deal with
any metastability issues in the input flip-flops, but mainly
because you should have some kind of glitch filter on the
inputs. I would suggest that 4x oversampling is the minimum.

When you say 180 pulses per inch, do you mean 180 transitions
per inch or 180 cycles per inch? Each complete cycle of the
encoder will give 4 transitions. Be sure to get this right.

For some applications it may be more interesting to know the
time of occurrence of encoder transitions. In this situation
you will need a much larger oversampling factor.

Finally, don't forget that various factors can cause jitter
or asymmetry in the encoder pulses. This can have the effect
of shortening the time between some transitions by a factor
of 2 or more, so that you need a higher clock frequency to
get reliable oversampling. A really smart encoder processor
can "learn" about this asymmetry, giving significantly
better accuracy for velocity measurements.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Jan De Ceuster]

I'm probably missing something, but I have a vector such as:

signal counter : unsigned(7 downto 0);

and want to set it to and integer (say 1). I have lots of cumbersome
ways to do it:

counter <= "00000001"; -- Lot's of writing and difficult to maintain.

or

counter <= (others => '0');
counter(0) <= '1'; -- Not very elegant
-- Does not work well other integers.

and of course:

counter <= unsigned(1);

What I would really like to do is overload assignment "<=" so I could
just write:

counter <= 1; -- My idea of elegant

but I don't think VHDL allows that since "<=" is also "less than or
equal to".

It would be nice if VHDL had a "just copy the damn bits" assignment
operator, maybe call it "<-", but as far as I know it does not. As near
as I can tell, the vast majority of so-called conversion functions are
really just copying bits anyway.

Ok, not the most interesting problem in the world, but VHDL type
conversion can be an awful pain at times.

well, there are a few sollutions.
use the IEEE.std_logic_arith package and do
counter <= conv_std_logic_vector(1,counter'high-counter'low+1);

or use the IEEE.numeric package (but you'll have to look that one up)
with a similar conversion function.

or write the number in hex format:
counter <= X"01";

a 'clean' sollution to write certain bits:
counter <= (0 => '1', others => '0');

kind regards,
Jan

PS I'm not posting in newsgroups from this email address...

 

[Kai Harrekilde-Petersen]

Nicolas Matringe <matringe.nicolas@numeri-cable.fr> writes:

Jan De Ceuster a écrit :
well, there are a few sollutions.
use the IEEE.std_logic_arith package and do
counter <= conv_std_logic_vector(1,counter'high-counter'low+1);
or use the IEEE.numeric package (but you'll have to look that one
up) with a similar conversion function.

Hello
I'd use the numeric_std package:
counter <= std_logic_vector(to_unsigned(n, counter'length));
(if you declare counter as unsigned instead of std_logic_vector you
can just write counter <= to_unsigned(n, counter'length);
It's still a little cumbersome though.

We have defined a bunch of central type-conversion functions that cut
this lexical crap to the minimum.

In our environment, I'd write

counter <= to_uns(1, counter'length);

We have similar to_XXX() functions that cover 99% of the conversions
needed between simple types, e.g. to_slv(), to_sl(), to_bool(),
to_int(), etc.

Having a central package that does this allows everyone to benefit
from this, and ensure that noone uses a "home-grown" conversion
function that has a synthesis issue.


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

 

[tom]

Göran wrote:

It's never too late to learn a new language
Thanks for the tip, but I think that VHDL will have to do (for
now)..
Moti.

You can also do recursive hardware in VHDL.
Although it's not as small as confluence.

Göran

Yes, but VHDL lacks higher-order datatypes. Try passing an
entity/architecture pair into an instance of another through a generic
port.

What is this good for? Imagine a generic binary tree component that
accepts a binary operation as an input. The same recursive component
can assemble a tree of XOR gates, tree of adders, or a tree of
multiplexors. In Confluence, you can pull this off:
{tree ('+') unify vector_list summation_result}


-Tom

 

[Göran Bilski]

tom wrote:

Göran wrote:

It's never too late to learn a new language
Thanks for the tip, but I think that VHDL will have to do (for

now)..

Moti.

You can also do recursive hardware in VHDL.
Although it's not as small as confluence.

Göran


Yes, but VHDL lacks higher-order datatypes. Try passing an
entity/architecture pair into an instance of another through a generic
port.

What is this good for? Imagine a generic binary tree component that
accepts a binary operation as an input. The same recursive component
can assemble a tree of XOR gates, tree of adders, or a tree of
multiplexors. In Confluence, you can pull this off:
{tree ('+') unify vector_list summation_result}


-Tom

Yes, That is something I miss from VHDL.

It would have been good if VHDL had taken more from ADA on the generic
functionality.

Göran

 

[Ralph]

7 wrote:

Sven Lossman wrote:

Here is a very sweet game for Linux/Windows/Apple.

http://cube.sourceforge.net/

Question from a newbie.

The game I know is excellent providing you have OpenGL working.
But not every liveCD for example boots up with OpenGL working.

The question for those in the know, is why is OpenGL not
integrated into the heart of X?

What I'm really getting at is why is 3D speedy graphics
methods not part of X?

Because not everyone wants or needs it. Not everyone wants to play 3d games
on Linux. Many of the uses for Linux do not even require X and many people
that use X are on servers that do not need high end video cards... Why have
all that 3d code and expensive cards if not needed?

 

[Egbert Molenkamp]

"Brian Drummond" <brian@shapes.demon.co.uk> wrote in message
news:r79r11tsegkosc33mn5bh54dp1s881ikkd@4ax.com...

..
What happens if you simplify the expression to:

term := conv_integer(expression)*4;
slice <= vector(term + 3 downto term); -- ?

It is possible that the compilation phase can now recognise the simpler
expression as having constant width.

Alternatively, Paul's loop is the longhand way to do it...

Some time ago i played with this problem. Hereby the results.

-- Xilinx ISE supports slice1(bhv)
-- the other synthesis tools I use do not support this.
entity slice1 is
port (ind : in integer range 1 to 4;
inp : in bit_vector(15 downto 0);
outp : out bit_vector(3 downto 0));
end slice1;

architecture bhv of slice1 is
begin
outp <= inp( ind*4-1 downto (ind-1)*4 );
end bhv;

-- Xilinx ISE doen not support slice(bhv)
-- notice the minor change
-- behaviour is exactly the same
entity slice is
port (ind : in integer range 0 to 3;
inp : in bit_vector(15 downto 0);
outp : out bit_vector(3 downto 0));
end slice;

architecture bhv of slice is
begin
outp <= inp( (ind+1)*4-1 downto ind*4 );
end bhv;

-- the loop variable is a constant (that is the trick!).
-- Most synthesis tools will support this.
architecture bhv_workaround of slice is
begin
process(ind,inp)
begin
for i in 0 to 3 loop
if i=ind then
outp <= inp( (i+1)*4-1 downto i*4 );
end if;
end loop;
end process;
end bhv_workaround;

Egbert Molenkamp

 

[Andrés]

cristian wrote:

Andres,

The ispLEVER software has an option that allow you to stop/continue
witht the map process depending on the porcentage of the delay that you
set.
That is, if you go to Tools-> Timing Checkpoint Options, the Timing
Checkpoint Options window will come up. There you can set the Estimated
Logic Delay that you will allow and then you have to tell the tool
whether to Stop or Continue when that number is violated. The 'Before
Route' is related to the Map process.

rgds

cristian

Hi Cristian,

thank you for your answer.

When I step through the design flow I perform MAP DESIGN. Having a look
at the Map Trace Report I can see the following lines in it:

----------------------------------------------------------------------------
Preference | Constraint| Actual|Levels
----------------------------------------------------------------------------
| | |
FREQUENCY NET "ts_clk" 133.330000 MHz ; | 133.333 MHz| 136.724 MHz| 0
| | |
FREQUENCY NET "ts_clk_90" 133.330000 | | |
MHz ; | 133.333 MHz| 826.446 MHz| 0
| | |
FREQUENCY NET "ts_wrclock" 66.660000 | | |
MHz ; | 66.662 MHz| 246.002 MHz| 0
| | |
----------------------------------------------------------------------------

When I go further in the design flow can try to perform MAP TIMING
CHECKPOINT I get the error message I stated before:

*********************************
Map checkpoint failed.
Design's logic delay (97 percent of total delay)
exceeds the 60 percent limit set in the map checkpoint options
*********************************
Process Stopped.

Done: failed with exit code: 0001.

I mean 97 percent would mean that there is some logic part which blows
up in a very heavy way. Why does the MAP TRACE Report not
find that fault ?

Rgds
Andrés

 

[Iwo Mergler]

Randolph J. Herber wrote:

Your description seems adequate and accurate.

Largely correct, but I'll nitpick anyway... :^)

The navigation problem is determing your location in 4-space (3D+T).

When the receiver knows nothing about its 4-space location, it tries for
all possible satellites until it avails an almanac from one of them.

The search goes over all satellites (SVs) *and* over all possible
doppler shifts and local oscillator errors. The Almanac is not strictly
required and doesn't help with the initial search unless you know where
you are.

The 'blind' search continues until 4 SVs are found. Some tricks can be
used to shrink the search space and reduce the initially required number
of SVs for an initial inaccurate position.

Then the receiver knows the correct time within a few seconds and that
the satellite from which the almanac was availed is above the horizon.

After receiving and demodulating the first SV signal for about 6 seconds,
the GPS time is known within better than 0.07 seconds.

The satellite almanac is a rough approximation of the satellite
constellation orbits such that the receiver can spend its efforts on
satellites which are near the satellite from which the almanac was
availed as these satellites also are likely to be above the horizon.
If the receiver has some idea of its location, such as assuming that
it is near (~1Mm) where it was turned off, then it can the current
time (such as from an internal quartz clock), assumed location and
the almanac (whether a saved almanac or one just availed from a
satellite) to do a more effective search.

Yes, these are the most common tricks to speed up the initial search.

It relies on creative definitions of "cold start". :^)

As each satellite is detected, the receiver starts searching for that
satellite's ephemeris data which is an extremely accurate description
of that satellite's orbit. Normally, that accuracy is in millimeters.

Each satellite transmits its own Ephemerides data every ~20seconds and
the almanac of the full constellation every ~12 minutes. Ephemeris is a
very accurate "best fit", but only in the short term (4 hours). Almanac
information is inaccurate, but degrades much more slowly.

It is kept to that accuracy by ground station monitoring of the
satellites by radar and lidar from known locations on the ground and
updating the satellites ephemeris several times a day.

As far as I know, the ground stations use (military) GPS to measure the
orbits. I have a feeling that the required Radar baseline may be larger
than the ground stations. And Lidar is normally used for aerial ground
mapping, I'm not sure it can handle atmospheric scatter at sufficient
accuracy.

Do you have any references for this?

Once four non-coplanar satellites are located, or the equivalent from
other known data, such as an accurately known time (such as a cesium
clock in the receiver) or altitude (e.g., known to be a specified
distance from sea level (consider a GPS receiver on a vessel at sea)),
it is possible to solve the four, non-linear equations in four unknowns
to determine the receiver's 4-space location. If more than 4 data
can be availed, then the various combinations generally different
solutions. These solutions could combined statistically to produce
a hopefully more accurate solution. If the receiver stays at a fixed
location in 3-space, then the time-separated solutions can be combined
statistically, to produce a hopefully more accurate solution also.

The most common practice is to combine all the available measurements

into a so called over determined solution. This gives you a
"best position", usually according to least squares criteria. The
time solution is integral to this, no special treatment needed.

There are more advanced ways of doing this, usually with an enormous
increase in required computing power.

The solution surfaces for two satellite signals are hyperboloids
of two sheets in 4-space, for 3 satellites it is a closed curve
in 4-space and for 4 satellites, a point in 4-space (some equivalent
of latitude, longitude, altitude and time, all at the equivalent of
a few nanoseconds accuracy).

Two points actually, but one is outside the satellite orbits.

Finally, the pseudo-range from a satellite is conversion of the
(possibly, assumed) time difference between the when a satellite
sent its signal and when the receiver received the signal converted
to distance.

Thats why it's called 'pseudo' range. it is subjected to the common
mode error of the receiver clock.

Several corrections are commonly applied: an assumed
base delay from passing through the atmosphere (particularly, the
ionosphere) and if a correction signal can be availed, corrections
for known errors in the satellites' signals. The correction signals
may come from Differential GPS from either a governmental source
(the US Coast Guard provides such a service), from a commercial
service or your own base station at a known location; WAAS, EGNOS,
LAAS or other equivalent, etc.

The almanac contains global average ionospheric corrections which are
always applied. WAAS/EGNOS DGPS normally corrects more accurately for
a large region (USA/Europe), DGPS beacons normally for an area of a
few 100Km. The smaller the region, the more accurate the correction.

Survey equipment normally consists of a reference receiver at a known
position and a mobile unit. This is a very small scale DGPS system
with added tricks (carrier phase measurement) which can achieve sub
cm accuracies.

Military GPS can measure the atmospheric delay for the exact position,
because the two frequencies have different delays trough the atmosphere.
Future GPS and the upcoming Gallileo system will provide dual-frequency
operation for civilian receivers.

You might find it interesting or useful to study the LORAN system.
(http://en.wikipedia.org/wiki/LORAN)

Receivers that combine GPS, Galileo, GLONASS, LORAN, INS or a miniature
cesium clock (http://www.nist.gov/public_affairs/releases/miniclock.htm)
are reasonable devices to consider building as the navigation technologies
complement each other. In particular, GPS and Galileo are designed
so that building a combined receiver would not be much more expensive
than a receiver for GPS or Galileo alone.

Kind regards,

Iwo

 

[KJ]

On Aug 14, 6:36 pm, rickman <gnu...@gmail.com> wrote:

I typically use down counters that are loaded with an initial value
and output a flag when reaching zero.  


I can't find this thread.  Anyone remember it and some keywords that
would let me find it?  There may be something wrong with Google
groups.  I search on "counter carry chain" and it finds *NO*

I think this is the link you're looking for. Andy's post from June 19
is the 8th one in the thread.

http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/36d7833968f3e102/452a230826d347aa?q=down+counter+%22Andy%22+group:comp.lang.vhdl

Kevin Jennings

 

[rickman]

On Aug 14, 9:17 pm, KJ <kkjenni...@sbcglobal.net> wrote:

On Aug 14, 6:36 pm, rickman <gnu...@gmail.com> wrote:

I typically use down counters that are loaded with an initial value
and output a flag when reaching zero.

I can't find this thread. Anyone remember it and some keywords that
would let me find it? There may be something wrong with Google
groups. I search on "counter carry chain" and it finds *NO*

I think this is the link you're looking for. Andy's post from June 19
is the 8th one in the thread.

http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/36d78...

Kevin Jennings

I guess that is the one. I don't see where they brought out the carry
flag to use elsewhere though and when I implement this, I get two
adders and the one generating the term count uses extra logic just to
get the carry out of the chain. This is using the Lattice tools in
their XP parts.

I seem to recall making this work by adding an extra bit to the input
value and separating the msb of the output as the carry. I'll give
that a try.

Rick

 

[Brian Davis]

On Aug 15, 10:13 pm, rickman <gnu...@gmail.com> wrote:

I seem to recall making this work by adding an extra bit to the input
value and separating the msb of the output as the carry. I'll give
that a try.

Not specific to your down counter problem, but I posted a

snippet a few years back that showed operand padding to
pull out the carry/overflow:

http://www.fpga-faq.com/archives/99500.html#99517

I'd first seen that in another post years ago,
that I can't locate anymore...

I've also noticed troubles with the google archive search,
I've been using the archive search on fpga-faq.com instead

http://www.fpga-faq.com/archives/index.html

Brian

 

[Andy]

On Aug 14, 8:17 pm, KJ <kkjenni...@sbcglobal.net> wrote:

On Aug 14, 6:36 pm, rickman <gnu...@gmail.com> wrote:

I typically use down counters that are loaded with an initial value
and output a flag when reaching zero.  

I can't find this thread.  Anyone remember it and some keywords that
would let me find it?  There may be something wrong with Google
groups.  I search on "counter carry chain" and it finds *NO*

I think this is the link you're looking for.  Andy's post from June 19
is the 8th one in the thread.

http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/36d78...

Kevin Jennings

Wow, what's old is new again...

I should note that since then, I have noticed that while the RTL view
from Synplify indicates using the next bit (carry), the technology
view sometimes comes up with something better, not necessarily using
the carry chain the way one would expect.

That said, I have never seen it do worse than a "count = 0"
comparison.

Also be aware that the "count - 1 < 0" (or "count + 1 > 2**n-1") trick
only works with integer types, not with unsigned vector types.

Andy

 

[JimLewis]

Hi Rick,
Integers and such are great for sim run time, however, if you are not
getting the hardware you want, here is an array based algorithm that
only uses one carry cell to implement the zero detect. It has a few
extras that you may want to remove. BaseReg is the loadable base
register. CntReg keeps the current count value. IntReg is a
registered version of the zero detect.

Best,
Jim
SynthWorks VHDL training


TimerProc : process (Clk, nReset)
variable Dec : unsigned(CntReg'Length downto 0) ;
begin
if (nReset = '0') then
BaseReg <= (others => '0') ;
CntReg <= (others => '0') ;
IntReg <= '0' ;
elsif rising_edge(Clk) then
if (TimerSel = '1' and Read = '0') then
BaseReg <= unsigned(DataIn) ;
end if ;
Dec := ('0' & CntReg) - 1 ;
if (Dec(Dec'Left) = '1') then
CntReg <= BaseReg ;
else
CntReg <= Dec(CntReg'Range);
end if ;
IntReg <= Dec(Dec'Left) ;
end if ;
end process ;

 

[Andy]

That's about the cleanest example using vectors I've seen.

I'm not sure it wouldn't be subject to the same final optimizations
from Synplify (et al?), since those optimizations were related more to
the entire carry chain than to just the end of it. Although outputting
the carry bit in the IntReg register would likely give it a strong
nudge towards preserving the carry bit intact (if not the entire
chain). I've not checked any results from integer-coded
implementations that also registered (count - 1 < 0) as a boolean
output.

Be careful if CntReg'Range is not "n downto 0".

Andy

 

[rickman]

On Aug 17, 12:15 pm, JimLewis <J...@SynthWorks.com> wrote:

Hi Rick,
Integers and such are great for sim run time, however, if you are not
getting the hardware you want, here is an array based algorithm that
only uses one carry cell to implement the zero detect. It has a few
extras that you may want to remove. BaseReg is the loadable base
register. CntReg keeps the current count value. IntReg is a
registered version of the zero detect.

Best,
Jim
SynthWorks VHDL training

TimerProc : process (Clk, nReset)
variable Dec : unsigned(CntReg'Length downto 0) ;
begin
if (nReset = '0') then
BaseReg <= (others => '0') ;
CntReg <= (others => '0') ;
IntReg <= '0' ;
elsif rising_edge(Clk) then
if (TimerSel = '1' and Read = '0') then
BaseReg <= unsigned(DataIn) ;
end if ;
Dec := ('0' & CntReg) - 1 ;
if (Dec(Dec'Left) = '1') then
CntReg <= BaseReg ;
else
CntReg <= Dec(CntReg'Range);
end if ;
IntReg <= Dec(Dec'Left) ;
end if ;
end process ;

I don't have any problem getting the basic counter to use the carry
chain, but I can not get the carry out for other purposes. The result
seems to depend on size and how the tool is invoked. If I use the
Lattice tool, an 8 bit counter uses 3 LUTs to detect the terminal
count. At 16 bits it duplicates the adder chain and pulls off the
carry out. Using Synplify directly the technology view shows two
adders while the RTL view shows one adder with 24 bits. The carry
comes out of the top and the lower N bits are used for the counter.
Go figure...

Rick