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 150500

Article: 150500
Subject: Re: Xilinx news
From: comp arch <comparchfpga@gmail.com>
Date: Mon, 24 Jan 2011 17:09:32 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 24, 2:51=A0pm, rickman <gnu...@gmail.com> wrote:
> On Jan 24, 12:21=A0pm, John Larkin
>
>
>
>
>
>
>
>
>
> <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> > On Mon, 24 Jan 2011 09:09:42 +0100, David Brown
>
> > <da...@westcontrol.removethisbit.com> wrote:
>
> > >I find it hard to believe that supposedly educated, intelligent and
> > >experienced engineers can post such ignorant xenophobic drivel.
>
> > Well, two facts exist:
>
> > 1. Their software is a nightmare, and it's costing them business
>
> > 2. They are dumping the French operation.
>
> > The software is the heart of an FPGA company. The very architecture of
> > the chip has to be coordinated with possible compiler strategies. The
> > idea of outsourcing anything this important to a group 8 or 9 time
> > zones away, working in another language, in a country where it's
> > almost impossible to fire incompetant workers, where people take long
> > lunches with wine and don't work weekends, just amazes me.
>
> This is probably a discussion to stay out of, but I want to correct a
> misapprehension on your part. =A0I have worked with the French at a
> major telecom company and will tell you that they are no more
> incompetent or drunk than American workers. =A0The continent does have a
> different work culture in terms of leave. =A0They get lots more vacation
> than we typically do and they manage to get their work done without
> working late nights and weekends.
>
> Actually I have always thought it very odd that US workers were
> willing to take on the burden of completing projects on time and
> budget when they have little or no say in the process of setting those
> goals. =A0Lets face it. =A0Being willing to work unlimited, unpaid
> overtime is something that the majority of workers in the US are
> unwilling to do. =A0For some reason engineers seem to be in a class all
> by themselves in that regard here in the US. =A0What other professions
> are willing to do that?
>
> > >Xilinx (or rather, their users and customers) have trouble with the
> > >Xilinx software because the Xilinx leadership do not prioritise it
> > >appropriately, and (apparently) do not listen to or understand the
> > >issues customers have with the software. =A0They alone are at fault. =
=A0It
> > >could well be that the main management fault was to hire a development
> > >team that was not competent to do the development - but the problem is
> > >their lack of competence, not their nationality!
>
> > I'd have been equally surprised had they outsourced anything this
> > core-critical to any other country that far from San Jose. Big
> > Software is nearly impossible to manage even without an ocean in the
> > way.
>
> Distance doesn't create problems in management... management creates
> problems in management. =A0I've worked on projects where no two people
> were in the same city and they progressed well, except for the
> management which kept feeding lies upstream in order to tell them what
> they wanted to hear. =A0I guess one difference is that it is a bit
> harder to manage by "walking around", something upper management
> should do. =A0Then they can find out things that they aren't being
> told.
>
> But none of this has to do with nationality.
>
> Rick

The nationality/work style thing is interesting. I've had the fortune
to work in a few european countries (Germany, Ireland), as well as the
US (San Jose). I really didn't find that the difference in vacation
led to better performance - I knew many good engineers in all
locations, and many terrible ones. In fact, I found that in the US (IC
design company), people were very much 9-5, even when busy, and talked
a lot. I liked the atmosphere, but I can't say it was that productive!
Better rested and rewarded employees are likely more productive,
because they feel mutual respect is more than a word, more vacation
means better balance, less burn out, more creativity, etc. I think
this may be why some silicon valley companies are getting close to 20
vacation days a year now...if your industry required drones, sure work
em to the bone, but in design, be it software, hardware or otherwise,
you certainly don't want drones...

Article: 150501
Subject: Re: Xilinx news
From: comp arch <comparchfpga@gmail.com>
Date: Mon, 24 Jan 2011 17:12:44 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 24, 3:09=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> On 23/01/2011 06:10, John Larkin wrote:
>
>
>
>
>
>
>
>
>
> > On Sat, 22 Jan 2011 23:03:16 -0600, "k...@att.bizzzzzzzzzzzz"
> > <k...@att.bizzzzzzzzzzzz> =A0wrote:
>
> >> On Sat, 22 Jan 2011 18:20:55 -0800, John Larkin
> >> <jjlar...@highNOTlandTHIStechnologyPART.com> =A0wrote:
>
> >>>http://www.eetimes.com/electronics-news/4212400/Xilinx-to-shutter-Fre.=
..
>
> >>> Yikes, this explains some stuff. I wonder how long it will take to
> >>> undo the damage.
>
> >> Damage? =A0The damage caused by closing a software development lab?
>
> > I meant the damage likely *done* by that lab. We'd been speculating
> > how Xininx managed to snarl up their software so thoroughly, and
> > whether they will ever get it fixed. I can't imagine why they'd
> > outsource something this important to France.
>
> I find it hard to believe that supposedly educated, intelligent and
> experienced engineers can post such ignorant xenophobic drivel.
>
> Xilinx (or rather, their users and customers) have trouble with the
> Xilinx software because the Xilinx leadership do not prioritise it
> appropriately, and (apparently) do not listen to or understand the
> issues customers have with the software. =A0They alone are at fault. =A0I=
t
> could well be that the main management fault was to hire a development
> team that was not competent to do the development - but the problem is
> their lack of competence, not their nationality!
>
> I know that sci.electronics.design is a hangout for mostly geriatric
> American right-wingers who like to spend their free time blaming the
> world's ills on "leftist weenies", foreigners, atheists, intellectuals,
> and other dangerous sub-humans. =A0That's fair enough, within the limits
> of freedom of speech. =A0It can even be entertaining at times. =A0But ple=
ase
> keep that sort of thing within s.e.d. and not serious newsgroups.
>
> Follow-up flames to s.e.d., and leave c.a.f. alone for a possible
> discussion about the actual effect of this news on Xilinx and its custome=
rs.

I've been told by many a FAE that the SW is being addressed very
strongly.
So the customers have been listened to, but I guess you can't turn an
tanker on a dime, and you can't replace massively complex software
overnight, but the next generation is coming...if you have a Xilinx
FAE, ask them!

Article: 150502
Subject: Re: Prime number testing on FPGA
From: backhus <goouse99@googlemail.com>
Date: Mon, 24 Jan 2011 22:56:28 -0800 (PST)
Links: << >>  << T >>  << A >>
On 24 Jan., 09:31, Kolja Sulimma <ksuli...@googlemail.com> wrote:
> On 20 Jan., 08:10, Dennis Yurichev <dennis.yuric...@gmail.com> wrote:
>
> > There are another number primality tests exists, so the question is,
> > is there can be such primality test which is suitable for FPGA in such
> > way, when it will work much more effectively than =C9douard Lucas and
> > Derrick Henry Lehmer's primality test running on generic computer?
>
> I can't compare the performance, but the reconfigurable computing
> people
> from imperial collage have been working on that:http://wwwhomes.doc.ic.ac=
.uk/~rcheung/papers/fpt04.pdf
>
> Kolja

