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
Thank you Brian.
The problem was, the netgen always crashed when I attempted to write a
hierarchical netlist.
I was doing some partial reconfigurable design in V2-6000.
I asked this crash question in this ng also but I can't solve that so fat.
Flattening was my
last resort.
Kelvin
"Brian Philofsky" <brian.philofsky@no_xilinx_spam.com> wrote in message
news:cerpdb$li15@xco-news.xilinx.com...
>
>
> Eyck Jentzsch wrote:
> > Hi Kevin,
> >
> > Kelvin wrote:
> >
> >> Hi, there:
> >>
> >> My Xilinx software generated a flattened netlist and SDF each over
> >> 100MB...Now NC_Verilog
> >> takes hundreds of hours to simulate that.
> >>
> >> Now if I write a perl to replace all the long wire names with some
random
> >> 10-alphabet string,
> >> it will probably shrink the file size to 10MB...But will that make my
> >> simulation faster?
> >> ---sample
> >> wire
> >>
\modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> >>
> >> 0)/F ;
> >> wire
> >>
\modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> >>
> >> 0)/G ;
> >>
> >>
> >> Thanks.
> >> Kelvin
> >>
> >>
> >>
> > This will not help much, it will just speedup the simulation startup
> > because of less file reading.
> > It will help more to check if you used all performance switches (and
> > aviod performance degrading options like +access+rwc or linedebug ;-)).
> > The online documentation (cdsdoc) has a dedicated chapter ('Maximising
> > simulation performance') for it.
> > HTH
> >
> > -Eyck
> >
>
> I agree with what has been said here but offer another possible
> suggestion to help out with this situation. Why are you flattening the
> netlist? If you keep some hierarchy (some not all of it), it will
> likely allow you to better manage the simulation in multiple ways.
> First, that will likely shrink many of the signal names you are having
> problems with as the hierarchy is no longer needed to be preserved into
> each individual signal name. Second, it would allow you to set
> accessibility to separate portions of the design by allowing you to
> specify the optimizing of portions you are not currently debugging and
> allowing visibility to the portions you are. Third, you can do a full
> timing simulation of part of your design so rather than trying to
> simulate the whole thing at once, you could do it in pieces. This not
> only makes for smaller and usually faster simulations but also can allow
> the re-use of sub-level testbenches, allow for parallel simulations (if
> you have more licenses available), uses less memory/less machine
> requirements, easier debug since it is smaller and better understood,
> and a handful of other benefits. Fourth, you could replace the portions
> of the design you are not currently trying to perform a timing
> verification on with behavioral or RTL code thus doing a mixed
> behavioral/RTL/Timing simulation which should perform much better than a
> full structural simulation.
>
> At some point in the design, it is always beneficial to do a full
> netlist timing simulation as it can detect problems that can be easily
> missed in functional simulation and static timing analysis (even in
> fully synchronous designs) however that is generally best done at the
> very end of the design cycle. Much of the timing verification can many
> times be done more efficiently in pieces by retaining the hierarchy and
> using it in this phase of verification. For information on hierarchy
> preservation for simulation, look at Chapter 6 in the Synthesis and
> Verification design Guide, the section titled, "Design Hierarchy and
> Simulation":
> http://toolbox.xilinx.com/docsan/xilinx6/books/docs/sim/sim.pdf
>
> Hope this helps.
>
> -- Brian
>
Article: 71976rickman wrote: <snip> > I have one socket on a board that Xilinx could not fill. I needed 5 > volt compatibility in a relatively low power device. All of the newer > (read supported by current software) devices that are 5 volt tolerant > have a power on current surge that makes it hard to use in a low power > design without extra circuitry. So I ended up using an Altera ACEX > (EP1K) device which is only about 3-4 years old. Otherwise their newer > chips are mostly similar. .. Perhaps the new Virtex-4 that Peter A. is dying to tell us about also solves the 5V i/o issues ;) -jgArticle: 71977
Hi Sumit, Yes, X vs. A can turn into a holy war, resulting in frustration on all sides :-) The easiest way to answer this question is to take your design and compile it in both Xilinx and Altera's tools. We both have freely available versions of our software. Quartus II Web Edition targets Cyclone and Stratix devices so that you can try them out. You'll want to figure out what the cheapest device is that your design fits into and still meets its performance target(s). Don't use the "auto device selection" feature alone -- use it to get an idea, then try picking a smaller device until your design no longer fits. Look at the timing margin you have, and reduce speed grades if possible. You'll also want to look at the data sheets to read about additional features (PLL/DCMs, DSP/Multipliers, memories, etc) that you think you may need. And in the end, everything comes down to price and availability. All that matters to you is how much the chip will cost you in the volume you need it. And depending on your risk tolerance, you may want to opt for more mature families that have ready availability. For this type of information, you'll need to contact your distributor or FAE/FSE from each company. Word of caution: Do not use "toy" designs to compare devices or software. Running 16-bit adders or my_little_cpu.v through two tools will not give you an accurate picture of how the devices and software behave on "real" designs. Regards, Paul Leventis Altera Corp.Article: 71978
> Thanks for your reply Thomas. I guess I should ask the question in a > different way: for devices from different vendors with the same number > of gates, will I get better performance and/or cost from a Flash or a > SRAM based FPGA ? Also, I assume that the comment about usability of > Xilinx cells being low is related to routability ? Is it any better > with the Altera/Actel etc parts ? As another poster has indicated, Flash-based devices are just SRAM FPGAs with an integrated Flash IP block. This removes the need for a stand-alone EEPROM/Flash chip for configuration, and can provide a higher bandwidth Flash-to-SRAM connection enabling faster configuration times, giving a "instant-on" capability. The downside of Flash is that you are stuck on a Flash process. Flash processes are behind standard CMOS processes -- I think I've seen 0.13u Flash talked about somewhere in EETimes, but that's about the best you get these days, and its immature. We've opted to include an on-die Flash memory in our Max II family of CPLDs. These devices can't really take advantage of cutting-edge process technology due to pad limitation and voltage/power requirements of the target market, so the process "penalty" isn't an issue. And CPLD users want a simple, one-chip solution and instant-on capabilities. To first order, chips manufactured in smaller process geometries are faster -- our 90 nm Stratix II family is ~50% faster than our 130 nm Stratix family. However, comparing two chips with different architecture (Stratix vs. Virtex II, Cyclone vs. Spartan 3) by using process technology is not going to necessarily give the right answer. For example, we find that Cyclone is significantly faster than Spartan-3, despite being manufactured on 130 vs. 90 nm. This can be due to numerous reasons -- power vs. speed trade-offs, software quality, architectural advantages, etc. The bottom line is you have to try out your design on the chips in question (via the software) to really know. As for usability/routability, Altera's FPGAs are designed to be routable at 100% utilization (both LUTs and registers) for all but the hairiest of designs. I don't have any first-hand knowledge of the routability of competitors parts and thus will not comment on that. Regards, Paul Leventis Altera Corp.Article: 71979
"Adrian" <adrian@nospam.com> wrote in message news:4104F20D.4090004@nospam.com... > Hi all, > > > I have just made the last release 0.7 of the freeware WinFilter > available on the web. > http://www.winfilter.20m.com > > WinFilter is a software tool provided as freeware to design digital > filter. A GUI makes it very user friendly. This software can design as > well IIR filters as FIR filters and can generate the C and VHDL code. > > The filter coefficients are now quantizied in float, 16-bit or 8-bit. > FIR filter are now synthezis in VHDL (speed or size optimization) with a > Resources Usage Estimation. > > Cheers, > Adrian > > > > -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- > http://www.newsfeeds.com - The #1 Newsgroup Service in the World! > -----== Over 100,000 Newsgroups - 19 Different Servers! =----- Is this available for download? I cannot see the link on the page for download? Thanks TomArticle: 71980
Has anyone seen output pins cause a design to randomnly fail? I have a very solid design that I accidently left two OBUFs with no ucf LOC contraint. depending how much i fill a v2pro device my logic will fail seemingly randmonly with these two OBUFs instantiated. I know that the randomn locations that ISE is choosing is not colliding with anything on my board but the design fails consistenly. Thoughts? MattArticle: 71981
On Wed, 04 Aug 2004 14:32:06 -0700, Austin Lesea <austin@xilinx.com> wrote: >By the way, I found out today that there is a public domain software >tool that converts IBIS back into spice, so you could then run the IBIS >model under a spice simulator that doesn't already support IBIS (like a >public domain spice program). Hi Austin, Could you please post a link to this tool? Thanks, Allan.Article: 71982
Thank you very much Joe! The /tmp idea is interesting. Kelvin "Joe" <joe_y@invalid_address.nospam.com> wrote in message news:cern4o$oua$1$8300dec7@news.demon.co.uk... > Kelvin wrote: > > Hi, there: > > > > My Xilinx software generated a flattened netlist and SDF each over > > 100MB...Now NC_Verilog > > takes hundreds of hours to simulate that. > > > > Now if I write a perl to replace all the long wire names with some random > > 10-alphabet string, > > it will probably shrink the file size to 10MB...But will that make my > > simulation faster? > > ---sample > > wire > > \modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1 > > 0)/F ; > > wire > > \modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1 > > 0)/G ; > > > > > > Thanks. > > Kelvin > > > > > > > > Hi Kelvin, > > In case your data files are store on a file server and the simulation is > executed by a separate server, the link between the two servers can be a > bottle neck. > > In SDF simulation the simulator access to the compiled binary files a > lot, so it is better to put all the files in the same machine that you > run simulation on. > > A lot of UNIX machines have /tmp directory that are accessible by > everyone, and it is possibly not mount to the file server. So you might > try to copy your files to /tmp directory and run the simulation from > there. (But don't tell your sys admin :-> ) > > Also try run the simulaion in command mode and redirect stdout to a file > instead of output to display. (messaage display can be another bottle neck). > > Joe >Article: 71983
daragoth@kuririnmail.com (Daragoth) wrote in message news:<317379a8.0408041333.cd5ec11@posting.google.com>... > Peter Alfke <peter@xilinx.com> wrote in message news:<BD34280A.7CD7%peter@xilinx.com>... > > I know (from my own experience) that it is tempting to design something > > small and neat. But I have also seen many failures when there just was not > > enough room to complete the design properly. > > My advice is: Think twice ( or thrice) before committing to a very tight > > footprint. > > Peter Alfke > > Thanks for the advice Peter, but unfortunately this isn't an option > for me. The space that the board must go in has already been > determined; it must be 40x30x10 mm in volume. I'm surprised that Peter didn't mention that Xilinx has a Spartan 3 in a 100 pin thin flat pack that measures 16 mm on a side (maybe Peter better look at his own data sheets!). The thickness is 1.6 mm, so it looks like you can do what you want to do (but it will be a custom). TomArticle: 71984
That's a very realistic description. I can verify this from my experience. Especially, if you're unexperienced with VHDL design, it will save a lot of time and make the result more reliable. BernhardArticle: 71985
Matthew E Rosenthal wrote:
> Has anyone seen output pins cause a design to randomnly fail?
>
> I have a very solid design that I accidently left two OBUFs with no ucf
> LOC contraint. depending how much i fill a v2pro device my logic will
> fail seemingly randmonly with these two OBUFs instantiated.
>
> I know that the randomn locations that ISE is choosing is not colliding
> with anything on my board but the design fails consistenly.
Howdy Matt,
First off, what do you mean by fail? Does PAR or MAP stop? Or does it
make it through the tools and then somehow not work when you put it on
the board?
I'm assuming you meant MAP or PAR would abort... in which case, I've had
situations like that before. It seems like the tool isn't especially
smart about how it assigns locations of things (especially GBUFs and
DCMs) and walks itself into a corner it can't get out of. I seem to
recall also having some problems with IOBs from time to time - it is as
if the tools sometimes pick pins but ignore the banking rules. Then
later, it detects the rule violation and stops. Again, this is from
memory, so I may be remembering the situation incorrectly.
But since you have a board, you want all the pins nailed down, right?
Have fun,
Marc
Article: 71986Hi Allan, > Obviously rules of thumb are based around certain assumptions. You > need to know how fast your chip is (w.r.t. your clock rate), whether > you are doing floorplanning, etc. You are right. It depends on device, required clock rate, design etc. How do you control fan-out? Is it through a tool-setting or through coding style itself? > Note that FPGA flip flops are basically free. Don't be afraid to use > them to make the routing easier. This is not very clear. Do you mean that we should insert registers in the paths in the RTL code? > This one is fairly good, although floorplanning (good or bad) can make > a difference. Note that a tightly packed part will often produce a > few excessively long delays due to routing congestion. Is there a thumb rule with respect to device occupancy? Should it be restricted to say 75% of the device so that routing does not get congested? Thanks, Kiran.Article: 71987
Hello, Peter Alfke <peter@xilinx.com> wrote: > > - Area (usability of cells, e.g. Xillinx wouldn't allow you to use > > 100% of the cells) > This is utter nonsense. There is nothing wrong with using 100% of the logic > resources, if the routing structure supports this. And that depends on the > design style. Newer families have considerably more routing than the old > ones. Whether a design is logic- or routing-limited has nothing to do with > the particular manufacturer. Nice to hear, that newer Xilinx Fpgas allow 100% usage. My experience based on several designs for XC4k to Virtex-E says, that 100% is no practical number. I got routing problems at about 66% doing an XCV1000. As unexperienced beginner I would have said, that a XCV800 should do if I have less than 70% fpga useage on an XCV1000. I mentioned Xilinx, because I can't say a word about Altera or other SRAM based fpgas. But if you choose an fpga, you should have in mind, that you might end up in mess, if you choose a device because marketing told you it's big enough. And reducing the design, just because your design is too big for an device is a very nasty and errorprone task. bye ThomasArticle: 71988
On 4 Aug 2004 23:27:02 -0700, kirandev@msn.com (Kiran) wrote: >Hi Allan, > >> Obviously rules of thumb are based around certain assumptions. You >> need to know how fast your chip is (w.r.t. your clock rate), whether >> you are doing floorplanning, etc. > >You are right. It depends on device, required clock rate, design etc. > >How do you control fan-out? Is it through a tool-setting or through >coding style itself? I use coding style. For example, if my source code has a signal feeding eight other LUTs, I know that the fanout is eight. Note that for most designs (which aren't pushing the technology to the limits) it's quite reasonable to ignore fanout in your source code and rely on the fanout limit in your synthesiser. This should have a default of 50-100 or so. It will replicate logic to maintain this limit. E.g. if the fanout limit is 100 and you have 200 loads on a flip flop, the synthesiser will replicate the flip flop (so that there are two flip flops fed with identical inputs) and each flip flop will drive 100 loads. My experience is that automatic replication makes floorplanning harder. >> Note that FPGA flip flops are basically free. Don't be afraid to use >> them to make the routing easier. > >This is not very clear. Do you mean that we should insert registers in >the paths in the RTL code? Yes. >> This one is fairly good, although floorplanning (good or bad) can make >> a difference. Note that a tightly packed part will often produce a >> few excessively long delays due to routing congestion. > >Is there a thumb rule with respect to device occupancy? Should it be >restricted to say 75% of the device so that routing does not get >congested? The obvious hard limit is 100% (although I once had Maxplus make some FFs out of comb. logic in a CPLD so that I actually used more than 100% of the flip flops in the device!). A practical limit is 50% to 100%. I've never seen anyone suggest a utilisation of less than 50%. There is also a tradeoff with development time. Lower utilisation means faster build times. I've seen projects which have had larger FPGA on the prototypes (to speed code development) and smaller FPGAs on the production units (to lower costs). This is also important if the requirments for your project are not fully understood- you have room to manoeuver during development. A lot depends on your design. It may end up being flip flop limited (which would be unusual in an FPGA, but more common in a CPLD), or it may be block ram limited, etc. My current chip is using most of the block ram but only about 40% of the FFs and logic. YMMV. Regards, Allan.Article: 71989
D. Kruse wrote: > I'm an analog engineer who's familiar with analog PLL's but not with > digital PLL's. I've been searching the internet for the NCO equivalent > of Kvd of an VCO and the Kphi of an 'exclusive or' phase detector. I > thought if I had those, I could use the analog transfer functions to > analyzer a PLL. > > Also, can you point me toward any NCO vendor webpages that would have > some application note using their product in an DPLL. > > Thanks for any help. > > D. Kruse Hello, from my understanding NCO and PLL are two different concepts for freuqncy synthesis. There are no feedback loops in an NCO. http://www.analog.com Search for:Direct Digital Synthesis (DDS) For sure you can combine NCO + PLL in an advanced concept. http://www.commdesignconference.com/archive/papers/2003/W221.htm Regards, AndreasArticle: 71990
Hi, Please let me know some good Verilog to VHDL conversion tools. In case you have tried any please let me know the good/bad part of it :) Regards, VivekArticle: 71991
I can't even open the page. I got the message: "Could not connect to remote server http://www.winfilter.20m.com/" Using Opera or Internet Explorer. Luiz CarlosArticle: 71992
Hi ! I need to create a I2C controller in FPGA and write or rewrite a I2C driver for linux running on xscale. Any idea how? If I use allready written standard HDL code and rewrite the driver or rewrite a HDL code and use linux driver in I2C package? thanks, SasaArticle: 71993
Sasa Bremec wrote: > Hi ! > > I need to create a I2C controller in FPGA and write or rewrite a I2C driver > for linux running on xscale. > > Any idea how? > > If I use allready written standard HDL code and rewrite the driver or > rewrite a HDL code and use linux driver in I2C package? > > > thanks, Sasa > > Why not simply use two GPIO of the XScale for that ... and the linux driver would already been written. SylvainArticle: 71994
Hi Having recently started using EDK. I have ISE 6.2 and eps 6.2 and an Avnet virtexII pro developement board. I downloaded the example PPC example from Xilinx and have yet to get it to work. I have noticed some errors in the UCF but gave up at that point. So i looked at the examples supplied with the avnet board. Fine after updating the projects to 6.2 everything seems to be ok. That is until i change the flow from xps to ise. Following the instructions presented in the xilinx example i can not get it working. I have tried most things but to no avail. Any help would be greatfully recieved Cheers PaulArticle: 71995
Jim Granville wrote: > > rickman wrote: > <snip> > > I have one socket on a board that Xilinx could not fill. I needed 5 > > volt compatibility in a relatively low power device. All of the newer > > (read supported by current software) devices that are 5 volt tolerant > > have a power on current surge that makes it hard to use in a low power > > design without extra circuitry. So I ended up using an Altera ACEX > > (EP1K) device which is only about 3-4 years old. Otherwise their newer > > chips are mostly similar. > > .. Perhaps the new Virtex-4 that Peter A. is dying to tell us about also > solves the 5V i/o issues ;) I can assure you that it does not. The problem is twofold, 1) with the thinner oxides that are being used, it gets harder and harder to provide 5 volt tolerance without adding processing steps which drives up the cost and 2) 5 volt tolerance is becomming less and less important as various standards evolve away from the use of 5 volt interfaces. It has been explained to me several times that in the FPGA world, they had two choices, retain 5 volt tolerance or compete effectively in the high dollar, most current technology markets. -- 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: 71996
Robert, The Xilinx LVDS inputs include 2.5V CML signals in their common mode range, just about. Use a resistor pack or two if you're worried! A lot of CML parts also have wide common mode range inputs that can handle the Xilinx LVDS output signals. Check out parts from Micrel and ONsemi. CML has the problem, like PECL, that the output is referred to Vcc. As the geometry shrinks in FPGAs, it's harder to support 3.3V. 5V is already dead. Xilinx have 90nm triple-oxide technology which mitigates some of these problems, but I'd be very impressed if they build a CML and an LVDS output on the same pair of IOBs. The Rocket I/Os with their specialist IOs are one way round the problem. I'd love to see Xilinx make a super-fast FPGA with the fabric based on CML. It would only need to be the size of an old 3020, but could open up a world of possibilities at gigabit rates, when use alongside a large conventional FPGA. Cheers, Syms. "Robert Sefton" <rsefton@nextstate.com> wrote in message news:2ndhdhFvc98vU1@uni-berlin.de... > Thanks, Austin. Not the answer I was hoping for, but I'll figure something out. When will CML be available as a SelectIO > option? Virtex 4? > > RobertArticle: 71997
I was wondering if someone could tell me what is free and what is not. I've purchased (and it's on the way) the $99 Spartan-3 development kit and I'm wondering if any additional expenses are invoked by using the various IP property on xilinx's web pages. LarryArticle: 71998
There was a pop up though, perhaps that broke things for you. "Luiz Carlos" <oen_no_spam@yahoo.com.br> wrote in message news:3fd8f66b.0408050249.77f78a90@posting.google.com... > I can't even open the page. I got the message: > > "Could not connect to remote server > http://www.winfilter.20m.com/" > > Using Opera or Internet Explorer. > > Luiz CarlosArticle: 71999
Dear everybody,
I'm using GNU toolchain for NIOS and I have some problems using the
C++ new
operator. I think my problems depend of my linker script, so I hope
any "guru"
can help me.
I have defined my ".data" section starting at 0xB0000. Once software
is running I'm able to verify that dynamic objects are allocated after
static memory. But,
if I delete one object and allocate it again, the new operator
allocate it at
an address below 0xB0000.
Is my linker script missing of any directive to define the dynamic
memory area ?
In general, how can I define dynamic memory area using ld ?
Below I have attached my linker script. "nasys_data_mem" is equal to
0x80000
I hope someone can help me.
Best Regards
/Alessandro
ENTRY(_start)
SECTIONS
{
/* Read-only sections, merged into text segment: */
. = nasys_data_mem;
/*
* Begin the read-only code section here.
*/
.text :
{
*(.text.prefix) /* Force prefix to be first */
*(.init)
*(.init.*)
*(.text)
*(.text.*)
*(.gnu.linkonce.t*)
} =0
. = ALIGN(4);
_etext = .;
PROVIDE (etext = .);
/*
* Begin the read-only but not-relocated section of
* memory here.
*/
_nasys_rodata = .;
.ctors :
{
_ctors_begin = .;
KEEP (*(.ctors))
_ctors_end = .;
}
.dtors :
{
_dtors_begin = .;
KEEP (*(.dtors))
_dtors_end = .;
}
.rodata :
{
*(.rodata)
*(.rodata.*)
*(.gnu.linkonce.r*)
}
_nasys_rodata_end = .;
/*
* --------------------------------------------------
* the .data section contains initialized and writeable
* variables. If we have separate code & data, we need
* to have it load in code area, but have the symbols
* resolve to the data area.
*/
_nasys_data_source = .;
/*_nasys_data_destination = (nasys_program_mem == nasys_data_mem) ?
_nasys_data_source : nasys_data_mem;*/
_nasys_data_destination = nasys_data_mem + 0x30000;
.data _nasys_data_destination : AT (_nasys_data_source)
{
_data = .;
*(.data)
*(.data.*)
*(.gnu.linkonce.d*)
SORT(CONSTRUCTORS)
. = ALIGN(4);
_edata = .;
_nasys_data_destination_end = .;
PROVIDE (edata = .);
}
_nasys_data_source_end = _nasys_data_source + SIZEOF(.data);
/*
* Lastly, the noninitialized storage area.
* This will start immediately following
* the initialized data destination address end.
* This is either right next to the code,
* if code address = data address, or out in
* the data memory, if they're different.
*/
__bss_start = .;
_nasys_uninitialized_storage = .;
.bss :
{
_bss = .;
*(.dynbss)
*(.bss)
*(.bss.*)
*(COMMON)
*(.dynsbss)
*(.sbss)
*(.sbss.*)
*(.scommon)
. = ALIGN(4);
}
_nasys_uninitialized_storage_end = .;
/*
* "_end" is used as the start of the mallocable memoryarea
*/
_end = .;
PROVIDE (end = .);
/*
* To see if you've exceeded memory, you can
* check the symbols "_end" for the end of all static
* data memory, and "_etext" for the end of the code,
* against your memory map. -- dvb
*/
/*
* ------------------------------------------------------------
* dvb say: "I'll leave all this stuff down here exactly
* as I found it, for debugging info, without
* understanding it."
*/
/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the
beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
/* SGI/MIPS DWARF 2 extensions */
.debug_weaknames 0 : { *(.debug_weaknames) }
.debug_funcnames 0 : { *(.debug_funcnames) }
.debug_typenames 0 : { *(.debug_typenames) }
.debug_varnames 0 : { *(.debug_varnames) }
/* These must appear regardless of . */
}
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