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
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
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
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 EilertArticle: 150503
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 changesArticle: 150504
>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.comArticle: 150505
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., DavidArticle: 150506
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: 150507On 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
> 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? NialArticle: 150509
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
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
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: 150512Hi 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.comArticle: 150513
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.comArticle: 150514
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.comArticle: 150515
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.comArticle: 150516
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 JenningsArticle: 150517
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. ChrisArticle: 150518
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. ChrisArticle: 150519
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
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. -- GaborArticle: 150521
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
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 EmanueleArticle: 150523
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 ThomasArticle: 150524
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:
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