Hi,
interesting paper.
Only drawback I see at the moment is the size of the prime numbers.
But if the algorithm can work with a given number of Processing
Elements on any number under test,
it would just be necessary to replace the BRAM storage by some
external memory interface for DDR-Ram or (if read only) FLASH memory.
(More elegant would be some network solution of course.)

Have a nice synthesis
   Eilert

Article: 150503
Subject: FPGA changes behaviour when the resource's usage percentage changes
From: Emanuele83 <emanuele83katamail@googlemail.com>
Date: Tue, 25 Jan 2011 00:42:04 -0800 (PST)
Links: << >>  << T >>  << A >>
Good day to everybody,

I have a problem with my new FPGA design. After a long time using
Spartan 2 my company migrated to SPARTAN 3A 3400 DSP on a BGA csg484
package. We had a lot of problems soldering this CSG484 packages and
the whole board has been baked 2 times. The first time the balls were
not melted totally and didn=92t solder completely the FPGAs to the the
PCB, due to a bad temperature profile. The same PCBs and the same
FPGAs has been baked another time with the correct temperature profile
and the balls were melted properly, the daisy chain was recognized and
the FPGA were possible to be programmed.

Since the beginning we had problems in the communication between FPGAs
and other onboard chips.
I program in VHDL and my code is correctly written from the
algorithmic point of view. It matches the requirements that I have set
to communicate with the other chips onboard and perform the correct
computations on the data that must be processed. I performed a post
synthesis simulation of each and every block that forms the design.
The aim of the design is to run @ 80Mhz speed.
The problem is that even setting the constraints over period, duty
cycle, OFFSET IN and OUT, with all the constraints met in the timing
report, the FPGA behaves in a totally different way if I change the
compiling settings (for example changing from AREA to SPEED goals, or
changing the state machine implementation from =93one hot=94 to =93auto=94)=
 or
