Clock Edge notation

[Mohammed khader]

Hi Roger,

What Mike said was correct . The output is switching with half the
frequency of 'mclk'.

some other comments on your code....
1) Dont Initialize the signals when you write code for synthesis
2) All FSMs should have a reset signal.(otherwise system starts from
a unknow state). Hence your First process should be like this...

process (mclk,reset)
begin
if (reset='0')then
cur_st <= write_a; -- If write_a is the initial state
elsif rising_edge(mclk) then
cur_st <= next_st;
end if;
end process;

 

[Roger Dahl]

zingafriend@yahoo.com (Neo) wrote in message news:<e5de3dea.0411162311.7178366a@posting.google.com>...

The behaviour you observe is correct as per hardware but wont show in
simulation because the process sensitivity list is for simulator
only(it would have shown if you had as required included the d_ctl in
the sensitivity list) , the hardware is not dictated by it, so for all
practical purposes the hardware comb logic triggers everytime the
d_ctl changes which is nothing but a not gate fed to itself. So to
accurately model your requirement you have to specifically state that
d_ctl <= '1' in the write_b state. but you present assignment is
modelling a clock.

Neo,

That explains it. I appreciate that you took the time to enlighten me. Thanks!

Roger

 

[Roger Dahl]

am.imak@gmail.com (Mohammed khader) wrote in message news:<d1c432c1.0411170046.62242ed7@posting.google.com>...

Hi Roger,

What Mike said was correct . The output is switching with half the
frequency of 'mclk'.

some other comments on your code....
1) Dont Initialize the signals when you write code for synthesis
2) All FSMs should have a reset signal.(otherwise system starts from
a unknow state). Hence your First process should be like this...

process (mclk,reset)
begin
if (reset='0')then
cur_st <= write_a; -- If write_a is the initial state
elsif rising_edge(mclk) then
cur_st <= next_st;
end if;
end process;

Hi Mohammed,

Thank you for your reply.

Actually, the output is switching as fast as the hardware can manage
while the state machine is in the second state. See Neo's post for the
explanation as to why this happens.

Thanks for the coding tips. Those things were in my original design
but I had shaved them off to make the example as brief as possible for
the group.

Roger

 

[Tim Olson]

In article <aedc0f92.0411170445.39294468@posting.google.com>,
wiener_norbert@yahoo.com (Wiener, Norbert) wrote:

| Hi all,
|
| Has anyone heard about the bitplane approach to implement FIR filters?
|

We did something that sounds similar to this for the correlation code in
a software rake receiver implementation. The incoming samples were only
5 bits, so performing computation with 16-bit or 32-bit registers wasted
most of the computation capability. By reorganizing the sample data
into bit planes (with each bit plane containing packed bits from bit N
of each sample), the outer loop could step over the 5 bit planes, with
the inner loop performing partial product operations on multiple samples
in parallel, utilizing the full width of the registers.

-- Tim Olson

 

[Allan Herriman]

On Fri, 19 Nov 2004 10:40:52 -0500, David Bishop <dbishop@vhdl.org>
wrote:

Std_logic_textio has been donated to the IEEE.

Does that mean they're going to own the copyright and not allow the
source to be distributed for free? That would be a bad thing.

Regards,
Allan

 

[David Bishop]

Allan Herriman wrote:

On Fri, 19 Nov 2004 10:40:52 -0500, David Bishop <dbishop@vhdl.org
wrote:


Std_logic_textio has been donated to the IEEE.

Does that mean they're going to own the copyright and not allow the
source to be distributed for free? That would be a bad thing.

One of the objectives of the vhdl-200x-ft group is to allow us
to freely distribute the source code for these packages. The fact
that the IEEE puts it's copyright on the code that I've worked on
has been a thorn in my side for years now.

Rest assured, we are working on this issue.

 

[Jim Lewis]

Allan,
I share that concern also. The previous problem
with IEEE was that the packages were a large part
of the standard. Since the pacakges are now
going to be part of 1076, we may be able to
overcome this issue.

On the other hand, while it would be nice to have
source, it is not necessary. What we really need
is good man page type documentation about each of
the functions in the packages.

Cheers,
Jim

On Fri, 19 Nov 2004 10:40:52 -0500, David Bishop <dbishop@vhdl.org
wrote:


Std_logic_textio has been donated to the IEEE.


Does that mean they're going to own the copyright and not allow the
source to be distributed for free? That would be a bad thing.

Regards,
Allan

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Allan Herriman]

On Sun, 21 Nov 2004 20:49:33 -0800, Jim Lewis <Jim@SynthWorks.com>
wrote:

Allan,
I share that concern also. The previous problem
with IEEE was that the packages were a large part
of the standard. Since the pacakges are now
going to be part of 1076, we may be able to
overcome this issue.

On the other hand, while it would be nice to have
source, it is not necessary. What we really need
is good man page type documentation about each of
the functions in the packages.

VHDL has separate package and package body. Users should really only
need the package.
For some of the existing IEEE packages though, you need the package
body just to work out what the functions actually do. Surely a little
comment in the package wouldn't be too hard?

Regards,
Allan

 

[Jim Lewis]

Allan,

VHDL has separate package and package body. Users should really only
need the package.
For some of the existing IEEE packages though, you need the package
body just to work out what the functions actually do. Surely a little
comment in the package wouldn't be too hard?

If I am going to write user documentation, I would rather
keep it separate and make it public domain - that way
IEEE can't claim it and keep it for themselves.

Regards,
Jim

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Nicolas Matringe]

Weddick a écrit:

Just starting with VHDL and was trying to make a serial shift register to
shift in 8 bits. I have attached my code and test bench. The problem I
have is that it seems the data takes an extra clock before it becomes
availabe at the output. Any help would be appreciated.

