Clock Edge notation

[Steffen Netz]

....

Steffen,
Are you saying that in correct VHDL the error message is printed when
the condition is true? That's not what I've understood from other
sources.
http://www.acc-eda.com/vhdlref/refguide/language_overview/test_benches/using_assert_statements.htm

Steve

I'm so stupid, that's when you have to work in Verilog for a while.
You are so right,
Sorry,

Steffen

 

[Mariusz]

Steve J wrote:

Mariusz,

Thanks for that. That appears to have solved it.
I'm surprised that isn't picked up by a syntax checker when I compile
the code.

Steffen,
Are you saying that in correct VHDL the error message is printed when
the condition is true? That's not what I've understood from other
sources.
http://www.acc-eda.com/vhdlref/refguide/language_overview/test_benches/using_assert_statements.htm

Steve

Steve,

No compiler should complain. That's what LRM reads. All sections are
optional so assert alone is perfectly OK.

Mariusz

 

[Ralf Hildebrandt]

killerhertz@gmail.com wrote:

I'm trying to create an entity with 'width' bits in and 'nbits'x'width'
bits out. I'm trying to use an unconstrained array to do this, but I'm
getting compile errors...

entity srsipo is
generic (
nbits : integer;
width : integer
);
port (

---------------------------------------------------------------------------
-- input
------------------------------------------------------------------
rst_na : in std_logic;
clk : in std_logic;
din : in std_logic_vector(width-1 downto 0);
-- output
-----------------------------------------------------------------
dout : out array (width-1 downto 0)
of std_logic_vector(nbits-1 downto 0)

---------------------------------------------------------------------------
);
end srsipo;

You have to define a type, that will be used for dout. At the moment,
you try to define a type AND use it at the same time. The type should be
defined in a package.



Remember: Old synthesis tools may not support 2D (or higher order)
arrays. Additionally, if this is a component, that is at top level of
the hierarchy and therefore dout will be connected to a pin it is also
not so good, to use an array type. -> Think about breaking it down to a
1D-array with the length of width*nbits.

Ralf

 

[aaaaaa]

Hi Suresh,
U are checking the value of M6_in as 4 but u have declared as some other
type. Kindly match the both , I hope that problem will be resolved.
Rgds
Anupam Garg

 

[aaaaaa]

Hi,
Yes, u can assign the two signals in a process but the difference will be
like as---
value of sig1 will be updated when the process is ended and so the last
sig1 value will be checked on the same process.
rgds
Anupam Garg

 

[Alvin Andries]

"Nemesis" <nemesis2001@gmx.it> wrote in message
news:1117097644.162234.64010@o13g2000cwo.googlegroups.com...

I'm trying to write a signed Multiplier in VHDL.
I wrote the code and synthesized it with ISE6.3 but it is to slow
for what I need, the synth. report says that the maximum clock speed
is 84MHz on a xcv2p50-5 target, I'd need something close to 128 MHz.
I also found some odd things, the report say that the XST inferred
4 MULT18x18s blocks, but I would have expected that 2 block were
sufficient.
Moreover the clock pin of the MULT18x18s block is unconnected (or at
least it seems to be looking at the "RTL Schematic View"), so why it
didn't used a simple MULT18x18 (asynchronous)?

Here is the VHDL code I wrote, please let me know if you have ideas
to improve the speed.

**********************multiplier.vhd*******************************
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity multiplier is
port (
A : in std_logic_vector(23 downto 0);
B : in std_logic_vector(23 downto 0);
CLK : in std_logic;
RESET : in std_logic;
MULT : out std_logic_vector(47 downto 0)
);
end multiplier;

