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, thank You for that estimation. I think ISE will be the right choice for me. From the web presentation of altium it looked like livedesign's virtual tools are more powerfull than ChipScope, but that seems to be a mistake. regards, BenjaminArticle: 80001
Hi Sergio, You need to define what you mean with "live"? MicroBlaze will start executing at 0x0 after reset. When accessing memory where there is no code, the bus usually returns with 0x0. This is add r0,r0,r0 on the MicroBlaze and it will then continue with the next address. So it will run through all memory addresses. You need to have code that loops the MicroBlaze or you can use the FSL for creating a sleep mode on MicroBlaze. If you have a FSL input to MicroBlaze where the FSL_Exists signal is low and you execute a blocking FSL read instruction, MicroBlaze will halt until that signal is '1'. This allows you to create a simple sleep mode. Göran sergio.tota wrote: > Dear Goran, > > you told me that not uploading the firmware does not mean that > MicroBlaze doesn't "work". > > Do you mean that even if with no code to execute they make access to > the OPB bus? > If so, why? > > And, there is a way to keep a MicroBlaze processor "live" without > making it access to the OPB bus? > > I think that I'll use FSL, but in the next months. > > Cheers. > > Sergio >Article: 80002
"Benjamin Menküc" <benjamin@menkuec.de> schrieb im Newsbeitrag news:cvumpu$h13$01$1@news.t-online.com... > Hi, > > thank You for that estimation. I think ISE will be the right choice for me. > From the web presentation of altium it looked like livedesign's virtual > tools are more powerfull than ChipScope, but that seems to be a mistake. > > regards, > Benjamin > it can not be said what is mistake or not livedesign demos are probably cool, and some of the ChipScope features are available in LiveDesign also, but generically ChipScope is better doing deep FPGA scoping, and defenetly better choice if you are doing mainly Xilinx designs, another thing is that Altium charges 9000 USD for the tools, and ChipScope cost a less than that :) AnttiArticle: 80003
On Sun, 27 Feb 2005 22:07:24 -0600, hmurray@suespammers.org (Hal Murray) wrote: >>If this is just a one-off or very low volume device that doesn't require >> a high-efficiency power source, why wouldn't you use an LDO? They're >>easy! Although switchers, etc, are getting easier and more reliable, >>they're more complicated -- just in component count alone. > >Beware. Modern LDO regulators have restrictions on the ESR of the >filter caps. Too low or too high and they oscillate. > >I'm far from a wizard on this topic. But I got burned several years >ago so it's on my hot-list of things to check carefully and then still >be suspicious. > >I think older non-LDO type linear regulators are easier to work with. >But they often don't go down to 1.2V. Also, bear in mind that older devices may not have the load-transient response performance that modern high-speed logic may need.Article: 80004
OpenSoc has released a new version of his free SystemC to Verilog Synthesizable Subset Translator with new features like function translation support. You can download it from www.opensocdesign.com Best Regards Javier Castillo jcastillo@opensocdesign.com www.opensocdesign.comArticle: 80005
>> The whole idea is to build the sampling part of an digital >> oscilloscope. This should include sampling, triggering as in an >> digital storage oscilloscope. > > > For that, you need 1:2:5:10:20:50:100 for the best human friendly > timebase (rather than a long binary counter). I agree with you on that! > You can code as above, with taps, and a single MUX, or you could have > a first stage that can select a choice of divide by /1/2/5/10, as a > clock enable into following cascaded /10 stages that select > 10/100/1000/10000 etc. I dont't what you mean by that! What are taps? I only know taps from the DCM's (and I can't see that I can use that for this) How will you use the MUX? Please sketch some VHDL or components for me so I can see the idea? > If you were being 'register frugal', (eg using a CPLD), > then the first stage of > /1/2/5/10/20/50 is 6 bits wide, and follow that with a number > of /100 cascades [7 bits] The idea is to make the smallest "die", so using only the FPGA and maybe some external RAM. > The output of this divider chain would be conditioned to be one clock > wide, and feed as ClkEnable into the simple binary-memory > scanning/loading counter - the scanner counter needs a trigger state > engine to Start on Signal trigger, and stop at MAX (or sooner if set).Article: 80006
Peter Alfke wrote: > Preben, your English is ok, better than my limited Danish. > You want to build a sampling scope (so do I). > You must start with the A/D vonverter, for that's where most of you > money goes. I already got the A/D converter. It's 8 bit conversion and min. sampling rate is 1MHz and maximum of 100MHz. So I use the highest clock that gives me no problems at the Starter Kit (Spartan 3). > That determines the sampling rate = clock, and you must have low > jitter! > The rest is not too complicated. You can use on-chip BlockRAM, but you > need an interface to external DRAM ( cheap and easily available). I > suppose you move all the display and human interface problems onto the > PC (that's what I would do). Saves you a lot of work and assures good > looks. Well, the time planning I made for my project is to last until the end of june where I hope to have build the sampling circuitry with triggering (and pre-triggering). > Now, designig a counter should be the least of your problems... Yes, it's not the counter, but the prescaling that irritates me. I read your note xl33_30 about the "unusual clock dividers". The problem for me is, that I need to build a configurable clock-divider and not a "fixed" division. I could use clock-division since this a nice idea, but also I need the min. sampling rate of 1MHz. The idea could also be to use a FIFO-buffer that just samples at the rate of fx. 50MHz (and prescale the FIFO-counting) and read from the FIFO (dual-port) at a faster or slower rate when the fifo is full!Article: 80007
I don not think it is possible there seems to be too much different maybe you can call xilinx or visit www.xilinx.com to get a resolutionArticle: 80008
hello I wish you could recommend a synthsis tool for systemC. It will be really wonderful if the tool is free for download. I know "Colexica" and "cocentric" ,but never use them. Who can give me some tips of these tools. ThanksArticle: 80009
"Kryten" <kryten_droid_obfusticator@ntlworld.com> wrote in message news:IevUd.2761$Qd1.1132@newsfe2-gui.ntli.net... > "Anthony Fremont" <spam@anywhere.com> wrote in message > news:aQtUd.66873$cW2.23375@fe2.texas.rr.com... > > > >> I see "TWI" in data sheets > > I see this done also but, according to Philips, it doesn't alleviate the > > end user of the responsibility of acquiring a license. Here let me > > quote them, I hope they don't sue me for copyright violations: > > > "It is Philips's position that all chips that can talk > > to the I˛C bus must be licensed." > > Any microcontroller with two I/O pins that can be > switched from 0V to hi-z can talk to the I2C bus. I agree, but I think they mean chips that are actually programmed. > I heard that they didn't mind you making an I2C master that can talk to I2C > slaves, since most of their I2C-ready chips were slaves for TV innards etc. > and they could not really demand a licence from potential customers. > > However I heard they did not want to allow people free rein to make > competing slave chips, so they did demand a licence fee on that. Well, that could be I suppose, but my qoute was directly from Philip's web site. > > Well, how do you like that? They see no end to their patent's reach. > > I maintain, however, that many of their patents have likely expired. > > I've sure never seen Philips defending their patent on I2C as vehemently > > as the above quote would indicate. Me thinks they don't want to make to > > many waves about their "obvious" technique lest they lose out on all the > > companies that currently pay them. > > When I was in the consumer electronics arena, word was that Philips > developed stuff like the I2C chips for TVs and RC5 / RC6 for their own TVs > etc, and their chip making branch was their to serve their consumer goods > making branch. They would sell their chips to others to spread the NRE but > they would not make much effort to support them. After all you might be a > competing TV maker. > > They made the RC5 standard public but it was not a very tight spec and some > manufacturers used unassigned codes for their own purposes. So when they > came up with RC6 they didn't bother publicising standards at all. > > > As long as you need to send data in both directions simultaneously, > > I suppose it is. > > Well, just ignore the stuff you don't want. > > > It does require 50% more wires though > > (2-wire I2C vs. 3-wire SPI) > > One more wire is not a huge burden. > > > Isn't it amazing how no-one needs a ground to > > communicate? > > > You kinda make SPI sound like a panacea compared to I2C > > Not my intention. > > The OP sounded like he just needed a point to point link, > thus the SPI would be good enough. > > > Real SPI requires chip select pins for each slave device > > I know. > > But if he only has the one slave, that's only one pin. > > > the total number of wires to 3 + > > number_of_slave_devices (not counting the ground), > > True, and I2C tackles that issue. > > > inconvenient and wasteful IMO. > > > > > > There are also I2C devices that have a > > maximum speed of 2 MHz. > > That is beyond the I2C spec, which is 100 kbps or 400 kbps in the faster > version. > I2C slaves are not obliged to run that fast, so you cannot rely on an I2C > slave being that fast. > > > > AFAIK, SPI is not that much faster than that > > But the SPI spec insists on a higher speed, thus if a slave say it uses SPI > then the guaranteed speed is higher. > > > There does seem to be some discrepancy out there as to what constitutes > > a START condition. Some vendors think you have to bring the clock low > > after bringing the data low before considering it a START. > > That's not how Philip's describes it though > > as they say nothing about bringing the > > clock low to complete the start condition. > > If Philips own the spec, then what they say _is_ the spec. > If other vendors wish to diverge, then they should look out. > > Maybe Philips should tighten up the spec. > > I have noticed that I2C slave interface on Microchip's PIC is a crock of > shit. > It locks up if it gets confused, then doesn't allow you to escape from it by > software. > > >> I2C master behaviour is easily implemented by > >> bit-bashing a pair of open-collector pins. > > > > I agree. I've just been doing this for the first time ever with some > > serial EEPROMs and a DS1307 real-time clock chip. I like it, it's a > > cake walk compared to Dallas 1-wire i/o. ;-) > > It is nice eh? > > Though I did find there were some quirks in various I2C slave chips. > My LM75 thermometer isn't talking to me yet! > I think it wants a 100 nF decoupler. Hard telling. I had real good luck when I recently implemented my bit bang I2C stuff. It worked the first time out. However, I can easily imagine how frustrating solving a problem could potentially be. I don't own a DSO or logic analyzer so I rely allot on fully understanding the protocol before writing that first line of code. The exception to this was when I wrote a Dallas 1-wire search routine. I didn't really understand it all until I was done writing the code. I blindly implemented a flow chart that Dallas provides. I did this in PIC assembler, but the problem cries out for a recursive solution. In my current project, I have a PIC talking to various serial eeproms and a Dallas 1307 real time clock. I2C may not be perfect, but it's doing a nice job for me. I've never used an LM75, but I have used an LM34 and various Dallas 1-wire temp sensors. I really like the 1-wire temp sensors, but they only come in Centigrade outputs.Article: 80010
"Jim Granville" <no.spam@designtools.co.nz> wrote in message news:42228d04$1@clear.net.nz... > Anthony Fremont wrote: > > "Kryten" <kryten_droid_obfusticator@ntlworld.com> wrote in message > > news:sjkUd.840$AB1.557@newsfe4-gui.ntli.net... > > > >>>;-) Also, if he's looking to sell these, he will need to obtain a > >>>license from Phillips. > >> > >>IIRC you do if you want to market it with "I2C" mentioned anywhere, > >>but if you call it something else (e.g. Two-Wire Interface or TWI) > > then you do not. > >>I see "TWI" in data sheets that look remarkably like I2C at first > > glance and may be identical. > > You can also call it AccessBUS, which is a PC variant. Or even SMBus? > > I see this done also but, according to Philips, it doesn't alleviate the > > end user of the responsibility of acquiring a license. Here let me > > quote them, I hope they don't sue me for copyright violations: > > > > ============================== > > > > "A license is required for implementing an I˛C interface on a chip (IC, > > ASIC, FPGA, etc). It is Philips's position that all chips that can talk > > to the I˛C bus must be licensed. It doesn't matter how this interface is > > implemented. The licensed manufacturer may use its own know how, > > purchased IP cores, or whatever. > > > > This also applies to FPGAs. However, since the FPGAs are programmed by > > the user, the user is considered a company that builds an I˛C -IC and > > would need to obtain the license from Philips. " > > > > ============================== > > > > Well, how do you like that? They see no end to their patent's reach. > > I maintain, however, that many of their patents have likely expired. > > I've sure never seen Philips defending their patent on I2C as vehemently > > as the above quote would indicate. Me thinks they don't want to make to > > many waves about their "obvious" technique lest they lose out on all the > > companies that currently pay them. > > Maybe, but I have a Philips data book IC12 that states : > " i2c BUS based system designs require no special license, and the i2c > bus protocol is easily implemented by virtually any microcontroller on > the market" > > i2c IS a trademark, and so if you want to get the perceived marketing > of that trademark, and use it in your DOCs, Philips have to give the OK. Interesting. My quote was straight from Philip's site in the licensing area. Perhaps the patents are finally expired? Here is a link to a document dated as 2H 2003: http://www.semiconductors.philips.com/acrobat_download/various/i2c_overview_2h_2003.pdf > <snip> > > There are also I2C devices that have a > > maximum speed of 2Mhz. AFAIK, SPI is not that much faster than that > > even with being able to transfer data full duplex. > > i2c has Speed nodes at 100Khz, 400KHz, 1MHz, and 3.4MHz, but few > devices can be found at 3.4MHz.... > SPI is now commonly spec'd to 25MHz, and some devices are 50MHz. That's pretty fast. I'm guessing you don't get 100M of bus length very easily. ;-) > Some SPI designs use a RING scheme, which removes the multiple > chip-select issues. With most SPI HW ports in uC, they fully support > this RING alternative. > > Using as FPGA-FPGA there is no strict need to stick to anyt of the i2c > speeds, and if you deployed it using CAN BUS buffers (or wired-OR > configured RS422 devices) you could probably get i2c over 20MHz > > > -jg >Article: 80011
"Jim Granville" <no.spam@designtools.co.nz> wrote in message news:42228d04$1@clear.net.nz... > You can also call it AccessBUS, which is a PC variant. I believe it is not a variant but a desk-top bus that uses I2C as the signalling protocol as a foundation. It then goes on to specify the contents of the messages sent across I2C. > Using as FPGA-FPGA there is no strict need to stick to any of the i2c > speeds, and if you deployed it using CAN BUS buffers (or wired-OR > configured RS422 devices) you could probably get i2c over 20 MHz If he is just using it for point-to-point comms there is no need to stick to any spec at all. With only one bus master there is no need for wire-oring of any sort, so no need for CANbus buffers either.Article: 80012
"Anthony Fremont" <spam@anywhere.com> wrote in message news:1dEUd.68226$cW2.61773@fe2.texas.rr.com... > >> Any microcontroller with two I/O pins that can be >> switched from 0V to hi-z can talk to the I2C bus. > > I agree, but I think they mean chips that are actually programmed. I think they mean any hardware implementation that handles much of the low level stuff. I've written software to bit-bang I2C without paying a licence. It would be pretty hard to enforce licence fees there, unlike chips that you have to make in millions. > I can easily imagine how frustrating solving a problem could potentially > be. Most problems I hear are due to people not following the I2C spec faithfully. > I rely a lot on fully understanding the protocol > before writing that first line of code. Yep, helps a lot. :-) > I2C may not be perfect, but it's > doing a nice job for me. I don't have any complaints about I2C at all. It is very cunning yet masters require only a couple of I/O bits to use it. > I've never used an LM75, but I have used an LM34 and various Dallas > 1-wire temp sensors. > I really like the 1-wire temp sensors, > but they only come in Centigrade outputs. Hmm, I only see the F-word <grin> used in weather reports where they translate the temperature for the benefit of people who couldn't/wouldn't get a grip on modern units. Typically old people. If you are making a weather station type thing then the rounding errors of the C to F conversion shouldn't be a big problem.Article: 80013
You can use sc2v to translate your SystemC code to a Verilog equivalent one and then synthesize it with a commercial Verilog synthesis tool. Sc2v is freely available at www.opensocdesign.com Regards Javier Castillo jcastillo@opensocdesign.com "Chinix" <qinxi@mail.csdn.net> wrote in news:1109590758.827243.293030 @f14g2000cwb.googlegroups.com: > hello > I wish you could recommend a synthsis tool for systemC. > It will be really wonderful if the tool is free for download. > I know "Colexica" and "cocentric" ,but never use them. > Who can give me some tips of these tools. > Thanks > >Article: 80014
Jeremy Stringer <jeremy@_NOSPAM_endace.com> writes: > One thing I guess you could consider is that the GPL can make things > difficult for companies that want to integrate your IP block into a > commercial product, because of the requirement to redistribute source > code. Well, not a big problem. Such companies are free to contact the author for a different licensing of the same source if they have different needs. MB -- Michel BILLAUD billaud@labri.fr LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)Article: 80015
Read my lips: I saird: "Virtex-II is faster". Peter Alfke digari@dacafe.com wrote: > So does it mean that if my design size is less than 5M (xilinx gates > ;-)) and i am not using the specific features of virtex-II then will I > get the same performance in both spartenIII and virtex2???Article: 80016
Preben, I would run the A/D continuously at the fastest rate possible with a "jitter-free" clock. Then, in the digital domain, you can always average or throw away samples to fit your time scale. At the frequencies you are mentioning, you just build a synchronous binary counter and either decode a specific value, and reset, or (my favorite) you detect overflow and synchronously preset to a certain value. I wish you success. Peter AlfkeArticle: 80017
hi even i was struggling with floating point calculation in vhdl...a simple search on google landed me on the following website. www.perso.ens-lyon.fr/jeremie.detrey/FPLibrary/ i tried the routines in xilnx ise + modelsim...it worked fine. nisheethArticle: 80018
Peter Alfke <alfke@sbcglobal.net> wrote: > Read my lips: > I saird: "Virtex-II is faster". > Peter Alfke But I guess Spartan III has "more bang for the buck" :-) -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 80019
Has anyone found the -12 Virtex4 speedfile that are mentioned in the latest Xilinx press release? I haven't seen them anywhere on their website. -KevinArticle: 80020
cecilia annovi wrote: > my name is Cecilia and I'm a student in engineering at the university of > Modena & Reggio Emilia. For my disseration I must work with Altera's FPGA. > I must analize signals from an EEG with multipliers and adders. the signal's > type is real, (float precision) so I'm working, to get my pourpuse, with > floating point. Well, I found the multiplier for floating point in the mega > wizard plug in manager (altfpmult) and it works well, but I can't find an > adder/subtracter for floating point! I' ve tried to built one with VHDL, but > I'm far from the target (it's not so easy..). First, do you really need floating point, and, if so, how big an exponent range do you need? Floating point multiply isn't much harder than fixed point, especially if you have multiply hardware like many FPGAs now do. Floating point add requires a barrel shifter which is pretty big. If you want full IEEE standard there is a lot more logic required. On many processors floating point is easy and just about as fast as fixed point, so much scientific and engineering programming is done that way. That doesn't mean that it needs to be done that way. Reducing the exponent range will simplify floating point addition somewhat, though you will have to learn something about floating point hardware to do that, and most likely you will anyway. Though the usual reason for using FPGAs for computation is speed, and I don't believe that EEGs are so fast as to require that speed. You might be able to do what you need in software on an FPGA based processor. -- glenArticle: 80021
I know I had made a big mess in my previos message.. I try to explain better and shortly... I've received some precious advices in this newsgroup about an unavailable block adder for floating point, and some of you adviced me to use libraries for floating point found in the web.. I have already included a foreign library in a project with Xilinx Project Navigator, without any problems...but I can't do the same in the Quartus II of Altera !! When I compile the foreign library I find a lot of errors without sense!! (e.g. the compiler can't find the top level entity of the project ..) in short: how can I include a library in a project compiled with the quartus II ?someone has been able to do this??? thank you...CeciliaArticle: 80022
Hello, some feedback about the counter we discussed sometime back. I did test my counter with the clock selector circuit from Peter. It works in rtl simulation and hence, I went directly to FPGA testing, with a chipscope core to give me feedback on the actual implementation. It actually failed, as I was thinking, in hardware. It sound reasonable to say that in order for this circuit to be actually usable, we either need to put constrains on the clock netlists, or to manually route the clock selector circuit so that it minimizes the delay to the counters it is driving, or, as I did, to use a bufg component so as to use the FPGA chip's clock plane. cheers Jacques Peter Alfke wrote: > I do not want to sound obnoxious, but "my" clock multiplexer is safe. > It does not create a glitch nor a runt pulse, provided metastability > settles within one half period. And that is practically guaranteed: at > the quoted clock rates, MTBF is many billion times longer than the > expected life of the universe... > And as I wrote before, no matter how you design with two clocks of > unknown phase relationship, you have to deal with metastability, and > everything becomes probabilistic... > Peter AlfkeArticle: 80023
It sounds like you are having the same frustrations I had when I first started out. If I remember right it has do with the order the files are compiled. If you go into QuartusII, open your project, goto the assignments menu, select the settings menu item the settings dialog window should open. >From the list on the left hand side select files. You should see a list of your source files. First thing you should check for is if all your files are there and if they are not then you need to add them. Second are they in the right order? Many compiles will perform a pass to build a dependencies list. Quartus doesn't, it expects you to put your files in the order they need to be built. Hope this helps. DerekArticle: 80024
> Preben, I would run the A/D continuously at the fastest rate possible > with a "jitter-free" clock. > Then, in the digital domain, you can always average or throw away > samples to fit your time scale. That's the idea I've had. > At the frequencies you are mentioning, you just build a synchronous > binary counter and either decode a specific value, and reset, or (my > favorite) you detect overflow and synchronously preset to a certain > value. Thanks.. I never thought about a preset value and then detecting overflow - that's a fine idea! Thanks for helping Preben
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