modifying the VHDL code slightly.
Thus I decided to decrease the clock frequency. I have a 40MHz
oscillator onboard and the 80Mhz is obtained by a DCM. I set the DCM
to let the system work at 40MHz (with some small modification in the
logic to let the external communication possible (RAM, external chips
which run at 40MHz), I changed the constraints on PERIOD AND OFFSETs
and the system was working. Ok, it is a matter of speed, I thought. No
it does not. Because, when I modified the VHDL code, or II added a
Chipscope core to debug my modifications, the design was no more able
to perform correct operations nor to communicate with some external
chips creating corrupted data. Even if ALL the constraints at 40MHz
are met.
I tried to overconstrain the design (real clock speed at 40MHz,
constraints to 50MHz or 60Mhz) and it works if I do not modify the
VHDL code slightly=85
For example leaving the VHDL code written by myself as it is and
adding a CHIPSCOPE analyzer CORE the behaviour of my FPGA is totally
different (all the constraints met, as usual).


Thus my doubts are:
Why, if the constraints are met, if SETUP and HOLD time are well
controlled by the Synthesis tool, my FPGA corrupts data?
Do I have to expect something like this? I mean, if the optimization
process is done by the ISE toolsuite, the translation the mapping,
routing and so on, should I trust the timing report results or should
I expect strange behaviour when I program my FPGA?
I am in the FPGA world since no more than 3 years and I never seen
something like this. Can somebody who has more experience tell me if
this is usual, if something like this is normal in a complex FPGA
design?
My boss usually programmed old QUICKLOGIC FPGAs using schematics and
he switched, under my advice, to XILINX Spartan 3A (not DSP) He
modified the schematics only a bit, using no constraints at all, doing
weird things with the clock,


Some info:
1_I have no possibility to check if the FPGA HW is broken or not. X-
ray or what else. I just wait for a new board which should be backed
carefully
2_I have no chances to perform post route simulations for the whole
project (I am in a hurry) and with my old design I did not do it
(SPARTAN 2) and everything was perfectly working (also without setting
any constraint over PERIOD or OFFSET)
3_I have 3 boards, when I program them with the same bitstream they
behave sometimes differently.
4_I also tried to run the synthesis SW on a different computer and
upgrade the ISE toolsuite to the latest version (ISE 12.4 Logic
Edition) but after compiling nothing changes

Article: 150504
Subject: Re: FPGA changes behaviour when the resource's usage percentage changes
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Tue, 25 Jan 2011 03:35:10 -0600
Links: << >>  << T >>  << A >>
>Good day to everybody,
>
>I have a problem with my new FPGA design. After a long time using
>Spartan 2 my company migrated to SPARTAN 3A 3400 DSP on a BGA csg484
>package. We had a lot of problems soldering this CSG484 packages and
>the whole board has been baked 2 times. The first time the balls were
>not melted totally and didn=92t solder completely the FPGAs to the the
>PCB, due to a bad temperature profile. The same PCBs and the same
>FPGAs has been baked another time with the correct temperature profile
>and the balls were melted properly, the daisy chain was recognized and
>the FPGA were possible to be programmed.
>
>Since the beginning we had problems in the communication between FPGAs
>and other onboard chips.
>I program in VHDL and my code is correctly written from the
>algorithmic point of view. It matches the requirements that I have set
>to communicate with the other chips onboard and perform the correct
>computations on the data that must be processed. I performed a post
>synthesis simulation of each and every block that forms the design.
>The aim of the design is to run @ 80Mhz speed.
>The problem is that even setting the constraints over period, duty
>cycle, OFFSET IN and OUT, with all the constraints met in the timing
>report, the FPGA behaves in a totally different way if I change the
>compiling settings (for example changing from AREA to SPEED goals, or
>changing the state machine implementation from =93one hot=94 to
=93auto=94)=
> or
>modifying the VHDL code slightly.
>Thus I decided to decrease the clock frequency. I have a 40MHz
>oscillator onboard and the 80Mhz is obtained by a DCM. I set the DCM
>to let the system work at 40MHz (with some small modification in the
>logic to let the external communication possible (RAM, external chips
>which run at 40MHz), I changed the constraints on PERIOD AND OFFSETs
>and the system was working. Ok, it is a matter of speed, I thought. No
>it does not. Because, when I modified the VHDL code, or II added a
>Chipscope core to debug my modifications, the design was no more able
>to perform correct operations nor to communicate with some external
>chips creating corrupted data. Even if ALL the constraints at 40MHz
>are met.
>I tried to overconstrain the design (real clock speed at 40MHz,
>constraints to 50MHz or 60Mhz) and it works if I do not modify the
>VHDL code slightly=85
>For example leaving the VHDL code written by myself as it is and
>adding a CHIPSCOPE analyzer CORE the behaviour of my FPGA is totally
>different (all the constraints met, as usual).
>
>
>Thus my doubts are:
>Why, if the constraints are met, if SETUP and HOLD time are well
>controlled by the Synthesis tool, my FPGA corrupts data?
>Do I have to expect something like this? I mean, if the optimization
>process is done by the ISE toolsuite, the translation the mapping,
>routing and so on, should I trust the timing report results or should
>I expect strange behaviour when I program my FPGA?
>I am in the FPGA world since no more than 3 years and I never seen
>something like this. Can somebody who has more experience tell me if
>this is usual, if something like this is normal in a complex FPGA
>design?
>My boss usually programmed old QUICKLOGIC FPGAs using schematics and
>he switched, under my advice, to XILINX Spartan 3A (not DSP) He
>modified the schematics only a bit, using no constraints at all, doing
>weird things with the clock,
>
>
>Some info:
>1_I have no possibility to check if the FPGA HW is broken or not. X-
>ray or what else. I just wait for a new board which should be backed
>carefully
>2_I have no chances to perform post route simulations for the whole
>project (I am in a hurry) and with my old design I did not do it
>(SPARTAN 2) and everything was perfectly working (also without setting
>any constraint over PERIOD or OFFSET)
>3_I have 3 boards, when I program them with the same bitstream they
>behave sometimes differently.
>4_I also tried to run the synthesis SW on a different computer and
>upgrade the ISE toolsuite to the latest version (ISE 12.4 Logic
>Edition) but after compiling nothing changes
>

I cant see any reason why you should be having any problems running at 80
MHz. If you have checked the timing report and there are no reported
problems then you should be fine. You shouldnt really need to do a post
route sim. I have worked on designs running with 400 MHz DDR memory without
the need for a post route sim. You dont say what chips you are interfacing
with but at 80 MHz you shouldnt have any real problems as long as you are
using correct design techniques and your board is routed correctly. A bit
of an unknown is the soldering of your chips. It seems a bit of a mystery
to me why your manufacturer is having so many problems soldering these
devices. At the end of the day if you cant start off with a good working
pcb then you could end up going round in circles.

Regards

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

Article: 150505
Subject: Re: Xilinx news
From: David Brown <david@westcontrol.removethisbit.com>
Date: Tue, 25 Jan 2011 10:46:11 +0100
Links: << >>  << T >>  << A >>
On 24/01/2011 18:21, John Larkin wrote:
> On Mon, 24 Jan 2011 09:09:42 +0100, David Brown
> <david@westcontrol.removethisbit.com>  wrote:
>
>> On 23/01/2011 06:10, John Larkin wrote:
>>> On Sat, 22 Jan 2011 23:03:16 -0600, "krw@att.bizzzzzzzzzzzz"
>>> <krw@att.bizzzzzzzzzzzz>   wrote:
>>>
>>>> On Sat, 22 Jan 2011 18:20:55 -0800, John Larkin
>>>> <jjlarkin@highNOTlandTHIStechnologyPART.com>   wrote:
>>>>
>>>>> http://www.eetimes.com/electronics-news/4212400/Xilinx-to-shutter-French-R-D-operation
>>>>>
>>>>> Yikes, this explains some stuff. I wonder how long it will take to
>>>>> undo the damage.
>>>>
>>>> Damage?  The damage caused by closing a software development lab?
>>>
>>> I meant the damage likely *done* by that lab. We'd been speculating
>>> how Xininx managed to snarl up their software so thoroughly, and
>>> whether they will ever get it fixed. I can't imagine why they'd
>>> outsource something this important to France.
>>>
>>
>> I find it hard to believe that supposedly educated, intelligent and
>> experienced engineers can post such ignorant xenophobic drivel.
>
> Well, two facts exist:
>
> 1. Their software is a nightmare, and it's costing them business
>
> 2. They are dumping the French operation.
>

Fair enough.

> The software is the heart of an FPGA company. The very architecture of
> the chip has to be coordinated with possible compiler strategies. The
> idea of outsourcing anything this important to a group 8 or 9 time
> zones away, working in another language, in a country where it's
> almost impossible to fire incompetant workers, where people take long
> lunches with wine and don't work weekends, just amazes me.
>

I am also not a fan of outsourcing, and I agree 100% that time 
differences and language differences can be a big problem.  It may well 
have contributed to Xilinx's software problems - that depends on how the 
development process was organised and managed.

All I object to is the implication that the problems occurred because 
the developers were French - an "explanation" that has been repeated 
here several times as though that was all that anyone needs to know.

The fact is, there are competent and incompetent people in all 
countries.  Developing software like FPGA design software is hard, for 
many reasons.  None of us can tell if these particular developers did a 
good job with a bad spec, or a bad job with a good spec, or where the 
problem lies (though ultimately the buck must land at the top-level of 
Xilinx management).

European work laws and work traditions are different from those in the 
USA.  But there is no reason to suggest that this in any way translates 
to Americans doing better work than Europeans.  You find it hard to 
understand that some Europeans take long lunches (lunchtime alcohol is 
quite rare these days except in wine-making regions, or in "business 
lunches" - just like in the USA).  Europeans find it hard to understand 
how people can concentrate on work knowing they could be fired just 
because the boss is having a bad hair day.  It's not better or worse, 
it's different.


>>
>> Xilinx (or rather, their users and customers) have trouble with the
>> Xilinx software because the Xilinx leadership do not prioritise it
>> appropriately, and (apparently) do not listen to or understand the
>> issues customers have with the software.  They alone are at fault.  It
>> could well be that the main management fault was to hire a development
>> team that was not competent to do the development - but the problem is
>> their lack of competence, not their nationality!
>
> I'd have been equally surprised had they outsourced anything this
> core-critical to any other country that far from San Jose. Big
> Software is nearly impossible to manage even without an ocean in the
> way.
>

Fair enough, and I agree here.  Maybe I overreacted to the references to 
France - I read your post as a specific condemnation of the lab having 
been in France, rather than a general condemnation of the lab being 
outsourced.  It is not clear to me whether I inferred too much, or 
whether you implied too much - if it is the former, then I apologise for 
overreacting; if it is the later, then I hope you can see my point.

>
>>
>> I know that sci.electronics.design is a hangout for mostly geriatric
>> American right-wingers who like to spend their free time blaming the
>> world's ills on "leftist weenies", foreigners, atheists, intellectuals,
>> and other dangerous sub-humans.
>
> Jim isn't typical.
>

No, he stands out a bit even in s.e.d.  But he isn't alone, either. 
However, it makes the group good for an argument sometimes, if time 
allows - there's no point arguing if everyone agrees, and s.e.d. is a 
group where people don't hold back in their disagreements!

mvh.,

David



Article: 150506
Subject: Re: FPGA changes behaviour when the resource's usage percentage changes
From: Emanuele83 <emanuele83katamail@googlemail.com>
Date: Tue, 25 Jan 2011 01:53:35 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 25, 10:35=A0am, "maxascent"
<maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote:
> >Good day to everybody,
>
> >I have a problem with my new FPGA design. After a long time using
> >Spartan 2 my company migrated to SPARTAN 3A 3400 DSP on a BGA csg484
> >package. We had a lot of problems soldering this CSG484 packages and
> >the whole board has been baked 2 times. The first time the balls were
> >not melted totally and didn=3D92t solder completely the FPGAs to the the
> >PCB, due to a bad temperature profile. The same PCBs and the same
> >FPGAs has been baked another time with the correct temperature profile
> >and the balls were melted properly, the daisy chain was recognized and
> >the FPGA were possible to be programmed.
>
> >Since the beginning we had problems in the communication between FPGAs
> >and other onboard chips.
> >I program in VHDL and my code is correctly written from the
> >algorithmic point of view. It matches the requirements that I have set
> >to communicate with the other chips onboard and perform the correct
> >computations on the data that must be processed. I performed a post
> >synthesis simulation of each and every block that forms the design.
> >The aim of the design is to run @ 80Mhz speed.
> >The problem is that even setting the constraints over period, duty
> >cycle, OFFSET IN and OUT, with all the constraints met in the timing
> >report, the FPGA behaves in a totally different way if I change the
> >compiling settings (for example changing from AREA to SPEED goals, or
> >changing the state machine implementation from =3D93one hot=3D94 to
> =3D93auto=3D94)=3D
> > or
> >modifying the VHDL code slightly.
> >Thus I decided to decrease the clock frequency. I have a 40MHz
> >oscillator onboard and the 80Mhz is obtained by a DCM. I set the DCM
> >to let the system work at 40MHz (with some small modification in the
> >logic to let the external communication possible (RAM, external chips
> >which run at 40MHz), I changed the constraints on PERIOD AND OFFSETs
> >and the system was working. Ok, it is a matter of speed, I thought. No
> >it does not. Because, when I modified the VHDL code, or II added a
> >Chipscope core to debug my modifications, the design was no more able
> >to perform correct operations nor to communicate with some external
> >chips creating corrupted data. Even if ALL the constraints at 40MHz
> >are met.
> >I tried to overconstrain the design (real clock speed at 40MHz,
> >constraints to 50MHz or 60Mhz) and it works if I do not modify the
> >VHDL code slightly=3D85
> >For example leaving the VHDL code written by myself as it is and
> >adding a CHIPSCOPE analyzer CORE the behaviour of my FPGA is totally
> >different (all the constraints met, as usual).
>
> >Thus my doubts are:
> >Why, if the constraints are met, if SETUP and HOLD time are well
> >controlled by the Synthesis tool, my FPGA corrupts data?
> >Do I have to expect something like this? I mean, if the optimization
> >process is done by the ISE toolsuite, the translation the mapping,
> >routing and so on, should I trust the timing report results or should
> >I expect strange behaviour when I program my FPGA?
> >I am in the FPGA world since no more than 3 years and I never seen
> >something like this. Can somebody who has more experience tell me if
> >this is usual, if something like this is normal in a complex FPGA
> >design?
> >My boss usually programmed old QUICKLOGIC FPGAs using schematics and
> >he switched, under my advice, to XILINX Spartan 3A (not DSP) He
> >modified the schematics only a bit, using no constraints at all, doing
> >weird things with the clock,
>
> >Some info:
> >1_I have no possibility to check if the FPGA HW is broken or not. X-
> >ray or what else. I just wait for a new board which should be backed
> >carefully
> >2_I have no chances to perform post route simulations for the whole
> >project (I am in a hurry) and with my old design I did not do it
> >(SPARTAN 2) and everything was perfectly working (also without setting
> >any constraint over PERIOD or OFFSET)
> >3_I have 3 boards, when I program them with the same bitstream they
> >behave sometimes differently.
> >4_I also tried to run the synthesis SW on a different computer and
> >upgrade the ISE toolsuite to the latest version (ISE 12.4 Logic
> >Edition) but after compiling nothing changes
>
> I cant see any reason why you should be having any problems running at 80
> MHz. If you have checked the timing report and there are no reported
> problems then you should be fine. You shouldnt really need to do a post
> route sim. I have worked on designs running with 400 MHz DDR memory witho=
ut
> the need for a post route sim. You dont say what chips you are interfacin=
g
> with but at 80 MHz you shouldnt have any real problems as long as you are
> using correct design techniques and your board is routed correctly. A bit
> of an unknown is the soldering of your chips. It seems a bit of a mystery
> to me why your manufacturer is having so many problems soldering these
> devices. At the end of the day if you cant start off with a good working
> pcb then you could end up going round in circles.
>
> Regards
>
> Jon =A0 =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

I do not know, but we are not able to find somebody really able to
perform a good soldering of this BGA packages. we've got 4 PCB for
prototyping and nobody is able to solder this stuff... sometimes the
VCC int is shorted, sometimes the chain is not possible to be
detected...
Yeah, ok the pcb has 12 layers with a lot of power planes, but it is
just a matter to use the correct temp profile.... Uff.. I do hope that
is a matter of HW....

Somebody on xilinx forum was complaining about my state machines reset
path. look at the example:

histogram_calculation_process : process (clk_120)
begin
if clk_120'event and clk_120=3D'1' then -- clk rising edge
   if rst /=3D '1' then -- not reset
      case state_m_1 is
	 when idle =3D>
              A_tcspc <=3D input_a;
              B_tcspc <=3D input_b;
              state_m_1 <=3D state_1;
	 when state_1 =3D>
	      output_sum <=3D S;
              state_m_1 <=3D idle;
	 when others =3D> null;
      end case
   else
     state_m_1 <=3D idle;
   end if;
end if;

I always used it and once that it is synchronized with the clock I do
not see a reason to do it differently... any advice?

Tnx
Emanuele

Article: 150507
Subject: Re: Xilinx news, David Brown and ""Xenophobia"" (see H1b FRAUD!)
From: David Brown <david@westcontrol.removethisbit.com>
Date: Tue, 25 Jan 2011 11:13:29 +0100
Links: << >>  << T >>  << A >>
On 24/01/2011 20:59, Greegor wrote:
> On Jan 24, 2:09 am, David Brown<da...@westcontrol.removethisbit.com>
> wrote:
>> I find it hard to believe that supposedly educated, intelligent and
>> experienced engineers can post such ignorant xenophobic drivel.
>>
>> Xilinx (or rather, their users and customers) have trouble with the
>> Xilinx software because the Xilinx leadership do not prioritise it
>> appropriately, and (apparently) do not listen to or understand the
>> issues customers have with the software.  They alone are at fault.  It
>> could well be that the main management fault was to hire a development
>> team that was not competent to do the development - but the problem is
>> their lack of competence, not their nationality!
>>
>> I know that sci.electronics.design is a hangout for mostly geriatric
>> American right-wingers who like to spend their free time blaming the
>> world's ills on "leftist weenies", foreigners, atheists, intellectuals,
>> and other dangerous sub-humans.
>
> You left out OUTSOURCING, Downsizing,
> dumping out staff en masse and hiring them
> all back as contractors to avoid social
> responsibilities, Pensions and raiding thereof,
> H1b visas and the way corporations take
> classes on how to BS around the law
> that requires them to hire qualified US people
> for the jobs first, etc.

I'd change "qualified US people" to "qualified local people", because 
this is an international group, not a US group, and the same thing 
applies to people in most countries.  Apart from that I'd agree that a 
lot of the current economic problems in the West stem these sorts of 
things.

> (Where WERE you
> back in Jan 2010 when that was discussed?)
>

I haven't followed s.e.d. much for a while - the signal-to-noise ratio 
is quite low, but when there is an interesting thread it can often be 
very addictive and time-consuming.

> I would EXPECT that most US Engineers
> would be very well focused on all of those
> threats to their livelyhood, wouldn't you??
>

Again, this is /not/ a US issue - though as is often the case, the US 
seems to be leading the West (for good and for bad) in these practices. 
  Typically the UK follows first, while the continental European 
countries have stronger laws protecting employees and are less affected. 
  But yes, these are things that affect many engineers around the world.



Article: 150508
Subject: Re: FPGA changes behaviour when the resource's usage percentage changes
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Tue, 25 Jan 2011 10:23:50 -0000
Links: << >>  << T >>  << A >>
> I do not know, but we are not able to find somebody really able to
> perform a good soldering of this BGA packages. we've got 4 PCB for
> prototyping and nobody is able to solder this stuff... sometimes the
> VCC int is shorted, sometimes the chain is not possible to be
> detected...
> Yeah, ok the pcb has 12 layers with a lot of power planes, but it is
> just a matter to use the correct temp profile.... Uff.. I do hope that
> is a matter of HW....


You need to find an assembly house with a Vapour Phase reflow oven, from
what I understand (from my assembly guys) this almost guarantees a good
result.

Even without this BGAs are pretty run of the mill, any competent assembly
house should be able to get this down.

Are you going to a quality assembly house or the cheapest one?


Nial 



Article: 150509
Subject: Re: Xilinx news
From: David Brown <david@westcontrol.removethisbit.com>
Date: Tue, 25 Jan 2011 11:26:06 +0100
Links: << >>  << T >>  << A >>
On 24/01/2011 23:17, John Larkin wrote:
> On Mon, 24 Jan 2011 11:51:12 -0800 (PST), rickman<gnuarm@gmail.com>
> wrote:
<snip>
>> But none of this has to do with nationality.
>>
>> Rick
>
>

It is important to distinguish between nationality and a country's laws 
and bureaucracy - the regulations in John's quotation are about a 
country's regulations, not an issue with the people.

> http://www.eetimes.com/electronics-news/4212317/Xilinx--sales-fall-short-of-estimates
>
> "Xilinx recorded $4.3 million worth of restructuring charges during
> the recently concluded quarter. Olson said the charges were greater
> than expected because the company is closing its software development
> operation in France, where regulations make eliminating jobs
> difficult."
>
> John
>

Clearly we don't know /what/ regulations are at issue here, as there 
could be many.

In general, you have to have good reason for firing people in Europe, 
and normally you have to give significant notice (I don't know the 
details for France, but 3 months is standard here in Norway.  Of course, 
this also means you can't quit your job without giving 3 months notice - 
it works both ways).  But cutting staff because you are downsizing /is/ 
a good reason, though you might have to pay some sort of severance pay 
or other compensation.  You can't just tell employees to clear their 
desks on the day, but you certainly can eliminate jobs.

So maybe there is more happening here - perhaps there is some sort of 
agreement that depends on Xilinx employing a certain number of people, 
tied to tax breaks, military contracts, etc.


Article: 150510
Subject: Re: FPGA changes behaviour when the resource's usage percentage changes
From: Emanuele83 <emanuele83katamail@googlemail.com>
Date: Tue, 25 Jan 2011 02:31:10 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 25, 11:23=A0am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > I do not know, but we are not able to find somebody really able to
> > perform a good soldering of this BGA packages. we've got 4 PCB for
> > prototyping and nobody is able to solder this stuff... sometimes the
> > VCC int is shorted, sometimes the chain is not possible to be
> > detected...
> > Yeah, ok the pcb has 12 layers with a lot of power planes, but it is
> > just a matter to use the correct temp profile.... Uff.. I do hope that
> > is a matter of HW....
>
> You need to find an assembly house with a Vapour Phase reflow oven, from
> what I understand (from my assembly guys) this almost guarantees a good
> result.
>
> Even without this BGAs are pretty run of the mill, any competent assembly
> house should be able to get this down.
>
> Are you going to a quality assembly house or the cheapest one?
>
> Nial

I do not know if it is the cheapest one. I know only that they are
soldering with IRs reflow.
I am not the one in the office who has the choice... Now we sent a
board to be reworked and new FPGAs will be soldered.
The point is that if they do it with the bad temp profile I am afraid
that the FPGA can be damaged...

Article: 150511
Subject: Re: FPGA changes behaviour when the resource's usage percentage changes
From: Mike Perkins <spam@spam.com>
Date: Tue, 25 Jan 2011 11:53:01 +0000
Links: << >>  << T >>  << A >>
On 25/01/2011 10:31, Emanuele83 wrote:
> On Jan 25, 11:23 am, "Nial Stewart"
> <nial*REMOVE_TH...@nialstewartdevelopments.co.uk>  wrote:
>>> I do not know, but we are not able to find somebody really able to
>>> perform a good soldering of this BGA packages. we've got 4 PCB for
>>> prototyping and nobody is able to solder this stuff... sometimes the
>>> VCC int is shorted, sometimes the chain is not possible to be
>>> detected...
>>> Yeah, ok the pcb has 12 layers with a lot of power planes, but it is
>>> just a matter to use the correct temp profile.... Uff.. I do hope that
>>> is a matter of HW....
>>
>> You need to find an assembly house with a Vapour Phase reflow oven, from
>> what I understand (from my assembly guys) this almost guarantees a good
>> result.
>>
>> Even without this BGAs are pretty run of the mill, any competent assembly
>> house should be able to get this down.
>>
>> Are you going to a quality assembly house or the cheapest one?
>>
>> Nial
>
> I do not know if it is the cheapest one. I know only that they are
> soldering with IRs reflow.
> I am not the one in the office who has the choice... Now we sent a
> board to be reworked and new FPGAs will be soldered.
> The point is that if they do it with the bad temp profile I am afraid
> that the FPGA can be damaged...

My experience is that as long as the profile is sufficient for solder to 
flow, and with a quality paste, it's unusual for things to go wrong.  I 
have also found from building prototypes in-house that whilst going over 
temperature is not disasterous, though may affect long term reliability.

Do you have a backup of an old snapshot of your design?  Can you check 
the PCB works in the same way it did when the snapshort was taken?

Whilst a 80 MHz clock is low, there are a myriad of reasons why a design 
change may stop the FPGA from funtioning as exected.  I assume you have 
checked the design will work with the specified clock rate?  There maybe 
issues with simulatenous switching, or through compromised decoupling.

Personally I would use, and I beleive its more conventional for:

histogram_calculation_process : process (clk_120)
begin
   if rst = '1' then -- not reset
      state_m_1 <= idle;
   elsif clk_120'event and clk_120='1' then -- clk rising edge
       case state_m_1 is
	 when idle =>
               A_tcspc <= input_a;
               B_tcspc <= input_b;
               state_m_1 <= state_1;
	 when state_1 =>
	      output_sum <= S;
               state_m_1 <= idle;
	 when others => null;
       end case
    end if;
end if;

This also reduces the complexity of the LUT.

Hope this helps.

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 150512
Subject: how to read an image from the PC and store it in FPGA ROM
From: "rizi" <cyclon786@n_o_s_p_a_m.gmail.com>
Date: Tue, 25 Jan 2011 06:44:10 -0600
Links: << >>  << T >>  << A >>
Hi

i am working on FPGAs.
As i am new in vhdl so i do not know how to deal with images in vhdl.
i want to read an image that is already stored in PC.
please can you help me how to read an image from the PC and store it in
FPGA ROM ?
(i want to do this in verilog or vhdl)

your suggestion will be appreciated.

Thank you
Rizi

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

Article: 150513
Subject: newbie looking for Xilinx help
From: "whitehat09" <whitehat09@n_o_s_p_a_m.gmail.com>
Date: Tue, 25 Jan 2011 06:44:20 -0600
Links: << >>  << T >>  << A >>
Hi everyone,
Im a masters student at the University of New Hampshire. For my thesis Im
working with a software defined radio (WARP from rice university) which
uses a Xilinx Virtex-4 FPGA. Previous to becoming a MS student I have
mostly used matlab for coding, had 1 course on C 4+ years ago, and 0
experience with VHDL. So its safe to say Im having a difficult time
understanding how Xilinx EDK/ISE works or even simple c header files. What
Im looking for is any material that would give a better understanding of
what the files are doing and how to better appreciate FPGAs. I was hoping
for web links, books, etc. specific to xilinx but I expect anything anyone
here suggests would be a great help.

Thanks

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

Article: 150514
Subject: Zero Padding Circuit Design
From: "hamkanen" <hamkanen@n_o_s_p_a_m.gmail.com>
Date: Tue, 25 Jan 2011 06:44:28 -0600
Links: << >>  << T >>  << A >>
Hi all, 

i want to design a zero padding circuit. 
The problem is the number of zero depends on the number of input data.

Let's say i have 2000 data input, the number of output data should be
divided by factor of 600. 
So number of zero padding = 400 --> (2000+400)/600 = integer value
Remember that number of data input could vary, so it will change the number
of zero padding  

Can you give me suggestion, how to implement zero padding circuit in
hardware?

*I plan to design the circuit 10 port parallely, so for above example, it
will need 200 clock to input all data.

Thanks

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

Article: 150515
Subject: tft lcd with xilinx fpga
From: "frozen001" <lciotti1@n_o_s_p_a_m.gmail.com>
Date: Tue, 25 Jan 2011 06:44:58 -0600
Links: << >>  << T >>  << A >>
I am attempting to interface a 4.3" tft LCD with a xilinx fpga.  Is there a
really comprehensive tutorial on doing this?  I am quite new to all of this
so the more detailed the better.  

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

Article: 150516
Subject: Re: FPGA changes behaviour when the resource's usage percentage changes
From: KJ <kkjennings@sbcglobal.net>
Date: Tue, 25 Jan 2011 05:22:37 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 25, 3:42=A0am, Emanuele83 <emanuele83katam...@googlemail.com>
wrote:
> My boss usually programmed old QUICKLOGIC FPGAs using schematics and
> he switched, under my advice, to XILINX Spartan 3A (not DSP) He
> modified the schematics only a bit, using no constraints at all, doing
> weird things with the clock,
>

You might want to look into these 'weird things with the clock' a bit
deeper.

Some other points to ponder
1. Do you have multiple clocks in your design?  If so...
1a. When you did the timing analysis do you have the tool set up to
analyze *across* clock domains?
1b. Based on the timing report of clock domain crossings, are each and
every crossing handled correctly?

2. Check power.  With the BGA and suspect soldering it will be
impossible to verify whether good power is making it to the die, but
maybe there is a power issue with the board that can be seen with the
scope.

3. Check input clock signal integrity

4. Since you're using DCM, does that allow you to bring out some form
of 'locked' output to indicate that the DCM is locked on to the input
clock properly?  If so, bring it out and see if the DCM ever comes
'unlocked'.  Alternatively, bring the DCM clock output to an output
pin.  The point of this exercise is to check that the FPGA clock is
actually working properly.  If it's not, then your problem is rooted
in #2 or #3.

> 3_I have 3 boards, when I program them with the same bitstream they
> behave sometimes differently.

The root cause of different behavior will be:
- Power supply to the part
- Timing (which includes clock domain transfers as mentioned above)
- Assembly issues (which you currently suspect)

Kevin Jennings

Article: 150517
Subject: Re: Zero Padding Circuit Design
From: Chris Maryan <kmaryan@gmail.com>
Date: Tue, 25 Jan 2011 05:33:38 -0800 (PST)
Links: << >>  << T >>  << A >>
I'm not sure what part is giving you trouble. Without giving away the answe=
r, think about using some combination of appropriately triggered counters. =
Try walking through your problem (on paper) for various amounts of input da=
ta - then it should become obvious how when you should trigger various even=
ts and how much the counters will count to before they trigger something el=
se.

Chris

Article: 150518
Subject: Re: tft lcd with xilinx fpga
From: Chris Maryan <kmaryan@gmail.com>
Date: Tue, 25 Jan 2011 05:44:39 -0800 (PST)
Links: << >>  << T >>  << A >>
RTFM is the universal answer for all of this. There may be some tutorials, =
but they likely won't cover the particular LCD you are using - that said, t=
ry Googling. The "M"'s in "RTFM" are the datasheets for the LCD and the FPG=
A.

Don't get overwhelmed by the size of the datasheets/manuals - odds are that=
 you don't need 90% of what's in them - stick with the basics.

- First start electrically - what does the data sheet for the LCD say is th=
e electrical format of the signals it accepts? (3.3V TTL? LVDS? 1.8V logic?=
 etc.). Then see the FPGA data sheet to see if you can find an IO standard =
that matches. Hook the two up accordingly.

- Next, write some basic VHDL/verilog/UCF files for the FPGA to instantiate=
 the signals to the LCD in your FPGA and set everything to the appropriate =
IO standard.

- Then dig into the LCD datasheet again and figure out what commands or dat=
a formating it needs and get cracking on a VHDL/verilog state machine or da=
ta formatter that accomplishes whatever it is that you want to do with the =
LCD. Depending on the application it was meant for, most LCDs are either co=
mmand and buffer based (that is, you write some commands to it, then write =
to a frame buffer on the LCD controller), or they are video stream based (i=
.e. no commands necessary, just send raw RGB data continuously).

Hope that helps.

Chris

Article: 150519
Subject: Re: FPGA changes behaviour when the resource's usage percentage changes
From: Emanuele83 <emanuele83katamail@googlemail.com>
Date: Tue, 25 Jan 2011 06:06:44 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 25, 2:22=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
> On Jan 25, 3:42=A0am, Emanuele83 <emanuele83katam...@googlemail.com>
> wrote:
>
> > My boss usually programmed old QUICKLOGIC FPGAs using schematics and
> > he switched, under my advice, to XILINX Spartan 3A (not DSP) He
> > modified the schematics only a bit, using no constraints at all, doing
> > weird things with the clock,
>
> You might want to look into these 'weird things with the clock' a bit
> deeper.
>
> Some other points to ponder
> 1. Do you have multiple clocks in your design? =A0If so...
> 1a. When you did the timing analysis do you have the tool set up to
> analyze *across* clock domains?
> 1b. Based on the timing report of clock domain crossings, are each and
> every crossing handled correctly?
>
> 2. Check power. =A0With the BGA and suspect soldering it will be
> impossible to verify whether good power is making it to the die, but
> maybe there is a power issue with the board that can be seen with the
> scope.
>
> 3. Check input clock signal integrity
>
> 4. Since you're using DCM, does that allow you to bring out some form
> of 'locked' output to indicate that the DCM is locked on to the input
> clock properly? =A0If so, bring it out and see if the DCM ever comes
> 'unlocked'. =A0Alternatively, bring the DCM clock output to an output
> pin. =A0The point of this exercise is to check that the FPGA clock is
> actually working properly. =A0If it's not, then your problem is rooted
> in #2 or #3.
>
> > 3_I have 3 boards, when I program them with the same bitstream they
> > behave sometimes differently.
>
> The root cause of different behavior will be:
> - Power supply to the part
> - Timing (which includes clock domain transfers as mentioned above)
> - Assembly issues (which you currently suspect)
>
> Kevin Jennings

thank you Kevin,

I do apologise, I did not finished the sentence about what my boss
does with his SPARTAN.
I would mean that, as old school, he use no debugger, no constraints,
he is getting the clock from a non-clk dedicated pins, adding buffers
just to delay signals until they working with the external
interfaces.. and the design works as expected (by him). my design,
though well written, and constrained, does not work as expected... It
is due, maybe, to my lack of experience....

My system has only one clock, now at 40MHz. For example I just changed
the constraints of IO pins drive strength from 8 to 6 being more
conservative and the behave changes...
I have already checked the DCM locked pin addressing it on a
testpoint, but it is always locked.
The clock signal was my first test. I modified the path and now goes
freely with a wire directly to the clock tree, there were some logic
on the clock path distorting the signal, and I bypassed it.

I'll try to check the power lines with an oscilloscope to check if
there are bounces...

Article: 150520
Subject: Re: Problem with iMpact
From: Gabor <gabor@alacron.com>
Date: Tue, 25 Jan 2011 06:13:48 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 24, 5:21=A0pm, ghelbig <ghel...@lycos.com> wrote:
> On Jan 24, 12:23=A0pm, Gabor <ga...@alacron.com> wrote:
>
>
>
> > On Jan 24, 1:50=A0pm, ghelbig <ghel...@lycos.com> wrote:
>
> > > I think that iMpact is messing with me.
>
> > > Here's what I do:
>
> > > 1) Create a bit file with ISE 11.5
> > > 2) Downloading the bit file to my Virtex-5 via JTAG. =A0(I'm using a
> > > DLC9G and WinXP)
> > > 3) Run a regression test on the system.
>
> > > If the regression test passes I do the following:
>
> > > 4) Create a MCS file with iMpact.
> > > 5) Load the MCS into the attached SPI chip (again, with the DLC9G)
> > > 6) Power cycle the board.
> > > 7) Re-run the regression test.
>
> > > Here's my issue:
>
> > > I have two bit files for this project. =A0One was created last month,
> > > one was created last week. =A0The steps above are repeated EXACTLY fo=
r
> > > the two bit files. =A0There are no warnings or errors generated with
> > > steps 2 through 6.
>
> > > Step 7 fails for one bit file, and passes for the other. =A0With one =
bit
> > > file, and chip never leaves the DONE state. =A0Keep in mind that both
> > > bit files load and run "just fine" when I load them through the JTAG
> > > port.
>
> > > Has anyone seen this before? =A0I haven't gotten any help from the
> > > factory yet.
>
> > > Regards,
> > > G.
>
> > The first thing I look for is whether the .mcs file was really created
> > correctly.
> > I have been burned by the ISE GUI grabbing an existing impact project
> > that
> > built a new .mcs file from an old .bit file.
>
> > If you look in the directory where the .mcs file was built, there
> > should also
> > be a .prm file with the same base file name. =A0In this file you can se=
e
> > the
> > name and modification date of the .bit file(s) that were used in
> > creating
> > the .mcs file.
>
> > Also I have had some issues with indirect SPI programming using
> > impact. =A0However usually these show up as an error when you go to
> > verify the .mcs file in SPI flash. =A0When you say "never leaves the
> > DONE state" do you mean that DONE never goes high? =A0Or does
> > DONE go high, but the chip never comes out of reset. =A0The latter
> > condition can be bitstream-dependent although I've never seen
> > this behavior when using Master-SPI config mode. =A0Just be sure
> > that you use the default startup clock (CCLK) when you run
> > BitGen.
>
> > -- Gabor
>
> It is the "DONE goes high, but the chip never comes out of reset"
> case. =A0It seems to be bit-stream dependent, I can make good MCS files
> from old BIT files.
>
> I'm stumped. =A0The only thing I can see different in the two cases
> (works, does not work) from start to finish is the Verilog code.
>
> G.

