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
Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3EFB3967.50BF61F0@xilinx.com>... > Unfair. > > Since Xilinx is winning 80+% of all new FPGA designs, what else would people be > talking about on the website? > > Xilinx has a policy of "very open communications" which means just what is > says. If there is a bug, we fix it. If there is a problem, we solve it. > Is Xilinx the only company to fix bug and solve problem? Sure Microsoft does too. All companies do. > Sweeping something under the rug comes back to only kill you later! > > I have recently noted that Altera, Actel, and others have been using this > newsgroup. > > That is a good thing. > > But do not weigh the quality of the product by the number of complaints on a > newsgroup. The number of complaints results in a very healthy and very high > quality product as we all read, respond, and act to fix problems, provide > solutions, and give our customers the best service and value. > Of course the number of complaints means something. Fixing bugs is good. But less bugs to fix is even better. > Who do you work for, and why did you feel motivated to post this? Perhaps you > need to go examine what makes up good business practices? See below for a > thread by thread comment..... I am not working for Altera or any other CPLD/FPGA chip companies. My post is a simple question of why we have far more Xilinx software related posts than altera's. > Austin > > qlyus wrote: > > > Just took a look of a few pages of comp.arch.fpga Thread Subject: > > > > Jun 26, 2003 Xilinx Webpack bugs bugs bugs (17 articles) > > someone who loves schematics, hates hdl, found a bug. old subject, but we > care, so we respond. > Is it a bug? Old subject? but still existing! No Xilinx people responded in this thread by the way. SO "we respond" is not accurate! > > > > Jun 26, 2003 CoreGen/Ngdbuild help (2 articles) > > what is wrong with asking for help? > I did not say it is wrong. > > > > Jun 26, 2003 ERROR:iMPACT:583 (4 articles) > > "done" doesn't go high is a pretty generic problem, we spend a lot of time on > configuration issues and tools because we have to. > Is iMPACT a Xilinx software? In other words, does it say "ERROR:Xilinx software"? I did not ask you what kind of problem is. > > > > Jun 26, 2003 Addressable Register core generator (1 article) > > Jun 26, 2003 Handelc, Plzzz help (1 article) P. Prasad > > Jun 25, 2003 Xilinx ML300 JTAG Configuration Problem (1 article) > > Jun 25, 2003 Xilinx XC3430A (2 articles) > > Confused customer wants info on a product we don't make? > I did not see confused Altera customers post help on a product Altera does not make. > > > > Jun 25, 2003 Webpack 5.2i can't synthesize (1 article) > > Jun 24, 2003 applying SCHMITT TRIGGER to CoolRunner-II CPLD's (2 articles) > > > > Xilinx related problems are overwhelming over Altera's. > > > > (1) Altera products are better? > > Market will decide. > You did not answer my question. > > > > (2) Altera users are smarter? > > Market will decide. > You did not answer my question. > > > > (3) Altera tech support ? > > Don't know. Don't use it much. But we did win the "top 10 best support > websites" award this month. > Thank, you answered my question. But the answer is "Don't not know." Well, Xilinx websites are good. Answer database is very helpful. FAEs are also very good. But I put big ? on phone support. > > > > (3) Very few people use Altera (Altera market share smaller than Xilinx) ? > > Xlinx market share has increased every quarter for the last year > (DataQuest-Gartner). Market will decide, not you or I. But altera says "Altera Tops CPLD Market in 2002". http://www.altera.com/corporate/news_room/releases/products/nr-cpld_leader.html Increasing for last year or winning 80+% of new designs is different from total market pecentage or users. Atleast Altera has a fair percent of market share. I think my question should change to "why altera users do not ask questions in newsgroup?" Again, I do not work for Altera. I am a long time Xilinx user. -qlyusArticle: 57301
"Patrick MacGregor" <patrickmacgregor@comcast.net> writes: > "Martin Thompson" <martin.j.thompson@trw.com> wrote in message > news:uk7b9z2w8.fsf@trw.com... > > HDL doesn't force abstration - you can write gate-level HDL. There > >are illustrious people populating this group who frequently do the > >"design equivalent of assembly coding" in HDL. > > HDL by its very nature is abstraction in the same way that C abstracts > from assembly. You describe logic and let some piece of software try > to figure out what it means. > You *can* write 'at the assembly level' in HDL. In FPGA land, You can go as far as instantiating LUTs and FFs directly wiring them up. Is that assembly enough? > > Come to think of it, last time I did a schematic I used the > >"abstraction" of a counter block, which hides flops inside it. Only > >if you know how to make a counter do you know "where every flop is". > >And that's the same in HDL - I know I've written code that will mean > >a counter gets built, so I know what flops there are there. > > > > Hierarchies are not abstractions. Punch down into the counter to see > the design. Sadly, these days it will probably be an HDL, so if a > newbie wants to learn about counter design, it won't help any. > No, it could easily be a architecture-optimised, target-specific, low (LUT/FF) level description of how to build a counter. Which could be described equally well in HDL or schematic. > I've used numerous counter types to solve different prolbems. T-FF > based, Johnson counters, D-FF based. Each has a place if you know how > they are built and what their tradeoffs are. > And with a decent library (HDL or schematic) you can have any of those. In VHDL you could use a single generic to change the style of a particular counter very quickly - I'm sure you can do the same in schematic. <snip> Debugging: > > I go back to my simulation, with its models and all that 'waste of > >time'. > > > > Another advantage of this approach is that I can write a testbench > >that covers all my (many) testcases and reports a pass or fail at the > >end. That way I can modify any code I like and know I haven't > >recreated any old bugs. Not quite so easy when staring at > >waveforms... > > > > Well, I guess we mean different things when we describe "simulations". > The Quartus tools allow me to simulate the design without having to > "model" anything. I can take the actual design and throw signals at > it directly to see if it is doing what it should. If I've built the > circuit according to the timing diagrams, I should see resultant > waveforms that match what I expect. Very simple to follow visually, > and it has the added benefit that you see a lot more about what is > going on in the circuit instead of a simple "pass/fail". BTW, with > waveforms you can also do pass/fail tests really, really easily and > automatically. There is no penalty from using waveforms, but there is > a lot to gain. I'm not opposed to the use of waveforms, just that complex transaction based systems are easier for a machine to check than for *me* to do by eye. YMMV. Describing a complex testbench as a *simple* pass/fail is misleading also - the testbench will have run the UUT through all of its functionality, checking that the outputs do the right thing in all circumstances. Just like you are doing with the waveforms. > Also, when you debug the board, you should be able to > match appropriate I/O signals with ones witnessed in simulation. > Seeing a blinky light turn on doesn't mean a circuit worked. You have > to know how well it is working, and know what the signal integrity is > along the way. This usually means o'scopes, which means, you guessed > it, waveforms. > Indeed - and there's no reason that because you use an HDL and automated testbench that you don't understand how the system should look 'in real life'. I'm quite at home with scope, logic analyser, printout of simulation waveforms and datasheets - never have enough bench space! I just find various other techniques helpful to my methodology as well. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 57302
"Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote
in message news:rvOKa.52693$JA5.936325@news.xtra.co.nz...
> I have a design in VHDL for a xc9572xl done using the web pack software.
>
> I am wanting to know how I can set the startup values of the registers.
>
After some more research it seems that I need to use the 'init' attribute.
But I have had no luck initing a register.
type v_reg_type is record
-- registers
IOLatch : std_logic_vector(4 downto 0);
IOLatch2 : std_logic_vector(4 downto 0);
end record;
signal r, rin : v_reg_type;
I want to do something like
attribute init of signal r.IOLatch : signal "10101";
(Clearly assuming I am on the right path)
But I have had no luck persuading webpack to compile it.
Thanks for any pointers.
Ralph
Article: 57303Hi, all: In the Vertex-2 datasheet, it mentioned about partial reconfiguration, where can I find more information on this topic? I have a variable design and a fixed design to put on same V-2 chip. Will partial reconfiguration process halt the current operation of the 'fixed' design on the chip? How can I guarantee the variable design doesn't rob away the hardware of my fixed design? Thanks. KelvinArticle: 57304
Bernd Paysan <bernd.paysan@gmx.de> writes: > Robert Myers wrote: > > Possible solutions: get away from Manhattan > > routing (25% savings in wire delay--yawn) > > He even said this was "novel". Looking at the 25 years old die of the 8086, > 45 angle wiring wasn't novel back then - when layout was made by hand, and > digitized afterwards. What's novel is chip place&route tools that can > handle 45 angle wiring. > One thing I've never understood is what makes IC P&R different to PCBs? PCB autorouters have been doing 45 degree routing for years... Interested minds want to know. Cheers! Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 57305
How do I define an offset constraint for an input signal that is referenced to the falling edge of the input clock? Do I simply add half a clock period? Eg NET "input_pad" OFFSET = IN (clk_period - (clk_period/2 + clk_to_out_fall)) ns BEFORE "clk_pad";Article: 57306
re-post with subject header!
Hi,
Are there any problems with having more than one asynchronous reset?
(Altera1k50 - datasheet has some info but uncertain as to what it implies).
I assumed that the synthesis tool just added an 'or' gate in front of the
reset on the FF, but I've ben told recently that this is not necessarily the
case and that it can cause problems. Can anyone shed any light on what
these might be please?
process (reset, clk, o_mreset)
begin
if (reset = '1') or (o_mreset = '1') then
dummy <= '0';
dummy2 <= '1';
elsif rising_edge(slow_clk) then
if control = '1' then
dummy <= i_dummy;
dummy2 <= i_dummy2;
end if;
end if;
end process;
Thanks
Ruth
Article: 57307Hi all, I'm looking for a tutorial/how-to/book/anything in IP core creation and reuse. What I'm looking for is something from the tools point of view (Xilinx preferable, I found their help docs pretty bad). Any suggestion? SantiArticle: 57308
Stephane Guyetant <sguyetan.dislikes.spam@IRISA.fr> wrote in message news:<bdf0b9$2hf$1@news.irisa.fr>... > I had this error while implementing RAMs with BlockRAMs: > the blockram is a componant instanciated within the coregen-generated > component which in my case was wrong (dualport vs single port). > I would suggest: > * make sure your library is compiled before your design. > * check the PORT MAP of the components > > VHDL is case unsensitive. IIRC Verilog is case sensitive. > > Finally I found the problem. It was that the name of the IP and the name of the container files (edf/ngo) it didn't match. Thanks. SantiArticle: 57309
In article <klfjfvkej6gjid66vjumdopjoiau97kslc@4ax.com>, Robert Myers <rmyers@rustuck.com> wrote: >Won't happen of course. Possible solutions: get away from Manhattan >routing (25% savings in wire delay--yawn), copper interconnect (been >done of course, discovered from the same article that copper atoms >like to diffuse into silicon, maybe it's just as well that chips >become obsolete every few years) ... It is, apparently, common knowledge that copper is doom, in terms of silicon. So I asked my chip-process-engineer brother how Intel and IBM can be investigating the use of copper. My digest of his answer is that the "copper equals doom" theory appears to be bunk. It certainly has some ways to go wrong, but from a chemistry and solid-state physics standpoint, it ought to be able to work. I may have misinterpreted what he said, but I throw this into the mix for discussion purposes. :-) -- In-Real-Life: Chris Torek, Wind River Systems (BSD engineering) Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603 email: forget about it http://67.40.109.61/torek/index.html (for the moment) Reading email is like searching for food in the garbage, thanks to spammers.Article: 57310
On Thu, 26 Jun 2003 21:56:58 GMT "Garrett Mace" <g.ryan@macetech.com> wrote: > Annapolis Micro Firebird, http://www.annapmicro.com/firebird_pci.html A powerhouse, for sure. But browsing your link, I saw that they also have 'Wildcard': an FPGA on a PCMCIA card: a really smart concept! It even has linux support. However, a real winner would be FPGA on a compact flash card. Does such a board exist? None are listed on http://www.fpga-faq.com/FPGA_Boards.shtml It would be a perfect match for a second hand iPaq as a development kit. Thanks, Bram -- "Gates' Law: Every 18 months, the speed of software halves."Article: 57311
Morten Leikvoll <mleikvol@online.nospam> wrote: > When I implement my design using max effort (=5), and the timing analyser > reports no timing errors, the implemented design does not work at all (very > buggy!). I am using several clock nets, but I make sure (I hope) that all > domains are crossed in a safe way. (The design works fine at effort 4, even > if some of the timings are reported bad). I know others have had this > problem. (All my small state machines are binary) > > Does anyone know what the actual problem with effort 5 is: I'd like to try > tweaking my design around those problems. Is your design fully synchronous? How do you handle the interaction between clock domains? Perhaps your design depends on minimum delays which are not met when you use the higher effort level? I've never seen anything like what you describe. But I would never use an effort level less than 5. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 57312
I need to use a variable _input_ threshold on an interface to a Xilinx Spartan2e. I have a DAC which can generate a voltage between 0.5V and 2.8V for Vref. Does anyone know which of the myriad I/O standards is optimum for this application? I have been using SSTL3-I, which seems to work, but I don't really know what is going on inside the input pad - does anyone except Xilinx?Article: 57313
Chris Torek wrote: > > In article <klfjfvkej6gjid66vjumdopjoiau97kslc@4ax.com>, > Robert Myers <rmyers@rustuck.com> wrote: > >Won't happen of course. Possible solutions: get away from Manhattan > >routing (25% savings in wire delay--yawn), copper interconnect (been > >done of course, discovered from the same article that copper atoms > >like to diffuse into silicon, maybe it's just as well that chips > >become obsolete every few years) ... > > It is, apparently, common knowledge that copper is doom, in terms > of silicon. So I asked my chip-process-engineer brother how Intel > and IBM can be investigating the use of copper. My digest of his > answer is that the "copper equals doom" theory appears to be bunk. > It certainly has some ways to go wrong, but from a chemistry and > solid-state physics standpoint, it ought to be able to work. > > I may have misinterpreted what he said, but I throw this into the > mix for discussion purposes. :-) Actually, from what I remember, your brother and robert are both right. If copper gets into silicon, you have a decent chance of a non-functional chip. So, what you do is you put a layer of metal(s) + other insulators between the copper and the silicon, forming a diffusion barrier. Bit like the rubber/plastic coating on the copper wire powering your favorite appliance. See: http://domino.research.ibm.com/comm/wwwr_thinkresearch.nsf/pages/copper397.html for a public-domain account of the development of copper at IBM. MayanArticle: 57314
David Brown <david@no.westcontrol.spam.com> wrote: > FPGA design is the same. Some things can be better expressed as schematics, > especially for small designs, and some designers will work better with > schematics than HDL depending on their background, experiance, and > interests. But to suggest that schematics are always easier to understand, > or to design, or will always generate faster/smaller circuits, is just > silly. Obviously this argument depends on your definition of 'better'. The schematic might produce fewer FFs/LUTs, but that's all. It won't be more extendable, more generic, more reusable, or quicker to design. Unless you're talking about a trivial design - I'm talking about a design which can fill a pair of 2V6000s. For the last nine months I've been working (in a team) on a design where the major components are common to five different PCBs, using a mix of Virtex-E and Virtex-II, speeds from 25 MHz up to 175 MHz, and even different internal bus formats from one board to the next. VHDL lets you parameterise your code so you can do things like this. The final code for this design (synthesisable design plus test benches) appears to run to about 800,000 lines. It's been argued that schematics give you control over the gates and flip-flops that you don't get in VHDL. Firstly, that's wrong; you can instantiate individual FFs and LUTs in your source code and have the synthesiser just pass them through. Or you can code so that the synthesiser infers exactly what you want. It's not always easy and usually requires hints (attributes) to the synthesiser. But more importantly, IMHO the big advantage of HDL is that I don't always have to worry about the exact FFs and LUTs. Sure, some of the time I have to think about every last detail to get the design to run fast. But that's what, 20-30% of the design at most? I don't want to worry about the rest. If it runs fast enough and doesn't take too much space then I've got better ways to use my time, like testing. Often maintainability and reusability are more important than saving every last flip flop, and schematics don't have a chance compared to well-written HDL code. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 57315
Petter Gustad <newsmailcomp5@gustad.com> writes: > > how is prosperity of MIPS? Who uses MIPS? What are the areas that MIPS There's an embedded R3000 (maybe slightly modified) in the Sony Playstation (if memory serves me right). So don't be surprised if somebody claim that MIPS is one of the top selling architectures... Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 57316
Hi Seth,
You may want to take a look at the APEX or Stratix PCI Development Kits from
Altera: http://www.altera.com/products/devkits/kit-dev_platforms.jsp.
The Stratix PCI kit looks pretty cool, and comes with the following
features:
- Stratix 1S25 device (cutting-edge fpga)
- PCI 32-bit/64-bit, 33/66 Mhz (PCI spec 2.3)
- 133 Mhz PCI-X (PCI-X 2.0 Mode 1)
- 3.3V and 5V tolerance
- 256 MB of DDR266 memory
- On-board flash for the FPGA
- Ethernet 10/100 and RS-232 connectors
- A whole bunch of debugging stuff
- Can hook up to the Nios Development Kit (which is also pretty nifty)
Go to http://www.altera.com/products/devkits/altera/kit-pci_stx.html for
more details.
If you are interested in this dev kit, I'd talk to an Altera rep or file an
issue with mysupport.altera.com to determine whether what you want to do on
Linux is feasible.
*** Best guesses below -- contact Altera to be sure! ***
If you willing to develop the hardware under Windows, then port the device
drivers on Linux, that looks like it can be done. The kit ships with the
Windows version of Jungo's WinDriver software, but according to their web
site a Linux edition is available and they claim that the driver code is
cross-OS portable so this *should* work. Quartus is available for Linux, so
you could do your hardware coding under Linux. But the Stratix PCI
Development Kit Application is made for Windows, so you would have to do
without that aspect of the tool-kit. It *is* open-source if you're the
adventurous type!
Good luck in your hunt,
Paul Leventis
Altera Corp.
"Seth" <skintigh_spam@yahoo.com> wrote in message
news:65541f48.0306261249.2e82dd3f@posting.google.com...
> I need an FPGA board with a 64-bit 66MHz PCI bus and Linux drivers,
> and I need to be able to demo it, and I need it fast.
>
> If that's not demanding enough I can add more requirements.
>
> I have looked through 53 vendors so far and there are no real winners.
>
> Thanks in advance.
Article: 57317qlyus@yahoo.com (qlyus) writes: > Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3EFB3967.50BF61F0@xilinx.com>... > > qlyus wrote: > > > > > Just took a look of a few pages of comp.arch.fpga Thread Subject: > > > > > > Jun 26, 2003 Xilinx Webpack bugs bugs bugs (17 articles) > > > > someone who loves schematics, hates hdl, found a bug. old subject, but we > > care, so we respond. > > > > Is it a bug? Old subject? but still existing! Most of that thread was/is a debate as to the merits of schematic vs HDL design. > > No Xilinx people responded in this thread by the way. SO "we respond" > is not accurate! > Steve Lass from Xilinx responded: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=3EFA391B.4000806%40xilinx.com I think the biggest reason for more Xilinx postings here is because until very recently (ie when Altera and Xilinx settled their legal differences and Altera were allowed to acknowledge the existence of the word FPGA in relation to their products) you couldn't get a response from Altera on this group, so *most* people with Altera questions presumably asked them elsewhere. This is starting to change, which is a good thing IMHO. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 57318
Hi Chris, Copper has been solved by the process guys. The trick is that you have to put a barrier metal (tantalum?) between the copper and the silicon dioxide/FSG in order to prevent the copper from diffusing into the dielectric. This makes copper processes more complicated (dual damascene) and hence a little more costly, have higher defect rates (tantalum bridging, via underfill, etc.) Apparently, things get trickier when you mix copper with lower-k dielectrics. There's a nice little paper here that describes things at a pretty high level: http://www.icknowledge.com/threshold_simonton/techtrends01.pdf It took a while for the fab guys to get everything worked out, but now adays I think almost everyone's in copper at .13u and definitely below. We've been successfully manufacturing and yielding chips use copper interconnects since the 0.15u node (in 2001), and all of our recent FPGAs use an all-copper process (APEX 20KC, APEX II, Stratix, Stratix GX, Cyclone). Regards, Paul Leventis Altera Corp. "Chris Torek" <nospam@elf.eng.bsdi.com> wrote in message news:bdh5md$pa1$1@elf.eng.bsdi.com... > In article <klfjfvkej6gjid66vjumdopjoiau97kslc@4ax.com>, > Robert Myers <rmyers@rustuck.com> wrote: > >Won't happen of course. Possible solutions: get away from Manhattan > >routing (25% savings in wire delay--yawn), copper interconnect (been > >done of course, discovered from the same article that copper atoms > >like to diffuse into silicon, maybe it's just as well that chips > >become obsolete every few years) ... > > It is, apparently, common knowledge that copper is doom, in terms > of silicon. So I asked my chip-process-engineer brother how Intel > and IBM can be investigating the use of copper. My digest of his > answer is that the "copper equals doom" theory appears to be bunk. > It certainly has some ways to go wrong, but from a chemistry and > solid-state physics standpoint, it ought to be able to work. > > I may have misinterpreted what he said, but I throw this into the > mix for discussion purposes. :-) > -- > In-Real-Life: Chris Torek, Wind River Systems (BSD engineering) > Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603 > email: forget about it http://67.40.109.61/torek/index.html (for the moment) > Reading email is like searching for food in the garbage, thanks to spammers.Article: 57319
"Ruth" <ruthsims@hotmail.com> wrote in message news:<3efc13b6$0$18497$ed9e5944@reading.news.pipex.net>... > re-post with subject header! > > Hi, > > Are there any problems with having more than one asynchronous reset? > (Altera1k50 - datasheet has some info but uncertain as to what it implies). > I assumed that the synthesis tool just added an 'or' gate in front of the > reset on the FF, but I've ben told recently that this is not necessarily the > case and that it can cause problems. Can anyone shed any light on what > these might be please? > > process (reset, clk, o_mreset) > begin > if (reset = '1') or (o_mreset = '1') then > dummy <= '0'; > dummy2 <= '1'; > elsif rising_edge(slow_clk) then > if control = '1' then > dummy <= i_dummy; > dummy2 <= i_dummy2; > end if; > end if; > end process; Perhaps the person that told you to beware of this was referring to the fact that some devices either (1) have reset nets that can not be driven from within the device or (2) it is difficult to guarantee timing under all conditions when an async reset is released. Item 2 is still a problem as far as I'm aware, at least for Xilinx (haven't tried Altera recently, so not sure there). But other than those two issues, I'm not aware of any reason that it would cause problems. I don't know why, but I keep holding out hope that Xilinx will someday address the release of async resets, or at least Peter or Austin will help us find an answer to this issue (referring to Hals unanswered questions in http://groups.google.com/groups?selm=v71unlhlf3ds74%40corp.supernews.com and the related thread ). MarcArticle: 57320
Paul Leventis wrote: > Hi Chris, > > Copper has been solved by the process guys. The trick is that you have to > put a barrier metal (tantalum?) between the copper and the silicon > dioxide/FSG in order to prevent the copper from diffusing into the > dielectric. http://www.chipscalereview.com/issues/0301/techReport.html gives an overview of barriers used. Tantalum Nitride is one of them, you also can use Titanium or Tungsten Nitride, and optionally add Silicon. Basically what you want is a robust crystal that doesn't allow the copper to migrate through. There are many available, pick those which can be processed easily and don't cost too much. Titanium Nitride is already used as barrier for the AlCu alloys, so the question is whether it's good enough (there are doubts). Tungsten has the disadvantage of crystalizing into nano-needles, which increases the surface resistance (not that Tungsten has a good inner resistance, either), but it works. Tungsten is also often used as local interconnect, and some processes use Tungsten barriers for AlCu (e.g. xfab 0.6u). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/Article: 57321
Ralph Mason wrote:
> "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote
> in message news:rvOKa.52693$JA5.936325@news.xtra.co.nz...
> > I have a design in VHDL for a xc9572xl done using the web pack software.
> >
> > I am wanting to know how I can set the startup values of the registers.
> >
>
> After some more research it seems that I need to use the 'init' attribute.
>
> But I have had no luck initing a register.
>
> type v_reg_type is record
> -- registers
> IOLatch : std_logic_vector(4 downto 0);
> IOLatch2 : std_logic_vector(4 downto 0);
> end record;
>
> signal r, rin : v_reg_type;
>
> I want to do something like
>
> attribute init of signal r.IOLatch : signal "10101";
>
> (Clearly assuming I am on the right path)
>
> But I have had no luck persuading webpack to compile it.
>
> Thanks for any pointers.
> Ralph
Hi Ralph:
The proper VHDL syntax is:
attribute init: string;
attribute init of q : signal is "S"; -- power up to 1, use "R" for 0.
Where the attribute statements go in your entity declaration, right after the
port declarations, e.g:
entity mydesign is
port( .... );
attribute init: string;
attribute init of q : signal is "S"; -- power up to 1, use "R" for 0.
end mydesign;
The attribute statement will not, of course, affect the behaviorial simulation
results. To change those, use the normal VHDL default value mechanism.
An alternate mechanism to attribute init that works for all entry methods
(Abel, schematic, Verilog, VHDL) is to add the constraint to a .ucf file:
NET mysignal INIT=S;
If you don't already have a .ucf file as part of your design, use Project->New
Source in iSE 5.2i to add one.
Good Luck,
Dennis McCrohan
Xilinx CPLD S/W
Article: 57322In article <bdh5md$pa1$1@elf.eng.bsdi.com>, Chris Torek <nospam@elf.eng.bsdi.com> writes: |> In article <klfjfvkej6gjid66vjumdopjoiau97kslc@4ax.com>, |> Robert Myers <rmyers@rustuck.com> wrote: |> >Won't happen of course. Possible solutions: get away from Manhattan |> >routing (25% savings in wire delay--yawn), copper interconnect (been |> >done of course, discovered from the same article that copper atoms |> >like to diffuse into silicon, maybe it's just as well that chips |> >become obsolete every few years) ... |> |> It is, apparently, common knowledge that copper is doom, in terms |> of silicon. So I asked my chip-process-engineer brother how Intel |> and IBM can be investigating the use of copper. My digest of his |> answer is that the "copper equals doom" theory appears to be bunk. |> It certainly has some ways to go wrong, but from a chemistry and |> solid-state physics standpoint, it ought to be able to work. |> |> I may have misinterpreted what he said, but I throw this into the |> mix for discussion purposes. :-) |> -- Copper is doom. IBM shipping large quantities of copper metallized chips. Hmm, secret double damascene process to keep copper out of si. Change "it ought to be able to work" to "It works" -- Del Cecchi cecchi@us.ibm.com Personal Opinions OnlyArticle: 57323
"Kelvin Tsai @ Singapore" wrote: > > Hi, all: > > In the Vertex-2 datasheet, it mentioned about partial reconfiguration, > where can I find more information on this topic? I have a variable > design and a fixed design to put on same V-2 chip. > > Will partial reconfiguration process halt the current operation of the > 'fixed' design on the chip? > > How can I guarantee the variable design doesn't rob away the hardware > of my fixed design? > > Thanks. > Kelvin Now that's the sticky wicket, isn't it? While manufacturers offer devices that support partial reconfiguration, they don't seem to offer the required support in software to generate useful bitstreams. The tricky part is keeping the routing from a given portion from running into the routing from another portion and also being able to provide interfaces for the wiring that needs to hookup. If there is support for this, I am not aware of it. -- 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: 57324
Ralph,
Another method (aside from passing an INIT) is to initialize the signal
that will be registered:
library ieee;
ues ieee.std_logic_1164.all;
entity ff is
port (d, c : in std_logic;
q : out std_logic);
end entity;
architecture ff_arch of ff is
signal q_temp : std_logic := '0'; -- XST will pass the proper INIT
value based off of the signal initialization
-- This INIT value is the state to
which the register will power up
-- q_temp is the signal that will be
registered
begin
:
:
Steve
Ralph Mason wrote:
>I have a design in VHDL for a xc9572xl done using the web pack software.
>
>I am wanting to know how I can set the startup values of the registers.
>
>Thanks
>Ralph
>
>
>
>
>
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