Clock Edge notation

Philipp wrote:

Now the question is if it is okay to leave it this way and let the
synthesizer do the work
It never bothers me to let the synthesizer
earn some of its license fees.

-- Mike Treseler
 
On 7 Feb 2005 00:32:33 -0800, jahaya@gmail.com wrote:

It appears that you just want a counter with a certain terminal count
rather than a general mod operation.

Try changing:

count_mod <= (count_mod+1) mod 176;

to:

if count_mod < 175 then
count_mod <= count_mod+1;
else
count_mod <= 0;
end if;

This should do the same thing, assuming that count_mod never exceeds
175.


BTW, avoid using type 'natural' for synthesis. This may produce a 32
bit value, unless the synthesiser is particularly clever. It is
better to use a constrained range, or perhaps an unsigned of
appropriate width.

Regards,
Allan
 
Tristan Gingold <tgingold@no.spam.free.fr> wrote in message news:<cu5hbm$91b$1@aphrodite.grec.isp.9tel.net>...
No, it is because you are enclosing the name within parenthesis. Then
the expression is not a name anymore, and its type is the base type.

A parenthesis expression is not a name, that the reason of the error.

Tristan.
Thank you.

Once the parenthesis were removed, the warning message did not appear.

Calvin
 
I dont know what vhdl-93 has to do with it but its not possible. There
is no indication of how many bits and which to assign to sample_out.
 
On 8 Feb 2005 03:37:06 -0800, "Neo"
<zingafriend@yahoo.com> wrote:

I dont know what vhdl-93 has to do with it
VHDL-93 fixed an oversight in VHDL-87...
* '87 allowed a function with a single argument to appear
in a port map
* '93 very sensibly extended that to permit an array type
conversion, which looks and behaves rather like a
function call

but its not possible. There is no indication of how
many bits and which to assign to sample_out.
I agree that the LRM appears to forbid this, in
section 3.2.1.1.
--
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 wrote:

but its not possible. There is no indication of how
many bits and which to assign to sample_out.

I agree that the LRM appears to forbid this, in
section 3.2.1.1.
Modelsim agrees.
It compiles fine, but elaboration is impossible.

-- Mike Treseler
______________________
65 steptoe Tue Feb 08 > vcom -93 unconstrained.vhd
65 steptoe Tue Feb 08 > vsim -c add_unconstrained
Reading /steptoe/usr1/modeltech/tcl/vsim/pref.tcl
# 5.8c
# vsim -c add_unconstrained
# // ModelSim SE 5.8c Mar 01 2004 Linux 2.6.8-24.10-default
# Loading /steptoe/usr1/modeltech/linux/../std.standard
# Loading /steptoe/usr1/modeltech/linux/../ieee.std_logic_1164(body)
# Loading /steptoe/usr1/modeltech/linux/../ieee.numeric_std(body)
# Loading work.add_unconstrained(rtl)
# ** Fatal: (vsim-3347) Port 'sample_in1' is not constrained.
# Time: 0 ns Iteration: 0 Instance: /add_unconstrained File:
/evtfs/home/tres/vhdl/play/unconstr.vhd
# FATAL ERROR while loading design
# Error loading design
Error loading design
 
Hi,
Let me start with the disclaimer that my VHDL know-how is *rusted* and am
trying to understand this better.

From LRM, 3.2.1.1, I find closest matching text as (slightly edited):
------- LRM
For a formal port of a design entity that is of an unconstrained array type
and that is associated in whole, the index ranges are obtained from the
corresponding association element in the port map aspect of the applicable
(implicit or explicit) binding indication.

-------- LRM

So I wonder why "sample_out" (formal) can't derive its range from
"Asample_out : OUT std_logic_vector(7 DOWNTO 0)" - the actual.

It is also puzzling to me that the same works for the "sample_in1" (and 2).

To me it looks like it is legal!

Thanks,
Sri


--
Srinivasan Venkataramanan
Co-Author: SystemVerilog Assertions Handbook, http://www.abv-sva.org
Co-Author: Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition.
http://www.noveldv.com
I own my words and not my employer, unless specifically mentioned
 
a wrote:
Have you tried an instantiation with two 7-bit counters?
The top_count_bad code looked fine to me, but the synthesis error
points
to the count_ud component (and hence source). I think you may need
to
dig one level of hierarchy deeper.
The lower level module, count_ud.vhd, compiles and synthesizes fine by
itself.
The problem is when the top module overrides the WIDTH value in either
(or both) of the lower level module.

It isn't so much that I need to get this working - I can find ways to
get around this problem for now. I, however, would really like to know
how to take advantage of 'resuability' with generics
 
I thought vectors were not treated as arrays. anyway the approach below
gets over it.
with changes as below (Asample_out_tmp is a signal declared as
unsigned).
sample_in1 => Asample_in1_tmp,
sample_in2 => Asample_in2_tmp,
sample_out => Asample_out_tmp
--std_logic_vector(sample_out),
);
Asample_out <= std_logic_vector(Asample_out_tmp);
 