Is there anything in the Verilog code that changes that might affect
the reset?  Does your reset depend on PLL or DCM lock?  That
can often be affected by seemingly unrelated changes especially
if there is a noisy clock input or insufficient power supply bypass.

-- Gabor

Article: 150521
Subject: Re: Overview for non-technicals.
From: "rupertlssmith@googlemail.com" <rupertlssmith@googlemail.com>
Date: Tue, 25 Jan 2011 06:14:56 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 21, 5:52=A0pm, rickman <gnu...@gmail.com> wrote:
> What's a BA? =A0I assume this is someone who doesn't really know
> anything about either software or hardware.

BA =3D Business Analyst. In this case, with a history as a developer, so
not so clueless as is sometimes the case.

Article: 150522
Subject: Re: newbie looking for Xilinx help
From: Emanuele83 <emanuele83katamail@googlemail.com>
Date: Tue, 25 Jan 2011 06:20:14 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 25, 1:44=A0pm, "whitehat09" <whitehat09@n_o_s_p_a_m.gmail.com>
wrote:
> Hi everyone,
> Im a masters student at the University of New Hampshire. For my thesis Im
> working with a software defined radio (WARP from rice university) which
> uses a Xilinx Virtex-4 FPGA. Previous to becoming a MS student I have
> mostly used matlab for coding, had 1 course on C 4+ years ago, and 0
> experience with VHDL. So its safe to say Im having a difficult time
> understanding how Xilinx EDK/ISE works or even simple c header files. Wha=
t
> Im looking for is any material that would give a better understanding of
> what the files are doing and how to better appreciate FPGAs. I was hoping
> for web links, books, etc. specific to xilinx but I expect anything anyon=
e
> here suggests would be a great help.
>
> Thanks
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

