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
Hi, Is it ok not to connect at least one DDR Address signal to a ddr controller? If so, should i connect it to GND or VCCIO? Thanks.Article: 110326
Antti, We are still characterizing the parts and process, so we don't want to put anything in the data sheet for V5 until we are done. But, there is no surge, or big Iccint that is required for V5... Austin Antti wrote: > Austin Lesea schrieb: > >> Manny, >> >> Just one comment: >> >> There has been no "in rush" or "bonus" current needed since Virtex II >> (V2, V2P, V4, V5 have no "inrush" for Vccint, the datasheet specifies >> the minimum Iccint required to power on and configure). >> >> What you describe was common for Virtex E, and older families. However, >> we decided that was unacceptable, so we fixed it (a long time ago, now). >> >> Austin >> > Austin, > > please check Xilinx publication EN049(v 1.3) page 2 > for Virtex-5 power requirements during configuration > > Antti >Article: 110327
John, I tried what you suggested, but I'm not having much luck because of some restrictions on TNM u sage and DCMs. The TNM_NET I specified feeds into a DCM_BASE, so I need it to derive all the child clocks. Page 279 of the cgd says, <SNIP> The TNM is pushed through the CLKDLL or DCM (as described below) only if the following conditions are met: =B7 The TNM group is used in exactly one PERIOD specification. =B7 The TNM group is not used in any FROM-TO or OFFSET specifications. =B7 The TNM group is not referenced in any user group definition. If any of the above conditions are not met, the TNM is not be pushed through. </SNIP> I tried the following in my UCF, but it fails. <SNIP> NET "adc_clk" TNM_NET =3D "TG_adc_clk"; TIMESPEC "TS_adc_clk" =3D PERIOD "TG_adc_clk" 4.0 ns HIGH 50 %; NET "adc_clk_dcm_clkfx" TNM =3D "TG_logic_clk"; TIMESPEC "TS_adcclk_to_logicclk" =3D FROM "TG_adc_clk" TO "TG_logic_clk" TIG; </SNIP> <SNIP> WARNING:XdmHelpers:793 - The TNM "TG_logic_clk" drives the CLKIN pin of DCM_ADV "adc_clkfx_dcm_inst". This TNM cannot be traced through the DCM_ADV because it is not used exclusively by one PERIOD specification. This TNM is used in the following user groups and/or specifications: TS_adcclk_to_logicclk=3DFROM TG_adc_clk TO TG_logic_clk TIG WARNING:XdmHelpers:625 - No instances driven from the following signals or pins are valid for inclusion in TNM group "TG_adc_clk". A TNM property on a pin or signal marks only the flip-flops, latches and/or RAMs which are directly or indirectly driven by that pin or signal. signal "adc_clk" WARNING:XdmHelpers:644 - No appropriate elements were found for the TNM group "TG_adc_clk". This group has been removed from the design. ERROR:XdmHelpers:650 - The period specification "TS_adc_clk" is invalid because the "TG_adc_clk" group was removed. ERROR:XdmHelpers:648 - The specification "TS_adcclk_to_logicclk" is invalid because its FROM group (TG_adc_clk) was removed. </SNIP> Do I have to manually derived all of the DCM clocks (I have a lot)? This seems ridiculous! Thanks, -Brandon JustJohn wrote: > On Oct 11, 8:03 am, "Brandon Jasionowski" <killerhe...@gmail.com> > wrote: > > > Why is ISE ignoring my constraint? > > Your statement: > > > The first two nets listed are assigned to a timing name belonging to > > paths that are asychronous to another clock. > > may show a mis-understanding of how the TNM and TNM_NET constraints > form timing groups (not "timing names", the name is just a label to > refer to the group). Timing groups are composed of instances of FFs, > memories, and other synchronous devices, they are _not_ composed of > nets. TNM_NET fans _forward_ from the named net and collects any > devices whose inputs are reached either directly or combinatorically > from that net. > > To get a clue what's happening, use Timing Analyzer to take a look at > the timing groups that are formed by your grouping constraints: > > > NET "ctrl1_clr" TNM_NET =3D "TN_ctrl_clr"; > > NET "ctrl2_clr" TNM_NET =3D "TN_ctrl_clr"; > > NET "sync_drpp_clr_inst/sync_r2<0>" TNM_NET =3D "TN_sync_drpp_clr"; > > NET "sync_drpp_clr_inst/sync_r2<1>" TNM_NET =3D "TN_sync_drpp_clr"; > > Look at the group "TN_ctrl_clr". > Does it contain "Source: ctrl2_ins/curr_st_FFd1 (FF)"? > Look at the group "TN_sync_drpp_clr". > Does it contain "Destination: sync_drpp_clr_inst/sync_r1_1 (FF)"? > (I'm guessing no on both...) > > If the groups don't contain the source and destination devices for the > timing path you want to ignore, the TIG constraint is not applied (or > worse, applied to a different set of sources/destinations that you did > not intend). > > Three possible suggestions are: > 1) If you want to ignore _all_ cross clock domain timing, you easily do > that with a TIG applied from your CLK1 group to your CLK2 group: > NET "adc_clk_dcm_clk0" TNM_NET "TG_Clk1"; > NET "adc_clk_dcm_clkfx" TNM_NET "TG_Clk2"; > TIMESPEC "TS_Clk1_to_Clk2" =3D FROM "TG_Clk1" TO "TG_Clk2" TIG; > (or whatever names you want to use for your TIMEGROUPsand TIMESPEC.) > I don't particularly like this though, it may hinder Place/Route by > allowing domain crossing nets to be excessively long, thus getting in > the way of more critical nets. It may be nicer to simply use a small > but achievable value: > TIMESPEC "TS_Clk1_to_Clk2" =3D FROM "TG_Clk1" TO "TG_Clk2" 2 ns; > (or whatever value works for you). > > 2) Closer to what you seem to want to do, use TPTHRU: > > NET "ctrl1_clr" TPTHRU=3D TH_clr; > NET "ctrl2_clr" TPTHRU=3D TH_clr; > and either: > TIMESPEC "TS_Thru_clr" =3D FROM "TG_Clk1" THRU "TH_clr" TO "TG_Clk2" TIG; > or possibly better for P/R: > TIMESPEC "TS_Thru_clr" =3D FROM "TG_Clk1" THRU "TH_clr" TO "TG_Clk2" 2 > ns; > > 3) To pick out only the particular paths that you show failing, use the > instance grouping constraint: > INST "ctrl2_ins/curr_st_FFd1" TNM "TG_Src1"; > INST "sync_drpp_clr_inst/sync_r1_1" TNM "TG_Dst1"; > TIMESPEC "TS_Src1_to_Dst1" =3D FROM "TG_Src1" TO "TG_Dst1" TIG; > or > TIMESPEC "TS_Src1_to_Dst1" =3D FROM "TG_Src1" TO "TG_Dst1" 2 ns; > > Hope one of these is of some help. > Regards, > John > > > I've been performing post-map static timing analysis and have noticed > > that my TIG UCF constraint is being ignored for some reason. Here is > > what I have: > > > > <SNIP> > > ## TIG > > NET "ctrl1_clr" TNM_NET =3D "TN_ctrl_clr"; > > NET "ctrl2_clr" TNM_NET =3D "TN_ctrl_clr"; > > NET "sync_drpp_clr_inst/sync_r2<0>" TNM_NET =3D "TN_sync_drpp_clr"; > > NET "sync_drpp_clr_inst/sync_r2<1>" TNM_NET =3D "TN_sync_drpp_clr"; > > TIMESPEC "TS_TIG_clr2synch" =3D FROM "TN_ctrl_clr" TO "TN_sync_drpp_clr" > > TIG; > > </SNIP> > > > > The first two nets listed are assigned to a timing name belonging to > > paths that are asychronous to another clock. This clock drives > > registered ports of an instance (synchronization circuit) with port > > name sync_r2(1:0). Normally I would edit the UCF manually, but it > > absorbed some of the signal names, so instead I used the constraint > > tool to generate the above. > > > > When I run timing I get the following: > > <SNIP> > > WARNING:Timing:3223 - Timing constraint PATH "TS_TIG_clr2synch_path" > > TIG; > > ignored during timing analysis. > > </SNIP> > > > > Here is one of the timing errors from the post-map static timing > > analyzer: > > <SNIP> > > Timing constraint: TS_adc_clk_dcm_clkfx =3D PERIOD TIMEGRP > > "adc_clk_dcm_clkfx" TS_adc_clk / 0.7 > > HIGH 50%; > > > > 278920 items analyzed, 4 timing errors detected. (4 setup errors, 0 > > hold errors) > > Minimum period is 8.415ns. > > -----------------------------------------------------------------------= ----=AD----- > > Slack: -0.270ns (requirement - (data path - clock path > > skew + uncertainty)) > > Source: ctrl2_ins/curr_st_FFd1 (FF) > > Destination: sync_drpp_clr_inst/sync_r1_1 (FF) > > Requirement: 0.571ns > > Data Path Delay: 0.590ns (Levels of Logic =3D 1) > > Clock Path Skew: 0.000ns > > Source Clock: adc_clk_dcm_clk0_bufg rising at 28.000ns > > Destination Clock: adc_clk_dcm_clkfx_bufg rising at 28.571ns > > Clock Uncertainty: 0.251ns > > Timing Improvement Wizard > > Data Path: ctrl2_ins/curr_st_FFd1 to sync_drpp_clr_inst/sync_r1_1 > > Delay type Delay(ns) Logical Resource(s) > > ---------------------------- ------------------- > > Tcko 0.291 ctrl2_ins/curr_st_FFd1 > > net (fanout=3D22) e 0.100 ctrl2_ins/curr_st_FFd1 > > Tfck 0.199 ctrl2_ins/curr_st_Out11 > > sync_drpp_clr_inst/sync_r1_1 > > ---------------------------- --------------------------- > > Total 0.590ns (0.490ns logic, 0.100ns route) > > (83.1% logic, 16.9% route) > > > > </SNIP> > > > > Why is ISE ignoring my constraint? How am I supposed to know what my > > true worst path is if I can't eliminate this timing error? > >=20 > > Thanks, > > -BrandonArticle: 110328
>I've been reluctant recently on envisaging a Virtex-4 device as being >operational in a battery-powered situation. The inrush configuration >current, high static power consumption, and the non-uniform power >exhibited subject to temperature rise are amongst few to name about the >shortcomings of SRAM FPGAs in general. Having said that, the >unprecedented versatile reconfigurable processing power is yet the >decisive factor in prototyping intensive DSP operations. My question >is: has any body come across a scenario in which a large FPGA was >battery-powered. I'm in the phase of deciding on solutions to employ >for my active research so it's quite critical. I don't want to start my >research with a major gap in my rationale. Can any veteran in here >comment on the topic please. Is it really ridiculous to think about >powering a large SRAM FPGA from a battery? Would really appreciate all >comments. What's the cheapest price ever a smallest Virtex-4 device was >reported? You said Xilinx fpga, but maybe actel's eeprom (?) based fpgas will do better for battery applications?Article: 110329
I think the primary question is whether the chip can handle the job. Once that is established, go for the lowest power consumption. It doesn't do any good to have a frugal chip that cannot get the job dene... Peter Alfke ============== pbdel...@spamnuke.ludd.luthdelete.se.invalid wrote: > >I've been reluctant recently on envisaging a Virtex-4 device as being > >operational in a battery-powered situation. The inrush configuration > >current, high static power consumption, and the non-uniform power > >exhibited subject to temperature rise are amongst few to name about the > >shortcomings of SRAM FPGAs in general. Having said that, the > >unprecedented versatile reconfigurable processing power is yet the > >decisive factor in prototyping intensive DSP operations. My question > >is: has any body come across a scenario in which a large FPGA was > >battery-powered. I'm in the phase of deciding on solutions to employ > >for my active research so it's quite critical. I don't want to start my > >research with a major gap in my rationale. Can any veteran in here > >comment on the topic please. Is it really ridiculous to think about > >powering a large SRAM FPGA from a battery? Would really appreciate all > >comments. What's the cheapest price ever a smallest Virtex-4 device was > >reported? > > You said Xilinx fpga, but maybe actel's eeprom (?) based fpgas will do better > for battery applications?Article: 110330
CBFalconer wrote: > Isaac Bosompem wrote: > > > ... snip ... > I am surprised to see Ryerson classified as a university. In my > student days it was a first class technical school, but definitely > not a university. No deprecation intended, my student days > preceded transistors. > > ... snip impressive list of student achievements ... > > -- > Some informative links: > <news:news.announce.newusers > <http://www.geocities.com/nnqweb/> > <http://www.catb.org/~esr/faqs/smart-questions.html> > <http://www.caliburn.nl/topposting.html> > <http://www.netmeister.org/news/learn2quote.html> > <http://cfaj.freeshell.org/google/> Yes they have switched 20 - 30 yrs ago. I have been worried about whether its reputation would affect my chances at some companies. It doesn't seem to be as well known as some of the other established Canadian schools (U of Toronto, U of Waterloo, Queens, etc.). -IsaacArticle: 110331
Tom Lucas wrote: > "Isaac Bosompem" <x86asm@gmail.com> wrote in message > news:1160712667.864828.182490@b28g2000cwb.googlegroups.com... > > > > Hi Peter, > > > > Yes that is important information. I apologize for not including it. > > > > I am currently in my 3rd year of Electrical Engineering undergrad at > > Ryerson University in Toronto, Ontario, Canada. The internship (if > > acquired) is slated to start right after this academic year. > > This effectively delays my graduation by 1 yr, but I think that is a > > really small price to pay for the experience. > > I would definitely recommend the year out - the difference between > graduates that had industrial experience and those who don't is huge and > employers really take notice of that. > > I would look at Dy4 Systems who I think are now part of a different > group (simple google to find I'm sure) who I believe are based around > Toronto or maybe somewhere else but Canada is a pretty small place ;-) > They are into single board computers for aerospace and make some > interesting things and work with some good technology on interesting > projects. Your skills would fit pretty well into their picture but I > have no idea about whether they do internships. > > <snip resum=E9> Hi Tom, I will take a look into it. I found their (new) website: http://www.cwcembedded.com/ Thanks for the info! -IsaacArticle: 110332
Tim wrote: > Frank Leischnig wrote > >>Do you mean something like: >> >>clk_n <= not clk; >>inst_ramb : RAMB16 >>port map ( >> clkb => clk_n, > > > This saves a bit of typing/declaration stuff: > > clkb => "not"(clk), > > > Hi Frank - As John/Tim said this should work. The Software knows about the optional inverter and will use them. If you want to doublecheck - you can use fpga_editor (to open your ncd) to zoom in on that particular BRAM instance - double click on the BRAM and look at the clock connections and attribute settings on the BRAM. - VicArticle: 110333
Joerg wrote: > Hello Isaac, Hi Joerg, > > > > I am currently in my 3rd year of Electrical Engineering undergrad at > > Ryerson University in Toronto, Ontario, Canada. The internship (if > > acquired) is slated to start right after this academic year. > > This effectively delays my graduation by 1 yr, but I think that is a > > really small price to pay for the experience. > > > > Absolutely! We need grads that have practical skills. I have seen many > (far too many) who can't even solder. It's pathetic these days. Yes, haha, I definitely need some pointers on that. Well I guess I can blame it on the fact that I am using my dads umm less that spectacular iron. > > >> *snip * > > Just a suggestion: Post again under the subject "Looking for internship > near Toronto". And also post in sci.electronics.design. There are a few > Canadians who know the industry up there. Monster might be another > avenue (though I don't know if that one is free). I will do that. I am a bit of a newbie to USENET so I am not too familiar with the various groups that have technical natured discussions. > Relocation: I wouldn't exclude other places. All my vacation jobs during > my university time were actually in other countries. Sometimes I pooled > my available rent money with a few others and then we found we were able > to rent a nice big house. Almost cost me less than my apartment near the > university. And you don't have to live off cans and ramen noodles. It is > amazing what you can cook out of fresh ingredients, from scratch, if you > have critical mass (enough cash contributing eaters). We took turns > shopping and usually cooked together. Pizzas, casseroles and what not, > all from scratch and for little money. Yep, we made our own dough. I > never ate any fast food from the first day at the university until they > handed me my masters. Still don't :-) Well relocation is definitely not out of the cards if some assistance can be offered. Or camping in with others haha. I also can cook for myself too. As a kid my parents were both working quite late at night so I had to do it or else I would go hungry ;). Though I have never made a casserole! I have made some pizza but that was with the assistance of my older sister. > -- > Regards, Joerg > > http://www.analogconsultants.com As an aside note, there is an offer for a position with Redline Communications (http://www.redlinecommunications.com/). I think I could be a fit with them. I will forward a resume to them. I am also hearing of RIM making postings later on. Though those will likely be game/app programming. That I think will be worth taking a look at. Thanks for reading this, anyone else have something to offer? -IsaacArticle: 110334
Hello Isaac, > I am also hearing of RIM making postings later on. Though those will > likely be game/app programming. That I think will be worth taking a > look at. Thanks for reading this, anyone else have something to offer? > Check these guys out, great company: http://www.slb.com/content/careers/needs/interns.asp? I did that when I was young. Real adventure, certainly not for the faint of heart. You have to be confident that you can stomach rough helicopter rides and living way out at sea. You might not want to apply if you have a tendency to get sea sick. Also requires a very thorough medical (they reimbursed me for all that). Candidates usually have to be in really good shape. The doc couldn't make my heart rate go up and asked me to step on it a bit on that exercise bike. Then its break belt began to smoke... -- Regards, Joerg http://www.analogconsultants.comArticle: 110335
Hi Anastasios, Please follow the configuration guide. If vcco_0 is 3.3V its essential that the pullups be to 3.3V also. - Vic Anastasios Salis wrote: > Hi eveyone, > > I am designing a schematic for a project using Virtex-4 35 SX, and a platform flash for configuration (XCF16PVO48C). For the FPGA I use VCCO_0 = 3.3V, VCCAUX = 2.5V, and VCCINT = 1.2V. For the platform flash I use VCCO = VCCJ = 3.3V and VCCINT = 1.8V. > > I want to use a 3.3V Jtag interface and the question is: I have connected the FPGA_INIT, FPGA_PROG_B and FPGA_DONE, and FPGA_CCLK to the Platform flash following the guide, but have trouble deciding the power supply to where I have to pull up these signals. Should it be 3.3V because VCCO_0 is 3.3V or should I pull them up to 2.5V because VCCAUX is 2.5V? Or it will work either ways? I have seen it done in the schematics of XILINX ML401_2_3 using 2.5V for pull up, although in the configuration guide it says to use VCCO_0. > > Am I missing something here? Are those pins powered up by VCCO_0 or VCCAUX? Another user in this forum has told mehe is using the 3.3V tolerant configuration guide from SPARTAN-3 and he is doing the same to V4. > > What is the optimum way to configure V4 in such a simple configuration scheme? > > Thank you all in advance, -Tasos-Article: 110336
As I answered on the other thread: If vcco_0 is 3.3V its essential that the pullups be to 3.3V also. - Vic jerzy.gbur@gmail.com wrote: > Anastasios D. Salis napisal(a): > >>When designing using a Virtex 4 (VCCO_0 = 3.3V) and a XCF16PV(VCCO=3.3V and VCCJ=3.3V) at MASTER-SERIAL connection the special configuration pins "DONE", "PROG-B" and "INIT" need pull-up resistors. At which voltage rail should they be pulled up to? At 3.3V or 2.5V? When using a THEVENING termination for the CCLK, at which voltage should it be pulled up? In all those cases what value should the resistors have? I have used 100 Ohm for the thevening termination, 330 Ohm for INIT and DONE and 4.7K for PROG-B. In the ML401-2-3 reference schematic 2.5V is used for pull-up but in the Platform Flash Configuration guide (DS123) it says that I should pull the up to VCCO_0 that is 3.3 V in my case and in ML401_2_3 case also. > > > I've got the similar issue, but Slave SelectMAP32 from microprocessor, > Vcco = 3,3V. I haven't found special solution for this configuration in > V4, so I use configuration from Spartan3 user guide (ds099.pdf > 3.3V-Tolerant Configuration Interface). > > >>Please help me, I am cofused. > > > I'm confused too :) > > Regards > > Jerzy Gbur >Article: 110337
The following code: output_process:process(clk) begin if( clk'event and clk='1') then mem_a <= mem_a_fabric; mem_q <= mem_q_fabric; mem_t <= mem_t_fabric; end if; end process; input_process:process(clk) begin if( clk'event and clk='1') then rd_reg1 <= mem_d( 7 downto 0); rd_reg2 <= mem_d(15 downto 8); rd_reg3 <= mem_d(23 downto 16); rd_reg4 <= mem_d(31 downto 24); end if; end process; is correctly placing registers at pads for d and q but not T. Seems like the XST is simplifying this down to one flop and routing the resulting signal through the T buffers. How do I register T at the OLOGIC? Thanks, Brad Smallridge aivision dot comArticle: 110338
Hi Manny, You may also want to consider the Virtex-4 SX25. The DSP slice burns just 2.3mW/100MHz dynamic power - so for a computation intensive low power application - this may be a good fit. The SX25 has 128 DSP slices where as the FX12 has 32. The SX25 has twice the logic cells and twice the static power as the FX12 though. If you can tolerate the power - you then have a migration path to the Virtex-4 SX35 if you need more computation bandwidth later. If you want to estimate the power consumption before you start your design, you can use the XPower Estimator spreadsheet located at: www.xilinx.com/products/design_resources/power_central This way you can get an idea of how Spartan-3E, Virtex4 and Virtex5 will compare for power for your particular application. - Vic Manny wrote: > Thanks a lot guys, all comments are really useful and I'm definitely > gonna reason much about them. > > My application is definitely gonna be DSP intensive. The bad news is > that it's basically a CDMA application so many things have to run in > parallel in a multiple access system, the more things can run in > parallel the more robust the model is and thus yielding in terms of > performance. The good news is that we'r not talking about RF signals in > here, so things doesn't need to run real fast. My major concern is that > things are quite coupled at the moment i.e. lots of things depends on > stuff that are yet to be fully characterized. As we might have settle > for less perfect hardware (not talking digital in here), our model > would grow more complicated as to accommodate for these imperfections. > The online reconfigurability of the system is also highly desirable as > functionality can change in time. So a CPLD won't do, not even a > low-cost spartan although ultimately we might have to sacrafice > reconfgurability. The only bright side in this mess is that I might be > able to argue, once the system has been fully developed, that certain > functionalities have to be ported to ASIC. I'm keen on having as much > DSP power as possible as there are advanced issue on the agenda such as > Doppler Effective and AOA estimation. So there is no doubt that I'll > end up time sharing the available DSP slices. For prototyping, I think > it always make sense to get a bit more than what you expect to use. > Virtex-4 FX12 seems a reasonable start with the open possiblity to > migrate to V-5 once the rest of the family is introduced. > > Cheers, > -Manny >Article: 110339
Brad Smallridge wrote: > How do I register T at the OLOGIC? Synthesis works from port to port. Maybe mem_t affects no top output port. -- Mike TreselerArticle: 110340
Seems like they are there. I can see them in the editor. They route through several hierarchies to a series of these: iobuf00 : IOBUF port map ( O => O( 0), IO => IO( 0), I => I( 0), T => T( 0) ); which are there but the OLOGIC is showing a latched O and a thru T. Brad "Mike Treseler" <mike_treseler@comcast.net> wrote in message news:4pain7Fi2vqaU1@individual.net... > Brad Smallridge wrote: > >> How do I register T at the OLOGIC? > > Synthesis works from port to port. > Maybe mem_t affects no top output port. > > -- Mike TreselerArticle: 110341
Might be some trouble if this is an SDRAM with a control register. What are you up to? "yy" <yy7d6@yahoo.com.ph> wrote in message news:1160763728.800770.182020@m7g2000cwm.googlegroups.com... > Hi, > Is it ok not to connect at least one DDR Address signal to a ddr > controller? If so, should i connect it to GND or VCCIO? Thanks. >Article: 110342
"Manny" <mloulah@hotmail.com> wrote in message news:1160755594.427130.118490@m73g2000cwd.googlegroups.com... > Hey, > > I've been reluctant recently on envisaging a Virtex-4 device as being > operational in a battery-powered situation. The inrush configuration > current, high static power consumption, and the non-uniform power > exhibited subject to temperature rise are amongst few to name about the > shortcomings of SRAM FPGAs in general. Having said that, the > unprecedented versatile reconfigurable processing power is yet the > decisive factor in prototyping intensive DSP operations. My question > is: has any body come across a scenario in which a large FPGA was > battery-powered. I'm in the phase of deciding on solutions to employ > for my active research so it's quite critical. I don't want to start my > research with a major gap in my rationale. Can any veteran in here > comment on the topic please. Is it really ridiculous to think about > powering a large SRAM FPGA from a battery? Would really appreciate all > comments. What's the cheapest price ever a smallest Virtex-4 device was > reported? > > Cheers, > -Manny > Sounds like I have a similar application. I am trying to make a go of it with V4 FX12. My budget is 2W as we use camcorder batteries with ~30 Whr capacity in our system. I'd be interested in even lower power but it sounds like V5 is no help as the ads conspicuously stress lower DYNAMIC power. I think I burn 1W when the fpga is unconfigured, but I'm not sure that is all in the FPGA. I've put in provisions to shut down entirely until wakened by USB or serial activity but I've not integrated it yet. If you get any reliable info on the V5 power situation, better batteries, or ways to improve the V4 consumption please post. Thanks, ClarkArticle: 110343
Tommy Thorn wrote: > I'm surprised none have mentioned it, but the Xilinx ML501 has finally > been released officially, even though it's not available online yet. > > Press release: > http://www.xilinx.com/prs_rls/2006/silicon_vir/06103ml501.htm > Board info: http://www.xilinx.com/ml501 > > It looks to be a very compelling kit. Unfortunately for me, the > XC5VLX50 isn't supported by the WebPACK and unlike with the original > ML401 release, software is _not_ included so unless you can afford the > full ISE package also, don't bother. > > Tommy > We now have the ML501 boards available in the online store for ordering. The easiest link is from here: http://www.xilinx.com/ml501 -> Online Store We built plenty of them, heck even Antti got one, so come and get 'em. Ed McGettigan -- Xilinx Inc.Article: 110344
Yet another issue is how much reconfiguration power budget compares to static power i.e. is it really worth it to reconfigure (partially or fully) as frequent as diserable and still maintain improvements over static power. Does Virtex-4 support tripple oxide technology for routing transistors? Actually I'm planning one using this frequently via having an ARM7 softcore (running on fusion) dispatching functionalities dynamically. In principle it sounds interesting but I don't knwo whether it is worth it or not and power reconfiguration budget might grow exponentially with the frequency of reconfiguration. Thanks a lot guys, it's really been rather insightful comments. Cheers, -MannyArticle: 110345
Hi Alessandro, > I'm using an Actel fuse A54SX72A, which has 2012 sequential cells and at > the moment I filled it up to more than 90%. Once I got it up to 100%! So you still have some cells to spare. > There can be the need more triple-redundant registers in it and I'm > afraid I will have routing problems with that. Routing depends on your design structure. Even with high device utilization, Designer usually is successful. If routing fails or you can't get timing closure, you can try place&route with the "Multiple Passes" option. > Has anyone here experienced this? Can I rely on the Actel Designer > backannotate to have a close-to-reality simulation? Certainly. You can export the netlist together with the SDF to perform gate-level simulation with effective cell and routing delays. Daniel Leu Inicore, Inc.Article: 110346
While I like Xilinx and think their docs, if you read enough of them you will find three things 1. Some things that aren't documented enough 2. Some things that aren't documented at all 3. Some things that aren't documented correctly ---Matthew Hicks "jbnote" <jbnote@gmail.com> wrote in message news:1160730426.999368.68570@e3g2000cwe.googlegroups.com... > Hello, > > Don't know if this is the right place to report this, but... > While reading some xilinx docs I came across the following typos: > > * ug071 v1.4, table 7-5 page 91, the column address spans bits 13:6 > * ug191 v1.2, table 6-7 page 103, the block type 001 / 010 should > correspond to block RAM routing and block RAM content, not block RAM > contents twice. This is just a guess, I've not checked this. > * ug191 v1.2, table 6-4 page 98, the CBC register address is wrong. > This is a small problem, but as all register addresses are not > consecutive, this may be misleading. > > These docs were the latest version I could find. > > Jean-Baptiste >Article: 110347
You could try turning off the "Trim unconnected signals" option. ---Matthew Hicks "Antti" <Antti.Lukats@xilant.com> wrote in message news:1160731469.227624.198590@f16g2000cwb.googlegroups.com... > Tim Verstraete schrieb: > >> Hey, >> >> I have 2 LVDS clock signals and both are terminated with the DIFF_TERM >> attribute on the LVDS25 input buffer IBUFGDS but i only use 1 of them >> ... now i want both buffers to stay in my design and not optimized >> away. Is there a constraint that i can place on that buffer? i guess >> that it should be a UCF constraint since when i look into the RTL >> viewer of planahead and ISE i still see the buffer. >> >> I know that there is an option in NGBuild -u which keeps the unused >> logic, but i do not want to use it just for that 1 buffer ... >> >> thanks in advance, >> >> kind regards, >> >> tim >> >> p.s. i'm using ISE8.2SP2 and a V4SX55-FF1148C > > the best thing possible is to use it without using it :) > 1) like route the unused input to non-bonded IO, > 2) or use in some net in way that the signal isnt really used but XST > fails to optimize it out > 3) or if you dont use BSCAN you can also route it to TDO pin > > all those tricks would keep the net alive. sure it would use > some interconnect resources. > > Antti >Article: 110348
Hi all, IMHO, there is something compare the golden output and DUT output in testbench (I call it Checker). But in verification book, there is both Scoreboard and Checker. Are they similar? Please recommend some reading on it.Thanks! Best regards, DavyArticle: 110349
Matthew Hicks wrote: > While I like Xilinx and think their docs, if you read enough of them you > will find three things > 1. Some things that aren't documented enough > 2. Some things that aren't documented at all > 3. Some things that aren't documented correctly 4. Some things are documented somewhere, but good luck finding it.
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