Allan Herriman wrote:

Top level ports (i.e. those that actually end up being pins on your
chip) should be std_logic or std_logic_vector (with descending range,
e.g. 7 downto 0). This will match the gate level VHDL or Verilog that
the back end tools spit out, allowing you to swap between RTL and gate
level representations in your test bench.
std_ulogic is also a good candidate
for top in and out bit ports.
It matches std_logic in port maps without
conversion and gives you drive error
detection for free at compile time.

-- Mike Treseler
 
"Calvin" <profpenguin@shaw.ca> wrote in message
news:c556d654.0502071016.ed5bb39@posting.google.com...
Tristan Gingold <tgingold@no.spam.free.fr> wrote in message
news:<cu5hbm$91b$1@aphrodite.grec.isp.9tel.net>...
No, it is because you are enclosing the name within parenthesis. Then
the expression is not a name anymore, and its type is the base type.

A parenthesis expression is not a name, that the reason of the error.

Tristan.

Thank you.

Once the parenthesis were removed, the warning message did not appear.
Why do parenthesis turn a variable into a non-(locally static subtype)?
I sure would like to understand this a little better.
Thanks in Advance,
Doug
 
Toby wrote:
I tried to add the tic thing, but it didnt seem to help. The procedure
posted earlier was simplified a bit. Here is the complete procedure
(including the tic call):
Yikes. Consider a synchronous testbench
using tic;tic;tic; instead of wait for 30ns;

Do you have a clock and reset process working
out through to the uut in and out signals?
Get this working first.

Do you have some base process wrapped around
the procedure declarations run the show?


-- Mike Treseler

___________________
main : process is
<declarations>
constant reps : natural := 16;
begin -- process main
init;
for i in 1 to reps loop
timed_cycle;
end loop;
for i in 1 to reps loop
handshake_cycle;
end loop;
coda;
end process main;
end architecture sim;
 
Well, reading the topic on the reset signal below, I think generating a
synchronous start (sync'd on the rising edge of sys_clk, which means it
will also be sync'd with the rising edge of the fast_clk at T11) might
be a better idea.

But then, now my concern is that the start signal (if generated at T11)
will be seen by processes dependent on sys_clk at T21 and by processes
dependentent on fast_clk at T12. Therefore the start will again not be
aligned at Tx1. Here I am assuming that a signal generated at the
rising edge of a clk will only be seen by other processes at the next
rising edge. Is this true? OR Are the signals available
instantaneously?
 
Can somebody either post, or tell me EXACTLY where to find a nice, BIG,
COMPLETE, good, testbench example with all this stuff you guys are
talking about? Several examples would be even better, but all this
stuff you guys are showing me is just pieces, and I'm having a little
trouble seeing the overall picture of a good testbench design. Thanks!

-Toby
 
cant say for sure but check if you have completely defined the type and
range for UFix and it is visible to the function.
 
Phil Tomson wrote:
Here's the error:

Analyzing Entity <csvm> (Architecture <synth_csvm>).
ERROR:Xst:829 - C:/phil/vhdl/svm/../fix_std.vhd line 1382: Constant Value
expected for Generic 'U'.


Here's the offending line:
Copy_V(F, N, overflow, rounding);
The error is about a generic. The line above does not contain a generic.
Seems to me that the line number in your error message is wrong.

Look in your code and try to locate where you declare and/or use generic
U (in an entity declaration or component instantiation).

Paul.
 
In article <cuusld$spu$1@voyager.news.surf.net>,
Paul Uiterlinden <no@spam.nl> wrote:
Phil Tomson wrote:
Here's the error:

Analyzing Entity <csvm> (Architecture <synth_csvm>).
ERROR:Xst:829 - C:/phil/vhdl/svm/../fix_std.vhd line 1382: Constant Value
expected for Generic 'U'.


Here's the offending line:
Copy_V(F, N, overflow, rounding);

The error is about a generic. The line above does not contain a generic.
Seems to me that the line number in your error message is wrong.

Look in your code and try to locate where you declare and/or use generic
U (in an entity declaration or component instantiation).
I did a `grep -i generic *.vhd` and nothing comes up in that code (there
is a testbench that has some, but it's not included in the ISE project).
That's what's strange about the error.

It would be nice if the Xilinx tools could synthesize a fixed point
package - so far I've tried two synthesizable (with other tools) fixed point
packages and it chokes on both, but for different reasons.

Phil
 
Yes that is a very interesting example. It has completely changed the
way I write testbenches, and I suspect it will also change the way I
write my VHDL design files. Thank you Mike! Does anyone else have any
COMPLETE testbench examples they can show me? I just love examples!
Thanks again Mike, your the best!

-Toby
 
Hello Charles,

I really appreciate your help with the syncronisation of the start
signal.
I tried your first suggestion (becuase the start signal stays active
throught)
and it seems to work.

Thank you,
Divyang M.
 
it prevents double output registers.
I will fill in the info files next week.

-- Mike Treseler
 

Welcome to EDABoard.com

Sponsor

Back
Top