Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Oct 25, 6:36 pm, motty <mottobla...@yahoo.com> wrote: > Thanks Sovan, > > I am going to try requesting the address before pushing data to see > what happens! Well, I also tried both for Four-Word cacheline writes. First I pushed the address then data. The NPI consumed the first word, then it stalled for a couple of cycles, then resumed... Now I use 64word xfers, pushing 64bit data one at the time, with large time gaps. When I have pushed all of the 64words (32pushes) I send the address and the data is transferred. GuruArticle: 125476
On 25 Okt., 19:38, martin_pa...@yahoo.com wrote: > On Sep 21, 12:09 am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > > > Hi > > > information from reliable source (but not verified by actual test- > > purchases): > > > "Actel silicon with and without Cortex-M1 enable option cost exactly > > the same, not a penny more" > > > I requested to verify and repeat that claim, and the source did stand > > to it. > > > If this is really so - this can only be verified when buying Actel M1 > > silicon and non-M1 at same time from same vendor, then it means that > > there really is no hidden fee any more in theARMsoftcore. > > > let me remind that while Actel also claimed M7 to be "free" the actual > > M7 enabled silicon cost 1 USD (qty 100k) or 100 USD (qty 1) more then > > silicon without M7 AES key. > > > Antti > > Antti et al, > > Antti is correct our pricing model for the M1 (ARM enabled Cortex-M1) > products is to offer them at the same price as our regular ProASIC3, > Igloo and Fusion device prices. Basically ARM enabled for free. > > However it should be noted than we do not set final resales for our > devices through distribution so you may see small variations in price > (for all products) which are not under Actel's control. > > Martin Mason > Actel Corp.- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - Hi Martin, thanks for OFFICIAL statement, my original info was also from inside Actel but from not as high level ;) This is REALLY good news. M1P250 seems like really nice little bastard, and if there is no ARM license fee, really nice. I was REALLY disappointed with the free-M7 story, the reseller add over 100 USD per IC for the "free ARM license" and they also told that this fee is forced by Atmel and they reseller has no control over it. I would have even paid that extra 100, but if you want to play with Actel M7, you really cant just buy one sample chip, I have tried and failed. So from what I understand in the case of M1 the resellers should not charge extra 100 USD for the "M1" logo on IC, that nice! AnttiArticle: 125477
Hi attached to xilinx forum message http://forums.xilinx.com/xlnx/board/message?board.id=OTHERIP&thread.id=19 is a simple JTAG-SPI gateway IP core that is been used for SPI flash programming on S3E the demo toplevel include Spartan-3 BSAN, but by only replacing that primitive it is adaptable to almost any FPGA/CPLD family AnttiArticle: 125478
Yes, this is on my list of concerns. For the time being I plan on solving the problem by using the "don't do that!" method. I started *way* too late to be ready for a Christmas light show so I won't be able to really fix this problem this year. "Chris Maryan" <kmaryan@gmail.com> wrote in message news:1193371715.999672.227300@y42g2000hsy.googlegroups.com... > Not really answering your question, but... Sink or source, 128 x 7mA > is a lot, your FPGA may not be able to handle it. You probably need > something a bit more efficient or maybe an extra level of transistors > to give current gain. >Article: 125479
<sendthis@gmail.com> wrote in message news:1193382473.115596.137900@k79g2000hse.googlegroups.com... > >> Here is a free suggestion (the price is right): >> I would write a specific word-pattern with an even mix of 1 and 0 into >> every location in the whole DRAM. >> Then read back sequentially at a slow pace through all addresses, >> always checking the readback. >> Sooner or later, you will pick up an error, becaue you exceeded the >> refresh delay. >> You may want to repeat this with different starting addresses and with >> different word patterns. > > The problem is during the read (I'm assuming you mean by disabling the > refresh altogether and relying solely on the refresh after read) is > that it takes several seconds to read from the DRAM. This will always > exceed the refresh time right? From the start_address to end_address > it takes quite a while for a 64Mbit DRAM. The spec calls for a 64ms > refresh. > A much bigger problem is that reading a DRAM location implicitly refreshes that entire row. Therefore, you can't poll to find out if your refresh is frequent enough because each read will perform a refresh. You will probably find that if you disable refresh totally then most of the memory will stay intact for several seconds (and across power cycles!). If I was you, I would disable refresh totally, write a test pattern to memory and then check it after about five seconds to find one location that has failed. Once you've picked that one, use that as your test location. You can then write to it with various refresh rates and see if the data is still valid many seconds later. You probably won't have found the worst-case cell in the device, but that's rather academic because every device will be different anyway so this is far from a valid characterization test.Article: 125480
On Oct 26, 3:07 am, sendt...@gmail.com wrote: > > Here is a free suggestion (the price is right): > > I would write a specific word-pattern with an even mix of 1 and 0 into > > every location in the whole DRAM. > > Then read back sequentially at a slow pace through all addresses, > > always checking the readback. > > Sooner or later, you will pick up an error, becaue you exceeded the > > refresh delay. > > You may want to repeat this with different starting addresses and with > > different word patterns. > > The problem is during the read (I'm assuming you mean by disabling the > refresh altogether and relying solely on the refresh after read) is > that it takes several seconds to read from the DRAM. This will always > exceed the refresh time right? From the start_address to end_address > it takes quite a while for a 64Mbit DRAM. The spec calls for a 64ms > refresh. The other problem is that the act of reading in fact performs a refresh so depending on the way you hooked up the address lines, you may actually refresh the entire chip many times over while reading through once. But I think Peter's second statement is really important. When you think of the mechanism for a single-event upset, how much difference is a fully charged capacitor vs a capacitor allowed to drain for the specified 64mS (or some other refresh rate of your choice). If the standard refresh rate only allows a charge drop of say 20%, I don't see how doubling the rate and allowing a charge drop of only 10% will greatly reduce the percentage of events that cannot discharge a given capacitor. Under normal operating conditions I would imagine that the charge drain is much smaller than 20%. In the old days, before the semiconductor manufacturers found radiation being emitted by some of the early ceramic packages, a lot of large memory systems used ECC with scrubbing refresh to make the system at all usable. In my opinion reducing the likelihood of uncorrectable multiple events via scrubbing is more effective than keeping your capacitors at peak charge. Regards, GaborArticle: 125481
On Oct 26, 7:39 am, "Nevo" <nev...@hotmail.com> wrote: > Yes, this is on my list of concerns. For the time being I plan on solving > the problem by using the "don't do that!" method. I started *way* too late > to be ready for a Christmas light show so I won't be able to really fix this > problem this year. > > "Chris Maryan" <kmar...@gmail.com> wrote in message > > news:1193371715.999672.227300@y42g2000hsy.googlegroups.com... > > > Not really answering your question, but... Sink or source, 128 x 7mA > > is a lot, your FPGA may not be able to handle it. You probably need > > something a bit more efficient or maybe an extra level of transistors > > to give current gain. You can never have too much capacitance on the VCCIO, in my opinion. At 120 Hz, it should be easy for you to stagger the output timing of the various triac drivers without materially affecting the dimming quality. This would reduce the issues of simultaneous switching and also reduce the high-speed decoupling requirements on VCCIO. However there may be another issue that gets you in the end. Where are you mounting all the triacs and how easy is it for the triac switching noise to find its way back to the FPGA power system? Even with optocouplers, if your input supply shares AC wiring with the triac AC system you may be in for trouble. Think about any possible coupling paths. Have Fun, GaborArticle: 125482
>...At 120 Hz, it should be easy for you to stagger the output timing >of the various triac drivers without materially affecting the dimming >quality I don't understand how he can do this. For a given brightness, doesn't this fix when he has to switch on the triac? (There's no choice about when to switch off: it won't switch off until the current falls to zero at the end of the half-cycle). MikeArticle: 125483
On Oct 25, 10:37 pm, Antti <Antti.Luk...@googlemail.com> wrote: > On 25 Okt., 23:21, Tommy Thorn <tommy.th...@gmail.com> wrote: > > > Surely you would be the kind of person to jump to conclusion? I have > > used Quartus II from before version 6 and I have never had a crash > > (unlike with ISE). > > > Tommy > > eh, yes, I have really occasionally touched quartus. > to my memory it did never have problems. > > so that made me really wonder that 7.1 self-terminates about once per > hour. > > expect that self-termiation it works rather fine, and yes its better > to live > with occasioal self-closure then real bugs with tools like some other > vendor tools > > Antti I am not sure I follow - your smallest design takes hour(s) to synthesize and p&r??? I have used Q2 7.1 for about 20K le designs. So far no problems. But I must say, that Q2 does crash once in a blue moon but that is during synthesis.Article: 125484
Thanks for the help guys. It appears to work when the AddrReq comes before the data push. I guess the IP needs to 'get ready' for one 64- bit entity using the req. And it does not work the other way around. The documentation (release notes) is misleading in the fact that it basically says that the safest way to do things is to push data then do the addr req. They should say next to that 'don't do this with 64- bit double-word writes though'. Maybe my reading comprehension needs adjustment.Article: 125485
On 26 Okt., 14:30, fpgabuilder <fpgabuilder-gro...@yahoo.com> wrote: > On Oct 25, 10:37 pm, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > > > On 25 Okt., 23:21, Tommy Thorn <tommy.th...@gmail.com> wrote: > > > > Surely you would be the kind of person to jump to conclusion? I have > > > used Quartus II from before version 6 and I have never had a crash > > > (unlike with ISE). > > > > Tommy > > > eh, yes, I have really occasionally touched quartus. > > to my memory it did never have problems. > > > so that made me really wonder that 7.1 self-terminates about once per > > hour. > > > expect that self-termiation it works rather fine, and yes its better > > to live > > with occasioal self-closure then real bugs with tools like some other > > vendor tools > > > Antti > > I am not sure I follow - your smallest design takes hour(s) to > synthesize and p&r??? I have used Q2 7.1 for about 20K le designs. > So far no problems. But I must say, that Q2 does crash once in a > blue moon but that is during synthesis.- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - no, the design take very little time to run p&r but Quartus itself SELF-terminates itself at least 1 time each hour! ok, so what you see "once in a blue moon" I see at least every hour... I switched from 7.1 to 7.2 maybe its better now AnttiArticle: 125486
When it comes to designing for fpgas or asics there are a lot of guidelines/rules that need to be followed consistently between the both. Yes! things dealing with verilog event queue, metastability and asynchronous clock domains, etc. What I am wondering is what are the key differences between the designs targeted toward one or the other. Thought it may make an interesting discussion. Some that come to mind are - + Number of logic levels between flops + Uniform delay through a lut vs different delays through nand gates. Asic delays highly dependent on the synthesizer and coding style? FPGAs more forgiving about how the combinatorial logic is coded? + Asynchronous resets in fpgas + Clock gating not as efficient in fpga therefore use flop enables. Require changes to the coding style? + Others?Article: 125487
On Oct 26, 5:42 am, Antti <Antti.Luk...@googlemail.com> wrote: > On 26 Okt., 14:30, fpgabuilder <fpgabuilder-gro...@yahoo.com> wrote: > > > > > On Oct 25, 10:37 pm, Antti <Antti.Luk...@googlemail.com> wrote: > > > > On 25 Okt., 23:21, Tommy Thorn <tommy.th...@gmail.com> wrote: > > > > > Surely you would be the kind of person to jump to conclusion? I have > > > > used Quartus II from before version 6 and I have never had a crash > > > > (unlike with ISE). > > > > > Tommy > > > > eh, yes, I have really occasionally touched quartus. > > > to my memory it did never have problems. > > > > so that made me really wonder that 7.1 self-terminates about once per > > > hour. > > > > expect that self-termiation it works rather fine, and yes its better > > > to live > > > with occasioal self-closure then real bugs with tools like some other > > > vendor tools > > > > Antti > > > I am not sure I follow - your smallest design takes hour(s) to > > synthesize and p&r??? I have used Q2 7.1 for about 20K le designs. > > So far no problems. But I must say, that Q2 does crash once in a > > blue moon but that is during synthesis.- Zitierten Text ausblenden - > > > - Zitierten Text anzeigen - > > no, the design take very little time to run p&r > but Quartus itself SELF-terminates itself at least 1 time each hour! > > ok, so what you see "once in a blue moon" I see at least every hour... > > I switched from 7.1 to 7.2 maybe its better now > > Antti Haven't seen that problem. I leave Q2 7.1 running before leaving at night. It goes through s,p&r for about 1/2 hour and then just sits idle without crashing or terminating. Could it be the license server on your machine? Or one of those Altera Opencore evaluation ip timing out on you?Article: 125488
On Thu, 25 Oct 2007 08:26:07 -0700, llombard@gmail.com wrote: >Hello, >I'm very interested into this topic as I am tryin to implement a >feedback loop (PID controller) with a spartan3e starter kit with >xilinx ISE. The + and * operation is taking almost 40ns which is much >more than 20ns limit for 50MHz operation. So I cut the operation is 3 >sub operations so it fits into 19.98ns. I'm not sure it is the right >way to do it but it seems to work. But still I get the message >"INFO:Xst:2385 - HDL ADVISOR - You can improve the performance of the >multiplier Mmult_sig_d_00_mult0001 by adding 2 register level(s)." for >the operation "sig_p <= pid_p*erreur/8192;" All variables are integer >signals. Could you advise me on what to do? If it's meeting timings (as you say it is) and there is no advantage to you in running it faster (say, 100MHz) you don't need to do anything. If you want to run it faster, add more pipeline registers around the multiplier and re-simulate to verify that your control loop stability is satisfactory. (Adding delays around a feedback loop makes me nervous :-) The multipliers in newer technologies (V4 and V5) seem to have a huge appetite for pipeline registers, and there are sometimes large delays between these registers and the CLB fabric, so it is sometimes worth adding a pipe stage devoted to getting signals from CLB registers into multiplier registers (and back out) if you need higher performance. If you follow the HDL ADVISOR advice, 100MHz (10ns) should be relatively easy even in Spartan-3e; but if you don't need that speed, what you have done is fine. - BrianArticle: 125489
On Mon, 22 Oct 2007 22:44:56 -0700, sendthis@gmail.com wrote: >Hi, > >I'm trying to control a SDR SDRAM (Micron 64Mbit chip) using an Altera >DE2 board. I've gotten the hardware interface squared away (thanks >everyone for your help!). > >Now it's the tricky stuff. Any one have an idea how I can change the >refresh rate while the RAM is in operation? If you roll your own controller (easy enough for SDR SDRAM) or can understand the core you are given, you can find what controls the refresh rate; invariably a counter. Replace the counter with an absurdly long one (say 32 bits), whose count length is controllable from a register accessible to whatever host CPU (NIOS in this case). It's either a reloadable down counter, which reloads and generates a refresh cycle when it hits zero; in which case you reload it from the register; or an up-counter which refreshes and resets to zero when a comparator triggers; in which case the register holds the comparator value. Then you have direct control of the refresh rate without messing with clock frequencies etc. - BrianArticle: 125490
On 26 Okt., 14:58, fpgabuilder <fpgabuilder-gro...@yahoo.com> wrote: > On Oct 26, 5:42 am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > > > On 26 Okt., 14:30, fpgabuilder <fpgabuilder-gro...@yahoo.com> wrote: > > > > On Oct 25, 10:37 pm, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > On 25 Okt., 23:21, Tommy Thorn <tommy.th...@gmail.com> wrote: > > > > > > Surely you would be the kind of person to jump to conclusion? I have > > > > > used Quartus II from before version 6 and I have never had a crash > > > > > (unlike with ISE). > > > > > > Tommy > > > > > eh, yes, I have really occasionally touched quartus. > > > > to my memory it did never have problems. > > > > > so that made me really wonder that 7.1 self-terminates about once per > > > > hour. > > > > > expect that self-termiation it works rather fine, and yes its better > > > > to live > > > > with occasioal self-closure then real bugs with tools like some other > > > > vendor tools > > > > > Antti > > > > I am not sure I follow - your smallest design takes hour(s) to > > > synthesize and p&r??? I have used Q2 7.1 for about 20K le designs. > > > So far no problems. But I must say, that Q2 does crash once in a > > > blue moon but that is during synthesis.- Zitierten Text ausblenden - > > > > - Zitierten Text anzeigen - > > > no, the design take very little time to run p&r > > but Quartus itself SELF-terminates itself at least 1 time each hour! > > > ok, so what you see "once in a blue moon" I see at least every hour... > > > I switched from 7.1 to 7.2 maybe its better now > > > Antti > > Haven't seen that problem. I leave Q2 7.1 running before leaving at > night. It goes through s,p&r for about 1/2 hour and then just sits > idle without crashing or terminating. Could it be the license server > on your machine? Or one of those Altera Opencore evaluation ip timing > out on you?- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - i did work very much with the simulator, so I was typing and clicking with mouse all the time and witnessed those self-closure effects. maybe it is related to simulator somehow AnttiArticle: 125491
David Spencer wrote: > ... snip ... > > A much bigger problem is that reading a DRAM location implicitly > refreshes that entire row. Therefore, you can't poll to find out > if your refresh is frequent enough because each read will perform > a refresh. > > You will probably find that if you disable refresh totally then > most of the memory will stay intact for several seconds (and > across power cycles!). If I was you, I would disable refresh > totally, write a test pattern to memory and then check it after > about five seconds to find one location that has failed. Once > you've picked that one, use that as your test location. You can > then write to it with various refresh rates and see if the data > is still valid many seconds later. You probably won't have found > the worst-case cell in the device, but that's rather academic > because every device will be different anyway so this is far > from a valid characterization test. Things may be much 'worse' than that. I remember one of the first 16k RAM chips developed, which we found (by accident) could retain information for days with power off. This couldn't be trusted. Those chips were actually static memory 2k x 8 bits, not dynamic. -- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> -- Posted via a free Usenet account from http://www.teranews.comArticle: 125492
On Oct 26, 8:05 am, Gabor <ga...@alacron.com> wrote: [] > > In the old days, before the semiconductor manufacturers found > radiation being emitted by some of the early ceramic packages, > a lot of large memory systems used ECC with scrubbing refresh > to make the system at all usable. In my opinion reducing the > likelihood of uncorrectable multiple events via scrubbing is > more effective than keeping your capacitors at peak charge. > > Regards, > Gabor I think you may be addressing his real problem as he mentions in another post. On Oct 25, 7:31 pm, sendt...@gmail.com wrote: [] > I do appreciate everyone's replies and I certainly didn't mean to > ignore your answers and questions that were trying to help me. > > Paul mentioned in his reply that it makes sense to do it in different > temperatures. This really is similar to what I am trying to do. I'm > trying to figure out (partly) if the refresh rate will help with the > radiation tolerance of the device (i.e. speeding it up). I think your test is a difficult one since you are looking for failures due to discharge by random radiation effects. Slowing down the refresh and finding one or few cells that tend to discharge more quickly than the rest as a few others have suggested does not really apply to the problem. You haven't specified what kind of radiation you are testing for (high energy cosmic rays, background radiation, BETA radiation, Nuclear power plant radiation(monitoring or robotic device?), or nuclear bomb) This is not a simple test rig. The programming of the refresh rate is a minor problem. The problem, if I understand your description correctly, is measure the failure rate DUE TO RADIATION versus refresh rate. Since radiation induced failures are random, you'll have to do a good number of test runs at various refresh rates to get a handle on the range of failure rate (to be able to say there were Y failures +/-y at refresh rate X) You need to be able to sort out what failures are due to the memory device itself and what is due to the radiation. The supplier of your memory may be able to give some advice on this test setup. (or are you working for the memory manufacturer?) I think you do not need to change the refresh rate dynamically. You should be able to do test runs at a fixed refresh rate, get the failure rate, reboot with a new refresh rate and start again. Depending on the radiation source you may need to replace the memory modules in a controlled way, to deal with the cases of permanent damage by the radiation. I'm not trying to be offensive with this final question/comment, but I take it your background is computer science only, right? You may need to get someone with a background in physical sciences (a physicist) to help design the experiment. (I have a BS in physics, but nuclear physics is not one of my strong points.) HTH, EdArticle: 125493
Hi, Is it possible to run XMD remotely using CableServer? This is the only missing item that would enable me to work completely remotely from my desk (instead of being in the lab, where we can't drink coffee ;) One alternative is to use Remote Desktop to control the lab computer but I'd really like to avoid having to install the complete Xilinx toolset on the lab computers. Another gizmo I found is a USB to ethernet converter (to control the platform cable usb remotely). Not sure if it would work though: https://www.ramelectronics.net/html/usb_server.html Thanks for any pointers. PatrickArticle: 125494
<sendthis@gmail.com> wrote in message news:1193355065.572064.187420@y42g2000hsy.googlegroups.com... > >> Probably so, but it isn't at all obvious how to answer. The DRAM >> doesn't care as long as every row is refreshed within the specified >> amount of time. Some refresh all rows in a big burst, others one >> at a time uniformly over the interval. You can refresh faster than >> the specified rate, but there is no system independent way to >> describe how to do that. For systems with a variable speed >> clock (such as power saving modes) one does have to design >> the refresh system appropriately. > > I know the mode register is initialized at the beginning with the > refresh rate (and some other information). Is it possible to reload > the mode register and will this do anything to the stored data (such > as letting all the caps discharge)? Is this even possible? > > I do appreciate everyone's replies and I certainly didn't mean to > ignore your answers and questions that were trying to help me. > > > Paul mentioned in his reply that it makes sense to do it in different > temperatures. This really is similar to what I am trying to do. I'm > trying to figure out (partly) if the refresh rate will help with the > radiation tolerance of the device (i.e. speeding it up). > Yes it will. The charge in the cell decreases over time. So running with a faster refresh rate will, at least somewhat, increase the minimum charge in a cell and increase the signal on the bit line. Have you reviewed the literature on this? I can't believe that this type of experiment hasn't already been done. del > >Article: 125495
On Fri, 26 Oct 2007 12:51:59 -0000, fpgabuilder <fpgabuilder-groups@yahoo.com> wrote: >When it comes to designing for fpgas or asics there are a lot of >guidelines/rules that need to be followed consistently between the >both. Yes! things dealing with verilog event queue, metastability and >asynchronous clock domains, etc. What I am wondering is what are the >key differences between the designs targeted toward one or the other. >Thought it may make an interesting discussion. > >Some that come to mind are - > >+ Number of logic levels between flops >+ Uniform delay through a lut vs different delays through nand gates. >Asic delays highly dependent on the synthesizer and coding style? >FPGAs more forgiving about how the combinatorial logic is coded? >+ Asynchronous resets in fpgas >+ Clock gating not as efficient in fpga therefore use flop enables. >Require changes to the coding style? All good questions, although some of your implied conclusions are arguable at best. >+ Others? I'd suggest the following: - cost per function (much higher in FPGA) vs. NRE (much higher in ASIC) - speed/density/power: cutting-edge ASIC will always win on all three of these, but the configurability and low NRE of FPGA may well win for many applications - instant-on: most FPGAs need configuration on power-up, and this can take some time; ASICs just need stable power rails and a reset - can't integrate custom analog functionality on an FPGA? But you specifically talked about "designing for"; in that case, I suspect your next big question should be about large, fixed functions. If you want a multiplier, or a memory, in an FPGA you need to use one of the available preset configurations of a built-in hard macro. If you don't have enough of those hard macros, tough luck. By contrast, such functions in ASIC are usually provided as parameterized library macros that can be built in any reasonable size or shape, and in any number, up to the device limits. And, of course, if you don't use some hard-macro resource on an FPGA, it's just wasted. The FPGA vendors work hard (and smart) to get the balance about right for the majority of their customers, and to keep the cost penalties reasonable for the others; but the issue is definitely there. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 125496
On Oct 26, 8:09 am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Mon, 22 Oct 2007 22:44:56 -0700, sendt...@gmail.com wrote: > >Hi, > > >I'm trying to control a SDR SDRAM (Micron 64Mbit chip) using an Altera > >DE2 board. I've gotten the hardware interface squared away (thanks > >everyone for your help!). > > >Now it's the tricky stuff. Any one have an idea how I can change the > >refresh rate while the RAM is in operation? > > If you roll your own controller (easy enough for SDR SDRAM) or can > understand the core you are given, you can find what controls the > refresh rate; invariably a counter. > > Replace the counter with an absurdly long one (say 32 bits), whose count > length is controllable from a register accessible to whatever host CPU > (NIOS in this case). > > It's either a reloadable down counter, which reloads and generates a > refresh cycle when it hits zero; in which case you reload it from the > register; or an up-counter which refreshes and resets to zero when a > comparator triggers; in which case the register holds the comparator > value. > > Then you have direct control of the refresh rate without messing with > clock frequencies etc. > > - Brian If it is an up counter with a comparator, be careful: if it is an equality rather than a greater-than comparator, and the CPU sets the trigger value to less than the current value of the counter, then the counter will have to roll all the way over, and likely miss a refresh, with potential data loss resulting. AndyArticle: 125497
Jonathan Bromley wrote: > - speed/density/power: cutting-edge ASIC will always win on > all three of these, but the configurability and low NRE of > FPGA may well win for many applications This is only true when working in the same feature size. FPGAs tend to be on the bleeding edge of process where ASIC starts usually lag behind by at least one or two process generations. Generally speaking, a lag of 2 generations puts a reasonably carefully executed FPGA design pretty much on par with an ASIC design in terms of the speed/power/density. Another factor to consider for FPGAs is that design errors do not restart the design cycle clock the way an ASIC error can.Article: 125498
On Oct 26, 7:31 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > All good questions, although some of your implied conclusions > are arguable at best. such as? > > >+ Others? > > I'd suggest the following: > - cost per function (much higher in FPGA) vs. > NRE (much higher in ASIC) In favor of fpga I would also put down less rigid market window/ size. > - speed/density/power: cutting-edge ASIC will always win on > all three of these, but the configurability and low NRE of > FPGA may well win for many applications > - instant-on: most FPGAs need configuration on power-up, and > this can take some time; ASICs just need stable power rails > and a reset > - can't integrate custom analog functionality on an FPGA? > > But you specifically talked about "designing for"; in that > case, I suspect your next big question should be about > large, fixed functions. If you want a multiplier, or a > memory, in an FPGA you need to use one of the available > preset configurations of a built-in hard macro. If you > don't have enough of those hard macros, tough luck. > By contrast, such functions in ASIC are usually provided > as parameterized library macros that can be built in any > reasonable size or shape, and in any number, up to the > device limits. And, of course, if you don't use some > hard-macro resource on an FPGA, it's just wasted. > The FPGA vendors work hard (and smart) to get the balance > about right for the majority of their customers, and to > keep the cost penalties reasonable for the others; but > the issue is definitely there. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. All good comments. But they are more related to the FPGA vs ASIC trade studies... I am more interested in differences in design practices...Article: 125499
On Fri, 26 Oct 2007 15:10:25 -0000, fpgabuilder <fpgabuilder-groups@yahoo.com> wrote: >On Oct 26, 7:31 am, Jonathan Bromley wrote: >> All good questions, although some of your implied conclusions >> are arguable at best. > >such as? "Uniform delay through a LUT" is some way off the truth these days - fanout delay typically dominates over LUT/gate internal delays, and in more recent processes it's routing delay that matters even more; these issues hit both ASIC and FPGA designers, albeit with many differences of detail - as I'm sure you're aware. "FPGAs more forgiving about how the combinatorial logic is coded?" Not in my experience, for sure - although of course almost all of that stuff is the synthesis tool's problem, not the designer's. But, to reiterate: interesting questions. All the more interesting because the answers to them continue to shift thanks to new FPGA, ASIC and design tool technology. > In favor of fpga I would also put down less > rigid market window/size. Indeed. [...] >All good comments. But they are more related to the FPGA vs ASIC >trade studies... I am more interested in differences in design >practices... Well.... I think I know what you're getting at, but surely awareness of market issues is a vital skill for designers, and such issues have a huge influence on design practice? -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.
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