Clock Edge notation

Your FSM coding in not correct as
You have not included the databus in the sensitivity list.
Temp is not assigned in other states resulting in latches.
You dont have an initial state to start, your default state A0 dosent
exist.
With above corrections, it would be better if you made assignments to
address and data bus explicitly in each of the states.

-Neo

 

[Brad Smallridge]

Hang a clock event around your B process,
put clk in your sensitivity list,
and it should run fine:

B: Process(clk)
begin
if( clk'event and clk='1') then
OBLed <= Count(19);
if (Count = x"FFFFF") then
LedCount <= LedCount + 1;
Leds <= LedCount;
end if;
end if;
end process;

b r a d @ a i v i s i o n . c o m

 

[Nicolas Matringe]

Marco Pikiri a écrit :

Going to "Save & Check" is all ok, but "Save & Compile" notify 64 errors for
"missing source" on variables "max_count_in" (32 errors) and "max_count_out"
(the other 32 errors). As a newbie, I ignore what's the problem's type...
For me the syntax's code is ok.

You declare max_count_in as a variable but you never assign a value,
except at declaration where you assign a default value based on a
signal's value, and you never even assign a value to this signal (freq_in)
Same goes for max_count_out.
Consider using generics and constants.

--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/

 

[Marco Pikiri]

Nicolas Matringe wrote:

You declare max_count_in as a variable but you never assign a value,
except at declaration where you assign a default value based on a
signal's value, and you never even assign a value to this signal
(freq_in) Same goes for max_count_out.
Consider using generics and constants.

Thanks a lot!

--
Marco

 

[Marco Pikiri]

Tim Good wrote:

2. [CUT]

Hope this helps,

Surely

Thanks a lot!
--
Marco

 

[zinga]

there is no max limit but the minimum should be greater than the frequency
of pulses/unit time.

 

[Sylvain Munaut]

Hi Jim

Is there another driver of pci_ad? Looks to me like there
is and it is not turned tristated until well into your
first pci write cycle. One thing you may want to try is
initializing all sources for pci_ad to all 'Z'.

Damn, I missed the obvious ! Since I was modifying my simple
test bench to make it more "advanced", I just forgot that there
was the PCI target core I'm working on plugged in ... And it
reacted to those "weird" test signals ...


Sylvain

 

[Mike Treseler]

praveen wrote:

Thanks Etem Tezcan,

I am looking for some reference code of AHB. Can some one please give
some reference where i can find it.

http://www.google.com/search?q=vhdl+ahb+example

-- Mike Treseler

 

[Stefan Duenser]

1) The conv_integer procedure does not work here, I always get the
errormessage: no feasable subprogram entry for conv_integer. Any ideas
whats wrong here?

I really dont understand why this is not working, because this functions are
declared in the ieee.std_logic_arith.all header...

FUNCTION to_integer ( arg1 : STD_ULOGIC_VECTOR; x : INTEGER := 0 ) RETURN
INTEGER;
FUNCTION to_integer ( arg1 : STD_LOGIC_VECTOR; x : INTEGER := 0 ) RETURN
INTEGER;
FUNCTION to_integer ( arg1 : STD_LOGIC; x : INTEGER := 0 ) RETURN
NATURAL;
FUNCTION to_integer ( arg1 : UNSIGNED; x : INTEGER := 0 ) RETURN NATURAL;
FUNCTION to_integer ( arg1 : SIGNED; x : INTEGER := 0 ) RETURN INTEGER;

FUNCTION conv_integer ( arg1 : STD_ULOGIC_VECTOR; x : INTEGER := 0 )
RETURN INTEGER;
FUNCTION conv_integer ( arg1 : STD_LOGIC_VECTOR; x : INTEGER := 0 )
RETURN INTEGER;
FUNCTION conv_integer ( arg1 : STD_LOGIC; x : INTEGER := 0 ) RETURN
NATURAL;
FUNCTION conv_integer ( arg1 : UNSIGNED; x : INTEGER := 0 ) RETURN
NATURAL;
FUNCTION conv_integer ( arg1 : SIGNED; x : INTEGER := 0 ) RETURN INTEGER

any useful tips?

 

[Stefan Duenser]

"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:1105036563.591863.97960@z14g2000cwz.googlegroups.com...

Try this.

Thanks a lot Mike, it worked!! Also thanks for your hint Egbert!

Bye

 

[Jim Lewis]

Sylvain,
Is there another driver of pci_ad? Looks to me like there
is and it is not turned tristated until well into your
first pci write cycle. One thing you may want to try is
initializing all sources for pci_ad to all 'Z'.

Regards,
jim

Hello all,

I'm trying to understand a weird behavior I'm observing in the simulator.
First I must say it's for a test bench so I don't "really" care about
optimality or synthesis.

I'm calling a procedure from a continuous process (no sensitivitylist) and
the result for the first "iteration" is not what I expect, while all the
others are OK.

The result can be seen here :

