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 153775

Article: 153775
Subject: Re: Smallest GPL UART
From: Giuseppe Marullo <giuseppe.marullonospam@iname.com>
Date: Thu, 17 May 2012 01:00:53 +0200
Links: << >>  << T >>  << A >>
>
> Note that this has nothing to do with metastability.
Houston we have a problem.

I am implementing this stuff on a LX9 board that has a direct USB serial 
interface. I tried to run it at 9600 baud, and it seemed to work fine.

I Implemented a small FSM that would echo a char back, maybe with a 
little modification, ie send 'a' get back a 'c' (+2).

It worked but not if I kept sending char (a key always pressed down), 
after about 20 chars there was some strange char back.

Thinking about baud rate tolerance and/or problem sending back fast the 
char it received, I fiddled with the stop bits, hoping that it would 
allow more time to "process" the incoming char.

No dice.

I tried to slow down the pace at which I would send chars, like 1 every 
second or so, but every 15-20 char max, there was a very different char 
back.

I was unable to debug with a LA (there is not much where I could connect 
between the pc and the fpga) I tried to simulate a workbench
to exercise the fsm. It was rather difficult for me (several tasks in 
parallel and so on) but the simulation seemed to work.

I tried to send the char it received from my pc to a serial LCD, and 
there was even more errors on the output of the LCD.


At the end, I added this to the rx pin:

reg [2:0] rx_buffer;
wire rx_clean = rx_buffer[2];
always @(posedge clk)
   rx_buffer <= {rx_buffer[1:0], rx};

It is working perfectly so far. Metastability, noise or whatever there 
is something I don't get here. I have a very fast clock (100MHz) so 
maybe it would benefit from a oversampling approach but the difference 
with this metastabilitywhatever dirty fix is very noticeable.


Giuseppe Marullo

Article: 153776
Subject: Re: FDE vs latch?
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Wed, 16 May 2012 19:12:03 -0500
Links: << >>  << T >>  << A >>

