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
Try this. Go back to SOPC Builder and reset all of your addresses, IRQ's, and reset and vector table, etc. addresses - even if they haven't changed. Then rebuild your system. One thing that I do is put my vector table in its own small on-chip ram to protect it and make sure interrupts are as fast as possible. You might want to check out www.niosforum.com to share Nios info. Ken "Julien Chevalier" <translate_to_french_the_word_knight_and_add_a_j@voila.fr> wrote in message news:ca9jc4$jr4$1@s1.read.news.oleane.net... > Hello, > > I use quartus II 4.00 and SOPC builder 4.00 to build a NIOS system on a > Stratix II board. > I enabled the support for external interruptions, add a user defined IP > connected via the provided avalon ahb bridge. > Everything is ok. > Then I try to use the interruption of the bridge, everything on the wire > is ok until the data_master_irq gets high. The iq number is ok, NIOS > makes a couple of instructions more and then stops on a strange adress > (totallly out of the memory map). but it doesn't fetch the ISR code indeed. > The soft uses nr-installusr and is exactly the same as the examples > provided. > > I tried whithout any soft isr and initialisation to see if i get the > famous message ... but nothing. > > How can I be sure of what is done by the compiler, is there any > restriction that I don't respect ? thanks for all your help and > experience about those interrupts on NIOS systems. > > Sincerely > > Julien ChevalierArticle: 70251
Hi, I'm using the output CLKFX of a DCM in a virtexII pro with CLKIN = 10MHz. The M factor is 27 and the D factor is 10 so that I get CLKFX = 27MHz. Since the PLL mode does not support CLKIN < 24 MHz should I still keep the feedback loop between CLK0 and CLKFB. Thanks. Christophe.Article: 70252
So after looking at the Virtex4 line of devices and their associated features (http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=v4_asmbl), I'm a little miffed at their chip resource allocation. First of all, suppose I'm planning on filling an FPGA full of logic. I'm probably going to run the majority of that logic in the same clock domain so I don't need a whole lot of DCMs. However, I do need some way to get my data to/from the chip. What's up with zero transceivers on the "logic platform"? The same can be asked of the "signal processing platform". I was so looking forward to getting away from the old parallel I/O issues, and if I'm going to have to deal with that, maybe we better leave those DCMs on there. It wouldn't take very many transceivers to alleviate the issue. Second, what about those of us who build and prototype digital bus controllers, routers, and similar applications. In that situation I'm looking for an FPGA with lots of memory, lots of transceivers, lots of DCMs, a fair amount of logic, and not much else. DSP and Processors don't really help me in that type of application, yet to get what I need I will end up spending the extra money for the FX chip.Article: 70253
Hi, A quick question.Any pointers will be of great help. Is there any way through XDL or someother tool that I can read the function each SLICE or LUT in a Virtex Device is implementing? regards --rajArticle: 70254
Brannon, wait until Xilinx releases the real details, and I am sure you will like them. There is a lot of flexibility in the I/O on all Virtex-4 families. As to the large number of global clock lines and DCMs, Xilinx must to cater to a wide range of customers, and some need them. If you need less, you can always leave them unused, but if you need more than are available, you (and we) would have a serious problem. DSP circuits can be used for many other functions than DSP. :-) Be patient... Peter Alfke Brannon King wrote: > > So after looking at the Virtex4 line of devices and their associated > features > (http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=v4_asmbl), I'm a > little miffed at their chip resource allocation. > > First of all, suppose I'm planning on filling an FPGA full of logic. I'm > probably going to run the majority of that logic in the same clock domain so > I don't need a whole lot of DCMs. However, I do need some way to get my data > to/from the chip. What's up with zero transceivers on the "logic platform"? > The same can be asked of the "signal processing platform". I was so looking > forward to getting away from the old parallel I/O issues, and if I'm going > to have to deal with that, maybe we better leave those DCMs on there. It > wouldn't take very many transceivers to alleviate the issue. > > Second, what about those of us who build and prototype digital bus > controllers, routers, and similar applications. In that situation I'm > looking for an FPGA with lots of memory, lots of transceivers, lots of DCMs, > a fair amount of logic, and not much else. DSP and Processors don't really > help me in that type of application, yet to get what I need I will end up > spending the extra money for the FX chip.Article: 70255
I bet the answer you get from Xilinx will be along the lines of "we analysed X number of designs from our customer base and found these three to be the best fit (to maximise our profits)". They won't actually say the bit in parentheses, but that's what they're in business for. Fair enough. I guess the 'new' architecture makes it somewhat easier to add further variants. After all, they've only used three letters (LSF) so far, that leaves space for 23 more mixes! ;-) I'm excited that the block structure will finally make partial reconfiguration a reality. cheers, Syms.Article: 70256
Brannon, Well, one can either say the glass is half full, or half empty. In an extensive survey of customers, we organized the Virtex 4 family into the LX, FX, and SX. The idea was pretty simple: we have a lot of customers today who do not use the MGTs, and want more logic for less cost(LX). They feel that they could have a lower cost solution if we did not put MGTs and 405PPCs in the chip (which they end up not using). Then there are those that like the MGTs. They have found that the MGTs go well with the 405PPCs, and those that like the PPCs often find use for the MGTs. The logic and BRAM has to be sufficient to balance these applications out, so the FX family is targeted for those folks. Then there are the DSP folks, (who quite frankly are happy with no one and nothing!). They want humongous amounts of DSP specific functionality (logic? who needs logic?). The SX family is intended for them. If we wished to add the MGTs to the SX family, then we have to ask, do they also need 405PPCs (as the two go together very well in talking to users). Maybe they do? Maybe they should? Three major families. If there is a significant demand for a hybrid of the feature sets, well, talk to us about it. With ASMBL, it can be done without moving heaven and earth. But remember that we supply a general purpose solution (now three general purpose solutions) so the chip has to have an almost universal appeal to a market segment, or it is not worth the effort to do it. As for clocks, I am happy to hear you only use one clock, but consensus is that we need to supply more global (and local) clocks with increasing numbers of CLBs to meet our customers' requirements. Prototyping ASICs is no longer our "big" business. In fact, it has gotten progressively smaller over the years as ASICs get progressively more difficult to do at all. We love when people just have to have the largest parts we make, however. If the mask for the next ASIC costs $2 million, then the cost (price) of the FX vs. the LX is not an issue anyway. Austin Brannon King wrote: > So after looking at the Virtex4 line of devices and their associated > features > (http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=v4_asmbl), I'm a > little miffed at their chip resource allocation. > > First of all, suppose I'm planning on filling an FPGA full of logic. I'm > probably going to run the majority of that logic in the same clock domain so > I don't need a whole lot of DCMs. However, I do need some way to get my data > to/from the chip. What's up with zero transceivers on the "logic platform"? > The same can be asked of the "signal processing platform". I was so looking > forward to getting away from the old parallel I/O issues, and if I'm going > to have to deal with that, maybe we better leave those DCMs on there. It > wouldn't take very many transceivers to alleviate the issue. > > Second, what about those of us who build and prototype digital bus > controllers, routers, and similar applications. In that situation I'm > looking for an FPGA with lots of memory, lots of transceivers, lots of DCMs, > a fair amount of logic, and not much else. DSP and Processors don't really > help me in that type of application, yet to get what I need I will end up > spending the extra money for the FX chip. > >Article: 70257
"Brannon King" wrote: >So after looking at the Virtex4 line of devices and their associated >features >(http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=v4_asmbl), I'm a >little miffed at their chip resource allocation. Oh, everyone is miffed at chip resource allocation. Almost always. But for different reasons. Just for a second, think about this from Xilinx's point of view: They can't make lots of different chips. Each different type adds to the development costs, support costs, inventory costs and sales costs. Some of their customers need lots of (Pick one: RAM, IOs, DCMs, processors, transceivers, multipliers, LUTS and FFs). Many other customers need less or could even care less. For example, I've never worked on a chip that had a reasonable use for a multiplier since the XC4000 days, when there wasn't any multipliers! So the chips Xilinx make must be compromises. What I see in the Virtex4 line is the following: 1) The logic platform is reasonable for things that are basically data movers/processors with RAM buffers. Yes, transceivers might be useful for some, but parallel IO isn't dead yet, and will not be dead as long as DDR SDRAM is the commodity memory technology. Probably not enough internal memory, but I'm sure there are other opinions! 2) The DSP platform is probably reasonable for DSP. Perhaps someone more versed in the DSP would could comment? 3) The full-featured platform should cover most other uses, but expect to pay for features you don't need. Now, did Xilinx miss any large volume uses of FPGAs? I don't think so. Sure, a prototype router might require no hard processor, no multipliers and other DSP support, and the designer will need to buy the FX chip with these features, but how many of these are going to be built? YMMV, SRA, SDD, OMNHO, ... -- Phil Hays Phil_hays at posting domain should work for emailArticle: 70258
Symon, Ha ha ha. That was really funny (really, it was). Almost quoted me chapter and verse. And I would hope it is OK with everyone that Xilinx continues to make money so that we can enable all of you to do likewise. Glad you are not puzzled by any of this. Austin Symon wrote: > I bet the answer you get from Xilinx will be along the lines of "we analysed > X number of designs from our customer base and found these three to be the > best fit (to maximise our profits)". They won't actually say the bit in > parentheses, but that's what they're in business for. Fair enough. > I guess the 'new' architecture makes it somewhat easier to add further > variants. After all, they've only used three letters (LSF) so far, that > leaves space for 23 more mixes! ;-) > I'm excited that the block structure will finally make partial > reconfiguration a reality. > cheers, Syms. > >Article: 70259
Julien Chevalier wrote: > Hello, > > I use quartus II 4.00 and SOPC builder 4.00 to build a NIOS system on a > Stratix II board. > I enabled the support for external interruptions, add a user defined IP > connected via the provided avalon ahb bridge. > Everything is ok. > Then I try to use the interruption of the bridge, everything on the wire > is ok until the data_master_irq gets high. The iq number is ok, NIOS > makes a couple of instructions more and then stops on a strange adress > (totallly out of the memory map). but it doesn't fetch the ISR code > indeed. The soft uses nr-installusr and is exactly the same as the > examples provided. > > I tried whithout any soft isr and initialisation to see if i get the > famous message ... but nothing. > > How can I be sure of what is done by the compiler, is there any > restriction that I don't respect ? thanks for all your help and > experience about those interrupts on NIOS systems. I've seen the Avalon interrupt controller act up if the interrupt signal isn't synchronized by at least 1 FF in the NIOS's clock domain. It generates a random-ish interrupt number that seems to be <highest defined IRQ>+1. BenArticle: 70260
Hi, I'm a new user of fpga, actually i'm learning about it and i need help. I want to know how import cpu's cores (8051 or z80) into a xilinx fpga device ( Spartan IIe ). If someone can send me a tutorial where i can learn about that i thanks a lot.Article: 70261
Try http://www.fpgacpu.org/ Syms.Article: 70262
Hi, there I am dealing with the back-annotated SDF timing simulation. The timing_vhdl file is generated by the Xilinx ISE tool and I applied it to the Modelsim simulator. But how can I obtain my original input/output signal? With older tools, I can identify, for instance, ..._D is the input of Data FF, ..._Q is the output of Data FF. But now I cannot trace these signals any more. It is dissappeard. How can I work around this problem? Which abbreviate is short for input or output of data flip-flop? I would appreciate any idea and suggestions. Thanks. Chao.Article: 70263
Hello everybody! I'm new here and I've got a quick and rather simple (as I suppose) question for more advanced members of group. What are the main disadvantages and problems concerning run-time management of logic resources on reconfigurable systems? I would be very appreciated if anyone could give any answers, comments and remarks. Christopher RedArticle: 70264
Hello,
i have the following problem: i try to latch external data (AD7...AD0) into
an internal FPGA register on the rising edge of an external signal (address
latch enable = ALE). Generally this seems to work, but i often have
situations where a very short peak is on the signal ALE. Peak is around 20
ns (can measure them with a scope), whereas my normal signal is around 12 us
(600 times longer).
What is a common way of handling this ?
1) I read on some webpages that there is a VHDL mechanism called
delay_mechanism (with "reject" or "after" statement).
I tried it on target FPGA, but it seems not to work. Could it be that this
works only for simulation ?
2) I found a lot of articles about doing an RC at the input side. How do i
calculate the values of R and C e.g. when i want to ignore all pulses below
50 ns ?
3) Is there any method to do it FPGA internal ? Don't want to add external
hardware... read of bad ways with delay lines.... i think i read somewhere
of reserved words like "SKEW", "SLOW", "FAST". Do they help me ? Should i go
in this direction ?
4) Or must i add an external clock only for this ? E.g. with a counter, only
when certain count value is reached, the line is valid ?
Regards,
Martin
Article: 70265> i try to latch external data (AD7...AD0) into > an internal FPGA register on the rising edge of an external signal > [...] when i want to ignore all pulses below 50 ns I don't think that there are good solutions with delays ... I assume you have a clock in your FPGA - almost any speed fits ... I can't imagine an FPGA exclusively filled with async logic.. there is really nothing? the common way (with clock) could be something like: synchronize your ALE signal, then register it once more... AND the synchronized and delayed signal ... (call it reg_en) describe your register as clocked with your clock and reg_en as clock_enable ... - the resulting behaviour is slightly different - your data gets captured after some delay ... if this is a problem: capture your data with ALE and register it to the next stage with clk and reg_en - you get some delay until your data is available - but as you only know whether the data is valid after the 50ns you need to wait at least 50ns after rising ALE ... - if your clock is faster than 20MHz you need more delays of the synced ALE - you can produce delays in your fpga without clocks (by direct manual placement in the fpga) but this gives you only very few ns (far below 50ns) bye, MichaelArticle: 70266
Arturo Rios wrote: > Hi, > I'm a new user of fpga, actually i'm learning about it and i need > help. > I want to know how import cpu's cores (8051 or z80) into a xilinx fpga > device ( Spartan IIe ). If someone can send me a tutorial where i can > learn about that i thanks a lot. Hi Try this http://www.opencores.org/ http://www.opencores.org/browse.cgi/filter/category_microprocessor You can check also this http://cs.lasierra.edu/~ehwang/mybook/toc.html Good luck -- Michal HUSEJKO Warsaw University of Technology PolandArticle: 70267
We have highlighted that Stratix II devices will ship to customers in July. Stratix II checkout and characterization is proceeding ahead of schedule. Stratix II Development Kits are on track to ship later in Q3. Dave Greenfield Altera Product Marketing > > Any news on when a Stratix-II Dev kit will be available? > > TommyArticle: 70268
I got this error when my c source was not in the cpu_sdk/src directory. I
moved my
source to that directory under my project now all is better. Let me know if
it works for you.
If you have your apps engineer on speed dial.......You might be designing
with Altera. hahahaha
For you Xilinx guys just do the subsituition.
"Julien Chevalier"
<translate_to_french_the_word_knight_and_add_a_j@voila.fr> wrote in message
news:ca3vfe$9be$1@s1.read.news.oleane.net...
> Hello,
>
> Im' using Quartus 4 and SOPC Builder 4.
> I'm preparing a nios design, but i've got a trouble with software build.
>
> The point is that the only way I have to generate the soft is to
> regenerate the whole system (both soft and hard).
>
> I obviously tried to use the command line tools, in vain.
> I tried to use the c macro offered in the generated modelsim do file ...
> but it's still not working ...
>
> Here is the error i have in the SOPC SDK SHELL when try to build
> montest.c code :
>
> [SOPC Builder]$ nios-build montest.c
> Can't use string ("-1") as a HASH ref while "strict refs" in use at -
> line 478.
>
> And attached is the log of the modelsim shell.
>
> If anybody has an idea from where it comes from, please let me know.
>
> Thanks for your attention.
>
> Julien Chevalier
> translate knight to french and add a j att voila dot fr
Article: 70269Hi, can I use the Floorplanner to subdivide the FPGA on the Celoxica RC200-Board in one static area and one reconfigurable area? It could be the answer of my tcp problem. The tcp could be static on the fpga and my application layer in an reconfigurable part. Thanks to Sarah for the answer to my first question. regards MichaelArticle: 70270
>Although the main power supplies on the board are OK, they actually >make good connectivity to a random number of power pads on the FPGA. >Each board has a different set of 'good' connections between the >power supply and the FPGA. Ugh. That's probably the worst sort of problem to have to track down. Any hints on how you found it? (just in case any of us are unlucky enough to encounter the same problem) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 70271
>Keep in mind that the newer Xilinx chips have a MUXF6 which allow up to >8 input muxes to be made with a single level of delay. That compares >well with the 16 input mux you can make from an Altera LAB. Routing is >an issue, but the speed of the tbufs driving long lines make them pretty >impractical for the newer chips running at high speeds. If you don't >need speed, you can use a single wire with a serial bus to reduce the >amount of logic and routing used. What the newer chips provide is speed >and lots of it. That can do a lot to reduce the size of a design. I'm not sure that "lots of speed" translates into don't need tbufs. I'd expect that designers expectations and goals would grow to use all available resources - both space and time. Yes, if I'm using a modern/fast part to implement an old design, I may be able to make speed/space tradeoffs. But I could also be speeding up the whole project and expecting a state machine that used to run a X MHz to now run at 3X or 5X. (adjust your goals to match the age of your design) Is there something fundamentally evil with tbufs? Or is the problem that they don't scale because the chips are getting bigger (when measured in gates, not microns). Suppose I design a FPGA with old fashioned tbufs and long lines, but don't cover the width of the whole chip, but just X LUT/FF units. Would that track other speed improvements as silicon gets faster? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 70272
It's now June 10, 2004 and they still haven't released it. Hendra "Peng Cong" <pc_dragon@sohu.com> wrote in message news:c9p5le$2hhl$1@mail.cn99.com... > Now the web page said 6.2i SP3 is scheduled for release June 9, 2004 > > "qlyus" <qlyus@yahoo.com> дÈëÓʼþ > news:da71446f.0406031421.7181250@posting.google.com... > > It is said "6.2i SP3 is scheduled for release June 2, 2004." > > > > http://support.xilinx.com/support/software/install_info.htm > > > > I want to see if the multi-pass PAR crashes in 6.2i is fixed. > > > > -qlyus > >Article: 70273
(Hal Murray) wrote: <Snip> >Suppose I design a FPGA with old fashioned tbufs and long lines, but >don't cover the width of the whole chip, but just X LUT/FF units. >Would that track other speed improvements as silicon gets faster? No, interconnect does not scale. Interconnect gets slower as the device geometry gets smaller. Transistors scale. As they get smaller, the operating voltage decreases and the switching speed increases. Nice, eh? Interconnect has a bulk resistivity set by the material. The end-to end resistance is (resistivity*length)/(width*thickness). If the ratios between length : width : thickness are constant, the resistance doubles if the size halves. This is why interconnect was almost ignorable at 3 micron geometry and is a major source of delay at .90 micron, even after changing to copper with a lower bulk resistivity. -- Phil Hays Phil_hays at posting domain should work for emailArticle: 70274
Martin Maurer wrote: > 1) I read on some webpages that there is a VHDL mechanism called > delay_mechanism (with "reject" or "after" statement). > I tried it on target FPGA, but it seems not to work. Could it be that this > works only for simulation ? Yes. > 2) I found a lot of articles about doing an RC at the input side. How do i > calculate the values of R and C e.g. when i want to ignore all pulses > below 50 ns ? This would distort the good edges along with the glitch. > 3) Is there any method to do it FPGA internal ? Don't want to add external > hardware... read of bad ways with delay lines.... i think i read somewhere > of reserved words like "SKEW", "SLOW", "FAST". Do they help me ? Should i > go in this direction ? No. > 4) Or must i add an external clock only for this ? Not only for this. Use synchronous design for everything. > E.g. with a counter, > only when certain count value is reached, the line is valid ? That's more like it. -- Mike Treseler
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