this is a VHDL primer

http://www.seas.upenn.edu/~ese201/vhdl/vhdl_primer.html

it is useful to understand how VHDL works. Please note that VHDL can
be used not only for FPGA, but also for other applications.
It might be useful if you have an idea of what is logic synthesis, how
digital electronics works from the HW point of view, and the internal
structure of an FPGA. Xilinx's white papers should be useful.

here a book that can be a beginning, a learn by example path to
follow:
http://www.amazon.com/FPGA-Prototyping-VHDL-Examples-Spartan-3/dp/047018531=
7

you can find a preview on google books. Please buy it (is not so
expensive and if you are a student it can be purchased by your
University) and do not download it from some weird locations like
rapidshare or emule or torrent or something else. The contents are not
guaranteed in that case!

http://books.google.com/books?id=3DmwUV7ZK9l9gC&printsec=3Dfrontcover&dq=3D=
FPGA+Prototyping+by+VHDL+Examples:+Xilinx+Spartan-3+Version&hl=3Den&src=3Db=
mrr&ei=3D89s-TajSHcrj4gbExbHCCg&sa=3DX&oi=3Dbook_result&ct=3Dresult&resnum=
=3D1&ved=3D0CDYQ6AEwAA#v=3Donepage&q&f=3Dfalse

regards
Emanuele