Hi
That's what you wrote in your VHDL )
Data bits are shifted in you data register on every clock edge, and this
data register is then copied in your dword output register. That makes 2
clock cycles between din and dword.
Just put the 'dword <= data;' assignment outside of the process, or use
a variable instead of a signal for data.
You should use a reset signal for your registers.

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

 

[Neo]

Hi,
I think the problem is not with conversion function but with the write
function, it wont take arguments which are functions or some other
expressions other than whats to be written.


Neo.

 

[Paul Uiterlinden]

Weddick wrote:

Just starting with VHDL and was trying to make a serial shift register to
shift in 8 bits. I have attached my code and test bench. The problem I
have is that it seems the data takes an extra clock before it becomes
availabe at the output. Any help would be appreciated.

begin
if xClk'event and xClk='1' then
if Ena = '1' then
data <= data(6 downto 0) & Din;
end if;
end if;
Dword <= data; <<<< This is your extra clock cycle <<<<
end process;


The assignment to Dword is within the clocked process, so inferring
flip-flops. This is the extra clock cycle you're seeing.

Move the signal assignment to outside the process and your extra clock
cycle (and extra flip-flops) will disappear.

Paul.

 

[Mike Treseler]

Manfred Balik wrote:

I have realized a watch viewing nanoseconds and seconds from a 31.611 MHz
clock (it's the only one in the design).

25 bit tick counter: 2**25 = 33,554,432
6 bit seconds counter with clock enable: 2**6 = 64
6 bit minutes counter with clock enable: 2**6 = 64
etc. etc.

At tick count 31,611,000 enable a seconds count
and a synchronous clear of ticks.

At seconds count= 60, enable a minutes count
and a synchronous clear of seconds.

etc, etc.

-- Mike Treseler

 

[Neo]

I dont understand this question. How can you measure time in
nanoseconds and femtosseconds when the clock freq itself is just
31MHz.

Neo

 

[Hal Murray]

I dont understand this question. How can you measure time in
nanoseconds and femtosseconds when the clock freq itself is just
31MHz.

Just multiply by the right scale factor. Or add N rather than 1
each time the clock ticks.

Suppose I had a clock running at 100 MHz and I wanted time in
ns. Just add 10 each time the clock ticks.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Thomas Stanka]

conphiloso@hotmail.com (john) wrote:

The problem is that the "Q(0)" bit of the counter is not incrementing
at the rising edge of the "inc" signal instead its incrementing when
"inc" signal goes from high to low. I want to increment Q(0) at rising
edge of the "clk" and rising edge of the signal "inc".

I can't see your intention in the code below. To detect rising edges
synchron you use a shift register.

test_sr<=test_sr(0)&test_sig
test_edge<=test_sr(0) and not test_sr(1)

The problem with your code is, that your counter increments, at the
next rising edge of clk while inc=1. If inc changes with your clock
for one clock cycle (can't see in your code, when inc will change in
relation to CLK) you will see that Q changes with inc but delayed for
one cycle. A good example why it could be better to use a small
gatedelay (after 1 ns), to see signals changing delayed to clock.

Q( 13 downto 0 ) <= ('0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0' );

Q<=(others=>'0') seems more readable to me and has the same semantics.

 

[Mohammed khader]

john wrote :

"inc" signal goes from high to low. I want to increment Q(0) at
rising
edge of the "clk" and rising edge of the signal "inc".
Please Advice!!

I did'nt understand why do you want to check 2 rising edge .It is
highly impractical .... According to me P is used as Enbale signal
for the counter....

If you intend to do then use nested rising edge if statements as
follows..
if(clk=1 and clk'Event)then
if(p=1 and p'Event)then
Q <=Q+1 ;
end if ;
end if ;

There are many more things to note ...

Qout <=Q;
Qout is inside the Clocked process so Output is one clock cycle

delayed.

Check the use of OTHERS keyword and try to use it for assinging long
words.. like in

If (Reset_c = '1' ) then

Q( 13 downto 0 ) <= ('0', '0', '0', '0', '0', '0', '0',
'0', '0', '0', '0', '0', '0', '0' );

Code for the state Machine is not clear and complete But it looks
like you are reseting the Conter after every increment...

 

[Mohammed khader]

zingafriend@yahoo.com (Neo) wrote in message news:<e5de3dea.0411250055.2d61ebea@posting.google.com>...

Hi,
I think the problem is not with conversion function but with the write
function, it wont take arguments which are functions or some other
expressions other than whats to be written.


Neo.

I got this error during Simulation NOT while compling.

According to me first CONV_STD_LOGIC_VECTOR is executed then the
return value is passed to the WRITE function.

Please clarify me if I am wrong.

 

[Thomas Stanka]

am.imak@gmail.com (Mohammed khader) wrote:

If you intend to do then use nested rising edge if statements as
follows..
if(clk=1 and clk'Event)then
if(p=1 and p'Event)then
Q <=Q+1 ;
end if ;
end if ;

I don't believe, that this piece of code will synthesis correctly.
Never use two clocks in one process for synthesisable code.

bye Thomas

 

[Mohammed khader]

usenet_10@stanka-web.de (Thomas Stanka) wrote in message news:<ef424d2c.0411280650.2041b819@posting.google.com>...

am.imak@gmail.com (Mohammed khader) wrote:
If you intend to do then use nested rising edge if statements as
follows..
if(clk=1 and clk'Event)then
if(p=1 and p'Event)then
Q <=Q+1 ;
end if ;
end if ;

I don't believe, that this piece of code will synthesis correctly.
Never use two clocks in one process for synthesisable code.

Hi Thomsa,

I did'nt say that " code will synthesis correctly". I said it is
hight impractical for this . If any one wants to just simulate then
will .