Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 150175

Article: 150175
Subject: some VHDL error
From: Santosh <santos2k7@gmail.com>
Date: Sat, 25 Dec 2010 22:33:20 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,
 I know this is a dumb question, asking to decode some error directly.
 I got the following error,

" Aggregate expression cannot be scalar type
ieee.std_logic_1164.std_logic"

and the code is

"parrout(7 downto 0)   =>   dataout_2(7 downto 0),".

Article: 150176
Subject: Re: some VHDL error
From: "maurizio.tranchero" <maurizio.tranchero@gmail.com>
Date: Sun, 26 Dec 2010 01:25:52 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 26, 7:33=A0am, Santosh <santos...@gmail.com> wrote:
> Hi,
> =A0I know this is a dumb question, asking to decode some error directly.
> =A0I got the following error,
>
> " Aggregate expression cannot be scalar type
> ieee.std_logic_1164.std_logic"
>
> and the code is
>
> "parrout(7 downto 0) =A0 =3D> =A0 dataout_2(7 downto 0),".

Hi Santosh,

First: when you provide a sample of code, please do include also the
signal definition.

Second: when reporting an error tell us also the compiler you are
using.

Third: some compilers do not allow the usage of ranges on left and
right operands during
assignments. If parrout is defined as 7 downto 0, you can try with
defining a simple signal
called dataout_2_7dt0 and write two separate assignments:

dataout_2_7dt0 <=3D dataout_2(7 downto 0);
...
parrout(7 downto 0)   =3D>  dataout_2_7dt0,

In case parrout is not only 7 downto 0, but wider, you should use a
temporary signal

signal temp_parrout : std_logic_vector( N-1 downto 0 ); -- with N=3D the
actual width of parrout

temp_parrout <=3D "00000000" & dataout_2(7 downto 0); -- with "00000000"
of the right dimension

parrout   =3D>  temp_parrout,

Good luck.
Maurizio

Article: 150177
Subject: Verilog inout, I2C
From: "ASIC" <hg10367@n_o_s_p_a_m.gmail.com>
Date: Tue, 28 Dec 2010 07:57:19 -0600
Links: << >>  << T >>  << A >>
Hello, I'm trying to create an I2C master module in Verilog. I've never
been able to successfully use inout's in Verilog and I'm still unsure why.
I compiled my code and ran a test bench and I noticed the signals were at
least changing; that is, the inout's seemed to be toggling.

After this (although I still don't know if the module is conforming to the
I2C bus protocol: baby steps) I decided to try it on my Altera DE2-115
board using the switches as inputs as I require an active high enable high
to begin transmission on the bus. When I loaded my code, compiled it again,
and installed it on the board I hooked up my logic analyzer and was excited
to see... something: nothing.

I'm confused why nothing at all showed up on my physical device while my
test benches were producing logical values. I'm posting here for any advice
from more experienced people. I've been trying to create this module for a
while now and finally started work on it but am sort of at a loss as to
where to begin my trouble shooting since I recently discovered how to
create test benches in the first place; before that I would just load it
onto my hardware lots of times.

These are the only lines that deal with the inout-ness of the pins:

inout sda;
	assign sda = (ena_sda)?sda_bit:`HIGH;
	assign sdaDataIn = (ena_sda)?`HIGH:sda;
	
inout scl;
	assign scl = (ena_scl)?(pSCL?`HIGH:`LOW):`LOW;

LOW is 0, while HIGH is 1'bZ. pSCL is a clock operating at the frequency
for I2C transmission. Is this right the use of bidirectional pins or am I
way off? If anyone wants more of the code just contact me; I don't want to
flood this post with irrelevant information. It's worth noting that in the
test-bench ena_scl and ena_sda were both working as expected which, in
turn, made sda and scl show up correctly on the simulation.

During my re-reading of this post I realized my physical test pin
assignments had no connection to the I2C bus which meant there was no
resistor to VCC on either of the lines. I fixed that; still have the exact
same output!

Thanks everyone.

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 150178
Subject: Re: Verilog inout, I2C
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Tue, 28 Dec 2010 10:03:28 -0600
Links: << >>  << T >>  << A >>
>Hello, I'm trying to create an I2C master module in Verilog. I've never
>been able to successfully use inout's in Verilog and I'm still unsure
why.
>I compiled my code and ran a test bench and I noticed the signals were at
>least changing; that is, the inout's seemed to be toggling.
>
>After this (although I still don't know if the module is conforming to
the
>I2C bus protocol: baby steps) I decided to try it on my Altera DE2-115
>board using the switches as inputs as I require an active high enable
high
>to begin transmission on the bus. When I loaded my code, compiled it
again,
>and installed it on the board I hooked up my logic analyzer and was
excited
>to see... something: nothing.
>
>I'm confused why nothing at all showed up on my physical device while my
>test benches were producing logical values. I'm posting here for any
advice
>from more experienced people. I've been trying to create this module for
a
>while now and finally started work on it but am sort of at a loss as to
>where to begin my trouble shooting since I recently discovered how to
>create test benches in the first place; before that I would just load it
>onto my hardware lots of times.
>
>These are the only lines that deal with the inout-ness of the pins:
>
>inout sda;
>	assign sda = (ena_sda)?sda_bit:`HIGH;
>	assign sdaDataIn = (ena_sda)?`HIGH:sda;
>	
>inout scl;
>	assign scl = (ena_scl)?(pSCL?`HIGH:`LOW):`LOW;
>
>LOW is 0, while HIGH is 1'bZ. pSCL is a clock operating at the frequency
>for I2C transmission. Is this right the use of bidirectional pins or am I
>way off? If anyone wants more of the code just contact me; I don't want
to
>flood this post with irrelevant information. It's worth noting that in
the
>test-bench ena_scl and ena_sda were both working as expected which, in
>turn, made sda and scl show up correctly on the simulation.
>
>During my re-reading of this post I realized my physical test pin
>assignments had no connection to the I2C bus which meant there was no
>resistor to VCC on either of the lines. I fixed that; still have the
exact
>same output!
>
>Thanks everyone.
>
>	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>

