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
Now there are two good stories to choose from.
Both are fundamentally correct, but each overstates its case.
I think your budget will make the decision for you.
Peter Alfke
=======================================
Richard Iachetta wrote:
> In article <3C353149.1A7CDD1A@earthlink.net>, palfke@earthlink.net says...
> > If you have infinite amounts of money and time, and never make a mistake
> > and never intend to change your design, then ASICs are great ( Low price
> > per chip, high performance, low power). But this comes at a high price
> > in non-recurring engineering charges ( $1 000 000 for a state-of-the art
> > big circuit ) and it takes months to get the first chip. And you must
> > always order and pay for a specific quantity, and never make a mistake
> > or a change.
> >
> > That's why more and more designers prefer the FPGA solution that does
> > not have these high up-front costs and long waiting time, and can be
> > bought in any quantity at any time, and be modified ad infinitum.
>
> All of this seems a bit overstated. Here's another perspective perhaps
> overstated in the other direction. You don't need infinite time and money to do
> an ASIC (I'll address mistakes in a minute). ASICs generally cost less per part
> but have an upfront NRE cost and longer lead time. So if your volume is large
> and you can afford the lead time, it often makes economic sense to go with an
> ASIC. There is typically a volume crossover point where on one side an FPGA is
> cheaper and on the other side an ASIC is cheaper.
>
> As you mentioned, state of the art ASICs perform better than state of the art
> FPGAs and can be much lower power so performance or power may require you to use
> an ASIC. ASICs offer much more flexability with regard to what you can do;
> while FPGAs have gotten very flexible, they are no where near as flexible as an
> ASIC with respect to different kinds of I/O drivers, pin placement, multiple
> PLLs, DLLs and clock domains, varieties of internal memories, etc. Custom ASICs
> offer even more flexibility and performance than standard ASICs allowing you
> construct your circuits at the transistor level. Even standard ASICs allow you
> map to just about any set of gates that you want for your circuit whereas
> designs in FPGAs must be mapped into whichever lookup tables, cells and math-
> assist resources are available in the target FPGA. Floorplanning is important
> for both ASICs and FPGAs but there can be more floorplanning headaches in FPGAs
> which pay a higher penalty if logic feeds other logic that is not close by ("off
> row" or whatever). In ASICs a slightly longer wire is just slightly more delay
> -- it scales much better.
>
> I would also argue that design source written for ASICs is much more portable
> and reusable than design source written for FPGAs. This is because FPGA designs
> (especially math functions) must be structured to map well to the particular
> FPGA architecture it is targeted for or a performance penalty (sometimes severe)
> will be paid. When porting the design to a different FPGA, the design may have
> to be rearchitected. Targeting an ASIC design to another ASIC technology is
> often just a case of resynthesis to the new library. Sometimes the netlist can
> be ported avoiding even the resynthesis.
>
> With regard to not being able to make a mistake when designing an ASIC and
> FPGA's being able to "be modified ad infinitum": Being able to modify an FPGA
> is great during product development but doesn't do as much good after a product
> has shipped. If people buy a video card with an FPGA on it and that FPGA has a
> bug, those people are usually in the same boat that they would be in if the card
> had used an ASIC instead. They are (usually) not going to be able to reprogram
> that FPGA at home so both the FPGA designer and the ASIC designer need to get
> the design right by ship time. During development time, mistakes are worse for
> ASICs but they are not as bad as some FPGA proponents would have you believe.
> ASICs commonly go through two or three passes and each pass is not a full respin
> of all the work, time and money needed to make the first part. In fact many
> second passes are ECs to the existing mask which preserve all of the design,
> synthesis, floorplanning, layout, wiring and timing work that has already been
> done.
>
> --
> Rich Iachetta
> iachetta@us.ibm.com
> I do not speak for IBM.
Article: 38101We are planning to develop a ASIC chips for a highspeed router. The majoy frequency may be 125M. Now at a verification stage, we made a FPGA version to check if the basic functions can work properly. But the FOUNDATION(virtex-II 4000-5) reports a timing contraints failure--the maximum logical delay is up to 9.7ns. After a very long-time optimization, the result is improved to 8.7ns, still not meet the timing requirement(8ns). we wonder if this problem exists when it goes to ASIC. I have no idea about ASIC's speed. I was told ASIC is faster than FPGA, if yes, how much faster? Seems VirtexII is already much faster than the old virtex or virtexE. I also notice somebody declare ASIC is NOT inherently faster than FPGA. Who is right? Your suggestion is very appreciated if you can help me or point me to the right direction to learn some basic ASIC knowledge. Thank you very much. ----------------------- Yu Jun yujun@huawei.comArticle: 38102
In article <651e62f3.0201041707.4039dced@posting.google.com>, Yu Jun <yujun@huawei.com> wrote: >We are planning to develop a ASIC chips for a highspeed router. The >majoy frequency may be 125M. Now at a verification stage, we made a >FPGA version to check if the basic functions can work properly. But >the FOUNDATION(virtex-II 4000-5) reports a timing contraints >failure--the maximum logical delay is up to 9.7ns. After a very >long-time optimization, the result is improved to 8.7ns, still not >meet the timing requirement(8ns). > >we wonder if this problem exists when it goes to ASIC. I have no idea >about ASIC's speed. I was told ASIC is faster than FPGA, if yes, how >much faster? Seems VirtexII is already much faster than the old virtex >or virtexE. I also notice somebody declare ASIC is NOT inherently >faster than FPGA. Who is right? ASICs done in a comparable process will be faster. But the NRE cost of doing an asic on a .12? uM process is substantial. Question: Could you simply add a couple more pipeline stages? -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 38103
Have you used enough pipelining? A logic delay of 9.7 ns indicates that a signal passed through many combinatorial blocks before it got re-clocked. Just stick a flip-flop in the middle of that path ( and compensate in other parallel branches ) The abundance of flip-flops in the FPGA architecture makes it very easy to increase throughput (clock frequency) by using extensive pipelining, albeit with increased latency. In many designs, pipelining can perforrm miracles... Peter Alfke, Xilinx Applications ============================== Yu Jun wrote: > We are planning to develop a ASIC chips for a highspeed router. The > majoy frequency may be 125M. Now at a verification stage, we made a > FPGA version to check if the basic functions can work properly. But > the FOUNDATION(virtex-II 4000-5) reports a timing contraints > failure--the maximum logical delay is up to 9.7ns. After a very > long-time optimization, the result is improved to 8.7ns, still not > meet the timing requirement(8ns). > > we wonder if this problem exists when it goes to ASIC. I have no idea > about ASIC's speed. I was told ASIC is faster than FPGA, if yes, how > much faster? Seems VirtexII is already much faster than the old virtex > or virtexE. I also notice somebody declare ASIC is NOT inherently > faster than FPGA. Who is right? > > Your suggestion is very appreciated if you can help me or point me to > the right direction to learn some basic ASIC knowledge. Thank you very > much. > > ----------------------- > Yu Jun > yujun@huawei.comArticle: 38104
Richard Iachetta <iachetta@us.ibm.com> wrote: > With regard to not being able to make a mistake when designing an ASIC and > FPGA's being able to "be modified ad infinitum": Being able to modify an FPGA > is great during product development but doesn't do as much good after a product > has shipped. If people buy a video card with an FPGA on it and that FPGA has a > bug, those people are usually in the same boat that they would be in if the card > had used an ASIC instead. They are (usually) not going to be able to reprogram True. But there are plenty of applications where it is easy to change the programming. Most FPGAs have to be programmed every time at power up anyway, which helps too. FPGA not only gives you the opportunity to correct mistakes but also the ability to add new features. In some applications that is invaluable. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 38105
On 4 Jan 2002 17:07:50 -0800, yujun@huawei.com (Yu Jun) wrote: >We are planning to develop a ASIC chips for a highspeed router. The >majoy frequency may be 125M. Now at a verification stage, we made a >FPGA version to check if the basic functions can work properly. But >the FOUNDATION(virtex-II 4000-5) reports a timing contraints >failure--the maximum logical delay is up to 9.7ns. After a very >long-time optimization, the result is improved to 8.7ns, still not >meet the timing requirement(8ns). > >we wonder if this problem exists when it goes to ASIC. I have no idea >about ASIC's speed. I was told ASIC is faster than FPGA, if yes, how >much faster? Seems VirtexII is already much faster than the old virtex >or virtexE. I also notice somebody declare ASIC is NOT inherently >faster than FPGA. Who is right? > >Your suggestion is very appreciated if you can help me or point me to >the right direction to learn some basic ASIC knowledge. Thank you very >much. > >----------------------- >Yu Jun >yujun@huawei.com In my experience with three designs which have seen both standard cell and FPGA implementations, I have observed a 3 to 5 times speed up with the ASIC implementation. The context was .25u standard cell desing and maximum frequency in the designs was 500 MHz. One design was an 8 bit microcontroller with lots of memory, one a 16 bit processor with embedded 10bt implementation and the last one a small block in a mixed signal design. These were all mostly control logic dominant designs and the ASIC implementations were done using static cmos, DFF registers. I think the 3-5 speed up only goes up to 500~600 MHz (i.e. if your design times 100 MHz on an FPGA you can expect 300 to 500 MHz) because above that speed, the clocking overhead with static cmos becomes too high. In my latest .25u design, the worst case setup+clk->q is around 1.5 ns so anything nearing 500 MHz leaves you only 500 ps to work with. With domino circuit techniques you can go much higher with a full custom design. Muzaffer Kal http://www.dspia.com DSP algorithm implementations for FPGA systemsArticle: 38106
On Sat, 5 Jan 2002 01:34:57 +0000 (UTC), nweaver@CSUA.Berkeley.EDU (Nicholas Weaver) wrote: >Question: Could you simply add a couple more pipeline stages? In a control logic dominated design, it can be very difficult to pipeline the design if existing interblock timing needs to be preserved. For datapath oriented designs, pipelining is easier usually. Muzaffer Kal http://www.dspia.com DSP algorithm implementations for FPGA systemsArticle: 38107
I DOes any body already working on Residue Number Systems , a kind of arithmetic which handle large numbers avoiding large carry propagation (a locations constraints ) I would like to share advices from you thanks jacky -- Use our news server 'news.foorum.com' from anywhere. More details at: http://nnrpinfo.go.foorum.com/Article: 38108
hamish@cloud.net.au wrote: > > True. But there are plenty of applications where it is easy to > change the programming. Most FPGAs have to be programmed every > time at power up anyway, which helps too. > > FPGA not only gives you the opportunity to correct mistakes but > also the ability to add new features. In some applications that > is invaluable. > > Hamish > -- > Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au> In many ways its even better than that since FPGAs allow an evolutionary approach to design. This has some big benefits in allowing s/w development to start earlier. You can even apply the evolutionary thing to the device's timing - in some cases. There's also something on the budgetary side that's been missed out. ASIC design tools (synthesisers, simulators, layout tools, etc.) are MUCH more expensive than the corresponding ones for FPGAs. I believe its normal in ASIC design to have several "seats" for each of these wich is going to burn another couple of $100K of investment. There's this nice quote I read from the head of NKK's Telecom? division that seems to be right up the FPGA's street (approx) ``Innovate radically, implement steadily''Article: 38109
hi, i have read in a document about full custom design. explaining why the nre costs are high it is written "..each primitive logic function or transistor is manually designed and optimized. ... the designer must manipulate the individual geometric shape wich represent the features of each transistor on the chip; hence the often applied term for full custom design: "polygon pushing". a relative simple 3000 gate design might require the handling of 300k rectangles per chip..." i guess this statement refers to an cad tool, but i don't understand the role of rectangles and the term "polygon pushing". maybe somebody could explain me a little bit in more detail? thanks, matthias weberArticle: 38110
Matthias Weber wrote:
> i have read in a document about full custom design. explaining why the nre costs are high it is written
> "..each primitive logic function or transistor is manually designed and optimized. ... the designer must manipulate
> the individual geometric shape wich represent the features of each transistor on the chip; hence the often applied term for
> full custom design: "polygon pushing". a relative simple 3000 gate design might require the handling of 300k rectangles per chip..."
CAD for full custom design makes transistors and interconnect by drawing out the
shapes needed at each layer. As an example, layers might be: 1) well implants
(for CMOS), 2) active (defines source+drain), 3) poly to active contact, 4)
polysilicon (makes the gates), 5) P source drain, 6) N Source drain, 7) metal
one contact, 8) first level metal, and so on. To define a transistor in full
custom, the designer draws out polygons (mostly rectangles) to describe each
layer. This allows the designer freedom to size and position each transistor,
which can lead to a slightly higher performance design, both smaller die size
and faster than the "cell library" or "gate array" versions of the same design,
at a cost of vastly higher designer time.
P P
P P
WWWWWWWWWWWWWPWWPWWWWWWWWWWWWWWWW
W P P W
W P P W
W AAAAAAAAAPAAPAAAAAAAAA W
W A P P A W
W A P P A W
W A P P A W
W A CCC P P CCC A W
W A C C P P C C A W
W A CCC P P CCC A W
W A P P A W
W A P P A W
W AAAAAAAAAPAAPAAAAAAAAA W
W P P W
W PPPP W
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
Above is a transister. The layers shown are "W" for well, "A" for active, "P"
for polysilicon and "C" for first level contacts.
--
Phil Hays
Article: 38111On Sat, 05 Jan 2002 16:15:11 GMT, Matthias Weber <msweber@onlinehome.de> wrote: >hi, > >i have read in a document about full custom design. explaining why the nre costs are high it is written >"..each primitive logic function or transistor is manually designed and optimized. ... the designer must manipulate >the individual geometric shape wich represent the features of each transistor on the chip; hence the often applied term for >full custom design: "polygon pushing". a relative simple 3000 gate design might require the handling of 300k rectangles per chip..." > >i guess this statement refers to an cad tool, but i don't understand the role of rectangles and the term "polygon pushing". >maybe somebody could explain me a little bit in more detail? On silicon the transistors are manufactured by placing multiple layers on top of each other. Each layer is described by multiple polygons and the devices are generated by the overlaps of the layers. It is not completely unlike PCB design especially when you look at connectivity. Some of the layers are for device generation (nwell, pwell, active, oxide, etc) and some layers are for connectivity (mostly metal layers, contacts etc). Here is a picture http://argon.eecs.berkeley.edu:8080/~ee143/Chip_Layout/figures/device.14.html In full custom design, the devices are designed manually. But there is still some automation for layout. One designs small scripts which take a transistor level schematic and generate all the transistors according to the W/L sizes in it and if annotated can even generate the cross-coupled and multi-leg devices. Almost no one generates all the polygons by hand. In standard cell or gate array designs, the gates are already designed, all the polygons pushed and the behaviour is characterized and a synthesis tool can use the library to infer gates and the P&R tool is used to place the gates and route the connectivity. hth, Muzaffer Kal http://www.dspia.com DSP algorithm implementations for FPGA systemsArticle: 38112
The difficulty with RNS lies in converting to and from RNS so that you can use
inputs from other parts of the system and be able to use the outputs. The fast
carry chain in the Xilinx parts gives you all the carry logic for free (no
additional LUTs are needed), and is considerably faster and smaller than
conventional arithmetic done with other carry structures. As it turns out, the
built in fast carry chains make it so that RNS has little to offer in terms of
both performance and area in FPGAs that have the fast carry structures.
jacky Renaux wrote:
> I
>
> DOes any body already working on Residue Number Systems , a kind of arithmetic
> which handle large numbers avoiding large carry propagation (a locations
> constraints )
> I would like to share advices from you
>
> thanks
>
> jacky
>
> --
> Use our news server 'news.foorum.com' from anywhere.
> More details at: http://nnrpinfo.go.foorum.com/
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 38113
32 bit carry chains at 100MHz is possible in a SpartanII-5, but you do have to
watch the loading of the input signals as well as the placement of the
flip-flops driving the inputs relative to the carry chain. For this performance
you don't want any combinatorial logic driving the LUTs which feed the carry
chain, and you want the flip-flops driving the carry chain immediately adjacent
to the least signficant luts they are driving. In your case, you have two reset
signals OR'd together. These may or may not be connecting directly to the
flip-flop reset pins (check it in the FPGA editor or if you have an edif to
schematic converter or equivalent you can check it there). Quite often, the
reset logic, when specified like this will result in an additional layer of
logic between the carry chain and the flip-flops.
Also check the count enable connections, which ideally should connect to the
flip-flop CE input. With 32 bits, your loading of the clock enable or reset
signals can significantly slow the propagation of those signals. If they are
feeding into the LUT before the carry chain, that prop delay adds to the 5+ ns
delay for the carry chain. For best performance, you should duplicate the
control signals so that each copy only drives a few bits. Finally, the routing
delay has to be minimized, which is done by floorplanning so that the registers
driving inputs in your counter are immediately adjacent to the counter bits
where they are used.
A 32 bit non-loadable counter is alot easier than more complicated carry chain
functions, as it can be arranged so that the controls are all after the carry
chain. The ideal construction (for maximum performance) for this counter uses
FDRE primitives with the combined reset signal fed to the FDRE R pin, the count
enable to the CE pin. The carry chain luts are simply buffers to feedback the
counter's current value. THe MUxcy D inputs are all '0' and the LSB's CIN is
hardwired to '1'. This avoids any high fanout signals having to propagate
through the carry, and has all the carry chain inputs coming from the same slice
that they drive. The last remaining thing here would be to register the
combined reset and use that instead of using the OR directly. It may mean
changing the logic that produces the reset signals to make them happen a clock
earlier to compensate for the addtional clock delay.
I have found that frequently, it is less effort to go ahead and instantiate the
components in a generate statement rather than trying to coax the synthesizer
into inferring the correct construction for things like this. That has the
added benefit of allowing you to put the floorplanning in the code too. Here is
the generate code for the instantiated and placed counter:
signal cy:std_logic_vector(32 downto 0);
begin
cy(0)<='1';
CNTR:for i in 0 to 31 generate
constant rloc_str : string := "R" & itoa( ((width-1)/2)-(i/2)) & "C0" &
".S" & itoa(slice mod 2);
signal s:std_logic;
attribute RLOC of U1 : label is rloc_str;
attribute RLOC of U2 : label is rloc_str;
attribute RLOC of U3 : label is rloc_str;
begin
U2: MUXCY port map (
O => cy(i+1),
CI => cy(i),
DI => '0',
S => q(i) );
U3: XORCY port map (
O => s,
CI => cy(i),
LI => q(i) );
U1: FDRE port map (
Q => q(i),
D => s,
R => Reset,
CE => ce,
C => clk );
end generate CNTR;
Falk Brunner wrote:
> "Jason Berringer" <jberringer@trace-logic.com> schrieb im Newsbeitrag
> news:IJ5Z7.12027$A67.3131096@news20.bellglobal.com...
>
> >
> > library ieee;
> > use ieee.std_logic_1164.all;
> > use ieee.std_logic_unsigned.all;
> >
> > entity counter is
> > generic(width : integer := 32);
> > port(
> > clk : in std_logic;
> > cnt_clr : in std_logic;
> > cnt_enable : in std_logic;
> > reset : in std_logic;
> > cnt_out : out std_logic_vector(width-1 downto 0)
> > );
> > end counter;
> >
> > architecture RTL_counter of counter is
> >
> > signal countL : std_logic_vector(cnt_out'range);
> >
> > begin
> >
> > P1: process (reset, cnt_clr, clk, cnt_enable) begin
> > if (reset = '1' or cnt_clr = '0') then
> > countL <= (others => '0');
> > elsif (rising_edge(clk)) then
> > if (cnt_enable = '1') then
> > countL <= countL + 1;
> > end if;
> > end if;
> > end process;
> >
> > cnt_out <= countL;
> >
> > end RTL_counter;
>
> As far as I can see, this simple ce'ed counter should run @100 Mhz, even in
> a Spartan-II-5. Just compile the counter alone and look at the timing
> report. It should clearly say tha clk can be faster than 10ns. Often, the
> timing analyzer is doing wiered things (not at all, false paths are more the
> problem here) and it looks like the circuit is too slow.
>
> --
> MfG
> Falk
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 38114Hi everyone where can I find an indepth manual about P&R in Quartus II ? thank in advanceArticle: 38115
when i simulate with modelsim5.5e,it says:
# testbench
# vsim -lib work -t 1ps -L xilinxcorelib_ver -L unisims_ver -L simprims_ver -foreign {hdsInit f:/eda_tools/resources/downstream/modelsim/ModelSim_32Bit.dll} -pli f:/eda_tools/resources/downstream/modelsim/ModelSim_32Bit.dll testbench glbl
# Loading f:/eda_tools/resources/downstream/modelsim/ModelSim_32Bit.dll
# Loading work.testbench
# ERROR: Could not open library xilinxcorelib_ver at xilinxcorelib_ver: No such file or directory
# ERROR: Could not open library unisims_ver at unisims_ver: No such file or directory
# ERROR: Could not open library simprims_ver at simprims_ver: No such file or directory
# Loading work.NA_Message_Generate
# ERROR: Could not open library xilinxcorelib_ver at xilinxcorelib_ver: No such file or directory
# ERROR: Could not open library unisims_ver at unisims_ver: No such file or directory
# ERROR: Could not open library simprims_ver at simprims_ver: No such file or directory
# Loading work.NA_Message_Receive
# ERROR: Could not open library xilinxcorelib_ver at xilinxcorelib_ver: No such file or directory
# ERROR: Could not open library unisims_ver at unisims_ver: No such file or directory
# ERROR: Could not open library simprims_ver at simprims_ver: No such file or directory
# Loading work.na_fifo16_256
# ERROR: Could not open library xilinxcorelib_ver at xilinxcorelib_ver: No such file or directory
# ERROR: Could not open library unisims_ver at unisims_ver: No such file or directory
# ERROR: Could not open library simprims_ver at simprims_ver: No such file or directory
# Loading work.SYNC_FIFO_V3_0
# ERROR: Could not open library xilinxcorelib_ver at xilinxcorelib_ver: No such file or directory
# ERROR: Could not open library unisims_ver at unisims_ver: No such file or directory
# ERROR: Could not open library simprims_ver at simprims_ver: No such file or directory
# Loading work.MEM_BLK
# Loading work.glbl
after i compile xilinx lib,there is not simprims_ver/xilinxcorelib_ver /unisims_ver directory.why?
Article: 38116Did you read through the Quartus II tutorial? Altera's device datasheets should give you some insight into device architectures. Kevin Brace (don't respond to me directly, respond within the newsgroup) ssy wrote: > > Hi everyone > > where can I find an indepth manual about P&R in Quartus II ? > > thank in advanceArticle: 38117
Hello, I am currently in a project which uses Spartan FPGA and need to know how to program it. Can I make my own version of the Parallel Cable III and use it to program via the JTAG pins(i have a schematic from the xilinx website). Or if I decide to use a Serial PROM ,how can i get it programmed?...is a ciruit schematic avaiable for the same? Or are there any other programming options that i havent considered? Reply soon.Article: 38118
divya wrote:
>
> HI,
> I WANT TO KNOW WHERE I CAN GET INFORMATION ON HOW TO DO FLOORPLANNING
> IF POSSIBLE WITH EXAMPLES.
> DIVYA
I don't claim to be some kind of expert of Xilinx floorplanner,
but no one else seems to comment on it, so I will throw in my two cents.
Before you start floorplanning your design, you probably should ask
yourself if it is really necessary to floorplan your design.
It is possible that it might still be possible to improve timings of
your design by modifying your RTL code.
What I learned from doing manual floorplanning is that floorplanner is
not a magic tool like the synthesis tool (Does anyone still believe that
synthesis tool is a magic tool that generates optimized circuit? I used
to think that way, but ever since I got into floorplanning, I no longer
think so.), and only potentially reduces routing delays if done
correctly, but won't reduce LUT delays at all.
Modifying your RTL code, using different synthesis options, or using a
different synthesis tool is the only way you can reduce LUT delays, and
sometimes, it is better modifying your RTL code first before
floorplanning because sometimes it is just impossible to meet specified
timings only by manual placement, and some LUT delays also has to be
eliminated.
As far as I know (I haven't checked Xilinx website in detail),
Xilinx doesn't seem to really have a nice application note explaining
how to do floorplanning.
It seems to me that the Floorplanner manual is the only source of
information, but Floorplanner manual only covers how to use the tool,
and not the floorplanning strategies on how to do it.
First of all, having no experience using Floorplanner or any similar
tool, what I first did was reading the Floorplanner manual.
I guess the trick I learned here is not trying to learn every features
when you read the manual for the first time.
Just get to know how to place a LUT or a FF to a desired location, how
to constrain LUTs and FFs to certain area, and learn more features as
you get more familiar with the tool.
Use .UCF flow if you are using the tool for the first time, because I
found .UCF flow easier to use than the regular flow.
Assuming that you are targeting a Virtex architecture device
(Virtex/Virtex-E/Spartan-II/Spartan-IIE. Virtex-II architecture is
similar to Virtex, but has 4 Slices per CLB), the first thing you should
do is to download or order the device datasheet.
In the device datasheet, Xilinx gives you some idea of what the chip's
routing structure is like, but in my opinion, they should provide more
diagrams of the internal routing structure and routing delay numbers
(Altera's manuals are far better in this area).
Although, I suppose if I had access to FPGA Editor, I probably can see
what the internal routing structure is like . . . (I am a poor ISE
WebPACK 4.1 user).
A report generated by TRACE or Timing Analyzer should give you a picture
of what the routing delay numbers are in a Virtex architecture.
From the routing delay numbers I saw in a Timing Analyzer
report, LUT connections within the same Slice is the fastest (worst case
0.222ns for Spartan-II XC2S150-5CPQ208 at 85 degrees Celsius) for a LUT
to LUT routing delay.
Then the second fastest routing delay will be LUT connections between
Slices within the same CLB (I believe it is about 0.385ns).
The third fastest will be routing delay between horizontally adjacent
CLBs, and I thought it was about 0.456ns.
After that, if I am correct, all routings will go out to the GRM
(General Routing Matrix) which I understand is generally called a switch
matrix or a switch box.
Routing delay starts to get large when an interconnect has to go out to
a switch matrix.
I think a LUT to LUT interconnect delay is about 0.8ns to 0.9ns between
vertically adjacent CLBs.
Going to a LUT a few CLBs away horizontally or vertically can take 1.2ns
to 1.4ns, but this can depend on how the routing congestion is like.
If you read a Timing Analyzer report carefully, you might notice that
when a signal has to travel long distance, for example, from near an
input pin to an IOB output FF or tri-state control FF, it doesn't take
"that" much of time compared to moving a signal from one LUT to another
LUT a few CLBs away horizontally or vertically.
I don't have access to FPGA Editor, so I don't know for sure, but it
seems like P&R (Place & Route) tool automatically selects a long wire
which can transfer a signal fast when that signal has to travel long
distance.
So, summarizing what I say, here are the strategies on how to floorplan
a design for Virtex architecture.
* Keep LUTs as close as possible. Keep them within a CLB if possible,
and if that is not, place them horizontally adjacent to each other.
* Avoid placing LUTs a few CLBs away.
* If two LUTs cannot be placed closed to each other because a signal has
to travel from near an input pin to an IOB output FF or tri-state
control FF, place one of the
LUT closer to the IOB FF near the IOB.
I think the key of improving performance in Virtex architecture is to
keep relevant LUTs as close as possible to each other, however, MAP
doesn't seem to do a good job of finding the right combination of LUTs
to merge within a CLB.
A designer with some knowledge of Virtex architecture can do a better
job than MAP in my opinion.
I suppose a tool like Synplicity's Amplify perhaps finds the right
combination of LUTs to merge within a CLB, but I will rather see Xilinx
implementing a feature that will use the previous place and route
information to find a better combination of LUTs to merge in MAP.
Currently, I don't believe such a feature is implemented, but if
implemented, I am sure that full automatic design (no handplacing was
used) should get at least 10% improvement in timings by just
recompiling.
Also, another feature I will like to see added is priority mapping,
placement, and routing for user specified critical path signals (like
for signals entering the chip unregistered that goes towards IOB FF).
I am sure there are other people out there who know better than
me regarding floorplanning, so if someone else know better ways to do
floorplanning, let me know.
Kevin Brace (don't respond to me directly, respond within the newsgroup)
Article: 38119
renjini wrote:
>
> Hi
> i want some information on xilinx floorplanning .i will be glad if u
> could get me some information on this
> renjini.k
I don't claim to be some kind of expert of Xilinx floorplanner,
but no one else seems to comment on it, so I will throw in my two cents.
Before you start floorplanning your design, you probably should ask
yourself if it is really necessary to floorplan your design.
It is possible that it might still be possible to improve timings of
your design by modifying your RTL code.
What I learned from doing manual floorplanning is that floorplanner is
not a magic tool like the synthesis tool (Does anyone still believe that
synthesis tool is a magic tool that generates optimized circuit? I used
to think that way, but ever since I got into floorplanning, I no longer
think so.), and only potentially reduces routing delays if done
correctly, but won't reduce LUT delays at all.
Modifying your RTL code, using different synthesis options, or using a
different synthesis tool is the only way you can reduce LUT delays, and
sometimes, it is better modifying your RTL code first before
floorplanning because sometimes it is just impossible to meet specified
timings only by manual placement, and some LUT delays also has to be
eliminated.
As far as I know (I haven't checked Xilinx website in detail),
Xilinx doesn't seem to really have a nice application note explaining
how to do floorplanning.
It seems to me that the Floorplanner manual is the only source of
information, but Floorplanner manual only covers how to use the tool,
and not the floorplanning strategies on how to do it.
First of all, having no experience using Floorplanner or any similar
tool, what I first did was reading the Floorplanner manual.
I guess the trick I learned here is not trying to learn every features
when you read the manual for the first time.
Just get to know how to place a LUT or a FF to a desired location, how
to constrain LUTs and FFs to certain area, and learn more features as
you get more familiar with the tool.
Use .UCF flow if you are using the tool for the first time, because I
found .UCF flow easier to use than the regular flow.
Assuming that you are targeting a Virtex architecture device
(Virtex/Virtex-E/Spartan-II/Spartan-IIE. Virtex-II architecture is
similar to Virtex, but has 4 Slices per CLB), the first thing you should
do is to download or order the device datasheet.
In the device datasheet, Xilinx gives you some idea of what the chip's
routing structure is like, but in my opinion, they should provide more
diagrams of the internal routing structure and routing delay numbers
(Altera's manuals are far better in this area).
Although, I suppose if I had access to FPGA Editor, I probably can see
what the internal routing structure is like . . . (I am a poor ISE
WebPACK 4.1 user).
A report generated by TRACE or Timing Analyzer should give you a picture
of what the routing delay numbers are in a Virtex architecture.
From the routing delay numbers I saw in a Timing Analyzer
report, LUT connections within the same Slice is the fastest (worst case
0.222ns for Spartan-II XC2S150-5CPQ208 at 85 degrees Celsius) for a LUT
to LUT routing delay.
Then the second fastest routing delay will be LUT connections between
Slices within the same CLB (I believe it is about 0.385ns).
The third fastest will be routing delay between horizontally adjacent
CLBs, and I thought it was about 0.456ns.
After that, if I am correct, all routings will go out to the GRM
(General Routing Matrix) which I understand is generally called a switch
matrix or a switch box.
Routing delay starts to get large when an interconnect has to go out to
a switch matrix.
I think a LUT to LUT interconnect delay is about 0.8ns to 0.9ns between
vertically adjacent CLBs.
Going to a LUT a few CLBs away horizontally or vertically can take 1.2ns
to 1.4ns, but this can depend on how the routing congestion is like.
If you read a Timing Analyzer report carefully, you might notice that
when a signal has to travel long distance, for example, from near an
input pin to an IOB output FF or tri-state control FF, it doesn't take
"that" much of time compared to moving a signal from one LUT to another
LUT a few CLBs away horizontally or vertically.
I don't have access to FPGA Editor, so I don't know for sure, but it
seems like P&R (Place & Route) tool automatically selects a long wire
which can transfer a signal fast when that signal has to travel long
distance.
So, summarizing what I say, here are the strategies on how to floorplan
a design for Virtex architecture.
* Keep LUTs as close as possible. Keep them within a CLB if possible,
and if that is not, place them horizontally adjacent to each other.
* Avoid placing LUTs a few CLBs away.
* If two LUTs cannot be placed closed to each other because a signal has
to travel from near an input pin to an IOB output FF or tri-state
control FF, place one of the
LUT closer to the IOB FF near the IOB.
I think the key of improving performance in Virtex architecture is to
keep relevant LUTs as close as possible to each other, however, MAP
doesn't seem to do a good job of finding the right combination of LUTs
to merge within a CLB.
A designer with some knowledge of Virtex architecture can do a better
job than MAP in my opinion.
I suppose a tool like Synplicity's Amplify perhaps finds the right
combination of LUTs to merge within a CLB, but I will rather see Xilinx
implementing a feature that will use the previous place and route
information to find a better combination of LUTs to merge in MAP.
Currently, I don't believe such a feature is implemented, but if
implemented, I am sure that full automatic design (no handplacing was
used) should get at least 10% improvement in timings by just
recompiling.
Also, another feature I will like to see added is priority mapping,
placement, and routing for user specified critical path signals (like
for signals entering the chip unregistered that goes towards IOB FF).
I am sure there are other people out there who know better than
me regarding floorplanning, so if someone else know better ways to do
floorplanning, let me know.
Kevin Brace (don't respond to me directly, respond within the newsgroup)
Article: 38120My company has a large inventory of boards that have a 40 pin DIP socket that was originally meant for another chip. My new need is to run an equivalent (opcode compatable) 8051 @ 5 Mhz plus some glue and a couple of other oddball things. Ideally I would like to use a device that is also a 40 pin DIP so that I can use the boards. I am brand-new to the PLD/FPGA arena but have about 20 years of EE experience. After a quick search around the web I found the Atmel ATV2500, a 40 pin DIP PLD (data sheet is at http://www.atmel.com/atmel/acrobat/doc0249.pdf). Since I'm so new to this I have no idea of how to estimate if this thing is remotely capable of meeting my logic requirements. Any input, URLs, etc. is appreciated. TIA. - StoutArticle: 38121
Stout wrote: > > My company has a large inventory of boards that have a 40 pin DIP > socket that was originally meant for another chip. My new need is to > run an equivalent (opcode compatable) 8051 @ 5 Mhz plus some glue and > a couple of other oddball things. Ideally I would like to use a > device that is also a 40 pin DIP so that I can use the boards. > > I am brand-new to the PLD/FPGA arena but have about 20 years of EE > experience. > > After a quick search around the web I found the Atmel ATV2500, a 40 > pin DIP PLD (data sheet is at > http://www.atmel.com/atmel/acrobat/doc0249.pdf). Since I'm so new to > this I have no idea of how to estimate if this thing is remotely > capable of meeting my logic requirements. Any input, URLs, etc. is > appreciated. TIA. > > - Stout A strange target, this one :-) What chip did the 40 pin socket target ? Do you mean you hope to Implement a 8051 SoftCore+Other things in a ATF2500 ? The answer is NO. ( not by a long shot :) If you already have the 8051 on the board and want the 2500 to do 'some glue and a couple of other oddball things', then yes, that becomes possible. You will see the 2500 does come in DIP40, and has centre Vcc.Gnd, but appart from that, the 24IO and 14IP are very 'swapable'. The Flash ATF2500 is 'advance information', but the ATV2500 is available, and we have used them. So, you could worm the PCB, or make a daughter PCB. If you don't have the 8051, and these PCBs are 'really expensive', then I'd look at a daughter PCB using TQFP44 89S52/53 (& up) + TQFP ATF1502 - both are In System Programmable, and low cost. We have done PCB's like this, and if you make SOME of the DIP40 pins single sided ( not thru hole ), then there is room on the top for TQFP44's and it keeps small mechanically. -jg -- ======= 80x51 Tools & IP Specialists ========= = http://www.DesignTools.co.nzArticle: 38122
Hi Kevin I look at the tour of Quartus II it contain the following info: 1 view fit in floorplan editor 2 editng assignment but these is not enough I want to know the methodology, not only the operations, that is to say, not only how to perform these operations, but also why and how to use all these operations thank you in advance Kevin Brace <nospamtomekevinbraceusenet@nospamtomehotmail.com> wrote in message news:<a18oti$4q7$1@newsreader.mailgate.org>... > Did you read through the Quartus II tutorial? > Altera's device datasheets should give you some insight into device > architectures. > > > > Kevin Brace (don't respond to me directly, respond within the newsgroup) > > > > > ssy wrote: > > > > Hi everyone > > > > where can I find an indepth manual about P&R in Quartus II ? > > > > thank in advanceArticle: 38123
"Nachiket Kapre" <nachikap@yahoo.com> schrieb im Newsbeitrag news:eadce17c.0201052213.146ca927@posting.google.com... > Hello, > I am currently in a project which uses Spartan FPGA and need to know > how to program it. Can I make my own version of the Parallel Cable III > and use it to program via the JTAG pins(i have a schematic from the > xilinx website). Or if I decide to use a Serial PROM ,how can i get it Yes, this is one option. > programmed?...is a ciruit schematic avaiable for the same? Or are This is the second one. The circuit is available in the datasheets. > there any other programming options that i havent considered? You can use an embedded microcontroller to configure the FPGA. Dont let Xapp58 confuse you, doing a simple slave serial mode configuration is MUCH simpler and faster. All you have to do is to clock in the data bit by bit (or byte by byte) and thats almost all. The configuratio sequence is described in the datasheets and some Xapps. -- MfG FalkArticle: 38124
In article <3C36C682.3D6F4035@algor.co.uk>, Rick Filipkiewicz wrote: > There's also something on the budgetary side that's been missed out. ASIC design tools > (synthesisers, simulators, layout tools, etc.) are MUCH more expensive than the > corresponding ones for FPGAs. I believe its normal in ASIC design to have several > "seats" for each of these wich is going to burn another couple of $100K of investment. The price difference is going smaller all the time as FPGA designs are getting bigger and bigger and actually require same tools as the ASIC design. Physical synthesis tools for FPGAs are not cheap. And I don't understand how simulators are chaper for FPGA, they are the same as with ASICs. Logic simulators don't care wheter it is FPGA or ASIC. Also layout tools are not necessary in ASIC design, many layouts are done by the vendor and the signoff is netlist based. Of course this costs more than just buying silicon process, but also reduces the risks, there is no need to do own test silicons to test special blocks etc. I think the main reason to go with ASIC is speed and capacity (and price also that is connected to the capacity). It's quite easy to get 3-5x more speed with ASICs compared to even fastest FPGAs. In reality some structures are very bad for FPGAs, for example complex multiplexer structures kill FPGAs (even if you use tricks like 3-state busses etc.). Sometimes the gates needed in ASIC is 10x less even if you count with "real" FPGA gates. Also the internal memories of FPGAs are very small compared to what you can create with ASICs. And FPGA price is a huge problem if any volume is planned without reduced functionality. VirtexII 6000 for example is very expensive chip, and you need quite big pile (~10) of them to replace big 0.13u ASIC. And think about the power consumption of those 10 FPGAs and the problems to do PCB layout for 10 big chips.
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