Clock Edge notation

[Klaus Falser]

In article <1116351201.114042.248890@z14g2000cwz.googlegroups.com>,
Bassman59a@yahoo.com says...

I think I should be able to do this, but I can't figure out what signal
attribute or other magic incantation is necessary. The following is
for a test bench.

Given a signal:

signal InData : std_logic_vector(7 downto 0); -- or whatever

assigned in some process somewhere:

InDataDrive : process is
begin
InData <= foo;
wait until FooIsHappy;
InData <= bar;
wait until BarIsHappy;
end process InDataDrive;

I'd like to have a process somewhere detect that InData changes and
then do something with the new value:

DealWithIt : process is
begin
... do some stuff
wait until InData'event;
... do more stuff
end process DealWithIt;

This all works wonderfully except when foo and bar are the same. In
that case, the wait until InData'event triggers on the initial change
(imagine that some other process changes both foo and bar during the
time BarIsHappy is false) but when InData is assigned bar (same as
foo), DealWithIt doesn't trigger.

I also tried

wait until InData'active;

which also didn't work.

Seems to me that even though the values assigned to InData are the
same, there are still transactions on InData.

I'm using ModelSim XE 6.0a. Perhaps there's an optimization happening?

I tried

wait until (InData'transaction = '1');

but that was even more evil -- my entire simulation suspended here.

The statement
wait until InData'active;

has a implicit sensitivity list of InData. If InData
gets no new value (foo and bar are the same) there is
no event on InData and the wait clause is not triggered,
even if InData'active is true.

InData'transaction gives a signal which toggles between
'1' and '0' every time a transaction ( = assignment)
on InData is made, regardless of whether the new value is
the same as the old value.
You can trigger on this signal and it will work perfectly
if you write

wait on Indata'transaction;

Regards
Klaus

 

[Marcus Schämann]

jo.spreutels@gmail.com schrieb:

the screen is staying in power save mode.So I guess it is confused by
the syncing.
The timing is calculated for a 800 *524 display(640 ,480).

And the RBG signals are departing from the board.but they have to,
right?
I don 't know what you mean by this?
the R,B,G an hor,ver sync have to be connected to the board.

Hi Jo,

As far as I can see you increase your vertical counter every clock
cycle. That is not correct - it has to be increased at the end of each
line at (sx_pointer=799). Try this:

if (sx_pointer=799) then
if (sy_pointer = 524) then
sy_pointer <= "0000000000";
else
sy_pointer <= sy_pointer + 1;
end if;
end if;

I hope that works!

Marcus

 

[Marcus Schämann]

jo.spreutels@gmail.com schrieb:

the screen is staying in power save mode.So I guess it is confused by
the syncing.
The timing is calculated for a 800 *524 display(640 ,480).

And the RBG signals are departing from the board.but they have to,
right?
I don 't know what you mean by this?
the R,B,G an hor,ver sync have to be connected to the board.

and there are some signals wrong in your code
It's better this way:

if (sy_pointer <= 494) and (sy_pointer >= 493) then
sv_sync <= '0';
else
sv_sync <= '1';
end if;

 

[Martin Thompson]

jo.spreutels@gmail.com writes:

the screen is staying in power save mode.So I guess it is confused by
the syncing.
The timing is calculated for a 800 *524 display(640 ,480).

How have you calculated it? There are various tables out there that
Google will find that will tell you the timings... or you can do what
I did and measure them off a standard graphics card in the right mode

And the RBG signals are departing from the board.but they have to,
right?

They do, but you can't (I don't think) just send 3.3V logic signals
straight up the VGA cable to the monitor. The PDF link I directed you
to has some schematics of what resistors to use I think.

Does that help?

Martin

--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

 

[Jonathan Bromley]

On 18 May 2005 06:33:10 -0700, ALuPin@web.de wrote:

