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
Rick Filipkiewicz wrote: > > Duane wrote:The one weak link on Linux is a lack of a synthesis tool. Though > > > Synplicity had a job posting for Linux programmer some months back, so > > here's hoping... > > > > Its supposed to be out real soon and as far as I've been informed it won't > cost any extra but that was before the IPO > > > > > I actually purchased VMware, since I still need it to run the synthesis > > tools. But that is all I use it for. All my other tools are either > > native Linux or run under wine. > > What simulator are you using under Linux & how much extra did you have to > pay over the NT price ? I am using Modelsim, because some clients expect it. For Linux, the only version available (at least at the time) was Modelsim SE. I believe the pricing was the same regardless of the platform, at a swoon inducing $20K. Windoze platforms also had available Modelsim PE (a supposedly lower performance version) at a much more reasonable $5K, sigh... But simulators are a bright spot for Linux these days. I am aware of 5 Linux native VHDL simulators, at prices from $20K down to $800, and several offering very cheap versions for students. Green Mountain Computing Systems - http://www.gmvhdl.com/products.html Blue Pacific Computing - http://www.bluepc.com/bluehdl.html FTL Systems - http://www.ftlsystems.com/compiler_simulators/pathway.html Cadence - http://www.cadence.com/company/pr/04_17_00linux.html Mentor Graphics - http://www.model.com/linux.html -- My real email is akamail.com@dclark (or something like that).Article: 26926
"Dan" <daniel.deconinck@sympatico.ca> wrote in message news:o3CM5.2624$x6.56788@news20.bellglobal.com... > > To send a I2C line high > - disable the tristate Output buffer. (The I2C line has a 10Kpullup) > > Am I missing something in this driver logic ? This is probably not your problem, but you should ideally have a lower resistance pull-up on the SCL and SDA lines. For 5V systems, about 1.8k is recommended in the spec. MHArticle: 26927
I've just (finally) gotten around to posting an article I wrote in July on memory testing and the source code that goes with it. Some minor flaws in the address bus test have been recently touched up as well, so if you downloaded this code from Embedded.com previously, please get the latest here: http://www.netrino.com/Articles/MemoryTesting/ The code is placed into the public domain and may be used for any purpose public or private. There are some limitations in its use (it's written in C), but the underlying algorithms are solid and could be ported to the assembly language of your choice if necessary. Enjoy, Michael BarrArticle: 26928
Hi ! If you choose to go the "piezo" way, here is the most simple, yet very powerful (loud) circuit you can use with very low supply voltage : http://www3.sympatico.ca/erv/piezo.gif The bigger the inductance & the piezo element, the higher the audio volume can be, this is how 1-2 cell powered alarm clocks attain high audio output levels. You change the volume (and thus power consumption) by adjusting the "ON" time (adjust the base resistor value to prevent exessive VCEon voltage ). Only drawback is that the sound output frequency lower value is far higher than your 40 Hz limit (see the specs for the piezo element). hope this helps ! Eric. Caution : disconnecting the piezo load is very likely to kill the transistor. ------------------------------------------------------------------------------------------------ Dan wrote: > I want to generate a given frequency 40HZ to 5KHZ with counters and output > this to a speaker mounted on a PCB. > > LowQuality is accepatble. > Power enough to be heard by human from 10 feet. > > Please recommend a speaker and interface for FPGA. > > Thanks > DanArticle: 26929
Jamie Lokier wrote:
>
> eml writes:
> > Exactly. And how many of us actually care about whether or not we have
> > source code? As far as I'm concerned, it's just wasting valuable disk
> > space.
>
> Haven't you ever used a program ("X") that has a simple but critical
> bug, and the vendor won't be fixing it for a year?
>
> Never had to avoid certain constructs on your code because the synthesis
> tool generates the wrong circuit?
>
> Never had a project where a simple change to X would be simpler than
> a big bunch of scripts to pre-process and post-process the files you
> pass to/from X?
>
> In my experience, source === if the vendor won't fix their program in a
> timely fashion, I can. Or I look to see if someone else has. Sure it's
> a little extra effort, but weigh that up against the cost of working
> around the bugs or lack of critical features.
The other point, of course, is that under GPL (which most Open Source
programs adopt, as far as I can tell), you are legally obliged to
distribute the source code as well!
Besides, the original poster was uninformed. The majority of Linux
programs are available as binaries - in nice easily-installed packages
called .deb or .rpm (etc.) They'll even check for dependencies and run
configuration scripts to make sure the program is properly installed.
The remaining point is that if (s)he don't like it, don't use it - just
don't bitch about it. There's no obligation on the part of open-source
programmers to solve his(her?) problem with the open-source credo.
To be honest it sounds like the poster would be better off staying in
the nice safe Windows environment, it sounds like the trade-offs
there are more to the poster's tastes than those under Linux.
[You can probably tell I have little sympathy for people who moan without
cause having done no gainful research into what they're moaning about]
Simon.
Article: 26930
----------
In article <3A02FE26.32245678@netrino.com>, Michael Barr <mbarr@netrino.com>
wrote:
> I've just (finally) gotten around to posting an article I wrote in July
> on memory testing and the source code that goes with it. Some minor
> flaws in the address bus test have been recently touched up as well, so
> if you downloaded this code from Embedded.com previously, please get the
> latest here:
>
> http://www.netrino.com/Articles/MemoryTesting/
>
> The code is placed into the public domain and may be used for any purpose
> public or private. There are some limitations in its use (it's written
> in C), but the underlying algorithms are solid and could be ported to the
> assembly language of your choice if necessary.
>
> Enjoy,
hey, cool. thanx Michael.
--
r b-j
Wave Mechanics, Inc.
45 Kilburn Street
Burlington VT 05401-4750
http://www.wavemechanics.com/
tel: 802/951-9700 ext. 207 robert@wavemechanics.com
fax: 802/951-9799 robert@audioheads.com
--
Article: 26931Richard Chidester <richardc@xilinx.com> wrote: >Gentlemen, > >Due to some difficulties, the shirts were held up in manufacturing! We have >them in stock now and we will start shipping. > Even to Europe? Richard ------------Richard Dungan------------- Radix Electronic Designs, Orpington, UK richardATradix-designDOTcoDOTuk ---------------------------------------Article: 26932
I have a 3.3 volt (non 5 volt tolerant) bidirectional bus coming out of an FPGA and need to shift it to true 5 volt CMOS levels. Can anyone recommend an octal level shifting buffer where I can get 3.3 volt CMOS on one side and 5 volt true CMOS levels on the other side ??? Thanks, StuartArticle: 26933
This is a multi-part message in MIME format. --------------DED9628EE0896B0664E7877F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yes! Best regards, Richard Chidester Richard Dungan wrote: > Richard Chidester <richardc@xilinx.com> wrote: > > >Gentlemen, > > > >Due to some difficulties, the shirts were held up in manufacturing! We have > >them in stock now and we will start shipping. > > > > Even to Europe? > > Richard > > ------------Richard Dungan------------- > Radix Electronic Designs, Orpington, UK > richardATradix-designDOTcoDOTuk > --------------------------------------- --------------DED9628EE0896B0664E7877F Content-Type: text/x-vcard; charset=us-ascii; name="richardc.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Richard Chidester Content-Disposition: attachment; filename="richardc.vcf" begin:vcard n:Chidester;Richard tel;fax:303-442-9124 tel;work:303-544-5558 x-mozilla-html:TRUE org:CPLD Software Group;Xilinx, Inc. <br><img SRC="http://www.xilinx.com/sxpresso/images/webpack_ise_logo.jpg" height=70 width=104><font size=-1><a href=""></a> "The empires of the future are the empires of the mind." <BR><CENTER><I> ... Winston Churchill</I></font></CENTER> adr:;;2300 55th Street;Boulder;Colorado;80301;USA version:2.1 email;internet:richardc@xilinx.com title:Sr. Technical Marketing Engineer note;quoted-printable:<br><img SRC=3D"http://webster/images/button.gif" height=3D74 width=3D184><font size=3D-1><a href=3D""></a>" Yeah. Free my mind. Right. No problem.=0D=0A " <BR><CENTER><I> ... (Neo - in The Matrix)</I>=0D=0A</font></CENTER> fn:Richard Chidester end:vcard --------------DED9628EE0896B0664E7877F--Article: 26934
Rick Filipkiewicz <rick@algor.co.uk> writes: > What simulator are you using under Linux & how much extra did you have to > pay over the NT price ? FinSim from Fintronic (it was AFAIK the first serious simulator on Linux), the Linux price is the same as the Windows price (and cheaper than Solaris, HPUX, etc versions). Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+Article: 26935
Is it possible to build a crosspoint switch in CPLD/FPGA, or is the solution to use a Lattice device? The desire is to put a bi-directional bridging layer between dedicated CPU pins & the IO circuitry to allow programmable rerouting to IO pins. Having it all live in the one prog device ALONG WITH any other interface glue logic would be handy. Cheers GregArticle: 26936
sja@world.std.com (Stuart J Adams) writes: > Can anyone recommend an octal level > shifting buffer where I can get 3.3 volt > CMOS on one side and 5 volt true CMOS levels > on the other side ??? Yes, take a look for example at Fairchild's site. 74LVX3245, LVX4245, LVXC3245, LVXC4245 : octal dual supply translating transcievers w/ 3-state outputs. I know Philips has a similar chip and probably others too. Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+Article: 26937
Hello Martin, Same features, except the pinout. So, for example, FLEX 10K30E device is NOT pin compatible with ACEX 1K30 device. Ashok Martin Thompson wrote: > Can anyone tell me what the difference between the ACEX and FLEX > families of Altera devices is? As far as I can tell, the only > difference is the number of packages supported... > > Anyone from Altera lurking here? > > Thanks, > Martin > > -- > Martin Thompson > martin.j.thompson@trw.comArticle: 26938
Richard Chidester wrote: > > Gentlemen, > > Due to some difficulties, the shirts were held up in manufacturing! We have > them in stock now and we will start shipping. Address is below! :) -- ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt."Article: 26939
Check out the Xilinx web site - www.xilinx.com Ashok Peter wrote: > >> Digital-only ASICs (as opposed to mixed analog+digital) have quite low > >> NREs, below $10k for a reasonably straightforward FPGA -> ASIC > > > >I've done digital ASICs with NRE costs in the $100k range. It depends > >on the vendor, technology, size, megacells etc. > > Sure, with an on-chip Z80-lookalike and 300k gates :) But the > equivalent FPGA would be a massive device, and very very expensive. In > only 10k + volume the ASIC would be a very good deal despite the NRE. > > Peter. > -- > Return address is invalid to help stop junk mail. > E-mail replies to zX80@digiYserve.com but remove the X and the Y. > Please do NOT copy usenet posts to email - it is NOT necessary.Article: 26940
Ray Andraka wrote: > > And it is an absolute nightmare for source control, particularly when the work > goes to a third party as it does for most consulting. Also creates problems if > you have multiple projects with different tweaks in the source code. No > thanks. I'd rather work around the bug and have everyone working with the same > set of tools than open this can of worms. As I see it, this is an internal process issue. Should you wish to retain an iron grip over your process, of course it's better to stick with released and officially supported software. OTOH, if you need to get something done, you know the fix, and you have the capability to do it, it'd be madness not to fix it in a controlled situation. Of course, this does imply some management overhead - as a (primarily) software company, it's not a problem for us (we regularly have several versions of software available on the network) but I accept others have different setups and don't have this provision. Personally I almost always come down on the side of choice. In theory we have the capability for a complete meltdown - in practice this never happens because we employ intelligent people who understand how we work. There was an article in New Scientist recently about why queues happen. In nature, random particles almost never line up in ordered lines in order to gain an advantage for their particular (no pun intended :-) goals. Humans do it all the time, and it works rather well. The difference is that humans know their goals, and can appreciate the subtle advantages of an incremental change. Pitifully few time management studies take this a-priori knowledge into account when calculating an efficient route to success. Shame. Essentially I think you treat staff like particles at your peril. Treat them as intelligent humans and you get a lot more out them - this includes their time management and efficiency. I have harsh words for staff who waste time playing with fixing s/w unless they really can justify it, but frequently I find that having someone writing and distributing a set of input and output filters for an erroneous program is just as time-wasting as fixing (and making the fixed program available on the network) the original code. As always, your mileage may vary - so it comes down to how you want you (and your staff) to work, both together and independently. I do think it's important to understand why you decide a certain route should be policy, though ... Simon.Article: 26941
I still stand by my statement. True, tweaking the source may get you there quicker, but if it is being handed off to someone or archived, the tweaks represent one more variable in the mix that is likely to be missed when it comes time to maintain the design. Been there, seen that a few too many times. Simon Gornall wrote: > > Ray Andraka wrote: > > > > And it is an absolute nightmare for source control, particularly when the work > > goes to a third party as it does for most consulting. Also creates problems if > > you have multiple projects with different tweaks in the source code. No > > thanks. I'd rather work around the bug and have everyone working with the same > > set of tools than open this can of worms. > > As I see it, this is an internal process issue. Should you wish to > retain an > iron grip over your process, of course it's better to stick with > released > and officially supported software. > > OTOH, if you need to get something done, you know the fix, and you have > the > capability to do it, it'd be madness not to fix it in a controlled > situation. > Of course, this does imply some management overhead - as a (primarily) > software company, it's not a problem for us (we regularly have several > versions > of software available on the network) but I accept others have different > setups and don't have this provision. > > Personally I almost always come down on the side of choice. In theory we > have > the capability for a complete meltdown - in practice this never happens > because > we employ intelligent people who understand how we work. > > There was an article in New Scientist recently about why queues happen. > In > nature, random particles almost never line up in ordered lines in order > to > gain an advantage for their particular (no pun intended :-) goals. > Humans > do it all the time, and it works rather well. The difference is that > humans > know their goals, and can appreciate the subtle advantages of an > incremental > change. Pitifully few time management studies take this a-priori > knowledge > into account when calculating an efficient route to success. Shame. > > Essentially I think you treat staff like particles at your peril. Treat > them > as intelligent humans and you get a lot more out them - this includes > their > time management and efficiency. I have harsh words for staff who waste > time > playing with fixing s/w unless they really can justify it, but > frequently I > find that having someone writing and distributing a set of input and > output > filters for an erroneous program is just as time-wasting as fixing (and > making > the fixed program available on the network) the original code. > > As always, your mileage may vary - so it comes down to how you want you > (and > your staff) to work, both together and independently. I do think it's > important > to understand why you decide a certain route should be policy, though > ... > > Simon. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 26942
On Fri, 03 Nov 2000 18:48:40 +0000, Simon Gornall <simon@unique-id.com> wrote: >> In my experience, source === if the vendor won't fix their program in a >> timely fashion, I can. Or I look to see if someone else has. Sure it's >> a little extra effort, but weigh that up against the cost of working >> around the bugs or lack of critical features. > >The other point, of course, is that under GPL (which most Open Source >programs adopt, as far as I can tell), you are legally obliged to >distribute the source code as well! Of course ONLY if you distribute the binary you generate. If you fix the problem and use the program yourself, you DON'T have to distribute the source. If you distribute the binary, it is only fair that you also distribute the sources because you received them initially yourself for "free". Muzaffer http://www.dspia.comArticle: 26943
On Sat, 04 Nov 2000 00:54:10 GMT, Ray Andraka <ray@andraka.com> wrote: >I still stand by my statement. True, tweaking the source may get you there >quicker, but if it is being handed off to someone or archived, the tweaks >represent one more variable in the mix that is likely to be missed when it comes >time to maintain the design. Been there, seen that a few too many times. > Actually GPL gives you the best of all worlds. You get the source and the binary for the program; you use the binary if that's all you need. If you find and fix a bug, you do the right thing and submit a patch to the original author. Now you have a widely available fix to the problem you found and the process begins again. Muzaffer http://www.dspia.comArticle: 26944
Be careful with I2C clock if you are recieving it into Xilinx parts. The I2C pullup, even if lowered to 1K, may not provide a sharp enough rising edge for the high speed Xilinx logic. Consequently, if you are using the IIC clock signal directly buffered into your internal logic's clock inputs, false clocking may occur as the external signal slowly crosses the ibuf switching level. (Data book says there is about 300mV Schmitt trigger type input hysteresis, but cross-talk and/or ground bounce can easily sneak in to disrupt that rising edge). The Philips spec says to filter the signals; this can be done by internally re-sampling the signals with a suitable high-speed clock (faster than 6X the IIC clock, slower than the signal transition time through the switching region), and simply looking for three consecutive highs or lows before deciding the external signals have changed state. This only costs 2 Spartan CLBs. "Mike H." wrote: > > "Dan" <daniel.deconinck@sympatico.ca> wrote in message > news:o3CM5.2624$x6.56788@news20.bellglobal.com... > > > > To send a I2C line high > > - disable the tristate Output buffer. (The I2C line has a 10Kpullup) > > > > Am I missing something in this driver logic ? > > This is probably not your problem, but you should ideally > have a lower resistance pull-up on the SCL and SDA lines. > For 5V systems, about 1.8k is recommended in the spec. > > MHArticle: 26945
Muzaffer Kal wrote: > > On Fri, 03 Nov 2000 18:48:40 +0000, Simon Gornall > >The other point, of course, is that under GPL (which most Open Source > >programs adopt, as far as I can tell), you are legally obliged to > >distribute the source code as well! > > Of course ONLY if you distribute the binary you generate. If you fix > the problem and use the program yourself, you DON'T have to distribute > the source. If you distribute the binary, it is only fair that you > also distribute the sources because you received them initially > yourself for "free". True enough, but I was responding to "Why do I get all the source code - it just fills up my disk". > I still stand by my statement. True, tweaking the source may get you there > quicker, but if it is being handed off to someone or archived, the tweaks > represent one more variable in the mix that is likely to be missed when it comes > time to maintain the design. Been there, seen that a few too many times. What you say is of course the safest and most reliable method. It doesn't cope with all situations - if you've a show-stopper bug, you end up using something else, and there was presumably a reason why you didn't use 'something else' first, so you're losing somewhere. Our approach is to use CVS for open-source s/w. If people make changes to code, they must check in the code to the network CVS server (hey, it's not hard!) AND tag the changes in a branch called "PROJECT_xxx" so there can be no problems going back to what was actually used on the project afterwards. They're also encouraged to propogate fixes/patches to the original authors - after all, this means we don't have to keep it online :-) (actually we do anyway, but it's still easier to say "Use XXX" rather than "Check out branch YYY of XXX", even though the whole thing is web-based.) I have before now checked out a branch of old source code and given it to a contractor to work with. No problem. The system works quite well, there is an established procedure to follow, and it makes us more flexible in what we do. Of course, your mileage may vary, and it does mean setting up the system in the first place. You pays your money and you makes your choice :-) ATB, Simon -- Physicists get hadrons!Article: 26946
Hi all, Being more of a software than hardware guy, I don't appear to be able to find vendors of any prototyping boards for Spartan2's. Are you all really that gung-ho that you just get your hands dirty and build a board :-) Or am I missing all the adverts due to years of auto-filtering ads on Usenet ? The Spartan2 looks ideal for what we need to do, but I'd rather take out some of the initial design uncertainty by buying a prototype board that I know works - offers on (an e- :-) postcard please ... Cheers, Simon. -- Physicists get hadrons!Article: 26947
Hi, "Ashok Chotai" <Ashok.Chotai@xilinx.com> schrieb im Newsbeitrag news:3A035133.9706DA1D@xilinx.com... > Hello Martin, > Same features, except the pinout. So, for example, FLEX 10K30E device is > NOT pin compatible with ACEX 1K30 device. > Ashok > I recently checked the pinouts of the EP1K100QC208 208pinner against the 10KE device. Every I/O pin and configuration pin was identically, they just switched some VCCIO / GND / VCCINT pins to prevent changing the device. Functionally you wouldn't get problems, but a 10K would cause a short between power supply in 1K layouts and vice versa... CU, CarlhermannArticle: 26948
In article <3a02ce1a.2445236103@news.trw.com>, martin.j.thompson@trw.com (Martin Thompson) wrote: > Can anyone tell me what the difference between the ACEX and FLEX > families of Altera devices is? As far as I can tell, the only > difference is the number of packages supported... Funny, I was just about to ask the /exact/ same question! There are slight differences in timing parameters, but it's not as simple as one being faster than the other! Take a look at the example circuit benchmarks in the data sheets and you'll see that the 1K is a bit slower on simple functions but faster on some complex ones compared to the 10KE equivalent. -- Steve Rencontre http://www.rsn-tech.co.uk //#include <disclaimer.h>Article: 26949
Duane wrote: > > But simulators are a bright spot for Linux these days. I am aware of 5 > Linux native VHDL simulators, at prices from $20K down to $800, and > several offering very cheap versions for students. > > Green Mountain Computing Systems - http://www.gmvhdl.com/products.html > Blue Pacific Computing - http://www.bluepc.com/bluehdl.html > FTL Systems - http://www.ftlsystems.com/compiler_simulators/pathway.html > Cadence - http://www.cadence.com/company/pr/04_17_00linux.html > Mentor Graphics - http://www.model.com/linux.html Looks like I have to add another, in beta: Aldec - http://www.aldec.com/Riviera_Linux/default.htm -- My real email is akamail.com@dclark (or something like that).
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