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
Nicholas Weaver wrote: > > In article <29f7d.3570$JG2.795@newssvr14.news.prodigy.com>, > superfpga <superfpga@pacbell.net> wrote: > >Paul- > >you make some good points in your discussions especially about the $1 extra > >cost compared to a $100 FPGA as well as highlighting the significance of > >saving that same $1 if it was in a Cyclone low cost device. > > > >However, how would you change your mind if some of the newer developing NV > >memory technologies were similar in size to flash cell/dram cell (<< area of > >SRAM), also used standard leading edge CMOS process (unlike Flash or DRAM), > >thus much more cost effective bulk memory without adding any process premium > >to the rest of the chip? Though maybe not the holy grail, don't you think > >it provides a good amount of value as cited by some of Hals, Jim's and > >Nicholas' posts? There are probably even other ideas out there for value. > > a) I doubt it would come without a process penalty in the .13 or 90nm > node (or the equivelent at a given point in time). If it could, that > might be another story. That is what he is describing. I don't know if he knows something we don't, but certainly it is conceivable that a new NV type could be process compatible with CMOS. > b) If it could, it would need to be many times rewriteable to be > acceptable to the FPGA companies. One of the real advantages of the > FPGAs over other technologies (antifuse, etc) is the unlimited rewrite > capability. THus a write once or limited write memory would be far > less useful. I don't know how many times you would feel the need to write your NV ram. But various formats of separate chips only provide anywhere from 1000 to 100,000 guaranteed. I expect there are tons of apps for even 1000 time rewritable NV ram. > c) My point is that the security aspect of embedded NVram is > significantly less when compared to using the existing SRAM-based > bitfile encryption to protect a large external nonvolatile store. > So I'm a naysayer on NVram. But for the low end cost market, there is no built in encryption hardware. That is only on the expensive chips like Virtex-II and 4. Spartans don't have it and I believe we are talking about the low cost chips. If you are using the $100 FPGA, I don't think an external $1 NV memory will be a problem. With the low cost chips, the on board NV ram is likely more secure than than an encrypted external NV store since the encryption mechanism is not protected in any way. -- 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: 74001
> Why do I need a parity bit for the block RAM? They are often useful for other things. On FIFOs/buffers: End of packet flag. In-band vs out-of-band signaling. Used/free flags. Just plane more bits (wider) for things like table driven state machines. -- 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: 74002
Antti Lukats wrote: > > http://uclinux.openchip.org/forum/viewtopic.php?t=4 > > here is proof :) > > the opensource version as available from opencores is not yet good enough to > run uCLinux - well lets see if that will change, > I think there is a wish to have an open-souce multi-vendor FPGA softcare > capable to run uCLinux inside many people :) I could be wrong, but I thought open source cores that run uCLinux were already available for FPGAs. The only difference is that this one is code compatible with uBlaze. Am I wrong about 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: 74003
In article <415E3568.DEA2A396@yahoo.com>, rickman <john@bluepal.net> wrote: >BTW, that brings up the issue of RAM cell size. I recall that Mosys has >a 1T sram cell using a single transistor and a capacitor. This sounds >like a DRAM to me. Anyone know how this works? To the best of my >knowledge it does not require any refreshing or is that somehow done >invisibly? They don't call this peusdo-SRAM and I believe they have >some patents on it. It is Pseudo-SRAM: It provides an SRAM interface, and hides the refreshing process, but underneeth it all, its a small bank fast DRAM design. -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.eduArticle: 74004
> I have done read/write access to sram in a basic way in three cycles > without any problem. Good to hear. You might get down to 2 cycles by using the other edge of the clock for WE and putting it in the middle of the pair. OE would go on the second cycle. (Probablby work fine in the middle too - bus would just float a half cycle.) >> What particular SRAM is on the board that started this thread? > It is ISSI IS61LV25616AL. Data sheet is at http://www.issi.com/pdf/61LV25616AL.pdf The timing diagram for WE controlled writes is on page 9. Numbers are back on page 8. Looks like pretty standard SRAM - 0 setup, 0 hold. You can't do a single cycle write with simple/clean digital logic. The problem is skew - you can't guarantee that address will get there before WE to meet setup and also guarantee that it will get there after WE to meet hold times. (Or at least I can't see how to do it.) One solution is to make WE slightly less than a whole cycle. You could do something like generate WE as the AND of a WriteEnable and the first half of the cycle. That AND will be in a CLB. There will be delays (relative to clocking the address and data in IOBs) so WE will come out in the middle of the cycle, right where you want it. That's if all the delays work out. I don't know if this is interesting for the initial question. FPGAs may not be friendly for this sort of hacking - clocks don't get routed to CLB inputs. Better/cleaner to use a 2X clock. -- 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: 74005
Jon Beniston wrote: > General Schvantzkoph <schvantzkoph@yahoo.com> wrote in message news:<pan.2004.10.01.14.16.37.467412@yahoo.com>... > >>On Fri, 01 Oct 2004 06:18:58 -0700, Jon Beniston wrote: >> >> >>>>Here are some numbers: >>>>ASICS are only for extreme designs: >>>>extreme volume, speed, size, low power >>>>Cost of a mask set for different technologies: >>>>250 nm: $ 100 k >>>>180 nm : $ 300 k >>>>130 nm: $ 800 k >>>> 90 nm: $1200 k >>>> 65 nm: $2000 k >>>>plus design, verification and risk. >>>> >>> >>>Hmm. Take those figures with a pinch of salt. At the higher >>>geometries, you can definetly get much cheaper than that. >>> >> >>Those figures are for pure ASICs, what are the costs for structured ASICs? > > > I don't know much about <= 90nm, but if your paying $300k for 180nm > you're getting robbed. > > Structured-ASIC NRE is significantly less, say $40-70k depending on > process and vendor. For a glimpse of one approach to FPGA -> StructuredASIC, see http://www10.edacafe.com/nbc/articles/view_article.php?section=ICNews&articleid=144528 A couple of interesting points here : ** they take a TSMC 0.15u sub-metal wafer, and add the metal themselves. [Metal layers are normally more relaxed rules] ( could give rise to interesting yield discussions between the two companies :) ** They offer dual port, initialisable memory. [Not clear if this is from a ROM, or from a serial loader ] They target $20-$100 / 10K chip sales. Also claim this "Cost reduction and time-to-market are the basis of XPA-II's existence offering customers 0.15µm technology at one quarter of the NRE cost of a cell-based ASIC and one-third the cost of an FPGA in production. Prototypes can be shipped in as little as 21 days compared to standard cell ASIC lead times of 50-60 days." These structured Metal-only ASICs are really MASK FPGAs. The test will be how much revenue this segment can generate. -jgArticle: 74006
>Redundancy timing is a solved problem. Thanks. (Sorry if my post seemed insulting.) I think I understand how to do it in the normal design flow. I was fishing for things around the edge that might not have worked as expected. Maybe I've been looking at too many "typical" columns in the data sheets. Could a customer write code that would detect when a redundant section was used? I'm thinking of something like measuring the "typical" prop times on a part and see if some section is way out of line. -- 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: 74007
> > In this particular case, your critical path appears to stretch from a RAM to > > a RAM (configured as a ROM) with little logic in-between. Logic + > > routing-rich paths tend to accentuate the speed differences between the two > > devices, while RAM-heavy paths show a smaller advantage. > > Do you have tips for Martin on how to improve this for Cyclone > specific cases ? - ie should the ROM change to logic-based, rather than > RAM based, or would a pipeline stage help ? > The critical path is from bytecode RAM (the instruction cache for the processor), which has registered address but unregistered data ,out through a 'larg' table. A jump table to map bytecode instructions to microcode addresses. I was thinking to add another pipeline stage in this path. However, than the bytecode branches take one more cycle. When I add a register in this stage the critical path moved to the ALU and fmax was 106MHz. Not a big win and it showed that the pipeline is not so bad balanced. If you have another good idea, I would be happy to make JOP faster :-) Martin -- ---------------------------------------------- JOP - a Java Processor core for FPGAs: http://www.jopdesign.com/Article: 74008
Hi,
I wish to generate a frequency of approx 400 Hz using Xilinx
Spartan II(200 MHz)and send the 1 bit signal to a speaker output and
hope to hear some noise.
My VHDL code, tested on PeakVHDL simulator does generate the
waveform and is pasted at the far bottom. The problem is that the code
does not compile on Xilinx because "WAIT for 2.5 ns" is not supported
on Xilinx Spartan II for a process. What would be the simplest way out
to generate 400 approx Hz on a Xilinx 200MHz device? I have used
200MHz/(2 to the power of 19) = 382 Hz approx. (Use MSB of 19 bits of
STD_LOGIC_VECTOR)
Another thing which has confused me is: If I wish to write an
entity(below) for Spartan II, does the programmer worry about
generating the signal for "clk" input? Or simply connect it to the
correct pin of FPGA and I should get the signal of 200MHz?
ENTITY some_entity IS
PORT (clk : IN BIT);
END some_entity;
For my code tested on PeakVHDL, I have generated the 200MHz signal
using a test bed(music_tester) and then modified it to 400Hz.
I apologise if the question is basic.
Thanks in advance
ENTITY music_tester IS
PORT (clk : OUT STD_LOGIC; freq : IN STD_LOGIC);
END music_tester;
ARCHITECTURE behavioral OF music_tester IS
BEGIN
process
BEGIN
clk <= '1';
-- 200MHz is 5ns cycle
WAIT FOR 2.5 ns;
clk <= '0';
WAIT FOR 2.5 ns;
END process;
END behavioral;
ENTITY music1 IS
PORT (clk : IN STD_LOGIC; pinout : OUT STD_LOGIC);
END music1;
ARCHITECTURE music1_structure OF music1 IS
BEGIN
PROCESS(clk)
VARIABLE counter : STD_LOGIC_VECTOR(18 DOWNTO 0) :=
conv_std_logic_vector(0, 19);
VARIABLE Aint : INTEGER RANGE 0 TO 524287 := 0; -- 19 bits
BEGIN
IF RISING_EDGE(clk) THEN
counter := conv_std_logic_vector(Aint, 19);
Aint := Aint + 1;
-- Divide 200 Mhz/(2*2*2...19
times)
-- MSB has approx 382Hz
pinout <= counter(18);
END IF;
END process;
END music1_structure;
ENTITY testbench IS
END testbench;
ARCHITECTURE structure OF testbench IS
COMPONENT music_tester PORT (clk : OUT STD_LOGIC; freq : IN
STD_LOGIC); END COMPONENT;
COMPONENT music1 PORT (clk : IN STD_LOGIC; pinout : OUT STD_LOGIC);
END COMPONENT;
SIGNAL a, b :STD_LOGIC;
BEGIN
tester: music_tester PORT MAP(a, b);
UUT: music1 PORT MAP(a, b);
END structure;
Article: 74009what is the use/future of dsprocessors in vlsi -- thevlsiguruwww.totallychips.com - VHDL, Verilog & General Hardware Design discussion ForumArticle: 74010
"Rakesh Sharma" <srakesh@hotmail.com> wrote in message news:17c0a468.0410020202.18cd41c9@posting.google.com... > Hi, > > I wish to generate a frequency of approx 400 Hz using Xilinx > Spartan II(200 MHz)and send the 1 bit signal to a speaker output and > hope to hear some noise. > My VHDL code, tested on PeakVHDL simulator does generate the > waveform and is pasted at the far bottom. The problem is that the code > does not compile on Xilinx because "WAIT for 2.5 ns" is not supported > on Xilinx Spartan II for a process. What would be the simplest way out > to generate 400 approx Hz on a Xilinx 200MHz device? I have used > 200MHz/(2 to the power of 19) = 382 Hz approx. (Use MSB of 19 bits of > STD_LOGIC_VECTOR) The "WAIT..." statement is not synthesisable. You simply need a counter (ripple counter will do) to divide the clock down to 400 Hz or so. Write the VHDL for a toggle flip-flop and string lots of them together - not very elegant but it should work. LeonArticle: 74011
"Antti Lukats" <antti@case2000.com> wrote in message news:cjjtgn$mp6$03$1@news.t-online.com... > "Jon Beniston" <jon@beniston.com> wrote in message > news:e87b9ce8.0410010514.6fa501a@posting.google.com... > > > # Xilinx benefit if MicroBlaze is in the news > > > > > > # Such efforts expand usage of, and research in, MicroBlaze > > > > > > # It can be a usefull second opinion / benchmark > > > > > > # Xilinx will have trademark rights to MicroBlaze, so they can > > > restrict use of the name. Other examples of this are 6805 uC and i2c > > > instances. > > > > > > # The open source core is only a tiny portion of system development: > > > you also have compilers/SWdebuggers/HWDebuggers/Libraries, and all of > > > those will have Xilinx license restrictions for Xilinx FPGAs. > > > > Actully, the compiler & I believe the debugger are open source. This > > means that people are very close to having everything for free. > > 1) The compiler and binutils are GPL GNU stuff - that is Xilinx *must* > provide the source of the those GNU tools in source code form at no charge, > what they are doing, the gnu source of the tools is freely available from > Xilinx. And due to the GPL licensing they can not limit the access to that > source code. Xilinx don't have to provide the source free of charge. What they have to do is provide an offer to those who have access to the binaries, offering them the source code for no more than a reasonable distribution fee. They have no obligation to make the source code available to anyone else, nor do they have to make it free (as in beer), only free (as in speach). However, if someone buys a MicroBlaze development kit including the compiler, etc., then Xilinx must provide the source code to that someone, and they can then pass it on freely if they want. What this boils down to is that Xilinx has no obligations to make the tools easily available, but if someone posts the tools on opencores then Xilinx cannot complain (except perhaps regarding trademarks on the name). > > 2) It is not of big news yet, but the new EDK software ide is based on > Open-Source Eclipse Platform as well, but Eclipse licensing is different so > using Xilinx Eclipse tools is possible not free, but as Eclipse itself is > free and Open-Source there are no limitations for 3rd parties to develop > Eclipse based IDE for the Open-Source M*Blaze > > 3) uCLinux is Open-Source and free so if there is enough interest to get the > OpenSource M*Blaze to be able to be used in uCLinux, then we could have > truly open multi-vendor environment for FPGA+SoftCore+OS > > antti > http://uclinux.openchip.org > > >Article: 74012
Hi > Another thing which has confused me is: If I wish to write an > entity(below) for Spartan II, does the programmer worry about > generating the signal for "clk" input? Or simply connect it to the > correct pin of FPGA and I should get the signal of 200MHz? I'm not sure I understand the question but : The CLK input MUST be provided by external means like a Crystal Oscillator and must be directed to an appropriate pin on the FPGA. Then you must use constrainsts so that your VHDL nets that should be connected to the outside are locked onto the right pads of the FPGA (depends on your board design). SylvainArticle: 74013
Rick, Bad hair day? Answers below, Austin rickman wrote: > Austin Lesea wrote: > >>Jon, >> >>Peter is right: ASIC testing rarely gets more than 95% coverage. The >>best is about 98% coverage. >> >>We can get an arbitrarily high coverage by just increasing our patterns >>(99.9%+) for 0 added silicon cost. ASICs can not do that. > > > But as Peter pointed out, silicon cost is not the only variable cost. > The longer testing adds to the unit cost just as larger silicon does. > Completely different costs. You can not change silicon every week, but you can change BIST patterns. Patterns can be improved continually, which drives down costs. > > >>To get any better, they either have to add more logic for BIST (30%+ of >>a Pentium IV is BIST logic) which increases area and cost and decreases >>yield, or just be happy with the coverage of the scan chain (which is >>not all that good). > > > Nonsense. There are design techniques to measure testability to allow > as high testing coverage as is required by improving the test. If there > is no way to determine a fault in a node, then by definition, it won't > affect the operation of the chip! Any fault that makes a difference in > chip operation is observable, the only question is how to stimulate the > chip to detect it. That is a well understood problem. > So 98% is as good as you get in an ASIC, and we can get an arbritrariy higher coverage with no silicon area penalty. Then we can take our time to improve the patterns till they take very little time to run. What does "unobservable" error have to do with this? I am talking about that last 2% of errors that ASICs do not catch, and could be observable (if they took infinite time, and infinite resources). > > >>Each BIST or scan chain is unique, and software, test vectors, etc. muct >>be developed each time anything is new or different. > > > Yes, but that does not mean excess test development time. Much of this > process is automated. > True, but then you have to see what the automation missed. > > >>FPGAs have 0% extra area for BIST (they are 100% BIST with a different >>bitstream!). > > > No, by definition an FPGA has extra area for BIST, that is what makes it > an FPGA, all the *extra* stuff in it!!! What is the area overhead for > an FPGA vs. an ASIC; 10X, 20X? Even if you build an ASIC that is two > generations back such as 150 nm vs. 90 nm, the ASIC will be smaller, > faster and therefore cheaper. > > Unfair. ASICs do have fewer transistors to do the same job, but do not then use the fact that FPGAs have more to justify that ASICs have a better approach to testing: they do not. A certain very lasge ASIC manufacturer might be adding FPGA cores to their ASICs, not for any direct customer benefit, but because it might be easier and cheaper with more coverage to test them that way. > >>You must understand that the 405PPC, MGT, DCM, and other "hardened IP" >>are just like ASICs, so we already know everything there is to know >>about ASICs, their design, and testing. In fact Xilinx the 3rd largest >>'ASIC' manufacturer in the world (behind IBM and NEC -- >>Gartner/Dataquest 'ASIC/FPGA Vendor Ranking 2003'). >> >>FPGA vendors may be the last stronghold of full custom ASIC design left >>in the world. ASIC houses are mostly standard cell, or structured >>(basically same thing), with little or no full custom. >> >>Our customers tell us that if they want to play with the latest and >>greatest technologies and designs (like 10 Gbs MGTs), they need to use >>our FPGAs, because the ASIC cells are a generation behind. > > > How is using the "latest and greatest technologies" an advantage when it > comes with a 10X area premium??? Well, first off, the ppc, mgt, etc have no area (or cost) premium. In fact some would consider them free. And the 'premium' you claim for FPGAs must not be much, as we keep selling them for less $$, and have more features with each generation. > >Article: 74014
Hi All,
I am using XPower and I encounter the following warnings:
WARNING:Power:762 - Only 61% of the design signals have been set.
WARNING:Power:763 - Only 49% of the design signals toggle.
INFO:Power:556 - Estimate is inaccurate based on analysis of the
design, user
input and characterization data.
I am using the post-place-and-route simulation model and the
activities of all nodes are set by ModelSim using a vcd file
simulating up to 10000 cycles.
1) Specifically, how does it determine that the estimate is
inaccurate?
2) Are register-rich designs tend to be like that i.e. because
activities at varoius nodes has not been set properly?
3) WHAT CAN I DO?
The detailed report is below:
----------------------------------------------------------------
Release 6.3.01i - XPower SoftwareVersion:G.36
Copyright (c) 1995-2004 Xilinx, Inc. All rights reserved.
Design: stream
Preferences: stream.pcf
VCD File: stream.vcd
Part: 2v1000ff896-6
Data version: ADVANCED,v1.01,07-31-02
Power summary: I(mA) P(mW)
----------------------------------------------------------------
Total estimated power consumption: 567
---
Vccint 1.50V: 103 154
Vccaux 3.30V: 100 330
Vcco33 3.30V: 25 83
---
Clocks: 1 1
IOs: 0 18
Inputs: 0 0
Logic: 1 1
Outputs:
Vcco33 19 62
Signals: 1 1
---
Quiescent Vccint 1.50V: 100 150
Quiescent Vccaux 3.30V: 100 330
Quiescent Vcco33 3.30V: 1 3
Startup Vccint 1.5V: 250
Startup Vccaux 3.3V: 100
Startup Vcco33 3.3V: 50
---
Package power limits, ambient 25C: 5085
250 LFM: 7317
500 LFM: 8955
750 LFM: 10169
Thermal summary:
----------------------------------------------------------------
Estimated junction temperature: 32C
250 LFM 30C
500 LFM 29C
750 LFM 28C
Ambient temp: 25C
Case temp: 31C
Theta J-A: 12C/W
---
Max ambient at junction max of 85C: 78C
250 LFM 80C
500 LFM 81C
750 LFM 82C
Decoupling Network Summary: Cap Range (uF) #
----------------------------------------------------------------
Capacitor Recommendations:
Total for Vccint : 44
470.0 - 1000.0 : 1
4.70 - 10.00 : 2
0.470 - 2.200 : 5
0.0470 - 0.2200 : 8
0.0100 - 0.0470 : 14
0.0010 - 0.0047 : 14
---
Total for Vccaux : 8
470.0 - 1000.0 : 1
0.0470 - 0.2200 : 1
0.0100 - 0.0470 : 2
0.0010 - 0.0047 : 4
---
Total for Vcco33 : 11
470.0 - 1000.0 : 1
0.470 - 2.200 : 1
0.0470 - 0.2200 : 2
0.0100 - 0.0470 : 3
0.0010 - 0.0047 : 4
-----------------------------
I/O Bank Details:
Bank 0 (3.3V) :
470.0 - 1000.0 : 1
0.470 - 2.200 : 1
0.0470 - 0.2200 : 2
0.0100 - 0.0470 : 3
0.0010 - 0.0047 : 4
Total : 11
---
----------------------------------------------------------------
For further information on Bypass/Decoupling Capacitors see
application note 623
WARNING:Power:762 - Only 61% of the design signals have been set.
WARNING:Power:763 - Only 49% of the design signals toggle.
INFO:Power:556 - Estimate is inaccurate based on analysis of the
design, user
input and characterization data.
Power details:
-------------------------------------------------------------------------------
Outputs:1 Loads Loading(fF) C(pF) F(MHz)
I(mA) P(mW)
-------------------------------------------------------------------------------
Vcco33
mpc_d<10>-E0 35000 13 5.1
0.8 2.7
mpc_d<12>-E0 35000 13 5.1
0.8 2.7
mpc_d<14>-E0 35000 13 5.1
0.8 2.7
mpc_d<15>-E0 35000 13 5.1
0.8 2.7
mpc_d<16>-E0 35000 13 5.1
0.8 2.7
mpc_d<20>-E0 35000 13 5.1
0.8 2.7
mpc_d<22>-E0 35000 13 5.1
0.8 2.7
mpc_d<27>-E0 35000 13 5.1
0.8 2.7
mpc_d<07>-E0 35000 13 5.0
0.8 2.6
mpc_d<08>-E0 35000 13 4.9
0.8 2.6
-------------------------------------------------------------------------------
Logic: Loads Loading(fF) C(pF) F(MHz)
I(mA) P(mW)
-------------------------------------------------------------------------------
CompRegD345<3>-E1 1 10.0
0.0 0.0
CompRegB378-U1/SP.WSGEN 0 10.0
0.0 0.0
CompRegB378.WSGEN 0 10.0
0.0 0.0
CompRegB381-U1/SP.WSGEN 0 10.0
0.0 0.0
CompRegB381.WSGEN 0 10.0
0.0 0.0
CompRegB384-U1/SP.WSGEN 0 10.0
0.0 0.0
CompRegB384.WSGEN 0 10.0
0.0 0.0
CompRegB387-U1/SP.WSGEN 0 10.0
0.0 0.0
CompRegB387.WSGEN 0 10.0
0.0 0.0
CompRegB583-U1/SP.WSGEN 0 10.0
0.0 0.0
-------------------------------------------------------------------------------
Signals: Loads Loading(fF) C(pF) F(MHz)
I(mA) P(mW)
-------------------------------------------------------------------------------
__ibuf_mpc_a<04> 33 19 2.8
0.1 0.1
__ibuf_mpc_a<03> 33 19 2.8
0.1 0.1
__ibuf_mpc_a<02> 33 19 2.5
0.1 0.1
__ibuf_mpc_a<05> 33 17 2.2
0.1 ~0.0
__ibuf_mpc_oe 36 9 3.2
0.0 ~0.0
CompRegC216 78 23 0.9
0.0 ~0.0
internal_mpc_d<15> 1 3 5.1
0.0 ~0.0
internal_mpc_d<22> 1 2 5.1
0.0 ~0.0
internal_mpc_d<01> 1 2 4.9
0.0 ~0.0
internal_mpc_d<00> 1 2 4.8
0.0 ~0.0
-------------------------------------------------------------------------------
Clocks:1 Loads Loading(fF) C(pF) F(MHz)
I(mA) P(mW)
-------------------------------------------------------------------------------
stream/clk/IBUFG
Logic:
stream/clk/BUFG 6 10.0
0.1 0.1
Nets:
stream/clk 94 38 10.0
0.6 0.9
stream/clk/IBUFG 1 0 10.0
0.0 ~0.0
-------------------------------------------------------------------------------
Inputs: Loads Loading(fF) C(pF) F(MHz)
I(mA) P(mW)
-------------------------------------------------------------------------------
stream/clk/IBUFG 3 10.0
0.1 0.1
__ibuf_mpc_oe 3 3.2
0.0 0.0
__ibuf_mpc_a<00> 3 3.0
0.0 0.0
__ibuf_mpc_a<03> 3 2.8
0.0 0.0
__ibuf_mpc_a<04> 3 2.8
0.0 0.0
__ibuf_mpc_a<07> 3 2.8
0.0 0.0
__ibuf_mpc_we<3> 3 2.8
0.0 0.0
__ibuf_mpc_a<13> 3 2.7
0.0 0.0
__ibuf_mpc_a<10> 3 2.6
0.0 0.0
__ibuf_mpc_a<11> 3 2.5
0.0 0.0
-------------------------------------------------------------------------------
IOs:1 Loads Loading(fF) C(pF) F(MHz)
I(mA) P(mW)
-------------------------------------------------------------------------------
Vcco33
__ibuf_mpc_d<05> 3 5.3
0.0 0.0
mpc_d<05>-E0 35000 13 5.2
0.8 2.7
__ibuf_mpc_d<06> 3 4.9
0.0 0.0
mpc_d<06>-E0 35000 13 5.2
0.8 2.7
mpc_d<01>-E0 35000 13 4.9
0.8 2.6
__ibuf_mpc_d<01> 3 5.5
0.0 0.0
__ibuf_mpc_d<00> 3 5.8
0.0 0.0
mpc_d<00>-E0 35000 13 4.8
0.8 2.5
__ibuf_mpc_d<02> 3 5.2
0.0 0.0
mpc_d<02>-E0 35000 13 4.8
0.8 2.5
-------------------------------------------------------------------------------
Power improvement guide:
-------------------------------------------------------------------------------
3 of 101 registers use an enable signal
-------------------------------------------------------------------------------
Signal Power when Power when Power
savings
asserted(mW) disabled(mW) at
50%(mW)
-------------------------------------------------------------------------------
AddrInCount355/Start-E0 567.1 567.1 0.0
For further suggestions on power improvements see application note no.
421
Analysis completed: Sat Oct 02 16:28:00 2004
----------------------------------------------------------------
Article: 74015Rick, Configuration of a test pattern can make efficient use of our partial reconfiguration capabilities. I can not say how many seconds an FPGA spends in the tester, but it is less that an ASIC does. There also may be much faster ways to configure that we can use, but do not offer to customers. Why can we do 1,000's of BIST patterns faster? Well one obvious reason is that a BIST pattern in a FPGA can run at the speed of the FPGA, which is often 10X to 100X faster than the tester. It might have to run for 1000 clocks to finish, and then go on to the next test, which might be different by the contents of a few LUTs. If you are really curious of how we perform this magic, you can research all of our BIST patents and think about what you would do if you faced such a problem. Again, Peter is right. Austin rickman wrote: > You may be convinced, but that is not the same as having facts. The > simple fact that you "reconfigure tens and hundreds of times" means you > take a lot of time just loading your tests into the chip before you can > run them on the chip. The test methods for ASIC testing has been around > for a long time, it is the details of a particular test that is unique > for a given ASIC. This is not a new science, it is well understood and > largely automated. > > Which question is meaningless and cute? I didn't ask a question. I was > responding to *your* statements about total costs. I believe your point > was about the silicon area not being the sole or possibly even the > largest part of chip costs. Non-recurring costs can be large, but their > per-unit cost depends on the volume. However, the testing and silicon > per-unit costs are the same regardless of volume. So they are more > important as the volume increases. > > > Peter Alfke wrote: > >>I doubt that very much. I am convinced that FPGA testing is simpler and >>cheaper than ASIC testing. The secet is in the reconfigurability. We do not >>just apply external test vectors. We reconfigure tens and hundreds of times, >>and we have a lot of self-test engines that run in parallel inside the chip. >>And we can afford to spend a lot of engineering on our generic test >>methodologies, since they are amortized across >1 billion dollars in annual >>sales. ASICs have to develop new test methods for each design. >> >>But: >>What was the original question really about ? >>I think it was a meaningless "cute" question. >>Peter Alfke >> >> >>>From: rickman <spamgoeshere4@yahoo.com> >>>Reply-To: john@bluepal.net >>>Newsgroups: comp.arch.fpga >>>Date: Thu, 30 Sep 2004 16:54:28 -0400 >>>Subject: Re: FPGA vs ASIC area >>> >>> >>>Another large hunk of chip cost is testing. And lets face it, testing a >>>large, complex FPGA takes time on an expensive tester. An ASIC that >>>would fit on an FPGA will be a lot cheaper to test. Of course Xilinx >>>has that program that only tests FPGAs to the users test vectors, so I >>>guess that can help limit that part of the total cost. >>> >>>-- >>> >>>Rick "rickman" Collins >>> >>> > >Article: 74016
In article <415e8938$0$2840$cc9e4d1f@news-text.dial.pipex.com>,
Leon Heller <leon_heller@hotmail.com> wrote:
>The "WAIT..." statement is not synthesisable. You simply need a counter
>(ripple counter will do) to divide the clock down to 400 Hz or so. Write the
>VHDL for a toggle flip-flop and string lots of them together - not very
>elegant but it should work.
I know XST will infer a counter from
reg [31:0] ctr
always @(posedge clk)
begin
reg = reg + 1
end
Far easier than stringing flops to get a binary countdown.
--
Nicholas C. Weaver. to reply email to "nweaver" at the domain
icsi.berkeley.edu
Article: 74017GS, You are correct. FPGA devekopment can be done just as poorly as software code, and often is. Austin General Schvantzkoph wrote: >> The place where FPGAs win big is NRE, an FPGA design >> >>>costs millions less than an ASIC design. Even if you take out the cost >>>of the mask set there is a big difference because you don't have to >>>spend as much on verification on an FPGA design as on an ASIC. >> >>Even though you should (spend money on verification). People do not. >> >> With an FPGA you can >> >>>go into the lab with a design that's almost right because fixing the >>>bug is cheap, with an ASIC you have to have a design that's completely >>>right before you build it because you can't fix it later. >> >>Again, fixing it as it is shipped is not a way to run a company. Not >>cheap if you ship 10,000 that you later have to retrofit (reprogram). >>But if it provides a competitive advantage, people will take advantage >>of it. > > > I didn't say no verification, I would never go into the lab with a design > that hadn't been verified. The difference is that you can spend a few > weeks to a couple of months simulating an FPGA and then go into the lab > and run it in a real system at the real clock speed and get the last bugs. > In big systems the bit patterns should be loaded by the software not by > serial proms, if a bug crops up you rev the software. Everyone expects > software to be buggy so no one blinks an eye if there is a new software > release, let the software guys take the blame. In my experience the > software guys feel so guilty about bugs that it's hard to convince them > that it's not their fault. If a system can't be field upgraded then you > have to test the hell out of it but you do that on the real hardware. > Either way you are in the lab a full 12 to 18 months earlier with an > FPGA then you are with an ASIC. >Article: 74018
> As a quick aside, Cyclone has three speed grades, Spartan-3 only two. In > general, a speed grade represents about a 15% difference in performance. > > Slowest vs. slowest speed grade would be interesting. Ok, here it is: Cyclone slowest (-8): 77.5MHz Spartan slowest (-4): 77.8MHz Looks now better for X.... And now let's throw in some price numbers. Prices are single units from arrow.com and avnet.com, both devices in the same package (tqfp144): Cyclone: EP1C6T144C6: $41.60 Cyclone: EP1C6T144C8: $27.70 Spartan-3: XC3S200-4TQ144C: $19.93 no price for -5 speed grade And relate the price to density and speed in a 'funny' way: price / 1000 LCs / MHz: EP1C6-6: 41.60$ / 5.980 kLC / 98 MHz = 7.1 cent / kLC / MHz EP1C6-8: 5.98 cent / kLC /MHz XC3S200-T: $19.93 / 3.840 kLC / 77.8 MHz = 6.7 cent / kLC /MHz and now it looks again better for A... I did not take into account the multipliers and larger memories in the Spartan, but also not the fact that the Cyclones are available for a longer time (I got my first Cyclone samples 01/2003 and sold the first boards 02/2003 :-) Martin -- ---------------------------------------------- JOP - a Java Processor core for FPGAs: http://www.jopdesign.com/Article: 74019
>>Slowest vs. slowest speed grade would be interesting. > > Ok, here it is: > Cyclone slowest (-8): 77.5MHz > Spartan slowest (-4): 77.8MHz > Looks now better for X.... I can't reproduces those numbers ( or any of the one you gave ) (for xilinx, I mean, I don't have quartus installed), how do you proceed exactly ? > Spartan-3: XC3S200-4TQ144C: $19.93 Huh ? I can buy XC3S400-4FT256 for 23$ piece for very small qty (6 pieces in my case) and that's from an avnet company. > And relate the price to density and speed in a 'funny' way: > price / 1000 LCs / MHz: > > EP1C6-6: 41.60$ / 5.980 kLC / 98 MHz = 7.1 cent / kLC / MHz > EP1C6-8: 5.98 cent / kLC /MHz > XC3S200-T: $19.93 / 3.840 kLC / 77.8 MHz = 6.7 cent / kLC /MHz > and now it looks again better for A... For the XC3S400-4FT256 (assuming same frequency) : $23 / 7.680 kLC / 77.8Mhz = 3.85 cent / kLC / Mhz Numbers ... you can make them tell anything you want ;) > I did not take into account the multipliers and larger memories in the > Spartan, but also not the fact that the Cyclones are available for a > longer time (I got my first Cyclone samples 01/2003 and sold the first > boards 02/2003 :-) Yup, I think there are 200LC used for a booth multiplier, should be easy to lower that with a dedicated multiplier (and also go faster i would guess). Btw, is there any networking available ? I have a Avnet Spartan 3 kit with an ethernet PHY on bard, that would be nice to get TCP/IP ;) SylvainArticle: 74020
Ted, It is trying to tell you that your simulation test bench doesn't cause much to happen. The estimate is only as good as the test bench. If all those nodes don't ever switch, then you can probably simplify your design! The number of cycles is no measure of coverage. If I hold a register in reset, and clock it a million times, I will not see much power. So, without a test bench that exercises all of the registers, with the worst case transitions, the estimate isn't very good. But only you can tell what the register values should be, the tool can't just guess. Some people use a LFSR to generate pseudo random data as a stimulus. Might, or might not be appropriate in your case. Austin Ted wrote: > Hi All, > > I am using XPower and I encounter the following warnings: > WARNING:Power:762 - Only 61% of the design signals have been set. > WARNING:Power:763 - Only 49% of the design signals toggle. > INFO:Power:556 - Estimate is inaccurate based on analysis of the > design, user > input and characterization data. > > I am using the post-place-and-route simulation model and the > activities of all nodes are set by ModelSim using a vcd file > simulating up to 10000 cycles. > > 1) Specifically, how does it determine that the estimate is > inaccurate? > > 2) Are register-rich designs tend to be like that i.e. because > activities at varoius nodes has not been set properly? > > 3) WHAT CAN I DO? > > The detailed report is below: > > ---------------------------------------------------------------- > Release 6.3.01i - XPower SoftwareVersion:G.36 > Copyright (c) 1995-2004 Xilinx, Inc. All rights reserved. > Design: stream > Preferences: stream.pcf > VCD File: stream.vcd > Part: 2v1000ff896-6 > Data version: ADVANCED,v1.01,07-31-02 > > Power summary: I(mA) P(mW) > ---------------------------------------------------------------- > Total estimated power consumption: 567 > --- > Vccint 1.50V: 103 154 > Vccaux 3.30V: 100 330 > Vcco33 3.30V: 25 83 > --- > Clocks: 1 1 > IOs: 0 18 > Inputs: 0 0 > Logic: 1 1 > Outputs: > Vcco33 19 62 > Signals: 1 1 > --- > Quiescent Vccint 1.50V: 100 150 > Quiescent Vccaux 3.30V: 100 330 > Quiescent Vcco33 3.30V: 1 3 > Startup Vccint 1.5V: 250 > Startup Vccaux 3.3V: 100 > Startup Vcco33 3.3V: 50 > --- > Package power limits, ambient 25C: 5085 > 250 LFM: 7317 > 500 LFM: 8955 > 750 LFM: 10169 > > Thermal summary: > ---------------------------------------------------------------- > Estimated junction temperature: 32C > 250 LFM 30C > 500 LFM 29C > 750 LFM 28C > Ambient temp: 25C > Case temp: 31C > Theta J-A: 12C/W > --- > Max ambient at junction max of 85C: 78C > 250 LFM 80C > 500 LFM 81C > 750 LFM 82C > > Decoupling Network Summary: Cap Range (uF) # > ---------------------------------------------------------------- > Capacitor Recommendations: > Total for Vccint : 44 > 470.0 - 1000.0 : 1 > 4.70 - 10.00 : 2 > 0.470 - 2.200 : 5 > 0.0470 - 0.2200 : 8 > 0.0100 - 0.0470 : 14 > 0.0010 - 0.0047 : 14 > --- > Total for Vccaux : 8 > 470.0 - 1000.0 : 1 > 0.0470 - 0.2200 : 1 > 0.0100 - 0.0470 : 2 > 0.0010 - 0.0047 : 4 > --- > Total for Vcco33 : 11 > 470.0 - 1000.0 : 1 > 0.470 - 2.200 : 1 > 0.0470 - 0.2200 : 2 > 0.0100 - 0.0470 : 3 > 0.0010 - 0.0047 : 4 > ----------------------------- > I/O Bank Details: > > Bank 0 (3.3V) : > 470.0 - 1000.0 : 1 > 0.470 - 2.200 : 1 > 0.0470 - 0.2200 : 2 > 0.0100 - 0.0470 : 3 > 0.0010 - 0.0047 : 4 > Total : 11 > --- > ---------------------------------------------------------------- > For further information on Bypass/Decoupling Capacitors see > application note 623 > > WARNING:Power:762 - Only 61% of the design signals have been set. > WARNING:Power:763 - Only 49% of the design signals toggle. > INFO:Power:556 - Estimate is inaccurate based on analysis of the > design, user > input and characterization data. > > Power details: > ------------------------------------------------------------------------------- > Outputs:1 Loads Loading(fF) C(pF) F(MHz) > I(mA) P(mW) > ------------------------------------------------------------------------------- > Vcco33 > mpc_d<10>-E0 35000 13 5.1 > 0.8 2.7 > mpc_d<12>-E0 35000 13 5.1 > 0.8 2.7 > mpc_d<14>-E0 35000 13 5.1 > 0.8 2.7 > mpc_d<15>-E0 35000 13 5.1 > 0.8 2.7 > mpc_d<16>-E0 35000 13 5.1 > 0.8 2.7 > mpc_d<20>-E0 35000 13 5.1 > 0.8 2.7 > mpc_d<22>-E0 35000 13 5.1 > 0.8 2.7 > mpc_d<27>-E0 35000 13 5.1 > 0.8 2.7 > mpc_d<07>-E0 35000 13 5.0 > 0.8 2.6 > mpc_d<08>-E0 35000 13 4.9 > 0.8 2.6 > ------------------------------------------------------------------------------- > Logic: Loads Loading(fF) C(pF) F(MHz) > I(mA) P(mW) > ------------------------------------------------------------------------------- > CompRegD345<3>-E1 1 10.0 > 0.0 0.0 > CompRegB378-U1/SP.WSGEN 0 10.0 > 0.0 0.0 > CompRegB378.WSGEN 0 10.0 > 0.0 0.0 > CompRegB381-U1/SP.WSGEN 0 10.0 > 0.0 0.0 > CompRegB381.WSGEN 0 10.0 > 0.0 0.0 > CompRegB384-U1/SP.WSGEN 0 10.0 > 0.0 0.0 > CompRegB384.WSGEN 0 10.0 > 0.0 0.0 > CompRegB387-U1/SP.WSGEN 0 10.0 > 0.0 0.0 > CompRegB387.WSGEN 0 10.0 > 0.0 0.0 > CompRegB583-U1/SP.WSGEN 0 10.0 > 0.0 0.0 > ------------------------------------------------------------------------------- > Signals: Loads Loading(fF) C(pF) F(MHz) > I(mA) P(mW) > ------------------------------------------------------------------------------- > __ibuf_mpc_a<04> 33 19 2.8 > 0.1 0.1 > __ibuf_mpc_a<03> 33 19 2.8 > 0.1 0.1 > __ibuf_mpc_a<02> 33 19 2.5 > 0.1 0.1 > __ibuf_mpc_a<05> 33 17 2.2 > 0.1 ~0.0 > __ibuf_mpc_oe 36 9 3.2 > 0.0 ~0.0 > CompRegC216 78 23 0.9 > 0.0 ~0.0 > internal_mpc_d<15> 1 3 5.1 > 0.0 ~0.0 > internal_mpc_d<22> 1 2 5.1 > 0.0 ~0.0 > internal_mpc_d<01> 1 2 4.9 > 0.0 ~0.0 > internal_mpc_d<00> 1 2 4.8 > 0.0 ~0.0 > ------------------------------------------------------------------------------- > Clocks:1 Loads Loading(fF) C(pF) F(MHz) > I(mA) P(mW) > ------------------------------------------------------------------------------- > stream/clk/IBUFG > Logic: > stream/clk/BUFG 6 10.0 > 0.1 0.1 > Nets: > stream/clk 94 38 10.0 > 0.6 0.9 > stream/clk/IBUFG 1 0 10.0 > 0.0 ~0.0 > ------------------------------------------------------------------------------- > Inputs: Loads Loading(fF) C(pF) F(MHz) > I(mA) P(mW) > ------------------------------------------------------------------------------- > stream/clk/IBUFG 3 10.0 > 0.1 0.1 > __ibuf_mpc_oe 3 3.2 > 0.0 0.0 > __ibuf_mpc_a<00> 3 3.0 > 0.0 0.0 > __ibuf_mpc_a<03> 3 2.8 > 0.0 0.0 > __ibuf_mpc_a<04> 3 2.8 > 0.0 0.0 > __ibuf_mpc_a<07> 3 2.8 > 0.0 0.0 > __ibuf_mpc_we<3> 3 2.8 > 0.0 0.0 > __ibuf_mpc_a<13> 3 2.7 > 0.0 0.0 > __ibuf_mpc_a<10> 3 2.6 > 0.0 0.0 > __ibuf_mpc_a<11> 3 2.5 > 0.0 0.0 > ------------------------------------------------------------------------------- > IOs:1 Loads Loading(fF) C(pF) F(MHz) > I(mA) P(mW) > ------------------------------------------------------------------------------- > Vcco33 > __ibuf_mpc_d<05> 3 5.3 > 0.0 0.0 > mpc_d<05>-E0 35000 13 5.2 > 0.8 2.7 > __ibuf_mpc_d<06> 3 4.9 > 0.0 0.0 > mpc_d<06>-E0 35000 13 5.2 > 0.8 2.7 > mpc_d<01>-E0 35000 13 4.9 > 0.8 2.6 > __ibuf_mpc_d<01> 3 5.5 > 0.0 0.0 > __ibuf_mpc_d<00> 3 5.8 > 0.0 0.0 > mpc_d<00>-E0 35000 13 4.8 > 0.8 2.5 > __ibuf_mpc_d<02> 3 5.2 > 0.0 0.0 > mpc_d<02>-E0 35000 13 4.8 > 0.8 2.5 > ------------------------------------------------------------------------------- > > Power improvement guide: > ------------------------------------------------------------------------------- > 3 of 101 registers use an enable signal > ------------------------------------------------------------------------------- > Signal Power when Power when Power > savings > asserted(mW) disabled(mW) at > 50%(mW) > ------------------------------------------------------------------------------- > AddrInCount355/Start-E0 567.1 567.1 0.0 > > > For further suggestions on power improvements see application note no. > 421 > > Analysis completed: Sat Oct 02 16:28:00 2004 > ----------------------------------------------------------------Article: 74021
"H. Peter Anvin" <hpa@terminus.zytor.com> wrote in message news:cjcq0b$8g4$1@terminus.zytor.com... >> >> For either device, you do not need to compute the PLL values - if you >> tell Quartus the requirements it will compute the PLL settings for >> you. >> > > I've had problems with Quartus II 4.1 (Web Edition SP0-2) and getting > the PLL values to make sense. In particular, if I feed it: > > fin = 50 MHz > c0 = 4/1 = 200 MHz > c1 = 1/4 = 12.5 MHz > > ... it says it cannot make the desired PLL. 2.x and 3.x both did this > correctly, and if I lie and specify fin = 75 MHz it builds the correct > PLL and it works correctly with a 50 MHz input. The timing analyzer > spits out a message that the input frequency has been overridden (by > specifying clkin = 50 MHz as a timing constraint) and does the right > thing. > > This is for a Cyclone EP1C20F400C7 device. > > -hpa Hello Peter, Quartus configures PLLs that satisfy all the device constraints (e.g. VCO range, PFD range, etc), which is why it cannot build the specific configuration you suggested for a Cyclone device (though it can be built in Stratix/StratixGX/StratixII devices). In Cyclone devices, the VCO frequency must be between 490 Mhz and 1000 Mhz. For the example you gave, the resulting PLL's VCO frequency for a 75 Mhz input would be 600 Mhz (since the M counter is 8, and N counter is 1). But if you manually bypass this safeguard and feed in a frequency of 50 Mhz, the PLL's VCO frequency would be 400 Mhz, which is outside the supported range for Cyclone PLLs. In the situation described above (75 Mhz input selected, but 50Mhz actual) the PLL is operating outside the specified range, so jitter performance and static phase shift may be adversely affected. This limit was set in Quartus II 3.0 SP2 for the first time, as a result of characterization of the Cyclone devices. Previously, in Quartus II 3.0, the limit was 300 Mhz, based on preliminary simulation results. Hope this helps. - Subroto Datta Altera Corp.Article: 74022
Martin Schoeberl wrote: > For those who are interested in a short comparison between Cyclone and > Spartan-3: > > Cyclone EP1C6Q240C6: > fmax: 98 MHz, 2066 LC/Es (34% out of 5980) > Spartan-3 XC3S200-5 > fmax: 82 MHz, 2015 LC/Es (52% out of 3840) Where did you get this numbers from ? I get on ISE 6.2.03: xc3s200-4 Minimum period: 10.428ns (Maximum Frequency: 95.896MHz) xc3s200-5 Minimum period: 9.503ns (Maximum Frequency: 105.235MHz) cheersArticle: 74023
Sylvain, > >>Slowest vs. slowest speed grade would be interesting. > > > > Ok, here it is: > > Cyclone slowest (-8): 77.5MHz > > Spartan slowest (-4): 77.8MHz > > Looks now better for X.... > > I can't reproduces those numbers ( or any of the one you gave ) (for xilinx, I mean, I don't have quartus installed), > how do you proceed exactly ? Set a time constraint for clk (in this case I used 12ns). However, this should already be done in the UCF you downloaded with the project. Then look at the 'text-based post-plcae & route static timing report'. At the end you will find: Design statistics: Minimum period: 12.848ns (Maximum frequency: 77.833MHz) Don't let yourself be fooled by the maximum frequency from the synthesis report. These are dummy numbers (in this case 96 MHz...). > > Spartan-3: XC3S200-4TQ144C: $19.93 > Huh ? I can buy XC3S400-4FT256 for 23$ piece for very small qty (6 pieces in my case) and that's from an avnet company. The list price for the XC3S400-5FT256C (they don't have the -4 on the website) at avnet.com is $41. I just compared the prices that are available 'online'. I also got the Cyclone (Q240 package) cheaper: EUR 22.75 instead of $ ??..... for this device there is a 'call for quote' at arrow.com. The lead free costs $32.90, but these are more expensive in general. Btw, does somebody know why the lead free devices are more expensive. I did'n know up to now that semiconductors contain lead. I only know that it's part of the solder and when it's forbidden will probably increase production cost of PCBs. > > I did not take into account the multipliers and larger memories in the > > Spartan, but also not the fact that the Cyclones are available for a > > longer time (I got my first Cyclone samples 01/2003 and sold the first > > boards 02/2003 :-) > > Yup, I think there are 200LC used for a booth multiplier, should be easy to lower that with a dedicated multiplier (and also go faster i would guess). Yes that would drop the LC count and I could go with the next smaller Spartan-3. Uups, where is the XC3S100? The multiplication would be faster, but the multiplication (imul bytecode in the JVM) has a dynamic instruction frequency of 0.24% in typicall Java programs. That would not compensate for the clock frequency factor of 1.2 between the Cyclone and the Spartan-3. > Btw, is there any networking available ? > I have a Avnet Spartan 3 kit with an ethernet PHY on bard, that would be nice to get TCP/IP ;) Do you mean available with JOP? Yes, I have a small TCP/IP stack in Java with drivers for the CS8900 (Ethernet), PPP and SLIP. Even a small webserver is running on JOP: http://84.112.19.23 ;-) Martin ---------------------------------------------- JOP - a Java Processor core for FPGAs: http://www.jopdesign.com/Article: 74024
> Martin Schoeberl wrote: > > > For those who are interested in a short comparison between Cyclone and > > Spartan-3: > > > > Cyclone EP1C6Q240C6: > > fmax: 98 MHz, 2066 LC/Es (34% out of 5980) > > Spartan-3 XC3S200-5 > > fmax: 82 MHz, 2015 LC/Es (52% out of 3840) > > Where did you get this numbers from ? > I get on ISE 6.2.03: > xc3s200-4 Minimum period: 10.428ns (Maximum Frequency: 95.896MHz) > xc3s200-5 Minimum period: 9.503ns (Maximum Frequency: 105.235MHz) > Don't take the numbers from the Synthesizer! Use the frequency after P&R, in the post P&R static timing report. This mistake is done by many ISE users. Xilinx should change the text in the synthesizer report to state it clearly that this number is an estimation! Martin
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