Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
>
> 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
"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: 153777Giuseppe 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. -- glenArticle: 153778
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? ChrisArticle: 153779
>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.comArticle: 153780
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: 153781On 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. AndyArticle: 153782
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: 153783Le 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. NicolasArticle: 153784
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! ChrisArticle: 153785
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: 153786On 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
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
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. ChrisArticle: 153789
> 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
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
"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
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
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. - GaborArticle: 153794
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. - GaborArticle: 153795
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
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
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. RickArticle: 153798
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: 153799Rob 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:
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