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
Ivan, If it is an output (e.g TDO), it is actively pulled up to Vcco_0. If it is an input, use any reasonable value pullup resistor, and pull it up to the Vcco_0 supply (like 1K ohms, 10K ohms). Austin Ivan wrote: > Hi, > > Anyone know what is Xilinx recommended pull-up resistor value for > Virtex-4 configuration pins (TCK, TDO, TDI, TMS and M0-M2)? > > Thanks, > IvanArticle: 75151
"Antti Lukats" <antti@case2000.com> wrote in message news:<clb407$fuf$02$1@news.t-online.com>...
> ...
> So as example if I would make NIOX GPL it would prevent you using it in
> commercial products without re-releasing the modified source and possible
> your own ip as well. If you OTOH "buy" NIOX source code you are not bound to
> such restrictions and can make profit anyway you like.
GPL release does not preclude separate ("dual") commercial licensing.
>
> ...
>
> Also selling something "enforce" more feedback then giving away for free.
It is possible that customers are likely to be more annoyed by bugs in
a product they paid for, and have, by definition, been denied the
means to fix themselves.
In my experience there is no correlation between:
* shrinkwrap purchase and product quality
* shrinkwrap purchase and willingness or ability of developer to
listen. (It can be easily shown that beyond a certain modest size, a
software company is far less able to respond to customer issues than a
small, nimble individual or team with a reputation investment. In
particular, if the vendor is a monopoly, the battle is already lost.)
* shrinkwrap purchase and likelihood of customer to report bugs. (In
fact, the shrinkwrap customer is highly likely to be primed with
dismay and pessimism on approaching a commercial vendor: case in
point, Adobe.)
* probability of customer *fixing* bugs they find in shrinkwrap
purchase: Zero.
> And without feedback its really hard to find bugs and improve a product. As
> example my MicroBlaze/uCLinux free version has been available for downloads
> for several weeks, and there is ZERO feedback yet. Nothing.
Either nobody wants it, or they're happy with it as it is. I hope the
latter is the true explanation :-)
--Toby
>
> Antti
Article: 75152Hello, I'm using XtremeDSP II and SysGen. When I try to generate a hw cosim with some blockset XtremeDSP KIT the compilation make a error like: "Error running XtremeDSPJTAGPostGeneration" "Error using => set_param" "Invalid Simulink object name: led_hwcosim_lib/led hwcosim" Someone known what I need to do?Article: 75153
Hello, I am looking for a good place to download QuartusII 2.0 from - does anyone have a copy squirreled away? Cheers Dave.Article: 75154
Simon, I saw this article and thought of our musings about low power stuff! http://www.reed-electronics.com/electronicnews/article/CA475494?nid=2019&rid=1090846109 "Royal Philips Electronics’ Handshake Solutions and ARM today said they have jointly developed a clockless, compact ARM processor to addresses (sic) low power consumption" It's based on this stuff http://www.cs.man.ac.uk/apt/projects/processors/amulet/ http://www.cs.man.ac.uk/apt/projects/processors/amulet/AMULET3i_seminar.pdf I wonder if self-timed circuits will come to the FPGA world soon? A whole new level of pain! Best, Syms.Article: 75155
rickman <spamgoeshere4@yahoo.com> wrote in message > > >> > Ok, I am still confused about this. Does the current 6.3 webpack, > service pack 2 include the 3S2000/4000 or not? Is it in now and will be > taken out in 7.1? Oh, I think I understand now. The two different > service packs are for the webpack and the ISE, right? So the current > webpack *does* include all the spartan 3 devices, but will not in the > future. Ok, I understand. What even odder is the paid version of ISE, the ISE BaseX, is actually does not support Spartan 3 1000 and 1500 at all, while the free ISE Webpack supports it. So, in term of Spartan 3, you get less by paying more. HendraArticle: 75156
Hi, How about other input configuration pins that are not used in JTAG mode? Should I pull them up or down with 1/10K ohm resistor? Below is what I do, please let me know if this is okay. CCLK_0 – Pull down to GND with 1K ohm resister CS_B_0 – Pull up to Vccaux with 1K ohm resistor (to disable SelectMAP data bus) D_IN_0 – Pull down to GND with 1K ohm resister RDWR_B_0 – Pull up to Vccaux with 1K ohm resistor (to set D[7:0] to outputs) VBATT_0 – Pull down to GND with 1K ohm resister PROGRAM_B_0 – Pull up to Vccaux with 1K ohm resistor (No full-chip reset) PWRDWN_B_0 – Pull up to Vccaux with 1K ohm resistor (No power down mode) Thank in advance. Thanks, Ivan Austin Lesea <austin@xilinx.com> wrote in message news:<clof47$skk2@cliff.xsj.xilinx.com>... > Ivan, > > If it is an output (e.g TDO), it is actively pulled up to Vcco_0. > > If it is an input, use any reasonable value pullup resistor, and pull it > up to the Vcco_0 supply (like 1K ohms, 10K ohms). > > Austin > > Ivan wrote: > > Hi, > > > > Anyone know what is Xilinx recommended pull-up resistor value for > > Virtex-4 configuration pins (TCK, TDO, TDI, TMS and M0-M2)? > > > > Thanks, > > IvanArticle: 75157
vadim wrote: > Anyone knows of a programmable I/O card for a PC ? > > I am lookinf for something that can be plugged into PCI slot and > software programmed to generate arbitrary digital outputs such as > Square-Wave clock or any Serial bit pattern. A Xilinx/Altera PCI eval board perhaps? Regards, MarkArticle: 75158
I want to be able to read files off the compact flash card through the xilinx system ace chip which is connected to a xilinx virtex 2e FPGA. The compact flash card is formated as FAT12. Has anyone done this before, or at least could point me in the right direction in implementing this in verilog? Thanks, frankArticle: 75159
Hendra wrote: > > rickman <spamgoeshere4@yahoo.com> wrote in message > > >> > > Ok, I am still confused about this. Does the current 6.3 webpack, > > service pack 2 include the 3S2000/4000 or not? Is it in now and will be > > taken out in 7.1? Oh, I think I understand now. The two different > > service packs are for the webpack and the ISE, right? So the current > > webpack *does* include all the spartan 3 devices, but will not in the > > future. Ok, I understand. > > What even odder is the paid version of ISE, the ISE BaseX, is actually > does not support Spartan 3 1000 and 1500 at all, while the free ISE > Webpack supports it. So, in term of Spartan 3, you get less by paying > more. I think someone from Xilinx actually addressed that here. He said the inclusion of these two devices was a last minute decision and so they did not make it onto the CDs of any tools. But since webpack can be downloaded, you can get it that way. They also have not updated their marketing literature on the web site, that still says BaseX (and webpack, iirc) only supports up to 400. Give them a chance... I'm just glad they included what they did. Hmmmm, I guess the implication of the service pack issue is that BaseX also supports up to 3S4000!!! -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 75160
vadim wrote: > > Anyone knows of a programmable I/O card for a PC ? > > I am lookinf for something that can be plugged into PCI slot and > software programmed to generate arbitrary digital outputs such as > Square-Wave clock or any Serial bit pattern. Actually, there are such boards. They are called (oddly enough) arbitrary waveform generators. I think you can get analog and digital versions. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 75161
I have some code that compiles fine in Modelsim and under Quartus, but I
get an odd error under XST.
ERROR:HDLParsers:3324 -
//walmart800/allnetwork/arius/pc104c67/up/dinero/dinero/../OpcodeDefs.vhd
Line 128. IN mode Formal opcode of LIT with no default value must be
associated with an actual value.
The answer record on this error talks about passing generics into an
instance which is nothing like what I am doing. Here is a section of
the code in question.
type INSTDSPLY is (LIT, N0P,
CAL, RTI, JMP, JUMZ, JUMC, JUMO,
FTCH, STOR, FCHP, STRP, FCHB, STRB, FHPB, STPB,
DOOP, SWP, DRP, OVR, TORR, RFRM, RFTC,
RADT, RAD, RSB, RCM, RDRP,
ADNC, ADC, SBNC, SBC, CPNC, CPC, LAND, LOR, LXOR,
SHFL, SHFC, ZFLG, BFL, ERR);
function IRSLV_to_Inst (Opcode : IRSLV; LFLAG, BFLAG : STD_LOGIC)
return INSTDSPLY is
variable OpcodeInt : INSTVAL;
begin
if (Opcode(IRWdth-1) = '0') then
>>>>> return LIT; <<<<<< line number points here
elsif (Opcode = "10000000") then
return N0P;
elsif (not (Opcode(IRWdth-1) = '1' and
CountOnes(Opcode(IRWdth-2 downto 0)) = 3)) then
return ERR;
...
endif;
end IRSLV_to_Inst;
This function is being defined in a library package. It just looks up a
value of an SLV and returns an enumerated type for purpose of debug
display. Anyone have a clue? Is this an XST bug?
--
Rick "rickman" Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Article: 75162moti@terasync.net (Moti Cohen) wrote in message news:<c04bfe33.0410200517.391ab8d9@posting.google.com>... > Hello all, > > first a little background .. > I'm currently working on a fpga design (using VHDL) and using > the Xilinx spartan IIE fpga (xc2s400e) chip. > my design size is about 1300 slices (about third of the chip > capacity). > My problem is as follow : > sometimes when I change my top design and then re-synthisizes it, some > "parts" of my code is not working properly i.e. - some of my fpga > blocks are working as usuall and some dont (e.g. FSMs). > this appens not only for large code changes, sometimes it happens when > I "just" change an output pin to be '0' instead of '1' (a very minor > change). > my static timing analisys looks o.k. (at least the paths that i've > constrained). and I realy dont know where to start looking. > I checked my design over and over for "bad code" parts but didnt found > anything that might explain this. > > I would realy like to know if some of you have expeienesd something > similar in the past and if not maybe someone can give me a tip to > start with.. > > thanks in advance, Moti. HI, I faced similar problems.For FSM's one should be very careful in coding.Tool must infer it as FSM.Total design must be synchronous.System clock must be routed through GCLK.Do not ignore any warnings.Use gray or one-hot encoding for FSM.If you are implementing a combo logic using process block one must be extra careful,else one will end up in infering latches instead of combinational circuit.Also make sure after power on entire design is in known state. Even after doing so ,if u still struggling then modify constraints and try synthesising... Also you so POST P&R simulation for long duration.... Regards, Raghavendra.SorturArticle: 75163
Symon wrote: > Simon, > I saw this article and thought of our musings about low power stuff! > http://www.reed-electronics.com/electronicnews/article/CA475494?nid=2019&rid=1090846109 > "Royal Philips Electronics’ Handshake Solutions and ARM today said they have > jointly developed a clockless, compact ARM processor to addresses (sic) low > power consumption" > It's based on this stuff > http://www.cs.man.ac.uk/apt/projects/processors/amulet/ > http://www.cs.man.ac.uk/apt/projects/processors/amulet/AMULET3i_seminar.pdf > I wonder if self-timed circuits will come to the FPGA world soon? A whole > new level of pain! Interesting - Philips have been doing Async logic for a while, including Async 80C51 variants, and have the important tools needed to design in this area. Advantages are self-tracking of temp and Vcc, allowing wider operating tolerance. Power numbers I've seen for their earlier devices were good, but not stellar, but did improve rapidly as Vcc decreased. FPGAs could use this, with the right tools. -jgArticle: 75164
Hi Jim, Indeed, looks like some folks are thinking about this in FPGAs already. Check out http://www.opencores.org/articles.cgi/view/28 http://vlsi.cornell.edu/fpga.php http://www.async.caltech.edu/Pubs/PDF/ etc.... Cheers, Syms. "Jim Granville" <no.spam@designtools.co.nz> wrote in message news:SL_fd.23542$mZ2.871764@news02.tsnz.net... > Interesting - Philips have been doing Async logic for a while, including > Async 80C51 variants, and have the important tools needed to design in > this area. > > Advantages are self-tracking of temp and Vcc, allowing wider operating > tolerance. Power numbers I've seen for their earlier devices were good, > but not stellar, but did improve rapidly as Vcc decreased. > FPGAs could use this, with the right tools. > -jg >Article: 75165
>> And yea.. design to typical.. select of test even :-) unless your running >You bad boy! I'd never do that. (= I'd never admit to doing that!) ;-) There is an art to reading between the lines on a data sheet. Or maybe knowing which lines you can read between. If leakage current is critical, the difference between a warm room and 85C or 100C is huge. Consider the CPU in the remote control for your TV. What's its temperature? Are you going to compute battery life based on storing it in an oven? If you are only buying a few chips, you can measure them yourself. If you are placing a big order, you can get lots of help from FAEs. A few generations ago, it used to be common to fudge ratings by "correcting" for VCC and temperature. If you were willing to work a bit harder on your power supply, say promise it won't go below nominal, then you could pick up 5% on speed. Old Xilinx data books had a nice writeup. I'm pretty sure DEC did that with their high end Alphas. Then the silicon wizards made things more complicated. I don't understand the details but I'll bet it's an interesting story. I think the simple exponential temperature correction still holds for leakage current. Can anybody confirm that? (Any predictions on when that will break? Why?) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 75166
Hi Hal, Yeah, do you know about the Xilinx program 'speedprint'? You tell it Vcc and Temperature and it gives you personalised timings. Cheers, Syms. "Hal Murray" <hmurray@suespammers.org> wrote in message news:FrqdnW3ZmpgGHB3cRVn-uQ@megapath.net... > > A few generations ago, it used to be common to fudge ratings by > "correcting" for VCC and temperature. If you were willing to work > a bit harder on your power supply, say promise it won't go below > nominal, then you could pick up 5% on speed. Old Xilinx data books > had a nice writeup. I'm pretty sure DEC did that with their high > end Alphas. >Article: 75167
>Actually, there are such boards. They are called (oddly enough) >arbitrary waveform generators. I think you can get analog and digital >versions. The printer port is the classic low cost way to get data in or out of a PC. It may not be as fast as you want and/or you may not like the pauses from interrupts or the scheduler. With a bit of hacking, you can probably disable interrupts to fix that. If your task is simple enough, the idea of using an FPGA or CPU on a demo board seems pretty good to me. Pick the board to meet your requirements. Or use one from your collection. There are USB to GPIO gizmos. I don't have a URL handy. (I did a PCB for a USB to JTAG gizmo based on one.) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 75168
Jim Granville wrote: > > Symon wrote: > > Simon, > > I saw this article and thought of our musings about low power stuff! > > http://www.reed-electronics.com/electronicnews/article/CA475494?nid=2019&rid=1090846109 > > "Royal Philips Electronics’ Handshake Solutions and ARM today said they have > > jointly developed a clockless, compact ARM processor to addresses (sic) low > > power consumption" > > It's based on this stuff > > http://www.cs.man.ac.uk/apt/projects/processors/amulet/ > > http://www.cs.man.ac.uk/apt/projects/processors/amulet/AMULET3i_seminar.pdf > > I wonder if self-timed circuits will come to the FPGA world soon? A whole > > new level of pain! > > Interesting - Philips have been doing Async logic for a while, > including Async 80C51 variants, and have the important tools needed to > design in this area. > > Advantages are self-tracking of temp and Vcc, allowing wider operating > tolerance. Power numbers I've seen for their earlier devices were good, > but not stellar, but did improve rapidly as Vcc decreased. > FPGAs could use this, with the right tools. I have thought about this a bit and I don't see how any of this is an advantage. If you are doing real time work, even if it is not demanding, you have to meet a timing schedule. Although the async sequential devices are self timed and won't stop working from failing to meet setup and/or hold times on the FFs, if the device slows down, it will fail to meet the requirements of the application. If you app can tolerate a slow down of X% which allows the async logic to work over temp, then you could likewise run the sync logic at a slower clock and still meet the same system requirements over temp and voltage. So how is the async logic really better? You still have to make sure the device meets your timing constraints. The async logic just pushes it to a system timing problem rather than a low level timing problem. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 75169
Rick, I think the advantage is that the circuit goes as fast as it can for the given voltage/temperature conditions. So, for example, if you're running a cpu flatout to do some task, it'll finish faster if it's cooler. Like you, I'm struggling to see why it's necessarily lower power. Presumably the same number of nodes flip-flop during a logic algorithm in async or sync logic. Also, the clock distribution is saved, but replaced by a whole bunch of handshake lines. Just found this, some bloke at Intel doesn't think async design is a good idea:- http://www.eet.com/in_focus/embedded_systems/OEG20030606S0037 Cheers, Syms. "rickman" <spamgoeshere4@yahoo.com> wrote in message news:418088EB.F8286CA4@yahoo.com... I have thought about this a bit and I don't see how any of this is an > advantage. If you are doing real time work, even if it is not > demanding, you have to meet a timing schedule. Although the async > sequential devices are self timed and won't stop working from failing to > meet setup and/or hold times on the FFs, if the device slows down, it > will fail to meet the requirements of the application. If you app can > tolerate a slow down of X% which allows the async logic to work over > temp, then you could likewise run the sync logic at a slower clock and > still meet the same system requirements over temp and voltage. > > So how is the async logic really better? You still have to make sure > the device meets your timing constraints. The async logic just pushes > it to a system timing problem rather than a low level timing problem. >Article: 75170
rickman wrote: > Jim Granville wrote: > >>Symon wrote: >> >>>Simon, >>>I saw this article and thought of our musings about low power stuff! >>>http://www.reed-electronics.com/electronicnews/article/CA475494?nid=2019&rid=1090846109 >>>"Royal Philips Electronics’ Handshake Solutions and ARM today said they have >>>jointly developed a clockless, compact ARM processor to addresses (sic) low >>>power consumption" >>>It's based on this stuff >>>http://www.cs.man.ac.uk/apt/projects/processors/amulet/ >>>http://www.cs.man.ac.uk/apt/projects/processors/amulet/AMULET3i_seminar.pdf >>>I wonder if self-timed circuits will come to the FPGA world soon? A whole >>>new level of pain! >> >> Interesting - Philips have been doing Async logic for a while, >>including Async 80C51 variants, and have the important tools needed to >>design in this area. >> >> Advantages are self-tracking of temp and Vcc, allowing wider operating >>tolerance. Power numbers I've seen for their earlier devices were good, >>but not stellar, but did improve rapidly as Vcc decreased. >> FPGAs could use this, with the right tools. > > > I have thought about this a bit and I don't see how any of this is an > advantage. If you are doing real time work, even if it is not > demanding, you have to meet a timing schedule. Although the async > sequential devices are self timed and won't stop working from failing to > meet setup and/or hold times on the FFs, if the device slows down, it > will fail to meet the requirements of the application. If you app can > tolerate a slow down of X% which allows the async logic to work over > temp, then you could likewise run the sync logic at a slower clock and > still meet the same system requirements over temp and voltage. > > So how is the async logic really better? You still have to make sure > the device meets your timing constraints. The async logic just pushes > it to a system timing problem rather than a low level timing problem. There are some FPGA examples at http://www.ics.forth.gr/carv/async/demo/ You are broadly correct tho, no system is truly 'clockless', and so at some stage you need to know that your Async core _did_ complete the branch or thread or interrupt, within some system limit. Where Async can help, is in being more generally spread spectrum, ( so improves EMI ), and in having an automatic IDLE mode: When the Sw completes, it can stop. Of course, a std uC can come close to the same with HW IDLE control, and there are now many Spread spectrum clock generators. Downsides are: your core speed is now very elastic, and so cannot be used for software timing, plus faster clocked peripherals and interrupt type flags that can be dual port in nature (SW & HW access) must get very tricky to prove. On a system that had such a bug, it would be very enviroment sensitive. The biggest gain I can see from Async, is it (should?) self-track Vcc/Temperature/Process. Of these, Wide Vcc operation is likely to give the most user benefit. In a Sync system you may have 50- >100% margin by the time you apply Voltage/Temp/Process corners : In an Async system, that margin is available for extended battery life. -jgArticle: 75171
Hi, > To get repeatable > performance I had to resort to 2-phase clocking for local clocks. What do you mean ? Could you give more details on that? Thank you. Rgds AndréArticle: 75172
Good morning! For my own consideration, please: Is it correct that: 1.) TBUF-elements are not available in SPARTAN3 (physically)? 2.) I cannot make use of TBUF-library elements, also Webpack ISE 6.x is not producing an error? 3.) I can use behavioural descriptions with 'Z'-strengths? The synthesis tool is transforming them to logic regardless if I give the option "-tristate2logic yes/no"? 4.) I can use external (I/O)-TBUFS. Ok, well thank you for your good support at all! Thomas.Article: 75173
I saw the same posting too.. Self timed IC's tend to reduce power in several ways... for starts the peak is lower.. as nothing switches at the same time :-) second.. only the circuit active is running.. the next step is still idle the last step is now idle. The tend is to then be either idle or running.. not 'clocked and waiting'. Third.. the ripple effect... as each stage runs as fast as it wants/needs, things which would gobble time doing nothing, now take next to no time to do, so simple instructions process faster, and overall, the 'speed' can decrease.. or at least .. spend more time doing nothing as speed assumes a clock ;-) That's suppose to be good for a 30 % power drop. That's according to the thesis I read a few months back. The problem is, of course, the more you get the chip to do.. the less the power saving. Look at a hyper threading P4 for example.. all that silicon not doing anything until you hyper thread.. and then consume another 10 watts The classic example of this is a MOVE to register instruction in a processor... If a standard FPGA or processor, you would setup the address, read, write, allocate a bus, and on the next clock edge, execute a simultaneous read and write, now the whole chip sees this read and write.. and everything else decides its not for them. In an Async system, the MOVE sets up a async path between the register and the memory... everything else is still idle or doing something else (thru other async paths) and the memory and register do the data transfer between themselves nothing else knows / cares Sounds simple .. but they've been working on this for 10 years. I think because when things go wrong.. the system turns to custard, simulation requires specialist tools... you can't prototype in a FPGA either. From what I understand... there are a few MP3 players (?) also using async clocks to reduce overall power wasted or at least in the process. Simon "Jim Granville" <no.spam@designtools.co.nz> wrote in message news:Qw0gd.23562$mZ2.872624@news02.tsnz.net... > rickman wrote: > > > Jim Granville wrote: > > > >>Symon wrote: > >> > >>>Simon, > >>>I saw this article and thought of our musings about low power stuff! > >>>http://www.reed-electronics.com/electronicnews/article/CA475494?nid=2019& rid=1090846109 > >>>"Royal Philips Electronics’ Handshake Solutions and ARM today said they have > >>>jointly developed a clockless, compact ARM processor to addresses (sic) low > >>>power consumption" > >>>It's based on this stuff > >>>http://www.cs.man.ac.uk/apt/projects/processors/amulet/ > >>>http://www.cs.man.ac.uk/apt/projects/processors/amulet/AMULET3i_seminar.p df > >>>I wonder if self-timed circuits will come to the FPGA world soon? A whole > >>>new level of pain! > >> > >> Interesting - Philips have been doing Async logic for a while, > >>including Async 80C51 variants, and have the important tools needed to > >>design in this area. > >> > >> Advantages are self-tracking of temp and Vcc, allowing wider operating > >>tolerance. Power numbers I've seen for their earlier devices were good, > >>but not stellar, but did improve rapidly as Vcc decreased. > >> FPGAs could use this, with the right tools.Article: 75174
> In a Sync system you may have 50- >100% margin by >the time you apply Voltage/Temp/Process corners : In an Async system, >that margin is available for extended battery life. Huh? Why does one use more battery than the other? Power depends upon the work you do, not how fast you do it. I'm assuming both systems go to sleep when the don't have anything to do. In the sync case, you picked the clock so that the work gets done in time (with some slop for adding features?) and designed the system so it runs that fast in worst case conditions. With the async system, you figured out how many cycles you needed, added slop, then engineered the system so that it would get done soon enough when it was running hot and such. Same general worst-case idea, just turned inside out. I admit I've never designed an async system. You need something like that in the data sheet in ordr to build auseful systems. Right? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
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