Not sure if you have done this but I usually in my designs create a
seperate module with the IO buffers instantiated. So in my I2C design for a
Xilinx FPGA I have the following.

// SDA IO Buffer
IOBUF U_sda(
  .I  (1'b0), 
  .IO (sda_io), 
  .O  (sda_rd), 
  .T  (sda_wr));   

// SCL IO Buffer
IOBUF U_scl(
  .I  (1'b0), 
  .IO (scl_io), 
  .O  (scl_rd), 
  .T  (scl_wr));  

I then know that the buffers are correctly done. If your buffers are ok and
you have external pullups then it should work. It may be worth if you have
something like Chipscope to have a look and see what is going on inside the
chip.

Jon 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 150179
Subject: Re: Verilog inout, I2C
From: Andy Peters <google@latke.net>
Date: Tue, 28 Dec 2010 09:50:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 28, 9:03=A0am, "maxascent"
<maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote:
> >Hello, I'm trying to create an I2C master module in Verilog. I've never
> >been able to successfully use inout's in Verilog and I'm still unsure
> why.
> >I compiled my code and ran a test bench and I noticed the signals were a=
t
> >least changing; that is, the inout's seemed to be toggling.
>
> >After this (although I still don't know if the module is conforming to
> the
> >I2C bus protocol: baby steps) I decided to try it on my Altera DE2-115
> >board using the switches as inputs as I require an active high enable
> high
> >to begin transmission on the bus. When I loaded my code, compiled it
> again,
> >and installed it on the board I hooked up my logic analyzer and was
> excited
> >to see... something: nothing.
>
> >I'm confused why nothing at all showed up on my physical device while my
> >test benches were producing logical values. I'm posting here for any
> advice
> >from more experienced people. I've been trying to create this module for
> a
> >while now and finally started work on it but am sort of at a loss as to
> >where to begin my trouble shooting since I recently discovered how to
> >create test benches in the first place; before that I would just load it
> >onto my hardware lots of times.
>
> >These are the only lines that deal with the inout-ness of the pins:
>
> >inout sda;
> > =A0 =A0assign sda =3D (ena_sda)?sda_bit:`HIGH;
> > =A0 =A0assign sdaDataIn =3D (ena_sda)?`HIGH:sda;
>
> >inout scl;
> > =A0 =A0assign scl =3D (ena_scl)?(pSCL?`HIGH:`LOW):`LOW;
>
> >LOW is 0, while HIGH is 1'bZ. pSCL is a clock operating at the frequency
> >for I2C transmission. Is this right the use of bidirectional pins or am =
I
> >way off? If anyone wants more of the code just contact me; I don't want
> to
> >flood this post with irrelevant information. It's worth noting that in
> the
> >test-bench ena_scl and ena_sda were both working as expected which, in
> >turn, made sda and scl show up correctly on the simulation.
>
> >During my re-reading of this post I realized my physical test pin
> >assignments had no connection to the I2C bus which meant there was no
> >resistor to VCC on either of the lines. I fixed that; still have the
> exact
> >same output!
>
> >Thanks everyone.
>
> >--------------------------------------- =A0 =A0 =A0 =A0 =A0 =A0
> >Posted throughhttp://www.FPGARelated.com
>
> Not sure if you have done this but I usually in my designs create a
> seperate module with the IO buffers instantiated. So in my I2C design for=
 a
> Xilinx FPGA I have the following.
>
> // SDA IO Buffer
> IOBUF U_sda(
> =A0 .I =A0(1'b0),
> =A0 .IO (sda_io),
> =A0 .O =A0(sda_rd),
> =A0 .T =A0(sda_wr)); =A0
>
> // SCL IO Buffer
> IOBUF U_scl(
> =A0 .I =A0(1'b0),
> =A0 .IO (scl_io),
> =A0 .O =A0(scl_rd),
> =A0 .T =A0(scl_wr)); =A0
>
> I then know that the buffers are correctly done. If your buffers are ok a=
nd
> you have external pullups then it should work. It may be worth if you hav=
e
> something like Chipscope to have a look and see what is going on inside t=
he
> chip.

There's absolutely no reason to instantiate these sorts of buffers.
The usual assignment statements work, and have worked for many years.
All the instantiations do is make your code harder to understand and
not portable.

-a

Article: 150180
Subject: Microblaze GPIO interfaces to internal logic
From: Dave <starfire151@cableone.net>
Date: Tue, 28 Dec 2010 12:17:53 -0800 (PST)
Links: << >>  << T >>  << A >>
I'm using an older version of Xilinx ISE (V8.2.02i) and trying to
create a project with a Microblaze which interfaces through a GPIO
port to local combinatorial logic in the FPGA, not to the outside
world through FPGA pins.

I started a new project (top) from the ISE environment and defined my
overall system pinout.  I added a Microblaze processor as a component
to the architecture of top and instantiated the Microblaze via a port
map.  I added the Microblaze .ucf file into the project.  The only way
I could get the project to correctly synthesize was to use the same
literal names in my top entity defintions as were used in the
Microblaze component definitions.  The .ucf file that was created
during the XPS Microblaze creation defines port pins for the
peripheral functions.  How can I change the interface pinout on a GPIO
port to be directed to an internal set of logic instead of an FPGA pin
to the outside world?  For instance, if I wanted to use three pins
from the outside world to drive a 3-to-8 decoder in the FPGA and then
have the 8 outputs from the decoder drive 8 inputs of a GPIO port,
could I do this?  Do I absolutely have to include the Microblaze-
generated .ucf file (which pre-defines all the pinouts for the GPIO
ports) or can I define the .ucf for the top project from the ISE ?

Does the newer version of the ISE 12.3 (or 12.4) have this same
limitation on pinout allocation?

Does anyone have a simple example that demonstrates how to do this?

Article: 150181
Subject: Re: Verilog inout, I2C
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Tue, 28 Dec 2010 14:33:44 -0600
Links: << >>  << T >>  << A >>
>On Dec 28, 9:03=A0am, "maxascent"
><maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote:
>> >Hello, I'm trying to create an I2C master module in Verilog. I've
never
>> >been able to successfully use inout's in Verilog and I'm still unsure
>> why.
>> >I compiled my code and ran a test bench and I noticed the signals were
a=
>t
>> >least changing; that is, the inout's seemed to be toggling.
>>
>> >After this (although I still don't know if the module is conforming to
>> the
>> >I2C bus protocol: baby steps) I decided to try it on my Altera DE2-115
>> >board using the switches as inputs as I require an active high enable
>> high
>> >to begin transmission on the bus. When I loaded my code, compiled it
>> again,
>> >and installed it on the board I hooked up my logic analyzer and was
>> excited
>> >to see... something: nothing.
>>
>> >I'm confused why nothing at all showed up on my physical device while
my
>> >test benches were producing logical values. I'm posting here for any
>> advice
>> >from more experienced people. I've been trying to create this module
for
>> a
>> >while now and finally started work on it but am sort of at a loss as
to
>> >where to begin my trouble shooting since I recently discovered how to
>> >create test benches in the first place; before that I would just load
it
>> >onto my hardware lots of times.
>>
>> >These are the only lines that deal with the inout-ness of the pins:
>>
>> >inout sda;
>> > =A0 =A0assign sda =3D (ena_sda)?sda_bit:`HIGH;
>> > =A0 =A0assign sdaDataIn =3D (ena_sda)?`HIGH:sda;
>>
>> >inout scl;
>> > =A0 =A0assign scl =3D (ena_scl)?(pSCL?`HIGH:`LOW):`LOW;
>>
>> >LOW is 0, while HIGH is 1'bZ. pSCL is a clock operating at the
frequency
>> >for I2C transmission. Is this right the use of bidirectional pins or am
=
>I
>> >way off? If anyone wants more of the code just contact me; I don't
want
>> to
>> >flood this post with irrelevant information. It's worth noting that in
>> the
>> >test-bench ena_scl and ena_sda were both working as expected which, in
>> >turn, made sda and scl show up correctly on the simulation.
>>
>> >During my re-reading of this post I realized my physical test pin
>> >assignments had no connection to the I2C bus which meant there was no
>> >resistor to VCC on either of the lines. I fixed that; still have the
>> exact
>> >same output!
>>
>> >Thanks everyone.
>>
>> >--------------------------------------- =A0 =A0 =A0 =A0 =A0 =A0
>> >Posted throughhttp://www.FPGARelated.com
>>
>> Not sure if you have done this but I usually in my designs create a
>> seperate module with the IO buffers instantiated. So in my I2C design
for=
> a
>> Xilinx FPGA I have the following.
>>
>> // SDA IO Buffer
>> IOBUF U_sda(
>> =A0 .I =A0(1'b0),
>> =A0 .IO (sda_io),
>> =A0 .O =A0(sda_rd),
>> =A0 .T =A0(sda_wr)); =A0
>>
>> // SCL IO Buffer
>> IOBUF U_scl(
>> =A0 .I =A0(1'b0),
>> =A0 .IO (scl_io),
>> =A0 .O =A0(scl_rd),
>> =A0 .T =A0(scl_wr)); =A0
>>
>> I then know that the buffers are correctly done. If your buffers are ok
a=
>nd
>> you have external pullups then it should work. It may be worth if you
hav=
>e
>> something like Chipscope to have a look and see what is going on inside
t=
>he
>> chip.
>
>There's absolutely no reason to instantiate these sorts of buffers.
>The usual assignment statements work, and have worked for many years.
>All the instantiations do is make your code harder to understand and
>not portable.
>
>-a
>

I dont see how it can be harder to understand unless you have no idea how
an IO buffer works and if thats the case you shouldnt be doing FPGA design.
All the Xilinx devices I have used use the same syntax for the common
buffers and so the code should be fine across a wide number of devices.	  

					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 150182
Subject: Re: some VHDL error
From: Santosh <santos2k7@gmail.com>
Date: Wed, 29 Dec 2010 07:39:31 -0800 (PST)
Links: << >>  << T >>  << A >>
Hey
Maurizio,

I am sorry for incomplete question but thanks for your help I got the
clue.
:)

Regards
Santosh.

Article: 150183
Subject: Error in Clock Divider!
From: Santosh <santos2k7@gmail.com>
Date: Wed, 29 Dec 2010 07:43:16 -0800 (PST)
Links: << >>  << T >>  << A >>
I have got a clock divider code as follows:

entity divClk8 is
   Port ( CLK : in std_logic;
          CLK_OUT : out std_logic);
end divClk8;

architecture Behavioral of divClk8 is
signal count : std_logic_vector (3 downto 0) := "1111";
signal reset : std_logic := '0';

begin
process(CLK)
begin
if(reset = '1') then
count <= "0000";
elsif(rising_edge(CLK)) then
count <= count + 1;
end if;
end process;
CLK_OUT <= count(3);
reset <= (count(3) and not(count(2))and not(count(1))and
not(count(0)));
end Behavioral;



But when I try to compile it using ModelSim I get the following error

--  No feasible entries for infix operator "+". Type error resolving
infix expression "+" as type ieee.std_logic_1164.std_logic_vector.



I didn't get what the error message says. A little word of advice
would be really helpful!

Regards
San

Article: 150184
Subject: Re: Error in Clock Divider!
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 29 Dec 2010 07:51:31 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 29, 10:43=A0am, Santosh <santos...@gmail.com> wrote:
> I have got a clock divider code as follows:

> architecture Behavioral of divClk8 is
> signal count : std_logic_vector (3 downto 0) :=3D "1111";
> signal reset : std_logic :=3D '0';
>
> begin
> process(CLK)
> begin
> if(reset =3D '1') then
> count <=3D "0000";
> elsif(rising_edge(CLK)) then
> count <=3D count + 1;

>
> But when I try to compile it using ModelSim I get the following error
>
> -- =A0No feasible entries for infix operator "+". Type error resolving
> infix expression "+" as type ieee.std_logic_1164.std_logic_vector.
>

std_logic_vector signals do not have any math operators defined for
them.  A std_logic_vector is just a collection of bits with no numeric
interpretation.  To do what you want, you need to use a signal of type
unsigned which is defined in the package 'ieee.numeric_std'.  To fix
up the code:

- Add the line "use ieee.numeric_std.all" right after the line where
you currently have "library ieee"
- Change "signal count : std_logic_vector (3 downto 0)" to "signal
count : unsigned (3 downto 0)"

Kevin Jennings

Article: 150185
Subject: Re: Error in Clock Divider!
From: Benjamin Krill <ben@codiert.org>
Date: Wed, 29 Dec 2010 16:52:27 +0100
Links: << >>  << T >>  << A >>
Check your used libraries. Modelsim don't find an implementation
to add an integer 1 to a std_logic_vector.

On Wed, 2010-12-29 at 07:43 -0800, Santosh wrote:
> I have got a clock divider code as follows:
>=20
> entity divClk8 is
>    Port ( CLK : in std_logic;
>           CLK_OUT : out std_logic);
> end divClk8;
>=20
> architecture Behavioral of divClk8 is
> signal count : std_logic_vector (3 downto 0) :=3D "1111";
> signal reset : std_logic :=3D '0';
>=20
> begin
> process(CLK)
> begin
> if(reset =3D '1') then
> count <=3D "0000";
> elsif(rising_edge(CLK)) then
> count <=3D count + 1;
> end if;
> end process;
> CLK_OUT <=3D count(3);
> reset <=3D (count(3) and not(count(2))and not(count(1))and
> not(count(0)));
> end Behavioral;
>=20
>=20
>=20
> But when I try to compile it using ModelSim I get the following error
>=20
> --  No feasible entries for infix operator "+". Type error resolving
> infix expression "+" as type ieee.std_logic_1164.std_logic_vector.
>=20
>=20
>=20
> I didn't get what the error message says. A little word of advice
> would be really helpful!
>=20
> Regards
> San



Article: 150186
Subject: Re: Error in Clock Divider!
From: Dave <starfire151@cableone.net>
Date: Wed, 29 Dec 2010 08:32:03 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 29, 8:43=A0am, Santosh <santos...@gmail.com> wrote:
> I have got a clock divider code as follows:
>
> entity divClk8 is
> =A0 =A0Port ( CLK : in std_logic;
> =A0 =A0 =A0 =A0 =A0 CLK_OUT : out std_logic);
> end divClk8;
>
> architecture Behavioral of divClk8 is
> signal count : std_logic_vector (3 downto 0) :=3D "1111";
> signal reset : std_logic :=3D '0';
>
> begin
> process(CLK)
> begin
> if(reset =3D '1') then
> count <=3D "0000";
> elsif(rising_edge(CLK)) then
> count <=3D count + 1;
> end if;
> end process;
> CLK_OUT <=3D count(3);
> reset <=3D (count(3) and not(count(2))and not(count(1))and
> not(count(0)));
> end Behavioral;
>
> But when I try to compile it using ModelSim I get the following error
>
> -- =A0No feasible entries for infix operator "+". Type error resolving
> infix expression "+" as type ieee.std_logic_1164.std_logic_vector.
>
> I didn't get what the error message says. A little word of advice
> would be really helpful!
>
> Regards
> San

In addition to the responses you've had so far, don't you need to
include the port for the reset line input and also include it in your
process sensitivity list?

Article: 150187
Subject: Lattice ISPLever - how to prevent inferred latch
From: Mike Harrison <mike@whitewing.co.uk>
Date: Wed, 29 Dec 2010 18:00:18 +0000
Links: << >>  << T >>  << A >>
I noticed an odd thing happenning with Lattice EC VHDL project....

I have  a register config1(7 downto 0) holding various configuration states, updated in a state
machine which only gets clocked at certain times (i.e. not continuous). 

All bits of this register are set to 0  on powerup (implicitly, as per VHDL default).

I then assign a couple of pins to output a bit in this register for debug purposes 

pin112<= not config1(5);
pin109<= config1(5);

However on powerup, both of these pins are low. When the config1 register is subsequently clocked,
the pins then reflect the true and inverted states as you'd expect. 

The compile report does appear to suggest it is inferring latches for these signals.

TN1008 suggests use of else to avoid inferred latches, so I also tried 

pin112<='0' when config1(5)='1' else '1'; 

with the same result - it is still inferring a latch. 

I've worked around this by explicitly  latching the signals from  a continuous clock, but how would
I force it to NOT infer the latch, and use a simple combinatorial inverter from the register to the
pin?







Article: 150188
Subject: Re: Error in Clock Divider!
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Wed, 29 Dec 2010 19:22:18 +0100
Links: << >>  << T >>  << A >>
Le 29/12/2010 16:43, Santosh a écrit :
> I have got a clock divider code as follows:
>
> entity divClk8 is
>     Port ( CLK : in std_logic;
>            CLK_OUT : out std_logic);
> end divClk8;
>
> architecture Behavioral of divClk8 is
> signal count : std_logic_vector (3 downto 0) := "1111";
> signal reset : std_logic := '0';
>
> begin
> process(CLK)
> begin
> if(reset = '1') then
> count<= "0000";
> elsif(rising_edge(CLK)) then
> count<= count + 1;
> end if;
> end process;
> CLK_OUT<= count(3);
> reset<= (count(3) and not(count(2))and not(count(1))and
> not(count(0)));
> end Behavioral;
>
>
>
> But when I try to compile it using ModelSim I get the following error
>
> --  No feasible entries for infix operator "+". Type error resolving
> infix expression "+" as type ieee.std_logic_1164.std_logic_vector.

What do you plan to do with your divided clock output ? It will be a 
short glith-like pulse that will be very dependent on many things 
(mainly temperature) that won't be very usable.

Nicolas

Article: 150189
Subject: Re: Lattice ISPLever - how to prevent inferred latch
From: rickman <gnuarm@gmail.com>
Date: Wed, 29 Dec 2010 11:14:14 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 29, 1:00=A0pm, Mike Harrison <m...@whitewing.co.uk> wrote:
> I noticed an odd thing happenning with Lattice EC VHDL project....
>
> I have =A0a register config1(7 downto 0) holding various configuration st=
ates, updated in a state
> machine which only gets clocked at certain times (i.e. not continuous).
>
> All bits of this register are set to 0 =A0on powerup (implicitly, as per =
VHDL default).
>
> I then assign a couple of pins to output a bit in this register for debug=
 purposes
>
> pin112<=3D not config1(5);
> pin109<=3D config1(5);
>
> However on powerup, both of these pins are low. When the config1 register=
 is subsequently clocked,
> the pins then reflect the true and inverted states as you'd expect.
>
> The compile report does appear to suggest it is inferring latches for the=
se signals.
>
> TN1008 suggests use of else to avoid inferred latches, so I also tried
>
> pin112<=3D'0' when config1(5)=3D'1' else '1';
>
> with the same result - it is still inferring a latch.
>
> I've worked around this by explicitly =A0latching the signals from =A0a c=
ontinuous clock, but how would
> I force it to NOT infer the latch, and use a simple combinatorial inverte=
r from the register to the
> pin?

If you are making the assignment to config1 in a clocked process I
expect you are omitting an explicit reset assignment.  I'm not sure
what logic is generated under these conditions, or why, but I always
include an assignment to registers for the reset state.

The only way I can think that the two outputs would be in the states
you describe is if the register is being replicated and pushed into
the IOBs.  Each of the FFs might be reset by the power on reset,
assuming a correct value after being clocked.

When you say your state machine is not clocked continuously, do you
mean you are gating the clock?  Or are you enabling the clock?  You
might want to simplify your code to a test case and if the problem
remains, post it here.  If the problem goes away try adding in more of
the actual code until it breaks.

Otherwise, maybe you could post your code for us to read.

Rick

Article: 150190
Subject: Re: some VHDL error
From: "maurizio.tranchero" <maurizio.tranchero@gmail.com>
Date: Thu, 30 Dec 2010 03:00:22 -0800 (PST)
Links: << >>  << T >>  << A >>

> I am sorry for incomplete question but thanks for your help I got the
> clue.

Great! You're welcome.

Happy new year!
Maurizio

Article: 150191
Subject: Timing violation when initializing "some" FSMs and not others
From: Giuseppe Marullo <giuseppe.marullonospam@iname.com>
Date: Thu, 30 Dec 2010 13:56:31 +0100
Links: << >>  << T >>  << A >>
Hi,
I am designing a very simple cw keyer, and I am wondering why some 
timings in reset signal is triggering timing violations.

My problem is that apparently symmetrical FSMs get warnings on one 
instance while the other not.

I got timing violations when reset duration is, for example 60ns or 
100ns in the testbench:

...
		// Initialize Inputs
		fx2_clk = 0;
		paddledot <= 1'b1;
		paddledash = 1'b1;
		resetpin = 1;

		// Wait 100 ns for global reset to finish
		#60;
		resetpin = 0;

60 or 100ns are exactly on the raising edge of the feeded fx2_clk (40ns 
  period).

I got these warnings:

WARNING:Simulator:29 - at 63.358 ns: Warning: Timing violation in
    /test002/uut/dashstate_FSM_FFd1/  $recrem<recovery>( RST:62.893 ns,
    CLK:63.358 ns,991.000 ps)

WARNING:Simulator:29 - at 63.370 ns: Warning: Timing violation in
    /test002/uut/morsestate_FSM_FFd1/  $recrem<recovery>( RST:62.958 ns,
    CLK:63.370 ns,991.000 ps)

My question is: why I got the warning on dashstate and not on dotstate? 
They are debouncers for the dot and dash paddle inputs and they are 
identical.

I have similar problems on another FSM:
...
always @(posedge fx2_clk or posedge resetpin )
if (resetpin)
begin
  //  cwkeyer <= 1'b0;
//   wpm_tick_trigger <= 1'b0;
	morsestate <= 4'b0000;
end
else
   case (morsestate)
     4'b0000: begin
     // init state
                cwkeyer <= 1'b0;
	       wpm_tick_trigger <= 1'b0;
    	       morsestate <= 4'b0001;
              end
...

but not on this, that looks similar to me:

...
// WPM timer - fixed at 12 WPM at the moment
always @(posedge fx2_clk or posedge resetpin)
if (resetpin)
begin
//    wpm_tick_elapsed <= 1'b0;
//    cntwpm <= 24'b0;
     wpmstate <= 4'b0000;
end
else
    case (wpmstate)
	  4'b0000: begin
	             wpm_tick_elapsed <= 1'b0;
	  			    cntwpm <= 24'b0;
				    wpmstate <= 4'b0001;
	           end

...


The other question is: how is supposed async reset to be properly 
handled? Should I ignore the warnings?

WebISE is 10.1

TIA,

Giuseppe Marullo

PS: some snipplets of code:


...

reg [3:0] dotstate;
reg [3:0] dashstate;

...

always @(posedge fx2_clk or posedge resetpin)
if (resetpin)
   begin
    //dashout <= 1'b0;
    //cntdash <= 4'b0;
      dashstate <= 4'b0000;
   end
else
    case (dashstate)
	4'b0000: begin
               dashout <= 1'b0;
				  cntdash <= 4'b0;
  				  dashstate <= 4'b0001;
	         end
	4'b0001: begin
	           if (paddledash == 1'b0)
				     dashstate <= 4'b0010;
				  else
				     dashout <=1'b0;
             end	
	4'b0010: begin
	           if (paddledash == 1'b0)
				  begin
				     cntdash <= cntdash + 1'b1;
				  end
				  if (cntdash == 4'b011)
				  begin
				    dashout <= 1'b1;
					 cntdash <= 4'b0;
					 dashstate <= 4'b0001;
				  end
	         end
	endcase	

always @(posedge fx2_clk or posedge resetpin)
if (resetpin)
   begin
//   dotout <= 1'b0;
//   cntdot <= 4'b0;
    dotstate <= 4'b0000;
   end
else
    case (dotstate)
	4'b0000: begin
               dotout <= 1'b0;
				  cntdot <= 4'b0;
  				  dotstate <= 4'b0001;
	         end
	4'b0001: begin
	           if (paddledot == 1'b0)
				     dotstate <= 4'b0010;
				  else
				     dotout <=1'b0;
             end	
	4'b0010: begin
	           if (paddledot == 1'b0)
				  begin
				     cntdot <= cntdot + 1'b1;
				  end
				  if (cntdot == 4'b011)
				  begin
				    dotout <= 1'b1;
					 cntdot <= 4'b0;
					 dotstate <= 4'b0001;
				  end
	         end
	endcase
...

Article: 150192
Subject: Re: Error in Clock Divider!
From: jc <jcappello@optimal-design.com>
Date: Thu, 30 Dec 2010 06:30:27 -0800 (PST)
Links: << >>  << T >>  << A >>
Overloading will allow you to add integers like 1 (such as for basic
counters) to your std_logic_vector's. One of the IEEE libraries will
allow you to do this if you include the right one. Don't remember
which one off top of my head.

Some other observations:
- You are missing a reset input.
- You don't need to include reset into sensitivity list if you are
treating it synchronously.
- If you maintain std_logic_vector(3 downto 0) type OR use integer of
"range 0 to 3" there is no need to reset counter if you intend to
rollover at max (all 1's) value.

John

Article: 150193
Subject: XST Fails 2D array wild card sensitivity list
From: "cfelton" <cfelton@n_o_s_p_a_m.n_o_s_p_a_m.ieee.org>
Date: Thu, 30 Dec 2010 11:03:42 -0600
Links: << >>  << T >>  << A >>
XST Fails 2D array wild card sensitivity list


XST fails the following Verilog (similar HDL) where other synthesizers /
compilers do not?

wire [15:0] x [0:15];
wire [15:0] y [0:15];
wire [15:0] z;

wire [15:0] xo [0:15];
wire [15:0] yo [0:15];


always @(*) begin
    if (cnt < 8) begin
        xo[cnt] = x[cnt];
        yo[cnt] = y[cnt];
    end
    else begin
       xo[cnt] = z;
       yo[cnt] = 16’b0;
   end
end


HDL similar to the above fails in XST but synthesizes / compiles correctly
in all of the following 

	Icarus Verilog
	Modelsim
	Ncsim
	Cadence RTL Compiler
	Synplify Pro
	Altera Quartus

Does XST simply not support this?  
Or is the above not defined by the Verilog 1364 and the others just support
it anyway?  Or is there an XST switch that I am missing?


chris
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 150194
Subject: Re: Verilog inout, I2C
From: "cfelton" <cfelton@n_o_s_p_a_m.n_o_s_p_a_m.ieee.org>
Date: Thu, 30 Dec 2010 11:09:50 -0600
Links: << >>  << T >>  << A >>
>Hello, I'm trying to create an I2C master module in Verilog. 
  [snip]
>These are the only lines that deal with the inout-ness of the pins:
>
>inout sda;
>	assign sda = (ena_sda)?sda_bit:`HIGH;
>	assign sdaDataIn = (ena_sda)?`HIGH:sda;
>	
>inout scl;
>	assign scl = (ena_scl)?(pSCL?`HIGH:`LOW):`LOW;
>
  [snip]
>

  assign sda       =  (sda_bit == 0) ? 1'b0 : 1'bz;
  assign sdaDataIn = sda;

Only drive the signal low, tri-state IOBUF.  This assumes sda is the IOBUF
(top-level port) and sda_bit is the internal sdaDataOut signal.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 150195
Subject: Re: XST Fails 2D array wild card sensitivity list
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Thu, 30 Dec 2010 14:04:21 -0600
Links: << >>  << T >>  << A >>
>XST Fails 2D array wild card sensitivity list
>
>
>XST fails the following Verilog (similar HDL) where other synthesizers /
>compilers do not?
>
>wire [15:0] x [0:15];
>wire [15:0] y [0:15];
>wire [15:0] z;
>
>wire [15:0] xo [0:15];
>wire [15:0] yo [0:15];
>
>
>always @(*) begin
>    if (cnt < 8) begin
>        xo[cnt] = x[cnt];
>        yo[cnt] = y[cnt];
>    end
>    else begin
>       xo[cnt] = z;
>       yo[cnt] = 16’b0;
>   end
>end
>
>
>HDL similar to the above fails in XST but synthesizes / compiles
correctly
>in all of the following 
>
>	Icarus Verilog
>	Modelsim
>	Ncsim
>	Cadence RTL Compiler
>	Synplify Pro
>	Altera Quartus
>
>Does XST simply not support this?  
>Or is the above not defined by the Verilog 1364 and the others just
support
>it anyway?  Or is there an XST switch that I am missing?
>
>
>chris
>	   
>					
>---------------------------------------		
>Posted through http://www.FPGARelated.com
>

I think your problem may be the array indexing. I had a similar problem and
had to use an assign statement to fix it. 

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 150196
Subject: I Give Up!
From: rickman <gnuarm@gmail.com>
Date: Thu, 30 Dec 2010 12:57:06 -0800 (PST)
Links: << >>  << T >>  << A >>
The spam in Google groups has only gotten worse lately and there seems
to be no end in sight.  This group is getting hard to find the real
posts in and some of the other groups are just plain unusable with
five or ten spam messages to every real message.

Rather than to add spam filters as most newsgroup access providers do,
Google has invented an entirely new interface with an entirely new
look, with the ability to flag a post as spam (or otherwise
inappropriate) and it is hidden from your view.

That would be great, except that the new interface sucks compared to
the old one.  Maybe it is just that I'm used to the old one, but I
have tried the new one in one of the groups I access and I don't seem
to be liking it any more than when I first saw it.

For a company that is so good at search engines, why can't they
understand anything about how newsgroups should work?

Rick

Article: 150197
Subject: Re: I Give Up!
From: "cfelton" <cfelton@n_o_s_p_a_m.n_o_s_p_a_m.ieee.org>
Date: Thu, 30 Dec 2010 16:27:07 -0600
Links: << >>  << T >>  << A >>
>The spam in Google groups has only gotten worse lately and there seems
>to be no end in sight.  This group is getting hard to find the real
>posts in and some of the other groups are just plain unusable with
>five or ten spam messages to every real message.
>
 [snip]
>

I use a usenet (thunderbird) but also use dsprelated / fpgarelated for the
comp.fpga and comp.dsp.  I don't notice much spam through these web
interfaces.

chris	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 150198
Subject: Re: XST Fails 2D array wild card sensitivity list
From: OutputLogic <evgenist@gmail.com>
Date: Thu, 30 Dec 2010 16:01:35 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

There is a Xilinx answer record that addresses this issue:
http://www.xilinx.com/support/answers/20391.htm

Thanks,
Evgeni

Article: 150199
Subject: Re: Verilog inout, I2C
From: Mike Treseler <mtreseler@gmail.com>
Date: Thu, 30 Dec 2010 17:32:50 -0800
Links: << >>  << T >>  << A >>

>> On Dec 28, 9:03=A0am, "maxascent" wrote:

> I dont see how it can be harder to understand unless you have no idea how
> an IO buffer works and if thats the case you shouldnt be doing FPGA design.

What if I am using an Altera device?
Your scheme does not work at all.
Andy's works either way.

   -- Mike Treseler



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search