"Rob Gaddi" <rgaddi@technologyhighland.invalid> wrote in message 
news:20120516132644.4ee18da4@rg.highlandtechnology.com...
> On Wed, 16 May 2012 15:16:32 -0500
> "MikeWhy" <boat042-nospam@yahoo.com> wrote:
>
>> "Andy" <jonesandy@comcast.net> wrote in message
>> news:2afbb4b2-b865-4f40-b706-4cd60365535d@t35g2000yqd.googlegroups.com...
>> > WRT your function. If the i argument is known at synthesis time (this
>> > includes the index of a for-loop), then no hardware is synthesized at
>> > all, just wires. Otherwise, it will just be multiplexers, with no
>> > adder or multiplier (multiply/divide by power of two is just a shift,
>> > and the addition of 7 to a number that is already known to have zeroes
>> > in the least three bits does not take an adder, just a lut that always
>> > outputs 1, which may be shared with others, and some more wires).
>>
>> Doh! A for loop does seem the obvious answer. Does that synthesize in a
>> clocked process?
>>
>> Thanks.
>>
>
> It does if it's synthesizable.
>
> More specifically, if the loop can be unrolled into some mess of
> combinational logic, then that logic can be placed in front of a
> register, and the for loop can be synthesized.  If there is no
> combinational logic that would generate that function (or if there is,
> but it's enormous, e.g. a divider) then you can't synthesize it.

A counter and an array of bytes, rather than a shift mask and whatever, was 
the trick. It synthesized to a counter and a big mux. Thanks for the help.

    do_vcount : process (clk)
    ...

    v_out <= word_bytes(vcount);

    init_vword : for iword in 0 to NWORDS-1 generate
        word_bytes(iword) <= vword(word, iword);
    end generate;


Article: 153777
Subject: Re: Smallest GPL UART
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 17 May 2012 01:37:01 +0000 (UTC)
Links: << >>  << T >>  << A >>
Giuseppe Marullo <giuseppe.marullonospam@iname.com> wrote:

>> Note that this has nothing to do with metastability.
> Houston we have a problem.

> I am implementing this stuff on a LX9 board that has a direct USB serial 
> interface. I tried to run it at 9600 baud, and it seemed to work fine.

> I Implemented a small FSM that would echo a char back, maybe with a 
> little modification, ie send 'a' get back a 'c' (+2).

> It worked but not if I kept sending char (a key always pressed down), 
> after about 20 chars there was some strange char back.

> Thinking about baud rate tolerance and/or problem sending back fast the 
> char it received, I fiddled with the stop bits, hoping that it would 
> allow more time to "process" the incoming char.

Add one more stop bit to the device sending to your board.

Also, your board should start counting bits half way through the
start bit, such that it looks at the center of each bit.

You should be ready to start a new character after the middle of
the stop bit, though there really should be a whole stop bit.

As you note, because of clock tolerance, data might be coming in
faster than you can send it out. You could add a fifo, but eventually
you will fill it up unless you send data slower than it comes back.

-- glen

Article: 153778
Subject: Xilinx ISE Multiple Drivers Error
From: Christopher Head <chead@is.invalid>
Date: Wed, 16 May 2012 23:15:34 -0700
Links: << >>  << T >>  << A >>
Hi folks,
I seem to have convinced ISE to output incorrect multiple-driver error
messages. I've reduced the example to the following:

-- test.vhd
library ieee;
use ieee.std_logic_1164.all;

entity Test is
	port(
		Clock : in std_ulogic;
		Foo : out std_ulogic;
		Bar : out std_ulogic);
end entity Test;

architecture Arch of Test is
begin
	Foo <= '1';
	Bar <= '1';

	process(Clock) is
		variable Temp : std_ulogic := '0';
	begin
		if rising_edge(Clock) then
			Temp := not Temp;
		end if;
		Bar <= Temp;
	end process;
end architecture Arch;

-- test.prj
vhdl work test.vhd

-- test.xst
run
-ifn test.prj
-ofn test.ngc
-p xc6slx9-tqg144-2
-top test
-opt_level 1
-opt_mode speed
-arch arch

$ xst -ifn test.xst
Release 13.4 - xst O.87xd (lin64)
[snip]
Elaborating entity <Test> (architecture <Arch>) from library <work>.
ERROR:HDLCompiler:1401 - "/tmp/vhdl/test.vhd" Line 16: Signal Foo in
unit Test is connected to following multiple drivers:
ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd" Line 13: Driver 0: output
signal of instance Power ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd"
Line 16: Driver 1: output signal Temp of instance Flip-Flop

but clearly the signal with multiple drivers is Bar, not Foo!

Thoughts on this?

Chris

Article: 153779
Subject: Re: Xilinx ISE Multiple Drivers Error
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Thu, 17 May 2012 03:44:34 -0500
Links: << >>  << T >>  << A >>
>Hi folks,
>I seem to have convinced ISE to output incorrect multiple-driver error
>messages. I've reduced the example to the following:
>
>-- test.vhd
>library ieee;
>use ieee.std_logic_1164.all;
>
>entity Test is
>	port(
>		Clock : in std_ulogic;
>		Foo : out std_ulogic;
>		Bar : out std_ulogic);
>end entity Test;
>
>architecture Arch of Test is
>begin
>	Foo <= '1';
>	Bar <= '1';
>
>	process(Clock) is
>		variable Temp : std_ulogic := '0';
>	begin
>		if rising_edge(Clock) then
>			Temp := not Temp;
>		end if;
>		Bar <= Temp;
>	end process;
>end architecture Arch;
>
>-- test.prj
>vhdl work test.vhd
>
>-- test.xst
>run
>-ifn test.prj
>-ofn test.ngc
>-p xc6slx9-tqg144-2
>-top test
>-opt_level 1
>-opt_mode speed
>-arch arch
>
>$ xst -ifn test.xst
>Release 13.4 - xst O.87xd (lin64)
>[snip]
>Elaborating entity <Test> (architecture <Arch>) from library <work>.
>ERROR:HDLCompiler:1401 - "/tmp/vhdl/test.vhd" Line 16: Signal Foo in
>unit Test is connected to following multiple drivers:
>ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd" Line 13: Driver 0: output
>signal of instance Power ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd"
>Line 16: Driver 1: output signal Temp of instance Flip-Flop
>
>but clearly the signal with multiple drivers is Bar, not Foo!
>
>Thoughts on this?
>
>Chris
>

Perhaps XST is confused by your clocked process not being a normal
synthesizable style, because the signal assignment is outside of the 'if
rising_edge' section.

Garbage in, garbage out.

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

Article: 153780
Subject: Re: Xilinx ISE Multiple Drivers Error
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Thu, 17 May 2012 11:15:52 +0200
Links: << >>  << T >>  << A >>
Le 17/05/2012 10:44, RCIngham a écrit :
>> Hi folks,
>> I seem to have convinced ISE to output incorrect multiple-driver error
>> messages. I've reduced the example to the following:
>>
>> -- test.vhd
>> library ieee;
>> use ieee.std_logic_1164.all;
>>
>> entity Test is
>> 	port(
>> 		Clock : in std_ulogic;
>> 		Foo : out std_ulogic;
>> 		Bar : out std_ulogic);
>> end entity Test;
>>
>> architecture Arch of Test is
>> begin
>> 	Foo<= '1';
>> 	Bar<= '1';
>>
>> 	process(Clock) is
>> 		variable Temp : std_ulogic := '0';
>> 	begin
>> 		if rising_edge(Clock) then
>> 			Temp := not Temp;
>> 		end if;
>> 		Bar<= Temp;
>> 	end process;
>> end architecture Arch;
[...]
> Perhaps XST is confused by your clocked process not being a normal
> synthesizable style, because the signal assignment is outside of the 'if
> rising_edge' section.

I don't think so. I use this very often to output a variable, it works 
absolutely fine.


> Garbage in, garbage out.

Actually not.

What I think happens is that XST reduces ("optimizes") foo and bar to a 
single signal, names it foo probably because it's the first declared, 
and the complains about the multiple drivers.

Nicolas

Article: 153781
Subject: Re: Xilinx ISE Multiple Drivers Error
From: Andy <jonesandy@comcast.net>
Date: Thu, 17 May 2012 05:09:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 17, 3:44=A0am, "RCIngham"
<robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
> >Hi folks,
> >I seem to have convinced ISE to output incorrect multiple-driver error
> >messages. I've reduced the example to the following:
>
> >-- test.vhd
> >library ieee;
> >use ieee.std_logic_1164.all;
>
> >entity Test is
> > =A0 =A0port(
> > =A0 =A0 =A0 =A0 =A0 =A0Clock : in std_ulogic;
> > =A0 =A0 =A0 =A0 =A0 =A0Foo : out std_ulogic;
> > =A0 =A0 =A0 =A0 =A0 =A0Bar : out std_ulogic);
> >end entity Test;
>
> >architecture Arch of Test is
> >begin
> > =A0 =A0Foo <=3D '1';
> > =A0 =A0Bar <=3D '1';
>
> > =A0 =A0process(Clock) is
> > =A0 =A0 =A0 =A0 =A0 =A0variable Temp : std_ulogic :=3D '0';
> > =A0 =A0begin
> > =A0 =A0 =A0 =A0 =A0 =A0if rising_edge(Clock) then
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Temp :=3D not Temp;
> > =A0 =A0 =A0 =A0 =A0 =A0end if;
> > =A0 =A0 =A0 =A0 =A0 =A0Bar <=3D Temp;
> > =A0 =A0end process;
> >end architecture Arch;
>
> >-- test.prj
> >vhdl work test.vhd
>
> >-- test.xst
> >run
> >-ifn test.prj
> >-ofn test.ngc
> >-p xc6slx9-tqg144-2
> >-top test
> >-opt_level 1
> >-opt_mode speed
> >-arch arch
>
> >$ xst -ifn test.xst
> >Release 13.4 - xst O.87xd (lin64)
> >[snip]
> >Elaborating entity <Test> (architecture <Arch>) from library <work>.
> >ERROR:HDLCompiler:1401 - "/tmp/vhdl/test.vhd" Line 16: Signal Foo in
> >unit Test is connected to following multiple drivers:
> >ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd" Line 13: Driver 0: output
> >signal of instance Power ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd"
> >Line 16: Driver 1: output signal Temp of instance Flip-Flop
>
> >but clearly the signal with multiple drivers is Bar, not Foo!
>
> >Thoughts on this?
>
> >Chris
>
> Perhaps XST is confused by your clocked process not being a normal
> synthesizable style, because the signal assignment is outside of the 'if
> rising_edge' section.
>
> Garbage in, garbage out.
>
> ---------------------------------------
> Posted throughhttp://www.FPGARelated.com- Hide quoted text -
>
> - Show quoted text -

This style (assigning a signal from a variable after the clocked end-
if, in a clocked process) is shown in an example in IEEE 1076.6-2004,
IEEE Standard for VHDL Register Transfer Level (RTL) Synthesis.

If XST has a problem with that, it is a bug.

Like Nicolas, I use this all the time. I rarely use a signal except
for inter-process communications, and this is how I drive signals from
my processes.

Andy

Article: 153782
Subject: Re: Xilinx ISE Multiple Drivers Error
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Thu, 17 May 2012 09:04:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 16, 11:15=A0pm, Christopher Head <ch...@is.invalid> wrote:
> Hi folks,
> I seem to have convinced ISE to output incorrect multiple-driver error
> messages. I've reduced the example to the following:
>
> -- test.vhd
> library ieee;
> use ieee.std_logic_1164.all;
>
> entity Test is
> =A0 =A0 =A0 =A0 port(
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Clock : in std_ulogic;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Foo : out std_ulogic;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bar : out std_ulogic);
> end entity Test;
>
> architecture Arch of Test is
> begin
> =A0 =A0 =A0 =A0 Foo <=3D '1';
> =A0 =A0 =A0 =A0 Bar <=3D '1';
>
> =A0 =A0 =A0 =A0 process(Clock) is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 variable Temp : std_ulogic :=3D '0';
> =A0 =A0 =A0 =A0 begin
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if rising_edge(Clock) then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Temp :=3D not Temp;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bar <=3D Temp;
> =A0 =A0 =A0 =A0 end process;
> end architecture Arch;
>
> -- test.prj
> vhdl work test.vhd
>
> -- test.xst
> run
> -ifn test.prj
> -ofn test.ngc
> -p xc6slx9-tqg144-2
> -top test
> -opt_level 1
> -opt_mode speed
> -arch arch
>
> $ xst -ifn test.xst
> Release 13.4 - xst O.87xd (lin64)
> [snip]
> Elaborating entity <Test> (architecture <Arch>) from library <work>.
> ERROR:HDLCompiler:1401 - "/tmp/vhdl/test.vhd" Line 16: Signal Foo in
> unit Test is connected to following multiple drivers:
> ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd" Line 13: Driver 0: output
> signal of instance Power ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd"
> Line 16: Driver 1: output signal Temp of instance Flip-Flop
>
> but clearly the signal with multiple drivers is Bar, not Foo!
>
> Thoughts on this?
>
> Chris

The problem is that you are assigning a value to the signal "Bar" in
two different sections of your code and each of these will have a
driver.

The first one is in the architecture section:

    Bar <=3D '1';

The second one is in a process section:

    Bar <=3D Temp;

You need to get rid of the first assignment and if you want to have a
reset value then you should code this in your process section.

I am assuming that you did not simulate this code because if you had
it would show a 'U' state when the value of Temp is a '0' and in
conflict with the permanent assignment of '1'.

Note; 2nd post try as Google ate my 1st try.

Ed McGettigan
--
Xilinx Inc.

Article: 153783
Subject: Re: Xilinx ISE Multiple Drivers Error
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Thu, 17 May 2012 18:33:46 +0200
Links: << >>  << T >>  << A >>
Le 17/05/2012 14:09, Andy a écrit :

> This style (assigning a signal from a variable after the clocked end-
> if, in a clocked process) is shown in an example in IEEE 1076.6-2004,
> IEEE Standard for VHDL Register Transfer Level (RTL) Synthesis.
>
> If XST has a problem with that, it is a bug.

I confirm that XST doesn't have any problem with it.

Nicolas

Article: 153784
Subject: Re: Xilinx ISE Multiple Drivers Error
From: Christopher Head <chead@is.invalid>
Date: Fri, 18 May 2012 17:51:51 -0700
Links: << >>  << T >>  << A >>
On Thu, 17 May 2012 09:04:58 -0700 (PDT)
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:

> On May 16, 11:15 pm, Christopher Head <ch...@is.invalid> wrote:
[snip]
> > $ xst -ifn test.xst
> > Release 13.4 - xst O.87xd (lin64)
> > [snip]
> > Elaborating entity <Test> (architecture <Arch>) from library <work>.
> > ERROR:HDLCompiler:1401 - "/tmp/vhdl/test.vhd" Line 16: Signal Foo in
> > unit Test is connected to following multiple drivers:
> > ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd" Line 13: Driver 0:
> > output signal of instance Power ERROR:HDLCompiler:1379 -
> > "/tmp/vhdl/test.vhd" Line 16: Driver 1: output signal Temp of
> > instance Flip-Flop
> >
> > but clearly the signal with multiple drivers is Bar, not Foo!
> >
> > Thoughts on this?
> >
> > Chris
> 
> The problem is that you are assigning a value to the signal "Bar" in
> two different sections of your code and each of these will have a
> driver.
> 
[snip]

Yes, of course that's the problem with the original code. The issue
here is that XST isn't complaining about Bar: it's complaining about
Foo, which has only a single driver!

Chris

Article: 153785
Subject: Re: Xilinx ISE Multiple Drivers Error
From: Christopher Head <chead@is.invalid>
Date: Fri, 18 May 2012 17:54:19 -0700
Links: << >>  << T >>  << A >>
On Thu, 17 May 2012 11:15:52 +0200
Nicolas Matringe <nicolas.matringe@fre.fre> wrote:

> What I think happens is that XST reduces ("optimizes") foo and bar to
> a single signal, names it foo probably because it's the first
> declared, and the complains about the multiple drivers.
> 
> Nicolas

I think this may have hit the nail on the head. I tried changing the
constant assigned to Foo from '1' to '0', so that now the concurrent
assignments were of different values, and the error message properly
changed to complain about Bar.

Chris

Article: 153786
Subject: Re: Xilinx ISE Multiple Drivers Error
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Sat, 19 May 2012 15:53:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 18, 5:51=A0pm, Christopher Head <ch...@is.invalid> wrote:
> On Thu, 17 May 2012 09:04:58 -0700 (PDT)
>
>
>
>
>
> Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> > On May 16, 11:15=A0pm, Christopher Head <ch...@is.invalid> wrote:
> [snip]
> > > $ xst -ifn test.xst
> > > Release 13.4 - xst O.87xd (lin64)
> > > [snip]
> > > Elaborating entity <Test> (architecture <Arch>) from library <work>.
> > > ERROR:HDLCompiler:1401 - "/tmp/vhdl/test.vhd" Line 16: Signal Foo in
> > > unit Test is connected to following multiple drivers:
> > > ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd" Line 13: Driver 0:
> > > output signal of instance Power ERROR:HDLCompiler:1379 -
> > > "/tmp/vhdl/test.vhd" Line 16: Driver 1: output signal Temp of
> > > instance Flip-Flop
>
> > > but clearly the signal with multiple drivers is Bar, not Foo!
>
> > > Thoughts on this?
>
> > > Chris
>
> > The problem is that you are assigning a value to the signal "Bar" in
> > two different sections of your code and each of these will have a
> > driver.
>
> [snip]
>
> Yes, of course that's the problem with the original code. The issue
> here is that XST isn't complaining about Bar: it's complaining about
> Foo, which has only a single driver!
>
> Chris- Hide quoted text -
>
> - Show quoted text -

Sorry, I missed the Foo vs Bar part of your orignal post.  Which FPGA
Family were you using?

Ed McGettigan
--
Xilinx Inc.

Article: 153787
Subject: Re: Xilinx ISE Multiple Drivers Error
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Sat, 19 May 2012 15:55:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 18, 5:51=A0pm, Christopher Head <ch...@is.invalid> wrote:
> On Thu, 17 May 2012 09:04:58 -0700 (PDT)
>
>
>
>
>
> Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> > On May 16, 11:15=A0pm, Christopher Head <ch...@is.invalid> wrote:
> [snip]
> > > $ xst -ifn test.xst
> > > Release 13.4 - xst O.87xd (lin64)
> > > [snip]
> > > Elaborating entity <Test> (architecture <Arch>) from library <work>.
> > > ERROR:HDLCompiler:1401 - "/tmp/vhdl/test.vhd" Line 16: Signal Foo in
> > > unit Test is connected to following multiple drivers:
> > > ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd" Line 13: Driver 0:
> > > output signal of instance Power ERROR:HDLCompiler:1379 -
> > > "/tmp/vhdl/test.vhd" Line 16: Driver 1: output signal Temp of
> > > instance Flip-Flop
>
> > > but clearly the signal with multiple drivers is Bar, not Foo!
>
> > > Thoughts on this?
>
> > > Chris
>
> > The problem is that you are assigning a value to the signal "Bar" in
> > two different sections of your code and each of these will have a
> > driver.
>
> [snip]
>
> Yes, of course that's the problem with the original code. The issue
> here is that XST isn't complaining about Bar: it's complaining about
> Foo, which has only a single driver!
>
> Chris- Hide quoted text -
>
> - Show quoted text -

Sorry, I missed the distinction between Foo and Bar in the original
post.  Which FPGA family were you using?

Note: 3rd post attempt due to Google eating the first two.

Ed McGettigan
--
Xilinx Inc.

Article: 153788
Subject: Re: Xilinx ISE Multiple Drivers Error
From: Christopher Head <chead@is.invalid>
Date: Sun, 20 May 2012 14:51:29 -0700
Links: << >>  << T >>  << A >>
On Sat, 19 May 2012 15:53:26 -0700 (PDT)
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:

> Sorry, I missed the Foo vs Bar part of your orignal post.  Which FPGA
> Family were you using?
> 
> Ed McGettigan
> --
> Xilinx Inc.

This is targeting xc6slx9-tqg144-2. The original post has the .prj
and .xst files as well as the .vhd.

Chris

Article: 153789
Subject: Re: Interfacing a circuit in an FPGA to a PC
From: "Dr. Beau Webber" <j.b.w.webber@kent.ac.uk>
Date: Mon, 21 May 2012 12:11:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
> On Friday, 11 May 2012 09:49:05 UTC+1, Dr. Beau Webber  wrote:
> > If you have an interest in exchanging data between circuitry in an FPGA=
 and a PC, I have written a simple GUI that demonstrates transfers at full =
USB2 rates to and from an FPGA .....
> > There is a free (binary only) download :=20
> >    http://www.lab-tools.com/instrumentation/download/FPGA_PC_Release_TF=
.zip=20
> > If you run Norton, it will probably complain .....

Now : "The Symantec Insight Dispute team has reviewed your recent submissio=
n to the Insight Dispute Submission form Webpage form "FPGA_interface_demo_=
2012-05-13_TF." In light of further investigation and analysis Symantec is =
happy to remove this detection from within its products."

Article: 153790
Subject: ITU656 to Mpeg4 with Fpga?
From: backspace <stephanusr@gmail.com>
Date: Tue, 22 May 2012 05:51:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
An ADV7181BBSTZ - PAL/NTSC Video Decoder coverts an analogue video
camera signal to  ITU656 and YCrCb 4:2:2 [http://en.wikipedia.org/wiki/
Serial_digital_interface Serial digital stream]. Convert this to JPEG
over Ethernet with a FpGa as implemented by the SoC  Milkymist
project.

Ques: Where would one option an IP for this?

Article: 153791
Subject: Re: ITU656 to Mpeg4 with Fpga?
From: "scrts" <hidden@email.com>
Date: Tue, 22 May 2012 16:13:38 +0300
Links: << >>  << T >>  << A >>

"backspace" <stephanusr@gmail.com> wrote in message 
news:9ece362b-ba09-49b6-800c-520433d3bdc3@n16g2000vbn.googlegroups.com...
> An ADV7181BBSTZ - PAL/NTSC Video Decoder coverts an analogue video
> camera signal to  ITU656 and YCrCb 4:2:2 [http://en.wikipedia.org/wiki/
> Serial_digital_interface Serial digital stream]. Convert this to JPEG
> over Ethernet with a FpGa as implemented by the SoC  Milkymist
> project.
>
> Ques: Where would one option an IP for this?

So You need to convert video frames to JPEG or to MPEG4? MPEG4 would be huge 
and cost a lot... Afaik JointWave could offer something for You. 



Article: 153792
Subject: Re: Xilinx ISE Multiple Drivers Error
From: Anssi Saari <as@sci.fi>
Date: Tue, 22 May 2012 17:21:14 +0300
Links: << >>  << T >>  << A >>
Christopher Head <chead@is.invalid> writes:

> Hi folks,
> I seem to have convinced ISE to output incorrect multiple-driver error
> messages. I've reduced the example to the following:

Well, at least ancient 10.1 gets it right:

"test.vhd Line 22. Signal Bar has a multi source."



Article: 153793
Subject: Re: Spartan-6 66mhz pci
From: Gabor <gabor@szakacs.invalid>
Date: Wed, 23 May 2012 11:01:39 -0400
Links: << >>  << T >>  << A >>
jonpry wrote:
> On May 16, 12:58 pm, smit...@gmail.com wrote:
>>> It seems unlikely to me that any of that can be removed, and it is not
>>> even close to the 6ns clock to out that I need. Am I missing
>>> something? How can 66mhz pci timing possibly be met in a device with
>>> 3.5ns Tioop?
>> You're right. Spartan 6 only supports 33 MHz PCI. See table 1 in DS206, LogiCORE IP 32-Bit Initiator/Target v3 & v4 for PCI.
>>
>> www.xilinx.com/support/documentation/ip_documentation/pci32/v4_16/pci...
> 
> Thanks. That would explain it! I had assumed that since it could be
> done in S3E that it would be a breeze in S6.

In the Spartan 3E and some earlier parts, there were special
pins for TRDY and IRDY with built in logic to get the timing
down to something possible.  Only Xilinx was allowed to use this
feature, and it was part of every Xilinx PCI core.  Because
modern computers have mostly gone away from PCI for high
performance peripherals, Xilinx dropped the IRDY and TRDY
logic in the S6 and newer parts.  S6 LXT parts can easily
do 1 lane PCIe, which is about twice PCI-66 bandwidth at
a much lower pin count.  66 MHz PCI has pretty much gone the
way of PCI-X, and other high performance parallel buses.
(Anyone remember EISA?)  Almost no new systems use it.

- Gabor

Article: 153794
Subject: Re: Xilinx ISE Multiple Drivers Error
From: Gabor <gabor@szakacs.invalid>
Date: Wed, 23 May 2012 11:06:27 -0400
Links: << >>  << T >>  << A >>
Anssi Saari wrote:
> Christopher Head <chead@is.invalid> writes:
> 
>> Hi folks,
>> I seem to have convinced ISE to output incorrect multiple-driver error
>> messages. I've reduced the example to the following:
> 
> Well, at least ancient 10.1 gets it right:
> 
> "test.vhd Line 22. Signal Bar has a multi source."
> 
> 
13.4 would probably get it right, too if you target
a Spartan 3.  This is no doubt another bug introduced
with the "new parsers" for S6, V6 and newer parts -
hence Ed's question about target part.

- Gabor

Article: 153795
Subject: Re: Xilinx ISE Multiple Drivers Error
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 23 May 2012 10:19:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 23, 8:06=A0am, Gabor <ga...@szakacs.invalid> wrote:
> Anssi Saari wrote:
> > Christopher Head <ch...@is.invalid> writes:
>
> >> Hi folks,
> >> I seem to have convinced ISE to output incorrect multiple-driver error
> >> messages. I've reduced the example to the following:
>
> > Well, at least ancient 10.1 gets it right:
>
> > "test.vhd Line 22. Signal Bar has a multi source."
>
> 13.4 would probably get it right, too if you target
> a Spartan 3. =A0This is no doubt another bug introduced
> with the "new parsers" for S6, V6 and newer parts -
> hence Ed's question about target part.
>
> - Gabor

Yes, this is why I asked (although it was in the original post).  I
have confirmed that the problem only happens with the new parser
(Spartan-6, Virtex-6, 7 Series) and is not present in the original
parser.  This is still true for the ISE 14.1 release.

I filed an intenal change request/bug report on the issue to get it
fixed.

Note: I need to stop using Google groups because they continue to drop
my posts (2nd try) unless I logout and then back in again.

Ed McGettigan
--
Xilinx Inc.

Article: 153796
Subject: Logic Glitches in Spartan-3?
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Wed, 23 May 2012 16:34:26 -0700
Links: << >>  << T >>  << A >>
I've got a 24-input AND gate that I'd like to avoid having add another
register delay to before I toss it across a clock boundary.

	all_done <= and_reduce(done);

If I just do it, AND it all together without a flop on the output, does
anyone know whether I'll get transition glitches (an output of 1 when
not all inputs are 1)?