architecture Behavioral of multiplier is
signal A_signed : signed (A'high downto 0);
signal B_signed : signed (B'high downto 0);
begin
----------------------------------------------------------------
process (CLK,RESET,A,B)
--variable A_signed : signed (A'high downto 0);
--variable B_signed : signed (B'high downto 0);
variable MULT_signed : signed (A'high+B'high+1 downto 0);
begin
if RESET='1' then
MULT <= ( others => '0');
elsif rising_edge(CLK) then
A_signed <=signed(A);
B_signed <=signed(B);
MULT_signed := A_signed * B_signed;
MULT <= std_logic_vector(MULT_signed);
end if;
end process;
----------------------------------------------------------------
end Behavioral;
**********************multiplier.vhd*******************************

Hi,

Just a note: the asynchrounous clear of your multiplication will prevent the
use of the pipelined Xilinx multipliers because their register has only a
synchrounous reset.

Kind regards,
Alvin.

 

[Srinivasan Venkataramanan]

Hi,

"Steve J" <sjeapes@gmail.com> wrote in message
news:1117023376.247744.42860@g47g2000cwa.googlegroups.com...

Mariusz,

Thanks for that. That appears to have solved it.
I'm surprised that isn't picked up by a syntax checker when I compile
the code.

Perhaps you had a VHDL-93 mode turned ON (or is the default in your
compiler). report alone was allowed in VHDL-93, so if you wanted your
compiler to error out, use 87 - I wouldn't recommend that though.

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

 

[Ralf Hildebrandt]

killerhertz@gmail.com wrote:

You have to define a type, that will be used for dout.
I'm not sure I understand. Why do I have to define a type for dout?

At the moment, you try to define a type AND use it at the same time. The type should be defined in a package.
Where am I defining a type for dout? I'm using a standard array of type
std_logic_vector for the output port declaration...

"a standard array of type std_logic_vector" ist not a type. This is a thing, that declares
a type.

Besides, if I put a
type in my local package, the top level won't be able to see what the
type definition is, right?

No - the definition is visible, because the package is included with the

library my_lib;
use my_lib.my_package.all;

before the entity.

I'm not too worried about synthesis and it's hard to see how things are
working when dealing with an enormous vector, i.e. my length*width =
1KB.

The problem is not the length of the vector, but if your signal is one- or two-dimensional
(if you have an older synthesis tool).


Ralf

 

[Squidge]

ranjeet.gupta@gmail.com wrote in
news:1117057284.587389.41720@g44g2000cwa.googlegroups.com:

I have to learn about the ARM processor, Please Guide me with the
links
and the documentation where i can find the materials on the arm
processor.

Documentation: http://www.arm.com/documentation/
Compiler: http://devkitpro.sourceforge.net/index.shtml

 

[Ralf Hildebrandt]

Brandon wrote:

I understand that the package includes the type, but since I am using a
generic, how is the package going to know how to constrain the
std_logic_vector?

The package has to define the array in an unconstrained way and in your entity the
constraints will be set.

-- type ARRAYSTDLV_T is array(natural range <&gt of
std_logic_vector(natural range <>

But I get a compile error on the first type (commented out now). I did
some searching and it seems I can't do that.

I'm not shure if it is possible and don't have a VHDL compiler at hand, but what about

type ARRAYSTDLV_T is array(natural range <&gt of std_logic_vector;

AFAIK this will result in in unconstrained array of an uncontrained std_logic_vector.

Some usenet threads on
this area suggested using an unconstrained array of type bit, as I have
written above, which compiled and simulated correctly.

I can't remember the reason, but I was always told by profs to avoid
use of bit and bit_vector for synthesis, and not to mix my designs with
std_logic_vector and bit_vector. Is this true?

Yes, I have read such thing too and I guess it is because bit does not have something like
'X' and therefore simulation may be different than synthesis.

I have both Ashenden's Designer's Guide and Cohen's book, but neither
seem to mention how to create generics with 2d ports in this manner

This is because it is rare to have an array in an entity, as usually this will result in
many wires and this leads to huge designs.

I want to write realy solid, reusable VHDL
here. How is this issue addressed in practice? Bit arrays seem like a
'hack'?

Again I will suggest to use a 1D array of size width*nbits. ;-)

Ralf

 

[Egbert Molenkamp]

I added two examples:

I added two example processes. Process no_problem assigns a value to b and
in the next delta that value is assigned to c.
In hardware this would result in a wire between a,b and c. No problem!

The next process, comb_loop, is more complicated. b is assigned the value of
a (after a delta). In the next delta a is assigned the inverse of b.
This will not be stable during simulation (assuming initial vlaue is
'0'/'1'). Synthesis will result in a combinational loop (output of inverter
connected with the input).

no_problemrocess(a,b)
begin
b<= a;
c <=b;
end process;

comb_looprocess(a,b)
begin
b<=a;
a<=not b;
end process;

Egbert Molenkamp

"googler" <pinaki_m77@yahoo.com> schreef in bericht
news:1117428397.874853.285270@o13g2000cwo.googlegroups.com...

I have a process like below.

alu: process (ain, bin, sel, cinflag)
begin
...
end process alu;

Inside this process, it is modifying another signal cout based on the
values of the parameters. Basically, cout <= ain (op) bin. When the
signals ain and cout are identical, this ends up invoking the process
again (since the value of ain in the sensitivity list changes). How can
I prevent this from happening?

Thanks in advance.

 

[james]

On 26 May 2005 03:48:05 -0700, "Nemesis" <nemesis2001@gmx.it> wrote:

I also saw that if I use luts instead of MULT18x18 the speed is higher,
is there a way to obtain a lut based multiplicator without using the
Core?
*****

Check constraint guides for the particular FPGA. In the Virtex line,
Xilinx allows the selection of auto, block, or Lut. Not sure about the
Spartan 3. In the Spartan 2 all multipliers are lut based.

james

 

[Duane Clark]

M. Norton wrote:

I think I've found the answer and I thought I would post it back to the
thread, if for no other reason than maybe it'll help someone else who
searches google for that particular warning. (I did originally before
posting and did not find this answer.)

The explicit D and Q style was one I adopted from my previous employer.
As I said it worked well for the Actel devices, and as they did a lot
of ASIC work and used the same style, it worked well for the ASICs.
However, for Xilinx, it seems like it is overly complex. In an effort
to *demand* explicit rendering of a combinatorially sourced D input and
a sequential Q output, the Xilinx synthesizer misses out on some of the
shortcuts within it's own architecture.

I think you missed the source of the problem. Let's take a look at your
previous (pseudo)code:

if there's a new command strobe and if the address is right and if
the command says to write register then
if the data for the register is A then
signal_d <= '0';
clock_en <= '1';
else if the data for the register is B then
signal_d <= '1';
clock_en <= '1';
else
clock_en <= '0';
end if
end if

Notice that in the else statement, you don't assign anything to
signal_d. So therefore, the previous value cannot change, regardless of
what any other signals are doing. Therefore the data must be latched.
You even explicitely did this in the original code:
else
signal_d <= signal_q; -- if there's nothing going on, hold last

This code is not illegal, but it is bad design practice. I am pretty
sure that Actel in fact created a latch around the mux, which is easily
done. Actel (at least the Act1 and Act2 families that I am familiar
with) always uses the mux to create a latch, since the S module is edge
triggered. So your code simulated and worked correctly, but I am
guessing you never realized you were creating a bunch of latches. If the
Actel tools did not create a latch, then they are broken

And as for the old coding style, definitely get rid of it. Your new
style is vastly better. About the only thing I would suggest is instead of
elsif (clk'event and clk='1') then
use
elsif rising_edge(clk) then
But then again, that is just my preference; I think it is less cluttered.

 

[Mike Treseler]

Analog_Guy wrote:

ModelSim asserts a HOLD violation WARNING on my structural (post fit)
simulation, on a node internal to my design.

Lattice ispLEVER static timing analyzer specifies an Fmax (86 MHz)
which far exceeds my operating frequency (60 MHz). How can I get a
hold violation on an internal node?

The most common way is by not using a low-skew
network for the system clock. Check how "clk"
is distributed. Since your design is synchronous,
the static timing analysis result makes the testbench
timing result suspect. The design is working, right?

1. Does this appear to be a "design" problem, or a simulator problem
(i.e. delta cycles, etc.)?

I expect you have a backannotation or testbench error.
Does the same testbench work ok for the functional test?
Why are you using a timing simulation in the first place?

2. Is the style of checking for a zero count in the counter process,
and then performing a signal assignment to zero a cause for concern?

It's just poor style, since the assignment has no effect.

3. Is there a problem of using integers to define my counter pre-load
and trip points, or should everything be expressed in std_logic_vector?
It just seemed more intuitive to use integers.

That's fine.

4. In the second process, does the IF ... ELSIF ... ELSIF provide a
source for concern? The different counter settings are mutually
exclusive, so is it better to use independent IF ... THEN ... END IF
for each of the 3 conditions?

Wouldn't make any difference if the logic were the same.
A CASE might look cleaner.

5. In the second process, is there a problem in making a comparison of
the std_logic_vector counter to an integer value (i.e. ELSIF (counter =
0) )?

No, but the description might be easier to follow
if you combined the two processes into one.

-- Mike Treseler

 

[Analog Guy]

Thanks for the reply.

"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:3g488fFak26uU1@individual.net...
The design is working, right?

Yes, the design is working, but I am still worried about eliminating this
hold problem.

Does the same testbench work ok for the functional test?

Yes. I have no problems with functional simulation, and up until the device
has filled up, I had no problems
with the structural simulation. One thing to note is that the d-inputs of
the counter do tend to glitch
occasionally (i..e. when passing through the zero condition), but shouldn't
have any effect on the q outputs.

Why are you using a timing simulation in the first place?

As far as I was aware, that is the only way to verify the "physical" device
in the simulator, and to achieve a good
degree of confidence before going to the lab. By using the SDF delays, you
get a worst-case representation of the
timing. I realize the sims take orders of magnitude longer to run, but you
get a dynamic representation of your device
performance. Are you suggesting to use only the static timing analysis?

2. Is the style of checking for a zero count in the counter process,
and then performing a signal assignment to zero a cause for concern?

It's just poor style, since the assignment has no effect.

How would I correct the poor style? I would like to make the code as
logical and readable as possible. Are you
suggesting one of the following would be better:

1. IF (counter = 0) THEN
counter <= NULL;
ELSE
counter <= counter - '1';
END IF;


2. IF (counter /= 0) THEN
counter <= counter - '1';
END IF;


Or is there a better way to define this counter? I use a similar style when
coding a free-running
counter, only I pre-load on the zero condition instead of assigning to zero.
I thought this assignment
to zero was just an extension of the free-running condition?

 

[sk_effect]

Please refer this paper for CRC-16 single bit error correction
implementation in hardware. Its a highly optimized and time efficient
method.

http://www.itee.uq.edu.au/~sunil/publications.htm

Cheers,
Sunil

 

[Mike Treseler]

Analog Guy wrote:

Thanks for the reply.

You are welcome.

One thing to note is that the d-inputs of
the counter do tend to glitch
occasionally

That's fine.

As far as I was aware, that is the only way to verify the "physical" device
in the simulator, and to achieve a good
degree of confidence before going to the lab.

That is debatable, and the debate has occurred here many times.

By using the SDF delays, you
get a worst-case representation of the
timing. I realize the sims take orders of magnitude longer to run, but you
get a dynamic representation of your device
performance. Are you suggesting to use only the static timing analysis?

Functional simulation *and* synchronous design *and* STA.

That is up to you.

I use timing sims only to test tools,
not to test FPGAs or synthesis code.

Note that STA assumes that
all inputs are synchronized to the fpga clock,
and that no asynchronous logic is used in the design.

How would I correct the poor style?

2. IF (counter /= 0) THEN
counter <= counter - '1';
END IF;

That looks much cleaner to me.



-- Mike Treseler

 

[Duane Clark]

Analog_Guy wrote:

DEVICE:
Lattice ispMACH4256V CPLD

I tried to download the datasheet, but Lattice wants me to register to
do that. So forget it.

Mainly:
1. Does this appear to be a "design" problem, or a simulator problem
(i.e. delta cycles, etc.)?

It is possible that in certain configurations in a CPLD, there is a hold
time requirement. I certainly ran into this in some small Actel devices.
Does the datasheet show any hold time requirements for the internal
registers or whatever is in the ispMACH?

...
PROCESS (reset, clk)
BEGIN
IF (reset = '0') THEN
OUT_A <= '0';
OUT_B <= '0';
OUT_C <= '1';
ELSIF (clk = '1' AND clk'EVENT) THEN
IF (counter = trip_1) THEN
OUT_A <= '1';
ELSIF (counter = trip_2) THEN
OUT_B <= '1';
ELSIF (counter = 0) THEN
OUT_C <= '0';
END IF;
END IF;
END PROCESS;

Hmm.. it appears that the only way for OUT_A/B/C to get set back to
their original values is via an asynchronous reset. Where does this
reset come from? That may be the source of your problem.

 

[Mariusz]

vedpsingh@gmail.com wrote:

Hello all,

I downloaded the following packages from www.eda.org/fphdl

fphdl_base_pkg.vhd - Base package (named "fphdl_base_pkg")
fphdl_base_pkg_body.vhd - Base package body (synthesizable)

This package uses fixed_pkg . Which I downloaded from
http://www.eda.org/vhdl-200x/vhdl-200x-ft/packages/files.html

When I compiled the fixed_pkg package declearation, it gave following
errors

#Error: COMP96_0122: fixed_pkg.vhd : (812, 3): Symbol
"to_StdLogicVector" has already been declared in this region.
# Error: COMP96_0122: fixed_pkg.vhd : (813, 3): Symbol
"to_Std_Logic_Vector" has already been declared in this region.
# Error: COMP96_0122: fixed_pkg.vhd : (912, 3): Symbol "bwrite" has
already been declared in this region.

On googling for the above error I got a message at this link
http://www.electronic2.com/detail-10095547.html
which said to remove the ALIAS in the package declearation. It worked.

Again when i compiled the body of the fixed_pkg , for lines of this
kind :---

constant NAU : UNSIGNED(0 downto 1) := (others => '0');

following warnings came----

warning: COMP96_0119: fixed_pkg_body.vhd : (2610, 37): The range is
"null range".

When I changed the line to :----

constant NAU : UNSIGNED(0 to 1) := (others => '0');

the warning disappeared.

Now my questions are :

(1) why those ALIAS were kept there??? Were they kept there
delibrately.

(2)Does this below mentioned statement make any sense ?? what is (0
downto 1) ???
constant NAU : UNSIGNED(0 downto 1) := (others => '0');

(3) I want to use fphdl package to get a synthesisable LOG function in
my VHDL. Is there a better method for it, or am on right track ??

with regards
ved

Ved,

There were some issues with VHDL compiler and have been resolved now.
Contact Aldec support http://support.aldec.com to obtain an update that
will solve your compilatin problems.

Regards,
Mariusz

 

[David Bishop]

vedpsingh@gmail.com wrote:

Hello all,

I downloaded the following packages from www.eda.org/fphdl

fphdl_base_pkg.vhd - Base package (named "fphdl_base_pkg")
fphdl_base_pkg_body.vhd - Base package body (synthesizable)

This package uses fixed_pkg . Which I downloaded from
http://www.eda.org/vhdl-200x/vhdl-200x-ft/packages/files.html

When I compiled the fixed_pkg package declearation, it gave following
errors

#Error: COMP96_0122: fixed_pkg.vhd : (812, 3): Symbol
"to_StdLogicVector" has already been declared in this region.
# Error: COMP96_0122: fixed_pkg.vhd : (813, 3): Symbol
"to_Std_Logic_Vector" has already been declared in this region.
# Error: COMP96_0122: fixed_pkg.vhd : (912, 3): Symbol "bwrite" has
already been declared in this region.

I hit this one too when I was doing regression with Aldec. They
have fixed it.

On googling for the above error I got a message at this link
http://www.electronic2.com/detail-10095547.html
which said to remove the ALIAS in the package declearation. It worked.

Again when i compiled the body of the fixed_pkg , for lines of this
kind :---

constant NAU : UNSIGNED(0 downto 1) := (others => '0');

following warnings came----

warning: COMP96_0119: fixed_pkg_body.vhd : (2610, 37): The range is
"null range".

When I changed the line to :----

constant NAU : UNSIGNED(0 to 1) := (others => '0');

the warning disappeared.

These warning need to be there. The problem is that it is really easy
to pass a null array to something with had both a positive and negative
index. I have special traps in the code to check for these. Thus leave
it the way it was and ignore the warning.

Now my questions are :

(1) why those ALIAS were kept there??? Were they kept there
delibrately.

Yes, they were put there delibrately. That way you only need one
function. Once again, this is an Aldec bug, which they have now fixed.

(2)Does this below mentioned statement make any sense ?? what is (0
downto 1) ???
constant NAU : UNSIGNED(0 downto 1) := (others => '0');

This is a null array. If you pass a null array into a function I need
to pass one out, so I defined it here. Note that this is the same
constant that is in "numeric_std".

(3) I want to use fphdl package to get a synthesisable LOG function in
my VHDL. Is there a better method for it, or am on right track ??

Do you really need a Log? Ln is much simpiler, and there is an example
of both in the "fpalg_base_pkg". It it is a Log2 then it is even
simpiler. you can do this:
ln2 := find_msb (x, '1');