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
Hi, > You'd have to worry about bus loading, though. That is correct, and having two device pins touch one signal is a compliance violation. If you are careful what you do, though, it will work. EricArticle: 73876
Sorry for the redundant post. I tried to cancel my first one, after reading the subsequent response but apparently did not succeed! And now, to make matters worse, I've posted this third time... Eric Eric Crabill wrote: > > Hi, > > > You'd have to worry about bus loading, though. > > That is correct, and having two device pins touch > one signal is a compliance violation. If you are > careful what you do, though, it will work. > > EricArticle: 73877
Bulk capacitance on the regulator output will slow the ramp rate for either switching regulators or current-limited linear regulators (that turn on from a fixed voltage rather than ramping up with its input voltage). If you're trying to enable a regulator that doesn't include a current limit from a supply that's already steady, bulk capacitance won't provide the predictable ramp rate. "Sylvain Munaut" <tnt_at_246tNt_dot_com@reducespam.com> wrote in message news:415c3101$0$22074$ba620e4c@news.skynet.be... > Hi > > Austin Lesea wrote: > > > Just ramp on slower than that indicated in the data sheet, and > > everything is fine. > > May sound like a stupid question to experts but I'm more a sw/fw guy : > > How do you make it ramp slower ? Is there any obvious trick ? > > Looking at my regulator datasheet, doesn't even specify ramp rate ... > > > > SylvainArticle: 73878
Sylvain, Ramp on time is deterimined by the size of the filter capacitor, and the current capability of the power source. So, for example, if the supply can't output more than 10 amperes, and you have 1,000 uF of filtering, then using I=CdV/dt, and solve for dt, dt = CdV/I or .001F * 3.3V/10A = 330 us. Now you would need a LOT of capacitance to slow this down to 3.3 mS, basically 10,000 uF instead of 1,000 uF. If the supply was current limited at 1 ampere, then 1,000 uF would be just fine. Typically we suggest at least 4 470uF for the core, and a similar number for the Vcco, so that would closer to 2,000 uF, and life would be good all around unless the current output is so great that the voltage rises faster than the spec sheet allows. Austin Sylvain Munaut wrote: > Hi > > Austin Lesea wrote: > >> Just ramp on slower than that indicated in the data sheet, and >> everything is fine. > > > May sound like a stupid question to experts but I'm more a sw/fw guy : > > How do you make it ramp slower ? Is there any obvious trick ? > > Looking at my regulator datasheet, doesn't even specify ramp rate ... > > > > SylvainArticle: 73879
In reviewing a specific requirement, my design team is debating the benefits of in-field hardware upgradability. In the communications space, wondering if most system developers require and use ICR in production when implementing FPGA (instead of ASIC)? CraigArticle: 73880
Unfortunately I didnt get the files yet, therefore I ask again, if it would be possible that somebody sends me the Files Thanks a lot Cheers RArticle: 73881
jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0409290048.63a5a067@posting.google.com>... > "Antti Lukats" <antti@case2000.com> wrote in message news:<cjbrus$csk$02$1@news.t-online.com>... > > Hi All > > > > finally today the project maintainer at opencores uploaded the verilog > > design files for MicroBlaze compliant IP-Core. Download is available at > > opencores.com - as project aeMB !! > > How long before Xilinx try to get them to remove it do we reckon? > > Cheers, > Jon If Xilinx can establish a case against aeste (the developer of aeMB is working for that company) it will be removed. The question is how much information he had in his possession so that he produced a (reportedly) successful MB implementation. If he didn't infringe any of Xilinx hardware patents, he should be OK. BTW is the MicroBlaze instruction set patented??? If it is, it is very sad, this can be prohibit you from e.g. implementing a GPL'ed simulator??? Regards Nikolaos KavvadiasArticle: 73882
I was just wondering *roughly* how much area is required for a design targetted to an fpga in comparsion to a standard cell asic? I'm really looking for a ball park figure here - 2x, 5x, 10x, 50x, 100x the area requirements? (I undersatand its heavily dependant on the particular design) -- totallyadminwww.totallychips.com - VHDL, Verilog & General Hardware Design discussion ForumArticle: 73883
news@sulimma.de (Kolja Sulimma) wrote in message news:<b890a7a.0409161122.4470a33f@posting.google.com>... > That's what I really love about this newsgroup, people recommeding > products of their direct competitors. > Kudos to you, Tony! > > I designed the Trenz board. It is layouted in a way that you can cut > it in stripes without interrupting the power supply. For a dongle > product. > At 42mm x 30mm x 3.5mm it will give you 60 FPGA I/O plus configuration > and power supply, at 42mm x 20mm x 3.5mm you will have to solder every > IO to the board yourself. Are you sure that you can not squeeze it in > with these additional 2mm? > > You can cut away these 2mm but it will interrupt the main power > supply, you could fix that with a wire, but this will result in a > really ugly looking board afterwards. > > BTW: Can you tell us what it is that you want to build the board into? > > Also, does anybody know about a source for generic usb dongle cases? > Our quantities are not large enough to have a custom case molded. > > Kolja Sulimma This sounds like it really might work... the only concern I have is the height of 20 mm. I noticed there was a pushbutton on the board, is it this that's causing the height. If so, would it be possible to remove it easily? Thanks for your help. -DarienArticle: 73884
Sylvain Munaut <tnt_at_246tNt_dot_com@reducespam.com> wrote: : Hi : Austin Lesea wrote: : > Just ramp on slower than that indicated in the data sheet, and : > everything is fine. : May sound like a stupid question to experts but I'm more a sw/fw guy : : How do you make it ramp slower ? Is there any obvious trick ? : Looking at my regulator datasheet, doesn't even specify ramp rate ... Go to the Website of Regulator suppliers, like National Semiconductors or TI. They have application notes for FPGA supplies. E.g. TI has a Family of fast regulators. To limit the ramp up, they use a MOSFET. Look e.g at http://www-s.ti.com/sc/techlit/slva175.pdf Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 73885
totallyadmin <totallyadmin.1deq4n@info@totallychips.com> wrote: : I was just wondering *roughly* how much area is required for a design : targetted to an fpga in comparsion to a standard cell asic? I'm really : looking for a ball park figure here - 2x, 5x, 10x, 50x, 100x the area : requirements? (I undersatand its heavily dependant on the particular : design) And on technology... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 73886
Works now thanks. This code initiates the SRL16 with some sort of pattern, then loops it around continuously in a 10 bit cycle, and outputs to a pad where it can be seen with a scope. Not sure what the translate on/off or generic stuff is all about. library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; library UNISIM; use UNISIM.VComponents.all; entity srltest is port( clk : in std_ulogic; q : out std_ulogic ); end srltest; architecture Behavioral of srltest is component SRL16 -- synthesis translate_off generic ( INIT: bit_value:= X"6626"); -- synthesis translate_on port (Q : out STD_ULOGIC; A0 : in STD_ULOGIC; A1 : in STD_ULOGIC; A2 : in STD_ULOGIC; A3 : in STD_ULOGIC; CLK : in STD_ULOGIC; D : in STD_ULOGIC); end component; -- Component Attribute specification for SRL16 -- should be placed after architecture declaration but -- before the begin keyword -- Enter attributes in this section -- Component Instantiation for SRL16 should be placed -- in architecture after the begin keyword attribute init: string ; attribute init of SRL16_INSTANCE_NAME: label is "6626"; signal feedback : std_logic; begin SRL16_INSTANCE_NAME : SRL16 -- synthesis translate_off generic map( INIT => "6626" ) -- synthesis translate_on port map ( Q => feedback, A0 => '1', A1 => '0', A2 => '0', A3 => '1', CLK => clk, D => feedback ); q <= feedback; end Behavioral;Article: 73887
Works now thanks. This code initiates the SRL16 with some sort of pattern, then loops it around continuously in a 10 bit cycle, and outputs to a pad where it can be seen with a scope. Not sure what the translate on/off or generic stuff is all about. library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; library UNISIM; use UNISIM.VComponents.all; entity srltest is port( clk : in std_ulogic; q : out std_ulogic ); end srltest; architecture Behavioral of srltest is component SRL16 -- synthesis translate_off generic ( INIT: bit_value:= X"6626"); -- synthesis translate_on port (Q : out STD_ULOGIC; A0 : in STD_ULOGIC; A1 : in STD_ULOGIC; A2 : in STD_ULOGIC; A3 : in STD_ULOGIC; CLK : in STD_ULOGIC; D : in STD_ULOGIC); end component; -- Component Attribute specification for SRL16 -- should be placed after architecture declaration but -- before the begin keyword -- Enter attributes in this section -- Component Instantiation for SRL16 should be placed -- in architecture after the begin keyword attribute init: string ; attribute init of SRL16_INSTANCE_NAME: label is "6626"; signal feedback : std_logic; begin SRL16_INSTANCE_NAME : SRL16 -- synthesis translate_off generic map( INIT => "6626" ) -- synthesis translate_on port map ( Q => feedback, A0 => '1', A1 => '0', A2 => '0', A3 => '1', CLK => clk, D => feedback ); q <= feedback; end Behavioral;Article: 73888
Are you also guys@altera.com? From the 'NV on-chip memory' thread? "CraigR" <craigra@pacbell.net> wrote in message news:NbX6d.4661$nj.3114@newssvr13.news.prodigy.com... > In reviewing a specific requirement, my design team is debating the benefits > of in-field hardware upgradability. In the communications space, wondering > if most system developers require and use ICR in production when > implementing FPGA (instead of ASIC)? > > Craig > >Article: 73889
hpa@terminus.zytor.com (H. Peter Anvin) wrote in message news:<cjd1mj$aef$1@terminus.zytor.com>... > For the Altera people in this group... > > One of the things I find really annoying with Quartus II is that > whenever it gives resource counts, like in the final synthesis report > or in the SignalTap configurator, it gives "bits of memory." Hi Peter, The Memory Bits are provided in the Flow Summary section of the Report File to give a brief design overview, while inside the Report there is much more detailed information. The Fitter Resource Usage Summary section probably gives what you are looking for, breaking out exactly how many M512s, M4Ks and M-RAMs are required. Note that there is a detailed RAM Summary Report in both the Analysis and Synthesis section of the report and the Fitter section. These give the details on each hierarchical block, how many bits they use and how many of each block type are used. An important note is that the Fitter RAM Summary may show more blocks being used than the user would expect. This is because Quartus can spread the slices of a RAM across multiple blocks if it helps the design's timing. This is a feature, and if the device memory fills up, Quartus will pack them as tightly as possible, but is a cause for some confusion. In the future there will be a message added to the report clarifying this. The upcoming release of Quartus will contain improvements in the reporting of the memory blocks used as part of the Signal Tap II configuration. Hope this helps. - Subroto Datta Altera Corp.Article: 73890
Ben Twijnstra <btwijnstra@chello.nl> wrote in message news:<pMa6d.144318$C7.84061@amsnews05.chello.com>... > Hiya, > > > I'm working on a quadrature decoder to interface with a rotation > > sensor. My thought was to have an asynchronous process that operates > > on the A and B signals, and then have the 'state' variable synchronous > > with the clock in a seperate process. The following vhdl works as > > expected in one simulation tool, but produces garbage when I use > > Quartus. > > > > begin > > process(A_in, B_in) > > begin > > state(3) <= state(1); > > state(2) <= state(0); > > state(1) <= A_in; > > state(0) <= B_in; > > end process; > > state_out <= state; > > direction <= ( (not state(3)) and (not state(0)) ) or ( state(3) and > > state(0)) ; > > end a; > > > > I expect that 'state' will always be of the form XXYY where XX is the > > old state, and YY is the current state of the inputs A and B (for > > example, 0001, 0111, 1110 etc). With one simulation tool I have, it > > works exactly as expected. With Quartus, the 'state' variable is > > always 0000, 0101, 1111, or 1010. > > > > Is there something wrong with the way I'm trying to implement this? > > Any suggestions on a better way? > > The way you have written this code will make sure that Modelsim only > 'schedules' the process if A_in or B_in changes. In a synthesized design, a > process is always dependant on all its inputs, so also its internal state - > er - register (which you don't have here). > > If you synthesize this with Quartus (or any synthesis tool for that matter) > you will get warnings that state(1) and state(0) should also be on the > sensitivity list. The synthesis tool will subsequently simply generate a > wire between state(1) and state(3) and one between state(0) and state(2) > > What you should do here is work synchronously, something like > > process(clk) > signal tA, tB : std_logic; > begin > if rising_edge(clk) then > if (A_in /= tA) or (B_in /= tb) then > tA <= A_in; > tB <= B_in; > state(3) <= state(1); > state(2) <= state(0); > state(1) <= A_in; > state(0) <= B_in; > end if; > end if; > end process; > > state_out <= state; > direction <= ( (not state(3)) and (not state(0)) ) or ( state(3) and > state(0)) ; > > Even though I hate using the /= operator on a std_logic. > > Best regards, > > > Ben Thanks for the reply. I incorporated the component into a synchronous process and it works fine now. However, I still have a few questions just so I can get a better understanding of what was going on. > The way you have written this code will make sure that Modelsim only > 'schedules' the process if A_in or B_in changes. That was my intention. I wanted the output to change *only* when one of the two inputs changed. I see what you mean that the 'internal states' were not counted as inputs though. So, how would you go about making this component so that it will change state only when the input changes? > If you synthesize this with Quartus (or any synthesis tool for that matter) > you will get warnings that state(1) and state(0) should also be on the > sensitivity list. In fact, Quartus gives the following message: "Design top_quadrature_decoder: Netlist extraction and synthesis were successful. 0 errors, 0 warnings" > Even though I hate using the /= operator on a std_logic. Is this just a personal preference? or is there a reason one should avoid the /= operator? thanks, PhillipArticle: 73891
"Steven K. Knapp" wrote: > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:4159BB3B.10CC935B@yahoo.com... > > Brian Davis wrote: > > [snip] > > > > I don't think this is a problem. The ramp speed issue in only of > > concern at a voltage threshold around 0.8~1.0 volts. As it was > > explained to me, when the part powers up, there are a lot of transistors > > which are turned on initially. Once Vcc gets above about 1.0 volts, > > everything is biased and the transistors that need to be off are off. > > But the part draws a lot of current in the meantime as the voltage > > ramps. If the voltage ramps too fast, the PS can max out on current and > > for some reason, this will disturb the part and it will not initialize > > correctly to the point that a power down must be done to correct the > > problem. > > > > So the problem is that you must let the part draw as much current as it > > needs as the voltage ramps up. The spec is to let you know how much > > current you will need for a given ramp rate. Keep the ramp rate slower > > than the worst case spec and the part will be happy with the current > > spec'd in the data sheet. After the voltage rises above about 1.0 volts > > this is no longer an issue regardless of how the spec is written (or > > interpreted). > > The problem that you described is a completely different phenomena from much > older FPGA families. This phenomena does not exist on any of the modern > FPGA architectures like Virtex-II, Virtex-II Pro, Spartan-3, and Virtex-4. Are you sure you should include Virtex-II and Virtex-II Pro in this list? When I read the data sheet it still lists a minimum power up current of up to 1.1 Amps. If this is not the same issue as the Virtex and Spartan II parts, then what exactly is this current about? Or maybe my copies of the data sheets are old??? -- 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: 73892
Brad Smallridge wrote: > > OK well how do you apply a restraint to a path then? I indicated that in my other post. You specify sets of starting points (which can be FFs, SRLs, any other synchronous elements or IOB inputs) and a set of end points (FFs SRLs, any other synchronous elements or IOB outputs). Timing constraints are applied between the starting points and the ending points. A signal connects two objects which can include LUTs and other logic elements. These objects are connected by signals. But specing the time for a given signal is typically not useful since that is only a part of a path between timing end points. Does that make more sense? I was around when Xilinx first introduced this method of timing constraints. It seemed counter intuitive at first. But I learned that it was the only practical way to specify timing. So think in terms of paths between timing end points, not signals. -- 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: 73893
Nicholas Weaver wrote: > > In article <2s0j7fF1c0cu3U1@uni-berlin.de>, > Symon <symon_brewer@hotmail.com> wrote: > >Google says:- > >Pricing and Availability > > > >The Synplify 7.7 and Amplify 3.7 software are available now. Pricing for the > >Synplify software starts at $9,500 (U.S.) and pricing for the Amplify > >Physical Optimizer(TM) software starts at $29,000 (U.S.). For more > >information visit Synplicity's Web site at http://www.synplicity.com. > > > >Pro used to cost about double Synplify regular. > > Thanks, but I recall there being a cheaper Xilixn only verson or > sometihng. And a press release won't due for the budget info I need. Like Ken said, you might qualify for an educational discount. But the Xilinx only version is sold by Xilinx the last time I checked. It was $995, IIRC. It is pretty limited, like the free version with webpack, but at a higher number of lines of code. So if your project is pretty large, it may not be the right choice. I also recommend that you contact your local sales rep for Synplicity. -- 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: 73894
Hi, mike
I am a student of University of louisiana, I am beginner for Xilinx ISE 5.2I ,
seems you have a lot of experience on that, since you answer some questions in
the FPGA group, I wonder if you can help me in some of the problem.
When I am implement a counter in ISE, and after I set up the testbench
waveform, and try to get the result of the simulatin, it give me error as :
ERROR:
Model Technology's ModelSim executable cannot be found by Project
Navigator.
Please go to the 'Edit' menu, select 'Preferences' and then select
the 'Partner Tools'
tab. Using this dialog select the ModelSim executable that you wish
to use for
simulation. Then re-start Project Navigator and try this process
again.
I try everything but it still not work, would please tell me how to solve it
if you have faced with the similar problem.
Thank you in advance
Nan
______________________
Try reinstalling from the CD.
The files you need are vcom.exe and vsim.exe
You don't really need the rest of
Xilinx ISE until you have completed simulation.
-- Mike Treseler
Article: 73895Rick, We left the 'minimum power on current' in the data sheet so that folks would always be able to turn them on. The minimum current is not so much different now from the maximum leakage. So to turn a V2, V2P, etc on at 100C at Vccint(abs max) might require a bit more current than at room temp. That is what that table (specification)is all about. Austin rickman wrote: > "Steven K. Knapp" wrote: > >>"rickman" <spamgoeshere4@yahoo.com> wrote in message >>news:4159BB3B.10CC935B@yahoo.com... >> >>>Brian Davis wrote: >> >>[snip] >> >>>I don't think this is a problem. The ramp speed issue in only of >>>concern at a voltage threshold around 0.8~1.0 volts. As it was >>>explained to me, when the part powers up, there are a lot of transistors >>>which are turned on initially. Once Vcc gets above about 1.0 volts, >>>everything is biased and the transistors that need to be off are off. >>>But the part draws a lot of current in the meantime as the voltage >>>ramps. If the voltage ramps too fast, the PS can max out on current and >>>for some reason, this will disturb the part and it will not initialize >>>correctly to the point that a power down must be done to correct the >>>problem. >>> >>>So the problem is that you must let the part draw as much current as it >>>needs as the voltage ramps up. The spec is to let you know how much >>>current you will need for a given ramp rate. Keep the ramp rate slower >>>than the worst case spec and the part will be happy with the current >>>spec'd in the data sheet. After the voltage rises above about 1.0 volts >>>this is no longer an issue regardless of how the spec is written (or >>>interpreted). >> >>The problem that you described is a completely different phenomena from much >>older FPGA families. This phenomena does not exist on any of the modern >>FPGA architectures like Virtex-II, Virtex-II Pro, Spartan-3, and Virtex-4. > > > Are you sure you should include Virtex-II and Virtex-II Pro in this > list? When I read the data sheet it still lists a minimum power up > current of up to 1.1 Amps. If this is not the same issue as the Virtex > and Spartan II parts, then what exactly is this current about? > > Or maybe my copies of the data sheets are old??? > > -- > > 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: 73896
Nope. I did see that posting though. I am weighing cost benefits of ASIC for field upgradability. "Rotund Phase" <rotund_phase@hotmail.com> wrote in message news:2s31qkF1furbmU1@uni-berlin.de... > Are you also guys@altera.com? From the 'NV on-chip memory' thread? > "CraigR" <craigra@pacbell.net> wrote in message > news:NbX6d.4661$nj.3114@newssvr13.news.prodigy.com... >> In reviewing a specific requirement, my design team is debating the > benefits >> of in-field hardware upgradability. In the communications space, > wondering >> if most system developers require and use ICR in production when >> implementing FPGA (instead of ASIC)? >> >> Craig >> >> > >Article: 73897
Guy wrote: > > Let me first say thank you for your responses. > To address some of the questions / comments: > I realize that not everyone will extract the same application or value > from the on-chip NV memory, however, since it has the potential to > provide or support different applications, general enough value may be > justified for inclusion. > Answers / Comments for Jim and Hal: > a. bad bits: built in ECC would make bad bit transparant to the user > > b. speed = assume approximately 25ns access time > > c. width = flexible, 16/32/64 bit > > d. secure code storage would come by two assumptions: i) on-chip > processor preventing external need to access the memory. ii) readback > via JTAG etc of Memory would be programmed as disabled by the user > > e. on-chip charge pumps require no special external voltage supply > > f. user application would be able to log/write data to NV memory for > storage > > g. external applications could read NV data too, but you obviously > loose security > > h. OTP = nonerasable That makes it much *less* useful. When a CPU is put into an FPGA, it is a real encumbrance to use external memory and the internal FPGA memory is often not large enough for program storage. Having a hunk of NV *rewritable* (such as flash) memory would be very useful for this sort of app. When are SW programs *ever* mature??? My network router already has a code update waiting to go into the Flash. > i. no tradeoff with NV and Ram like functionality - it would be a > standard feature, not swappable block within the silicon family > > j. yes for non secure, it would enable integration into the FPGA of > on-board NV data for some applications (mature s/w code for example). > Realize that also for some applications, you can create a sense of > "virtual" unlimited multiwrite capability. To demonstrate what I mean > by Virtual multi-write, I'll use the following example. Let's say > that you know you may need to write 10,000 maximum lifetime events at > 100 bits data each but do not need to keep history for more than 16 > events. As a designer, you could buy a tiny block of flash or EEPROM > of 1.6kbits and keep writing over the older events. Or, with OTP, you > could simply purchase enough OTP memory to store the entire lifetime > worth of events. Many applications that store NV data can quantify > the lifetime of storage from a practical specification. One example, > Televisions need to store user configuration (like: color, tint, > favorite channels etc), and need to provide the user with unlimited > adjustments of this data. However if you make some assumption, the > design can calculate an upper limit of needed storage. For example, > lets say 512bits stored, TV life is 20 years. I would venture to > guess that if you assumed that data storage would occur Max once a day > for each of 20 years, you would be happy to remove the $1 EEPROM from > the board as long as the on-chip cost of the NV block was less. > 20yr*512b*365days = 7Mbit total > > Any other creative thoughts on how this could be used would be > appreciated. One poster indicated that 128 bits for a unique serial number would be useful. We have used Dallas one-wire parts for that sort of thing. So that could put a $1 price on providing a bit of NV memory, but the Dallas parts also have a bit of EEPROM memory, so again the reprogrammable feature is important. Another feature that we look for often is a way to provide a software configurable board jumper. This jumper needs to be reprogammable, control a signal on the board, and be asserted from power up. Currently we use a Flash PLD for this. -- 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: 73898
This seemingly simple question does not have a simple answer. There are too many variables. Modern FPGAs are leaping ahead of ASICs in the use of the tightest technology ( 90 nm today). Some FPGA structures are inherently as efficient as in ASICs (BlockRAM, I/O, transceivers, hard microprocessors). In other respects FPGAs can be far less efficient in their silicon use. But FPGAs benefit from a very regular and tight chip-layout, and they are manufactured by the multi-millions (as opposed to most ASICs). And finally: Silicon is cheap, silicon area is not decisive, the total manufacturing and distribution cost is! Don't count the square microns, count the dollars. Peter Alfke > From: totallyadmin <totallyadmin.1deq4n@info@totallychips.com> > Organization: Totallychips > Newsgroups: comp.arch.fpga > Date: Thu, 30 Sep 2004 12:35:07 -0500 > Subject: FPGA vs ASIC area > > > I was just wondering *roughly* how much area is required for a design > targetted to an fpga in comparsion to a standard cell asic? I'm really > looking for a ball park figure here - 2x, 5x, 10x, 50x, 100x the area > requirements? (I undersatand its heavily dependant on the particular > design) > > > -- > totallyadminwww.totallychips.com - VHDL, Verilog & General Hardware > Design discussion Forum >Article: 73899
hamilton wrote: > > T Lee wrote: > > > > Forth is very good for small embedded design. > > > > -Tony > > Forth is the perfect hacker language. > Write it once and no one else will able to read it again. > > Every time I follow up on a forth project, I have to re-write it in C > so it can be read by future programmers. > > Sorry Tony, I just don't by it. That is a self-perpetuating prophesy. There is nothing inherently incomprehensible about Forth, especially vs. C. It is a bit like saying Chinese is hard to learn because you learned English as a small child. When people refuse to work in Forth because there aren't many who work in Forth, you can see how that perpetuates the problem. I can see some significant advantages to an interactive language that you can run on the target without an emulator. -- 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
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