I seem to remember something about individual LUTs being glitch-free,
and the synthesizer has to compose my giant AND out of either a LUT
tree or a mess o' LUTs "wire-and" driving a carry chain,  Offhand, it
seems like neither structure should glitch.  "Try it and see" doesn't
work; testing all 2^24 combinations and trying to determine whether I
get a glitch would be a beast of an effort.

Anyone know offhand?

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 153797
Subject: Re: Logic Glitches in Spartan-3?
From: rickman <gnuarm@gmail.com>
Date: Wed, 23 May 2012 17:23:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 23, 7:34=A0pm, Rob Gaddi <rga...@technologyhighland.invalid>
wrote:
> I've got a 24-input AND gate that I'd like to avoid having add another
> register delay to before I toss it across a clock boundary.
>
> =A0 =A0 =A0 =A0 all_done <=3D and_reduce(done);
>
> If I just do it, AND it all together without a flop on the output, does
> anyone know whether I'll get transition glitches (an output of 1 when
> not all inputs are 1)?
>
> I seem to remember something about individual LUTs being glitch-free,
> and the synthesizer has to compose my giant AND out of either a LUT
> tree or a mess o' LUTs "wire-and" driving a carry chain, =A0Offhand, it
> seems like neither structure should glitch. =A0"Try it and see" doesn't
> work; testing all 2^24 combinations and trying to determine whether I
> get a glitch would be a beast of an effort.
>
> Anyone know offhand?
>
> --
> Rob Gaddi, Highland Technology --www.highlandtechnology.com
> Email address domain is currently out of order. =A0See above to fix.