When I comment the inner if-statement out
if (i <= wait_index) then
--if i=wait_index then
writeline(OUTPUT,ln);
write(ln,string'("loop "));
write(ln,j_help);
--end if;
wait on Clock, Data;
exit LOOP1_OUT when Data="10000100";
end if;

I get monitored in Modelsim
loop 0
loop 1
...
loop 49

But loop 50 is missing. Why?

Try moving the writeline() call to AFTER the two
write() calls, so that your message from the final
iteration is indeed written to stdout

And for further credit: explain why your original
code exhibits a memory leak.
--
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.

 

[Jonathan Bromley]

On 18 May 2005 09:08:46 -0700, ALuPin@web.de wrote:

Write and Writeline are fuctions defined in the STD.TEXTIO
library of VHDL.

Line is a type def. It is access STRING. i.e it is a pointer
to a STRING.
Fn. Write adds the string specfd. to this Line (in Ur case strbuf).
Writeline Flushes this line onto the file specfd. (in Ur case
output).
\/
And from this the memory leak arises! Is that correct ?

Not quite.

Typically, a procedure that does text output will build up some
text in a LINE variable using WRITE() and then send it to a
file or the console using WRITELINE(). Each call to
WRITE(L, stuff)
allocates a little more memory, to accommodate the new text.
However, when you eventually do
WRITELINE(output, L)
the memory pointed-to by L is deallocated (returned to free store)
and L is reset to NULL. This is fine. There is no memory leak.

However, in your original code, you did some WRITE operations
without a final WRITELINE. Consequently, at the end of your
procedure, the line variable points to some memory that has been
allocated to your program. But then your procedure returns, the
line variable goes out of scope, and nothing points to the
memory any more! So the allocated memory is lost. Each time you
call the procedure, a little more memory is lost. There is a
memory leak.

Languages such as 'e' that do automatic garbage collection do
not suffer this problem, but of course they pay a price in
performance.

The correct solution is to be very sure that any local pointer
variables used in your procedure are deallocated before the
procedure returns. A procedure such as WRITELINE does the
deallocation automatically, but in some situations you must
do it for yourself.
--
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.

 

[Mouarf]

could you please put your working code here?



<jo.spreutels@gmail.com> schrieb im Newsbeitrag
news:1116501131.841582.30780@o13g2000cwo.googlegroups.com...

it's working!!!

 

On Wed, 4 May 2005, Tomas wrote:

Hi,

has anybody successfully used this core? What I need to do seems to me
really really simple: configure a couple of settings of a transceiver
(operation frequency, transmitting mode, etc.). I was asked to do this
with a i2c bus.

I'm stuck creating the test bench just to do some read/write test. Has
anybody a simple testbench example?

Help.

Tomas

Hi,

I don't have a test bench but we have used it successfully with
serial Ram, an ultrasonic rangefinder & compass module all on the same i2c
bus.

Synthesised with quartus IIv3.0 to an apex20ke & nios, also to same device
in a 'pure' hardware (no processor) design. The latter was for an
autonomous mobile robot.

There are a couple of gotchas with using it, took a logic analyzer to find
them.

mail me if you need the details.

nigel g.


--
Nigel Gunton Phone : +44/0 117 32 83167 /"\
Senior Lecturer, School of Electrical & Computer Engineering, \ /
CEMS, University of the West of England, Bristol. X
ASCII Ribbon Campaign against HTML email & microsoft attachments / \

 

[Jim Lewis]

Divyang,

if (NEWLINE_p = '1' and NEWLINE_P'event) then
Use 'event only with clocks. They imply connection

to the clock input of a flip-flop.

Better yet if all your clock signals are std_logic, use
the rising_edge function:

if rising_edge(Clk) then

Cheers,
Jim

I've looked over the discussion in the forum on passing signal between
clock domains and read Clifford Cummings paper on asynchronous clock
design and coded a synchronizer circuit.

The problem is the I have a pulse coming in from a slow clock and this
has to be sampled by the fast clk which could lead to the signal being
active for more than 1 clk cycle in the fast clk.
So I've added edge detection in the synchronizer circuit. I think this
should do the trick. Can I get some expert opinion if this is correct
since it seems there is no way to thoroughly test a sync circuit
(easily).

port(
pCLK : in std_logic;
NEWLINE_v : in std_logic;
NEWLINE_p : out std_logic
);
end sync_v2p;

architecture RTL of sync_v2p is
signal stage1fifo,
stage2fifo,
pulsefifo : std_logic;

begin
process(pCLK) is
begin
if (pCLK = '1' and pCLK'event) then

-- perform two stage synchronization
-- as in SNUG2001 paper by Clifford Cummings
stage1fifo <= NEWLINE_v;
stage2fifo <= stage2fifo;

-- add third stage for edge detection
pulsefifo <= stage2fifo;

-- detect edge and assign output
if (stage2fifo = '1' and pulsefifo = '0') then
NEWLINE_p <= '1';
else
NEWLINE_p <= '0';
end if;

end if;
end process;
end RTL;

Also if I don't do edge detection in the sync circuit but use the
following piece of code in my block will it work and synthesize? (just
curious)

if (pCLK = '1 and pCLK'event) then
-- assume synchronizer is only 2 stage
-- and no edge detection is done in synchronizer
-- detect edge here
if (NEWLINE_p = '1' and NEWLINE_P'event) then

...

end if;

I have never seen 'event being used anywhere except for the clk which
is why I am asking this.

Thanks,
Divyang M

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

 

[Jim Lewis]

Neo,
I would not recommend using the stage1fifo for anything.
It is intended for metastable resolution.

If you need glitch suppression, you may need additional
registers in the term like you suggested. When crossing
clock domains, I would not expect need to do this. The
control signal crossing the clock domain needs to come
directly from the output of a register of the other clock
and directly into the registers of this clock domain.

Cheers,
Jim

divyang,
You are just checking for the rising edge of the data but not the
duration. so your output will always be one clock cycle in faster
domain even if the data remains high for multiple clock cycles in the
slower domain. This modification should check for that:
if ((stage2fifo = '1' and pulsefifo = '0') or stage1fifo = '1') then
---
---
However I am not very sure if its good idea to take the 'OR' of
stage1fifo or to put one more FF in faster domain and take its value
for ORING.

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

 

[Martin Thompson]

jo.spreutels@gmail.com writes:

I've tried what you said,but the screen is staying in powersave mode.
Somebody in school told me that it is possible to send the logic signal
straight to the screen.
Thanks for your help!!

Have a look here and see if it helps...
http://www.fpga4fun.com/PongGame.html

I can;t recall - did you simulate and see sync signals that seem to be
the right shape?

Martin

--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

 

[Mike Treseler]

Andy Peters wrote:

So, what's a reasonable workaround?

I put all the testbench procedures between the
IS and BEGIN of the main test process.
This allows you to access any signal in the
testbench architecture without passing parameters.

For an example see:
http://home.comcast.net/%7Emike_treseler/test_uart.vhd

-- Mike Treseler

 

[Jonathan Bromley]

On 19 May 2005 15:07:13 -0700, "Andy Peters" <Bassman59a@yahoo.com>
wrote:

Mike Treseler wrote:
Andy Peters wrote:

So, what's a reasonable workaround?
[for the need to wire-up every signal to any procedure

declared in a package, and related irritations]

I put all the testbench procedures between the
IS and BEGIN of the main test process.
This allows you to access any signal in the
testbench architecture without passing parameters.

Ah, but the "gotcha" in this case is that I want to create a standalone
module -- in this case, it's essentially a signal generator -- that I
can include in my testbench. The idea is that my test bench process
can simply call a "GeneratePattern" procedure in the signal generator
module and have it do its magic.

I found a sorta-solution in Janick Bergeron's book; it's his notion of
"client/server control." I created a global signal (of a custom
"command type") that's twiddled in the main test bench process (the
client), and a process in the signal generator module (the server)
waits on a transaction on that signal. The server parses that command
signal and calls the appropriate procedure.

Yes, but that's a hideous fuss to do something that's essentially
just a remote procedure call.

I hate to say it, but this is one area where Verilog shines; calling
tasks in other modules is as simple as a C function call.

I absolutely agree - although Verilog's cavalier attitude to
process synchronisation (in summary: who cares?!) is a
major problem for anyone who has ever stopped to think about
concurrent programming for more than about five minutes.

There *is* a workaround in VHDL, though it's not ideal.
Suppose you have a general-purpose procedure declared in a
package. Naturally, it has truckloads of signal parameters
to describe all the signals it drives and examines. When
calling this procedure, you are not much interested in these
signal parameters - they're the same every time you call it -
but you do want to be able to parameterise things like
pulse durations, the things that are different from one
call to the next.

So, my preferred solution is to keep the nice-but-clumsy
general-purpose procedure in the package, and then write
a simple jacket procedure inside each process that makes
use of the procedure. The jacket procedure can stitch
signals to the procedure, and it's entirely clear both
to you and to VHDL that the driver on any outputs is the
enclosing process. Better, but far from perfect -
I'd be interested to know if it helps with your issue.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

library ieee;
use ieee.std_logic_1164.all;

package pulsegen_package is
procedure pulsegen (
signal pulse_output: out std_logic;
high_period: in time;
low_period: in time;
pulse_count: in positive
);
end package;

package body pulsegen_package is
-- obvious implementation
end package body;

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

library ieee;
use work.pulsegen_package.all;
use ieee.std_logic_1164.all;

entity testbench is end;
architecture T of testbench is

signal S1, S2: std_logic;

begin

S1_driver: process
procedure pulser(high_period: in time) is
begin
-- General procedure, specialised to deliver
-- single pulses on S1
pulsegen(S1, high_period, 10ns, 1);
end
begin
...
pulser(5 ns);
pulser(10 ns);
...
end process S1_driver;

S2_driver: process
procedure pulsetrain(N: in positive) is
begin
-- General procedure, specialised to deliver
-- a train of 100MHz pulses on S2
pulsegen(S2, 5 ns, 5 ns, N);
end
begin
...
pulsetrain(15);
...
end process S2_driver;

end architecture T;

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

 

[Jonathan Bromley]

On 20 May 2005 02:53:29 -0700, "john Doef" <john_doef@yahoo.com>
wrote:

Jonathan Bromley a écrit :
[...]
However, when you eventually do
WRITELINE(output, L)
the memory pointed-to by L is deallocated (returned to free store)
and L is reset to NULL. This is fine. There is no memory leak.
Huu, this is not what the LRM says.

LRM says:
Procedure WRITELINE causes the current line designated by parameter L
to be written to the file and returns with the value of parameter L
designating a null string.

If L designates a null string, it is not reset to NULL.

You're right, and I was careless. Sorry.

My point about the memory leak remains valid. But of course
there is an important difference: a LINE that designates a
null string has attributes such as 'LENGTH, but if you set
an access variable to NULL and then try to examine its
attributes you will get a bad-pointer error.

Thanks for the clarification.
--
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.

 

[Brad Smallridge]

Thanks Nicolas. That seems the best.

if segment_pointer_count = (segment_pointer_count'range => '1') then
segment_pointer_count <= (0 => '1', others => '0');
else
Nicolas

 

[Ralf Hildebrandt]

samsky electronique wrote:

process(sig1,sig2,A,B,C)
begin
if (A > "001" and B > "010") then
sig1 <= '1';
else
sig1 <= '0';
end if;

if (C > "011" and sig1 = '0') then
sig2 <= '1';
else
sig2 <= '0';
end if;

end process;

It this advisable to write code like this, or should sig1 be in a
different process.

I would suggest to use a 2nd process for sig2, because to avoid
unnessecary computation for the simulator.

If signal A changes, the simulator has to evaluate the if-condition for
sig2 too, but this is a waste of computation.

The test for sig1 = '0' tests always the /old/ value of sig1. If sig1
has changed, sig2 will not be updated in the same simulator step. But
this does not lead to problems, because the sensitivity list is complete
and therefore the process is trigered again after sig1 has changed und
then the if-condition for sig2 ist evaluated using the new correct value
for sig1.

-> It is not wrong to code it so, but may be misleading if you read the
code later and leads to unnessecary computation of the simulator.


Ralf

 

[Eyck Jentzsch]

swiss student wrote:

hello every one

There are 10 states in my design,the next state depends on more than
one inputs.Now when i compile my code it gives me error as no feasible
entries

the code is as follows
ENTITY YYYY IS
port(
clk : IN std_logic;
rst : IN std_logic;
M1_IN,M2_IN,M3_IN,M4_IN,M5_IN : IN std_logic;
M6_IN : IN work.mux_range.sel_range
M1_OUT,M2_OUT,M3_OUT,M4_OUT,M5_OUT: OUT std_logic;
M6_OUT :OUT work.mux_range.sel_range);

END ENTITY;

The part of the of code for calculating the next state is as follows

when s4=
IF (M5_IN='0' and M6_IN = '4') THEN
^^^^^^^^^^^^

M6_IN is of type work.mux_range.sel_range so the compiler does not know,
how to interpret the '4' (neither the newsgroup does since you did not
provide the definition).

next_state<= s5;
else
next_state<=s4;
END IF;

can some one tell if there is some prob in this code

please let me know wat changes i need to make

suresh

-Eyck

 

[Steffen Netz]

Hi Steve,

this a trap of VHDL, because the assert statement tests on false Condition!
You can write :

assert NOT(((DATA_BUS(master_bit)) = (this_case(0))));
^
or assert ((DATA_BUS(master_bit)) /= (this_case(0)));
^

regards,

Steffen

Steve J wrote:

Hi,

I'm currently getting a strange message from my testbench output that
says

"Error: Master Selection : Test case 5 failed. Master bit was '1' but
should have been '1'"

This is generated using the following:
assert ((DATA_BUS(master_bit)) = (this_case(0)));
report "Master Selection : Test case " & integer'image(I) & " failed.
Master bit was " & std_logic'image(DATA_BUS(master_bit)) & " but should
have been " & std_logic'image(this_case(0))
severity error;

Why is this?
master_bit is an integer, DATA_BUS is a 16 bit std_logic_vector input
to my procedure and this_case is a 4-bit std_logic_vector

What I don't understand is why the comparison after the assert is false
when printing the two bits out in the report they look the same.

All suggestions appreciated

Steve

 

[Steffen Netz]

Hey,

assert rises the message if the condition is "true" !!!

assert true
report "I'm here"

gives I'm here

assert false
report "I'm here"

gives -
( Nothing ) !!!

Steffen

Steve J wrote:

I appreciate that assert reports an error on a false condition. That's
not what is confusing me as I've tried adding a not and the same thing
happens.

In the report statement I'm using the 'image to output the value of the
two sides of the comparison.

What I don't understand is why if both sides of the '=' are the same,
why is the rest of the report/severity bit being triggered. Surely '1'
= '1' is true and hence I wouldn't get a message.

Steve

Steffen Netz wrote:
Hi Steve,

this a trap of VHDL, because the assert statement tests on false Condition!
You can write :

assert NOT(((DATA_BUS(master_bit)) = (this_case(0))));
^
or assert ((DATA_BUS(master_bit)) /= (this_case(0)));
^

regards,

Steffen

Steve J wrote:
Hi,

I'm currently getting a strange message from my testbench output that
says




"Error: Master Selection : Test case 5 failed. Master bit was '1' but
should have been '1'"

This is generated using the following:
assert ((DATA_BUS(master_bit)) = (this_case(0)));
report "Master Selection : Test case " & integer'image(I) & " failed.
Master bit was " & std_logic'image(DATA_BUS(master_bit)) & " but should
have been " & std_logic'image(this_case(0))
severity error;

Why is this?
master_bit is an integer, DATA_BUS is a 16 bit std_logic_vector input
to my procedure and this_case is a 4-bit std_logic_vector

What I don't understand is why the comparison after the assert is false
when printing the two bits out in the report they look the same.

All suggestions appreciated

Steve

 

[Mariusz]

Steve J wrote:

I've replaced the statement causing me problems with

assert true;
report "......

and I still get the error messages.

Why would an assert statement always trigger? The assert is in a
procedure in a package. Would that cause problems?

TIA

Steve

Try removing the ; after assert. It executes a null command and the

report works always.