Article: 150523
Subject: Re: FPGA changes behaviour when the resource's usage percentage changes
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Tue, 25 Jan 2011 06:36:27 -0800 (PST)
Links: << >>  << T >>  << A >>
On 25 Jan., 15:06, Emanuele83 <emanuele83katam...@googlemail.com>
wrote:
> On Jan 25, 2:22=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
> > On Jan 25, 3:42=A0am, Emanuele83 <emanuele83katam...@googlemail.com>
> > wrote:
>
> > > My boss usually programmed old QUICKLOGIC FPGAs using schematics and
> > > he switched, under my advice, to XILINX Spartan 3A (not DSP) He
> > > modified the schematics only a bit, using no constraints at all, doin=
g
> > > weird things with the clock,
>
> > You might want to look into these 'weird things with the clock' a bit
> > deeper.
>
> > Some other points to ponder
> > 1. Do you have multiple clocks in your design? =A0If so...
> > 1a. When you did the timing analysis do you have the tool set up to
> > analyze *across* clock domains?
> > 1b. Based on the timing report of clock domain crossings, are each and
> > every crossing handled correctly?
[..]
>
> My system has only one clock, now at 40MHz. For example I just changed

Your description ring my "clock domain" alarm bell.
You should ensure that every clock domain crossing is right, which
implies that you first need to identifiy all different clock domains.
Every input that is not synchron to your clock and proper constraint
is a different clock domain which requires appropriate handling of
these inputs. Internal clocks on the same frequency can form different
clock domains in case clock tree is splitted. This is easy seen in
netlist but sometimes not obvious in RTL code.

bye Thomas

Article: 150524
Subject: Re: FPGA changes behaviour when the resource's usage percentage changes
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 25 Jan 2011 14:48:51 GMT
Links: << >>  << T >>  << A >>
Emanuele83 <emanuele83katamail@googlemail.com> wrote:

>Good day to everybody,
>
>Chipscope core to debug my modifications, the design was no more able
>to perform correct operations nor to communicate with some external
>chips creating corrupted data. Even if ALL the constraints at 40MHz

IMHO this is a problem with unconstrained paths. Did you constrain
input to ff and ff to output paths? Did you constrain paths between
unrelated clock domains?

>Some info:
>1_I have no possibility to check if the FPGA HW is broken or not. X-
>ray or what else. I just wait for a new board which should be backed
>carefully
>2_I have no chances to perform post route simulations for the whole
>project (I am in a hurry) and with my old design I did not do it
>(SPARTAN 2) and everything was perfectly working (also without setting
>any constraint over PERIOD or OFFSET)
>3_I have 3 boards, when I program them with the same bitstream they
>behave sometimes differently.

This may be due to FPGA variations. I'd get the constraints sorted out
first. Perhaps you could buy a development board and verify your
design on that so you have a proper reference.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------



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