I believe the glitch free behavior of a LUT is from a single input
changing which results in the same value being output from two
different configuration FFs in the LUT.

But how would an AND gate glitch?  I guess if one input is at a zero
and other inputs change you are concerned that a one might sneak
through?  That is what the LUTs (at least according to Xilinx) are
assured to prevent.  If you are worried about multiple inputs
switching simultaneously, e.g. a 1 to a 0 and a 0 to a 1, that is a
race condition and there are no guarantees.  It just depends on which
gets to the output first.

Rick

Article: 153798
Subject: Re: Smallest GPL UART
From: j.m.granville@gmail.com
Date: Wed, 23 May 2012 17:44:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, May 17, 2012 11:00:53 AM UTC+12, Giuseppe Marullo wrote:
> I tried to run it at 9600 baud, and it seemed to work fine.
> I tried to slow down the pace at which I would send chars, like 1 every 
> second or so, but every 15-20 char max, there was a very different char 
> back.
>
> At the end, I added this to the rx pin:
> 
> reg [2:0] rx_buffer;
> wire rx_clean = rx_buffer[2];
> always @(posedge clk)
>    rx_buffer <= {rx_buffer[1:0], rx};
> 
> It is working perfectly so far. Metastability, noise or whatever there 
> is something I don't get here. I have a very fast clock (100MHz) so 
> maybe it would benefit from a oversampling approach but the difference 
> with this metastabilitywhatever dirty fix is very noticeable.

 Did you also add a majority vote on those samples ?

 it does seem strange from a random sampling angle - if you are running 9600 baud, and you get failures of 1 in 25, that suggests an error window equivalent of around 4us.

 Things may not be random, I'd look around for something else wrong.