http://www.246tnt.com/files/wave.png

It shows two runs of the process that I would expect to be identical ...
I've run
the simulation thru both modelsim and simili with same results.

Here is the code snippet : (note it's just a test, not at all real PCI
... )

-- PCI Scenario
process

type dataseq_t is array(integer range <&gt of std_logic_vector(31
downto 0);

-- PCI Read sequence

-- PCI Write sequence
procedure pci_do_write(
w : in integer;
data : in test_t
) is
begin
pci_frame_n <= '0';
pci_ad <= data(0);
wait for 100 ns;
pci_frame_n <= '1';
pci_ad <= data(1);
wait for 100 ns;
pci_frame_n <= 'Z';
pci_ad <= data(2);
end procedure;

constant ts : dataseq_t(0 to 2) := ( x"12345678", x"9ABCDEF0",
x"13FF005A" );
begin

-- Reset
wait for 10 ns;
pci_do_write(2, ts);
wait for 200 ns;

end process;


Thanks for any insight ...

Sylvain

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[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.

 

[Mike Treseler]

Philipp Grabher wrote:

Currently I am implementing my own IP

Really?

which I wanna add to the FSL of the
Microblaze soft processor. But unfortunately I have problems with the RAM I
programmed. Although it is fully synthesizeable it doesnt work the way I
want it to on the FPGA. In the simulation it looks good to me, so probably
there is some syntax I use which causes problems on the FPGA.

This design has already been critiqued
elsewhere in this newsgroup.

-- Mike Treseler

 

[Mike Treseler]

See page 26 of
http://www.hep.wisc.edu/~gowrisha/Tutorial.pdf

--- Mike Treseler

 

[Mike Treseler]

Paul Urbanus wrote:

Thanks for the pointer, but a newbie tutorial on ModelSim isn't what I
need.

Did you see the bit on virtual signals?
That is a modelsim feature that might do what you want.

You also might try using a vhdl record type,
I think modelsim handles those identifiers reasonably.

-- Mike Treseler

 

[Tim Hubberstey]

Paul Urbanus wrote:

Mike Treseler wrote:

See page 26 of
http://www.hep.wisc.edu/~gowrisha/Tutorial.pdf

--- Mike Treseler


Mike,

Thanks for the pointer, but a newbie tutorial on ModelSim isn't what I
need. If you re-read my post, you'll see that I'm asking a deeper
question, the answer which is not "select the 'symbolic' radix for the
signal(s) in question, as indicated in the tutorial".

What I'm asking is how to get a symbolic display of a state if the
signal is a std_logic_vector and the states are defined as constants.

Or, how to assign explicit slv values to an enumerated type such as a
state type.

I know that I can brute force this and add a case statement to my code
that will allow me to convert the enumerated state type to an slv, which
I can than pass to the top level I/O pins. Then, I can view state
symbolically by just displaying the enumerated state signal from inside
the design. However, I was looking for a more elegant solution, which
may not exist.

This is not directly possible for a couple of reasons:

Firstly, you've got a scoping issue. The constants you are referring to
are defined *inside* the architecture while the pins you want to observe
are *outside*. As a result, the constants will not be "visible".

Secondly, constants and type definitions are in separate namespaces.
This means that even though you have enumerated your states with the
same names as your constants, they are NOT the same. However, there is a
real possibility that a synthesizer will not like your code *because*
you've used the same names (synthesizers tend to be excessively picky).

The cleanest way to do this, IMO, is to create an independent monitor
entity that understands the coding of your SLVs and outputs an
appropriate enumerated type. I suggest you move your constants into a
package and include the package in both your code and the monitor.

The way I often deal with this is to "cheat" and observe the enumerated
value inside the architecture. Unfortunately, this only works for RTL
and if you want to simulate gate-level code, you're stuck with a monitor
entity.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

 

[Nicolas Matringe]

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.
--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/

 

[Roger]

Are you truely trying to use the READ_FIRST mode? If so, you need to
add custom circuitry to do so since the selected device does not
support this option. If not, you should be able to modify your code to
remove the read before write behavior.

The ROM warnings suggest that you are not instantiating the ROM
properly. First, the READ_FIRST mode should be irrelavent for ROMs.
Second, you have not provided initial values for the ROM entries.
Without access to your code, its hard to be of much more help.

 

[Stefan Oedenkoven]

First thinks about this elegant ideas ;-)

a) Is it necessary to begin with one? Just start counting at zero.
b) Is it necessary to use vectors? Use integers.

regards,
Stefan

 

[Thomas Stanka]

Jan De Ceuster <jan.de.ceuster@xs4all.be> wrote:

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";

This should do only in VHDL 93 (and newer), but seems to be the best
sollution.

If the task is done for fixed numbers it could be usefull declaring
constants (maybe in a package once for ever).

CONSTANT ONE:std_ulogic_vector(7 donwto 0):="00000001";
.....
counter<=ONE;

bye Thomas