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
Yes, Norton Antivirus found that file on my PC and I deleted it. I don't
think it can do any harm unless you expand the .zip file.
Pete Dudley
Steve Gross <gross@pa.msu.edu> wrote in message
news:38021DD2.D97E900C@pa.msu.edu...
> I just now got a package from Xilinx noting the presence of a virus on the
> Alliance 2.1i and Foundation 2.1i CP, Solaris, and HP CD-ROMs.
>
> A couple of points:
>
> 1. For those of you who haven't received the package, look for the file:
>
> $XILINX/userware/training/virtex_arch.zip
>
> Xilinx says that if you don't have the file, you don't have the virus.
>
> 2. The virus is supposed to be a "nonharmful, nondestructuve" Microsoft
> Excel macro virus. How is it an issue on HP or Solaris platforms (last
> I knew, Microsoft hadn't released Excel for Unix)?
>
> -Steve Gross
Article: 18276Our solution was to change out the worst date codes and beef up the power supply to be able to deliver the current. Since the spike is short, the power supply doesn't have to deliver the current very long so heat dissipation wasn't a problem. Altera is due to visit with their recommendations tomorrow. -Dave > This would be a killer problem in some applications. Is there a way to avoid > or prevent the problem other than having a big enough power supply to plow > its way through the problem? > > Bob W.Article: 18277
I couldn't find the posts from back then, but I did look through the Altera book to find out whether they had selectable switching thresholds on this part. I didn't see anything, but I could have missed it. It does sound plausible. -Dave > There was an old series of posts (April this year?) on a similar problem with Altera 8K. > One theory was that it might have been crowbar current on the TTL level compatible > input buffers, i.e. with an artificial threshold voltage of 1.2 or whatever > volts rather than VCC/2, the upper and lower transistors can turn on simultaneously as > the power supply voltage comes up for some combinations of upper and lower > threshold voltages which vary with voltage and temperature. > Try http://www.dejanews.com with query "Altera power". > > regards, tomArticle: 18278
> Any idea how wide ( in uS ) is this ~700mA current mode ? The in-rush mode was a few hundred usec, but increased with decreasing temp. A weaker supply would make them last longer and could make it stick there forever. > Is it Time, or Voltage related ? It happened right at 1.2V on the 3.3V ramp up. We varied the ramp up time on the 3.3V but that didn't seem to affect it. > ie I have seen ICs ( not 10K50's ) that needed more Icc during Rampup of > Vcc, and once it hit the Power RESET level, it dropped back to a data > sheet level. This apparently has an internal reset that kicks in when the voltage approaches 3.3V. The current then abruptly drops to normal. > True. Our tests on the parasitic LatchUp SCR in PLDs showed high > trigger currents, ( >> 100mA ) but once triggered, the holding current > was < 10mA, which is actually a good SCR figure. Yeah, I don't think this was CMOS latchup. -DaveArticle: 18279
There is a minimum ramp time for the power supply of 100 msec. Our supply was ramping up in well under that. We did vary the ramp time and didn't see any appreciable difference. -Dave > Is the effect sensitive to dV/dt? IIRC, the Altera parts have a spec > on the rise time of the power supply, expecting it to be *less* that a > particular value to ensure correct operation. > (I just looked at a 10K datasheet, and it doesn't list this parameter > so either it doesn't matter, or the information can only be found in > some obscure app note.) > > Xilinx parts have a similar spec, and Xilinx recommend that you hold > the program line low (active) if the Vcc risetime is too long. > > Regards, > Allan.Article: 18280
In article <7tj3e2$bju$1@nnrp1.deja.com>, PJD <pjdecker@my-deja.com> wrote: > TI's TI380C30A Token-Ring MAC/PHY costs $56 (1k). > Their TI380C60A PHY costs $10 (1k). Ergo, the MAC costs $46. You wish it were so simple. But i think that TI don't sell that many C30A's (I know proteon/openroute use that part, but to the best of my knowledge Madge, Olicom and IBM do not use it.) The C60 probably sells more in volume, certainly olicom use that part. So some of the cost difference may be due to volume. > > Can the MAC be synthezised in an FPGA for a lower recurring cost? I don't know about a lower recurring cost. What you're going to be synthesising is : a token ring protocol handler + an onboard MAC processor + a memory controller and various interfaces. You either buy a processor license and/or IP. but synthing the whole lot can easily chew up 50K gates in an FPGA. > If so, what non-recurring costs are involved? I didn't think FPGA had NRE - except for your design time. > Are there any sources of Token Ring IP? Not that I know of. So it's "build your own" time. > Which level of Viewlogic/Synopsis FPGA Express would be required for a > design of that size? I can't comment on that. But there are other FPGA synth tools out there. -- AndyC. Senior Dev. Engineer at Madge.connect All views expressed here are my own and are not corporate views in any way, sense or form. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18281
The 1016E is faster and may cause some problems with asynchronous delays. You will need to recompile your source files. Mark Harvey. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18282
Hi everyone, If you have a spare/used XC6200-based Hotworks board lying around, drop me a mail and make me an offer. I'll pay for the shipping as well. Best regards, Chai Mee Joon, Lawrence cmj@canbox.com.sgArticle: 18283
Steve Rencontre wrote in message ... >It shouldn't matter if nCONFIG and nTRST are held low initially. >Sounds to me like your ByteBlaster may be faulty, or possibly you have >an incorrect driver setup. > >You say "standard" ByteBlaster - do you mean the +5V version? That >might well be the problem if you have 3V3 logic. Yes, it is +5V version. But it is connected according to the Altera datasheet. JTAG pins are pulled up to +5V and the ByteBlaster is powered from +5V. Do you think this still can be a problem? Mikhail MatusovArticle: 18284
mhs2z@hal.ee.Virginia.EDU (Maximo H. Salinas) wrote: > One place > that seems wrong, however, is in the connections within the LUTs > themselves, as seen using EDITBLOCK. I would have expected a connection > out of the Global_Reset block which would eventually lead to the S or R > pins in the LUT's registers, but I don't see that. The GSR connections to a PFU Flip-Flop are not shown. They are just assumed to be routed to every FF. Unless you have a Reset, Set, or FE-select other than the GSR signal, the LSR mux should be shown as unconfigured. > Instead the mux that > the LSR input drives has a connection at its '1' input, and no other > connections. This is puzzling. It's possible your code specifies that the flip-flop is always reset. Does it simulate this way? Also, GSR can only be an asynchronous reset. If you code the signal as a synchronous reset for some flip-flops, then Leonardo must create a non-GSR net for it. To be absolutely sure, you should probably instantiate the GSR explicitely as Rudolf Simburger <rudolf.simburger@icn.siemens.de> wrote in a previous post: | -- ############################################ | -- # GSR global set/reset | -- ############################################ | | COMPONENT GSR | PORT ( | GSR : IN STD_LOGIC | ); | END COMPONENT; | | -- instantiate GSR global set/reset | | GSR0 : GSR port map (pon_l_o); Although this doesn't give you control over whether individual flip-flops are set or reset when GSR is asserted. -- Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby Fermi National Accelerator Lab Phone: 630-840-3668 Batavia, IL 60510 Fax: 630-840-5406Article: 18285
Did you use VHDL? What Altera part were you targeting? Steve Moussa Ba <babs@eng.umd.edu> wrote in message news:38022FD7.7942AA9E@eng.umd.edu... > I have a design that was done using MAX2PLUS altera software. It uses > some of the supplied LPMs. I would like to test my design on a XILINX > XC4000XL chip as well. Is it possible to do so, if so, what is the > procedure. I apologize for the vagueness of the question as I am new to > the whole process. > > Thank you in advance >Article: 18286
It is my understanding that if you can use 1.8V parts, you are better off with the E parts. They will soon be cheaper, as well as all the other things die shrinks bring, ie faster, lower power, etc. On the other hand, I don't expect Xilinx to cut off Virtex users any time soon. I don't see this as any different than previous die shrinks, eventually they will obsolete the old parts, but they will remain available at some small(?) price premium for a long(?) time. If you want to fill in the (?) just look at the historical data. There's plenty available from Xilinx alone! Steve Stephen Charlwood <s.m.charlwood@bham.ac.uk> wrote in message news:3801C9ED.B7F81868@bham.ac.uk... > Hi all, > > With the advent of the Virtex-E parts, I am confused about where this > leaves the original Virtex devices. If anyone could offer any insights, > it would be appreciated. > > I would assume that if the die size of the Virtex-E devices is smaller > than the corresponding Virtex device (despite the fact that the Virtex-E > has more embedded RAM), then the original Virtex series would always > lose to Virtex-E on price/performance and thus become obsolete. This is > unless Xilinx plans to artificially maintain the prices of the Virtex-E > devices. > > Equally, it may be the case that the Virtex-E do have larger die sizes > and therefore Xilinx will offer both device architectures, depending on > the amount of embedded memory required. This may mean that the original > Virtex architecture is moved onto a 0.18 micron process as well, in > which it would definitely achieve smaller die sizes. > > Any thoughts appreciated, > > Steve > > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > Digital Systems & Vision Processing Group > School of Electronic & Electrical Engineering > University of Birmingham, Edgbaston, Birmingham, B15 2TT > e-mail: s.m.charlwood@bham.ac.uk > tel: +44 (0)121-414-4340 (shared)/fax: +44 (0)121-414-4291 > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/Article: 18287
From: Don Mills <mills@lcdm-eng.com>
Hey, John,
Because of the unexpectedly high turn-out at last week's Boston SNUG
meeting, we've been getting lots of requests to extend the San Jose
SNUG'00 'Abstracts' deadline a week. Please let your readers know that
that they now have until 5:00 (PST) Friday, Oct. 15th to get the abstract
for their proposed paper into snug_tech@synopsys.com. Also, if they
have any questions, <http://www.snug-universal.org> probably can answer
many of them.
- Don Mills, SNUG'00 Tech Chair
LCDM Engineering South Jordan, UT
P.S. Many thanks to those who attended and participated in the Boston
SNUG. It was extremely successful.
============================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 9,607 other
users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
Article: 18288
--
Position: FPGA Design
Tools: Xilinx
Description: Position in the Ottawa region, must have 2 years
experience.
Good people skills.
Contract Lenght: Perm
Available: ASAP
Salary/Per diem: Depending on Experience
Reply at the e-mail below
Spiro Egarhos
Technical Recruiter
Manpower Technical Services
email resumes to:
spiro.egarhos@na.manpower.com
Manpower Technical, a division of the world's largest staffing services,
Manpower Technical is accustomed to working with businesses engaged
instate-of-the-art technological projects. We meet the staffing needs of
close to 90% of the Fortune 500 companies. We have formed strategic
alliances with some of the world leaders and we maintain enduring and
exclusive relationships with international leading-edge businesses. If you
are interested in working on the other side of the globe or just around the
block, Manpower Technical is the quickest way to get there. With more than
2400 offices worldwide in 58 countries, Manpower Technical offers excellent
renumeration, health benefits, and FREE TRAINING for IT Professionals
Article: 18289I used VHDL yes, however, I also used ALTERA's LPM functions which are AHDL based. I was targeting the MAX7000S chips or FLEX10K. Moussa Steve wrote: > Did you use VHDL? > What Altera part were you targeting? > > Steve > Moussa Ba <babs@eng.umd.edu> wrote in message > news:38022FD7.7942AA9E@eng.umd.edu... > > I have a design that was done using MAX2PLUS altera software. It uses > > some of the supplied LPMs. I would like to test my design on a XILINX > > XC4000XL chip as well. Is it possible to do so, if so, what is the > > procedure. I apologize for the vagueness of the question as I am new to > > the whole process. > > > > Thank you in advance > >Article: 18290
Download Ia.n.i. RemoteControlSystem 1.2 beta. It's free!!! New site: http://jump.to/IaniProject Article 18564 of comp.arch.fpga:Article: 18291
In article <7tvfsg$6dt$1@info3.fnal.gov>, Don Husby <husby@fnal.gov> wrote: >mhs2z@hal.ee.Virginia.EDU (Maximo H. Salinas) wrote: >> One place >> that seems wrong, however, is in the connections within the LUTs >> themselves, as seen using EDITBLOCK. I would have expected a connection >> out of the Global_Reset block which would eventually lead to the S or R >> pins in the LUT's registers, but I don't see that. > >The GSR connections to a PFU Flip-Flop are not shown. They are just >assumed to be routed to every FF. Unless you have a Reset, Set, or >FE-select other than the GSR signal, the LSR mux should be shown >as unconfigured. I know the connections to the LUT are implicit and not shown, but I believe the connections within the LUT (as shown by EDITBLOCK) are indeed shown. These are the ones that are puzzling. > >> Instead the mux that >> the LSR input drives has a connection at its '1' input, and no other >> connections. > >This is puzzling. It's possible your code specifies that the flip-flop >is always reset. Does it simulate this way? The original VHDL simulates correctly. > >Also, GSR can only be an asynchronous reset. If you code the signal >as a synchronous reset for some flip-flops, then Leonardo must create >a non-GSR net for it. The resets are asynchronous in my design. > >To be absolutely sure, you should probably instantiate the GSR >explicitely as Rudolf Simburger <rudolf.simburger@icn.siemens.de> wrote >in a previous post: > >| -- ############################################ >| -- # GSR global set/reset >| -- ############################################ >| >| COMPONENT GSR >| PORT ( >| GSR : IN STD_LOGIC >| ); >| END COMPONENT; >| >| -- instantiate GSR global set/reset >| >| GSR0 : GSR port map (pon_l_o); > >Although this doesn't give you control over whether individual flip-flops >are set or reset when GSR is asserted. > I tried this already and did not see much of a difference in my NCD file. Again, what does the LUT look like when viewed by EDITBLOCK when the GSR is used to reset its registers? Have you opened up and NCD file from a design with a working reset that you could describe to me? > > >-- >Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby >Fermi National Accelerator Lab Phone: 630-840-3668 >Batavia, IL 60510 Fax: 630-840-5406 Thanks again, Max Salinas -- M. H. Salinas (MSalinas@Virginia.EDU) Senior Scientist Department of Electrical Engineering University of Virginia Article 18551 of comp.arch.fpga:Article: 18292
John, As an FYI for you, I use a laptop with 128 M of memory and I have NEVER gotten into a situation where I started swapping memory when I use Synplify as my FPGA synthesis tool. The designs I have synthesized fit into about 80% of a Virtex1000, and a different design which utilized 99% of an Altera Flex 10k. (Although that one was too dense to route properly). The software does a good job of maxing out the CPUs without swappiing (from checking my performance monitors). The P&R software from Xilinx and Altera (particularly the Quartus software) do require more memory than Synplify, so a large machine may be needed to facilitate the simulation and the physical implementation, but not necessarily the synthesis. Bigger is always better in computers (as in real life?) so it could never hurt to spend the extra bucks on a bigger machine. Pete John Cooley <jcooley@world.std.com> wrote in message news:FJB71o.FDH@world.std.com... > Kurt Caudle <caudlek@igs.net> wrote: > >Anyone in this group have advice on running Mentor on a Laptop. > > > >Hardware minimum? Does it import/export to the Mentor Unix Version > >easily? > > Kurt, > > I'm not exactly sure what you mean by "Mentor". I'm assuming > you're talking about the Mentor Windows-based tools from > its Model Tech and Exemplar divisions. Yes, they're easily > run on PC's -- but if you're going to do any real FPGA > synthesis or Verilog/VHDL simulation, I recommend you get > the biggest, fastest, meanest, memmory-loaded laptop you > can. EDA tools (not just Mentor's, but all EDA tool) can > seriously tax a workstation or a PC if you're doing real > design with them. And the few dollars you spend on getting > the higher end PC with LOTS of memory is more than worth the > time you'd spend if your tool sparts going to disk for swap > space.... > > - John Cooley > Part Time EDA Consumer Advocate > Full Time ASIC, FPGA & EDA Design Consultant > > ============================================================================ > Trapped trying to figure out a Synopsys bug? Want to hear how 9,607 other > users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)! > > !!! "It's not a BUG, jcooley@world.std.com > /o o\ / it's a FEATURE!" (508) 429-4357 > ( > ) > \ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys, > _] [_ Verilog, VHDL and numerous Design Methodologies. > > Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222 > Legal Disclaimer: "As always, anything said here is only opinion." > The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com Article 18552 of comp.arch.fpga:Article: 18293
Download Ia.n.i. RemoteControlSystem 1.2 beta. It's free!!! New site: http://www.geocities.com/SiliconValley/Chip/5989/ Article 18565 of comp.arch.fpga:Article: 18294
Maximo H. Salinas wrote: > I am having trouble getting a reset input into my ORCA FPGA to route > properly (as viewed in the NCD file via Epic and as observed in the lab <snip> > original design. I have tried having Leonardo/Spectrum infer the GSR > signal and providing it manually. According to the Exemplar > documentation, the VHDL reset signal should be assert high, by the way. > Ok. Let's try this again, I got almost done with my post and the %&$'ing computer locks up 8-( I use this all the time with Leo Sepctrum, so lets make sure the following things are done: 1) Make absolutely sure that *every* registered element in your design has an asynchronous reset coded for it. 2) This signal needs to be active-high. 3) Does not matter whether individual registers get cleared or preset. 4) The input pin is active-low, so make reset <= not(resetN); 5) In Leonardo Spectrum L3, set infer_gsr TRUE 6) Compile your design 7) Write the EDIF file You should be able to open the EDIF file and see that the startup component has been wired into your design. Alternatively you can use the command set global_sr reset to explicitly name your global reset net. Hope this helps. -- Brian C. Boorman Harris RF Communications Rochester, NY 14610 XYZ.bboorman@harris.com <Remove the XYZ. for valid address> Article 18553 of comp.arch.fpga:Article: 18295
Take the EDIF Output file (.EDO) file from the Altera tools, run this through Exemplar's Leonardo Spectrum L3 in the 're-target' mode, end up with a Xilinx design. -- Brian C. Boorman Harris RF Communications Rochester, NY 14610 XYZ.bboorman@harris.com <Remove the XYZ. for valid address> Article 18554 of comp.arch.fpga:Article: 18296
Hi, I've written some time ago that i need the schematic for the Lattice ISP-Cable. Some of you told me i could find the schematic at the Lattice webpage. I only could find the PIN-configuration for the cable from the PARALLEL-ADAPTER to the board that includes the ISP and not for the PARALLEL-ADAPTER itself. So it would be great if you could give me the exact URL (not only www.latticesemi.com )or send me the pdf-file direct via email. best regards Masterbot Sent via Deja.com http://www.deja.com/ Before you buy. Article 18555 of comp.arch.fpga:Article: 18297
In article <7tr0t2$93tp5$1@titan.xtra.co.nz>, "Darryl Jewiss" <darrylj@braemac.co.nz> wrote: > Mike > > You'll have to use a ByteBlasterMV cable, I think it uses a 74HC244 instead > of a 74LS244 for programming low voltage devices like the 10KA and 10KE's. > > Armin Mueller <armin.mueller@stud.uni-karlsruhe.de> wrote in message > news:37FDFA61.E389297F@stud.uni-karlsruhe.de... > > Mike wrote: > > > > > > We are having troubles in programming Altera 10K30A device via JTAG > port. > > > Altera software does not detect the device at all. Everything is > configured We have seen exactly this problem with a chain of 10K and MAX7000 devices being driven by 1) A parallel port extended with a 1m ribbon cable 2) A parallel port with really poor output drivers 3) A parallel port with a broken handshake line The solution to (2) and (3) was to install a cheap ISA multifunction card and disable all but the parallel port. On the way to this solution, we fixed (1) and (2) by buffering all the JTAG signals LOCALLY to the byteblaster socket on our board by building a 'dongle' for the byteblaster socket on a piece of stripboard. Interestingly, in scenarios (2) and (3), the parallel port in question was quite happy to drive a printer. We also improved (but didn't quite fix) the situation by installing the MaxPlusII dongle on a separate second parallel port. Also, check that you don't have EPP or ECP mode set in your computer's BIOS for the parallel port in question, as our setup didn't like that either. Hope this helps, Derek Roberts Sent via Deja.com http://www.deja.com/ Before you buy. Article 18556 of comp.arch.fpga:Article: 18298
On 12 Oct 1999 17:59:06 GMT, mhs2z@hal.ee.Virginia.EDU (Maximo H. Salinas) wrote: [snip] > Again, what does the LUT look like when viewed by EDITBLOCK when the > GSR is used to reset its registers? Have you opened up and NCD file > from a design with a working reset that you could describe to me? I had a look at some of my designs and I think the following describes the situation: For a FF set/reset only by GSR, the S/R pin on the FF will be enabled, which brings up the route from the pin through the FF S/R demux to the S/R Logic Block (the one with FE_ENABLE and SETRST on it). The GLOBAL RESET line into this block is _not_ highlighted. I aggree that this is confusing - it looks like the GSR is not being used, as long as the GSR block in the corner of the device is configured then everything should be OK Hope this helps Dave -- REPLACE "NOJUNK" in address with "david.storrar" to reply Development Engineer | Marconi Electronic Systems | Tel: +44 (0)131 343 4282 RCS | Fax: +44 (0)131 343 4091 Article 18557 of comp.arch.fpga:Article: 18299
On Tue, 12 Oct 1999 13:20:07 GMT, in <bAGM3.23643$m4.87407901@news.magma.ca> "Mike" <mmatusov@ics-ltd.com> wrote: >>You say "standard" ByteBlaster - do you mean the +5V version? That >>might well be the problem if you have 3V3 logic. > > >Yes, it is +5V version. But it is connected according to the Altera >datasheet. JTAG pins are pulled up to +5V and the ByteBlaster is powered >from +5V. Do you think this still can be a problem? Oh well, it was a theory... -- Steve Rencontre, Design Consultant http://www.rsn-tech.demon.co.uk/ -- remember to despam return address Article 18570 of comp.arch.fpga:
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