(ie you may not have fully fixed a problem, just moved it slightly)

  Samples should be ~52us clear of any edges, and Stop bit should flip to start edge polling, at 50% stop time (this gives margin for baud rate skews)
( Shipping UARTS have made this mistake, you can also check by sending two stop bits )
 You could output a pulse when you sample, and another when ready-for-Start, and scope that - at least a 1:25 failure is often enough, to be easy to catch.

Article: 153799
Subject: Re: Logic Glitches in Spartan-3?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 24 May 2012 01:39:13 +0000 (UTC)
Links: << >>  << T >>  << A >>
Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:
> I've got a 24-input AND gate that I'd like to avoid having add another
> register delay to before I toss it across a clock boundary.

>        all_done <= and_reduce(done);

> If I just do it, AND it all together without a flop on the output, does
> anyone know whether I'll get transition glitches (an output of 1 when
> not all inputs are 1)?

> I seem to remember something about individual LUTs being glitch-free,

That is the idea, though only true when the actual logic is
glitch-free. As you note, if one input is 0, for any combination
of other inputs the output should be zero. Note that does NOT
naturally happen for a SRAM. 

> and the synthesizer has to compose my giant AND out of either a LUT
> tree or a mess o' LUTs "wire-and" driving a carry chain,  Offhand, it
> seems like neither structure should glitch.  "Try it and see" doesn't
> work; testing all 2^24 combinations and trying to determine whether I
> get a glitch would be a beast of an effort.

It seems to me that a tree of glitch-free LUTs is glitch-free,
but see what others say.

Note that you might have different delays on the routes to different
inputs. In that case, depending on timing, there might be times
when all inputs are 1, and the output goes to 1. That is a race
condition, not a glitch.

-- glen



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