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
Hello, Is anyone else out there having issues with Altera's customer support? I've had an issue open with them for over two weeks now, and haven't even gotten a response on it. Not even a "We're working on it". Does anyone know how to elevate an issue within Altera? My Altera SE has been little help of late as well. Thanks for any suggestions. JohnArticle: 79701
Willie, Synchronous FIFOs are used to buffer data between logic in the same clock domain. Async FIFOs are required if you are buffering data where the write side is in a different clock domain as the read side. As for the application notes, I believe the Core Generator contains links to IP documentation. JohnArticle: 79702
Try googling "Altera support getting" -Newman "statepenn99" <statepenn99@yahoo.com> wrote in message news:1109170623.442528.327540@z14g2000cwz.googlegroups.com... > Hello, > > Is anyone else out there having issues with Altera's customer support? > I've had an issue open with them for over two weeks now, and haven't > even gotten a response on it. Not even a "We're working on it". Does > anyone know how to elevate an issue within Altera? My Altera SE has > been little help of late as well. Thanks for any suggestions. > > John >Article: 79703
Apart from the current requirements, it seems that I have to worry about the real estate for heat sinking. The new TI TPS75003 seems to be good device, but it basically consists of a linear regulator and not a switching one as I had thought. I guess I will have to compromise on the real estate for heat sinking. Maybe I will include a "finned" heat sink. The search for the best voltage regulator continues.....Article: 79704
Digari, EasyPath can also be reconfigured: IO, LUTs, DCMs, global resources are 100% tested on every part. So if you are clever, you could change your design by changing those items that are 100% tested (like the LUT). We call this the ECO feature. You may at some time in the future change those 100% tested items, and be guaranteed that they will function (with no test program changes, and no added cost to you). Performance gains are elusive, and I do not consider that they can be utilized without a lot of risk. I think that quite frankly, if either makes sense, EasyPath wins the $ issue for the larger devices, and H1 or H2 would win for smaller devices. That is basically because EasyPath takes advantage of the fact that large devices have a huge amount of redundancy (tons of resources) that allow us to choose those parts that have fully working resources for the particular customer's design and save a ton of $ on test time testing the part for one design instead of anyone's design, whereas the smaller devices do not have the same statistical benefit, and test time is not as long either, meaning EasyPath for small parts does not allow us the have the same cost savings as a custom chip. EasyPath also has a 2 for 1 special: in order to increase volume, or for your own test purposes, we will check the parts for 2 working patterns. Contact your Rep or FAE for details. http://www.xilinx.com/products/easypath/index.htm Austin digari@dacafe.com wrote: > For me it really doesn't matter whether the solution is ASIC (hardcopy) > or FPGA (Easypath) because both are not (re)configurable. > > But i see a performance and power gain in using hardcopy solution, > which is welcome in most of the cases. On the other hand immediate > availability of easypath solution is a plus because structured > ASIC/FPGA user is always TTM hungry. > > >>By their own figures, somewhere between 16% and 70% of conversions > > will > >>'suceed". (Or somewhere from 30 to 84% will FAIL). > > > this is what will increase the cost of hardcopy solution. > > So a direct question: > If the volume is 30K-to -50K, who will be cheaper ?? Hardcopy or > easypath ??? > > An indirect question: > What is the volume range where hadrcopy is cheaper and what is the > volume range where easypath is cheaper, if I don't consider TTM and > power/performance gains. > > -- Digari >Article: 79705
"jack lalo" <jacklalo020@hotmail.com> schrieb im Newsbeitrag news:a8960e4e.0502221344.36b6aec6@posting.google.com... > Hi all, > I'm asking if there is any difference between the Xilinx JTAG III > and IV??? I saw that the speed of the second is 8 time quicker than > the first, but i need a JTAG cable and all the schematics are for the > old one. Is it matter if i use the JTAG III instead of the PC4??? > thanks The good old one is just a tristate buffer. Can be easy rebuild. But you should add a RC-filter and two schmitt triggers in from of the TCK/CCLK line, since the signal from the parallel port might by noisy. Another point is, that the PC-III is only recommended with IO voltages of 5/3.3V. 2.5 might work or not. PC-IV works down to 1.5, AFAIK. And its faster, since it uses (years too late) ECP mode to transfer 8 bit of data and serialize them on the POD. Some yaers ago I did my own download cable design, using a 32 macrocell coolrunner and own control software. Downloading was at an instant. BING!! Why the hell has noone already done something like this and sells them? Especially for the big Virtex-II'n stuff life would be so much easier. Regards Falk P.S. I can email you the modified schematics of the PC-III if you like. Drop me a mail.Article: 79706
"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag news:cvg93s$pqa2@cliff.xsj.xilinx.com... > Sad to see the only viable competitor leaving the field....for "greener > grass" on the other side of the fence. There can be only ONE!!! Regards Falk P.S. FPGA meet Highlander ;-)Article: 79707
> I have a sub-module called "sdram.ctrl.vhd" which has an inout port > "DQ[15..0]". The tristate description is within that module. ... > where DQ_TOP is a bidirectional port of the top level. > > So the question is: > Can I connect two inout lines with a signal of STD_LOGIC ? > Or should I make the direct assignment ? > > i4 : sdram_ctrl > port map ( ... > DQ => DQ_TOP, > ... > ); That way is fine. Try it out and Quartus will not complain. MartinArticle: 79708
Here at El Camino we have a FPGA loader core (55 Mcells in a MAX 3000 device) that doesn't use the SPI mode. After configuration the core leaves the MMC/SD card available to the FPGA in any mode without power cycling. Wolfgang "Martin Schoeberl" <martin.schoeberl@chello.at> schrieb im Newsbeitrag news:6kKSd.65146$2e4.63938@news.chello.at... > It seems that the SD/MMC cards get popular for FPGA designs > today. These cards are real consumer products and are in effect > cheaper than bare NAND chips (for low/medium volume). > I would like to summarize the facts I've found in c.a.f [1] and on > various web sites. > > SD Cards are now considered for configuration of an FPGA. > One of the first projects, done by Antti, uses MMC and load > the configuration stream with a small CPLD (21 cells) [2]. > Another FPGA loader was done by Arnim Laeuger for a SD > card and takes about 50 cells in an EPM3064 [3]. > Ad Anuff has used an Atmel ATTiny12 for this task [4]. The > design (asm program, eagle library, schmatic) is available at [5]. > > However, what's the big win when configuring the FPGA from > the SD Card? > Cost saving? You need an additional part (CPLD w 64 cells) or > an ATTiny12. Both are around $2. That's the same price as for > a serial Flash. > Flexibility? You need a SD slot on your PC to write the configuration > file onto the card. > > I think SD Cards are a very fine addition for an FPGA with a soft-core > processor to be used as file system. Than it's better to connect the > card direct with the 4-bit interface to the FPAG. > If you use it also for configuration all above approaches use the > SD Card in SPI mode. That maens 1/4 of the available bandwith. > And AFAIK you cannot swith to the SD bus mode without powering > off the card. And for a file system it can make a difference if your > transfer rate is 12MB/s or only 3MB/s [6]. > > Martin > > [1] > http://groups-beta.google.com/group/comp.arch.fpga/browse_thread/thread/80f39633c74b22e2 > http://groups-beta.google.com/group/comp.arch.fpga/browse_thread/thread/7669de518b0c9bab > http://groups-beta.google.com/group/comp.arch.fpga/browse_thread/thread/fbd9392981fc2855 > > [2] http://www.opencores.org/projects.cgi/web/mmcfpgaconfig/overview > [3] http://www.opencores.org/projects.cgi/web/spi_boot/overview > [4] http://groups.yahoo.com/group/java-processor/message/110 > [5] > http://groups.yahoo.com/group/java-processor/files/sd_card_fpga_interface/ > [6] http://www.sandisk.com/pdf/oem/ProdManualSDCardv1.9.pdf >Article: 79709
"Wolfgang Loewer" <nospam.wolfgang.loewer@elca.de> schrieb im Newsbeitrag news:cvie7h$d1r$04$2@news.t-online.com... > Here at El Camino we have a FPGA loader core (55 Mcells in a MAX 3000 > device) that doesn't use the SPI mode. After configuration the core leaves > the MMC/SD card available to the FPGA in any mode without power cycling. > > Wolfgang Hi Wolfgang, Yes we know! Sure 1900EUR is nice price for 55 macrocells! oh well I have sold single 2 input and gate for 10 USD :) the mmc boot IP Core at opencores (donated to the public by me) also works in MMC mode (not SPI) ok, I admit I did not have reasons to add SD support so thats not (yet) available. MMC only IP core is 21 PLD cells, MMC+SD would be around 55 Cells (it cant be done with much less), when I have time or there is community funding I will add SD card to support the Core, or maybe I am continue to be lazy and somebody does it for me :) AnttiArticle: 79710
"Pablo Bleyer Kocik" <pablobleyer@hotmail.com> schrieb im Newsbeitrag news:1109170182.442577.56910@o13g2000cwo.googlegroups.com... > Hello group. > > I am trying to get my Spartan3-based design to partially reconfigure > itself using Answer Record #18416 as a guideline > (http://www.xilinx.com/xlnx/xil_ans_printfriendly.jsp?BV_UseBVCookie=yes&get PagePath=18416). [snip] > The whole idea of my project is to use partial-reconfiguration to > support many types of audio filters (this is an audio effects > processor). Maybe it is going to be much better to ditch my current > SP-3 design in favor of a Virtex one that supports modular blocks. Am I > right? > > Best regards. Hi first many congratulations for th s430, I assume it yours ? yes I am afraid you are about right - the S3 partial reconfig - my guess is nobody is using it, it could be useable but the effort to get it done could be too high to be reasonable. it could, OTOH maybe you just about to get it working the way you are trying. But dont expect much help, its nomans land where you are walking! ASFAIK Xilinx (Spartan group!) has interest in S3 partial reconfig. (maybe thats outdated info, but I had/have that impression) AnttiArticle: 79711
"Antti Lukats" <antti@openchip.org> schrieb im Newsbeitrag news:cvigln$1tl$02$1@news.t-online.com... > "Pablo Bleyer Kocik" <pablobleyer@hotmail.com> schrieb im Newsbeitrag > news:1109170182.442577.56910@o13g2000cwo.googlegroups.com... > > Hello group. > > > > I am trying to get my Spartan3-based design to partially reconfigure > > itself using Answer Record #18416 as a guideline > > > (http://www.xilinx.com/xlnx/xil_ans_printfriendly.jsp?BV_UseBVCookie=yes&get > PagePath=18416). > > [snip] > > The whole idea of my project is to use partial-reconfiguration to > > support many types of audio filters (this is an audio effects > > processor). Maybe it is going to be much better to ditch my current > > SP-3 design in favor of a Virtex one that supports modular blocks. Am I > > right? > > > > Best regards. > > Hi > first many congratulations for th s430, I assume it yours ? > > yes I am afraid you are about right - the S3 partial reconfig - > my guess is nobody is using it, it could be useable but the > effort to get it done could be too high to be reasonable. > > it could, OTOH maybe you just about to get it working > the way you are trying. But dont expect much help, > its nomans land where you are walking! > ASFAIK Xilinx (Spartan group!) has interest in S3 partial reconfig. UUPS, typo: I meant "Xilinx has NO interest in S3 partial reconfig..." > (maybe thats outdated info, but I had/have that impression) > > Antti > >Article: 79712
"Antti Lukats" <antti@openchip.org> wrote in message news:cvig1v$cme$03$1@news.t-online.com... > > ok, I admit I did not have reasons to add SD support so thats not (yet) > available. > MMC only IP core is 21 PLD cells, MMC+SD would be around 55 Cells > (it cant be done with much less), when I have time or there is community > funding > I will add SD card to support the Core, or maybe I am continue to be lazy > and somebody > does it for me :) Where do you get the SD spec? I hyave not been able to find a copy anywhere. Seems you have to join an industry group for substantial money.Article: 79713
Andrés wrote: > Martin Schoeberl wrote: >>> Is it possible to use a tristate VHDL description in a hierarchical >>> design that is in a sub module or do I have to use it only on the top >>> level description (snip) > What do you mean with "Just declare your signals inout" ? > I have a sub-module called "sdram.ctrl.vhd" which has an inout port > "DQ[15..0]". The tristate description is within that module. > On my top level file I instantiate the module with > > i4 : sdram_ctrl > port map ( ... > DQ => top_signal_dq, > ... > ); > "top_signal_dq" is of STD_LOGIC_VECTOR(15 DOWNTO 0). > > In the top level file I make then the assignment: > > DQ_TOP <= top_signal_dq; > > where DQ_TOP is a bidirectional port of the top level. At least in verilog connecting inout ports directly to the submodule works. I have not found out how to connect two inout ports within a module (whether connected to a submodule or not). Assignment is not bidirectional, so you can't do that. The verilog TRAN gate is not synthesizable, but should work if it was. -- glenArticle: 79714
"Pete Fraser" <pfraser@covad.net> schrieb im Newsbeitrag news:111pi2gfo0lkd5@news.supernews.com... > > "Antti Lukats" <antti@openchip.org> wrote in message > news:cvig1v$cme$03$1@news.t-online.com... > > > > > ok, I admit I did not have reasons to add SD support so thats not (yet) > > available. > > MMC only IP core is 21 PLD cells, MMC+SD would be around 55 Cells > > (it cant be done with much less), when I have time or there is community > > funding > > I will add SD card to support the Core, or maybe I am continue to be lazy > > and somebody > > does it for me :) > > Where do you get the SD spec? > I hyave not been able to find a copy anywhere. > Seems you have to join an industry group for substantial money. > > http://www.sdcard.org/sdio/Simplified%20Physical%20Layer%20Specification.PDF thats the official free (simplified) specification. by using MMC spec and this simplified version should be almost enoough to write the non-SPI mode SD card bootloader IP Core :) the main differences are 1 ACMD41 must be used instead of CMD1 2 SD card has no streaming read or write 3 the RCA assignment is different differences 2 and 3 are the reason why minimal SD card core is 55 macrocells comparing to MMC only core (21) Antti PS I have/had a better SD spec as well but dont recall where it isArticle: 79715
> The new TI TPS75003 seems to be good device, but it basically consists > of a linear regulator and not a switching one as I had thought. Could you please be more specific on this ? I was thinking of using it myself. I just quickly read the datasheets. To me, it seems to have two buck regulators for core and I/O, where you usually have most of the current, and a linear regulator for VCCAUX. Given that VCCAUX powers also DCM modules, and its quiescent current is not so big, perhaps you would have choosen an LDO in any case, to have it less noisy. Am I missing something obvious here ?Article: 79716
AL wrote: > Hi, I take that back, it works for always @(posedge CLK_IN) > as well as always @(CLK_IN), but only for very simple logic, > if else and case statement, etc. For harder logic such as a > counter, it read back 00000000. Does anyone know why? always @(posedge CLK_IN) says that the statements within the block are executed on the rising edge of CLK_IN. If they are not doing that, or if the are getting executed at other times then you have found a bug. reg q; always @(posedge clk) q=d; implements the usual edge triggered flip-flop like the 74LS74. If you put more in the always block you will get extra logic before your flip-flop; always @(posedge clk) q=d1 & d2; is an AND gate and a FF. reg [3:0] q; always @(posedge clk) q=q+1; is a four bit adder followed by four FFs, otherwise known as a synchronous counter. (If you add up/down it could be a 74LS193) -- glenArticle: 79717
Check out: http://biz.yahoo.com/prnews/050223/sfw066_1.html AustinArticle: 79718
See: http://biz.yahoo.com/prnews/050223/sfw032_1.html AustinArticle: 79719
I was using the nice feature of Verilog 2001, constant functions, to specify port widths. Some of my constant functions called other constant functions. Synplify had no problem with this. However, Modelsim won't allow me to call constant functions from within constant functions, so I have to embed the functions so there is only a single function call. Weak. Is that part of the standard or just a Modelsim shortcoming? -KevinArticle: 79720
I'm not so sure, but you can try to use the "configuration" in both your
modules and top level HDL, for example:
(in module)
architecture A of Module is
begin
...
end A;
architecture B of Module is
begin
...
end B
configuration CFG_A of Module is
for A
end for;
end CGF_A;
configuration CFG_B of Module is
for B
end for;
end CGF_B;
(in top-level)
architecture C of TOP is
...
U_Module: Module
port map( ..... );
...
end C;
configuration CFG_TOP of TOP is
for C
for U_module: Module
use configuration A work.CFG_A (for example)
end for;
end for;
end CFG_TOP;
I hope it's not so far from the solution, bye!
Andrea
> Hi,
>
> I have an VHDL toplevel entity with multiple architectures. If I try
> to synthesis this with the Xilinx ISE 6.3i and the XST Synthesis Tool,
> then only the last architecture will be synthesized.
>
> Therefore my question: Is it possible to select the architecture that
> will be synthesized and how this work?
>
> Best Regards
> Mathias
Article: 79721"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag news:cvib32$8v41@cliff.xsj.xilinx.com... > Digari, > EasyPath can also be reconfigured: IO, LUTs, DCMs, global resources are > 100% tested on every part. So if you are clever, you could change your > design by changing those items that are 100% tested (like the LUT). We > call this the ECO feature. You may at some time in the future change > those 100% tested items, and be guaranteed that they will function (with > no test program changes, and no added cost to you). So far so good. But how is it handled by the software, especially P&R?? OK, I could write tons of LOCs to lock out the not tested logic. But what about routing? Regards FalkArticle: 79722
"Antti Lukats" <antti@openchip.org> schrieb im Newsbeitrag news:cvigln$1tl$02$1@news.t-online.com... > > The whole idea of my project is to use partial-reconfiguration to > > support many types of audio filters (this is an audio effects > > processor). Maybe it is going to be much better to ditch my current > > SP-3 design in favor of a Virtex one that supports modular blocks. Am I > > right? There are many ways to skin a cat. Different filters can also be realized by keeping the processing structure (MACs, delays etc.) but just reloading filter coefficients, which can be done using BRAM, SRL16, SelectRAM. Or go for a complete hazzle free approach, reconfigure the whole FPGA and keep an (complete) FPGA image for every different filter in FLASH memory (its cheap) Regards FalkArticle: 79723
Hello digi,
I am using ML310, but still working with ppc_405.
Recently, I used uart_interrupt. In my case, the following step was needed
to initialize interrupt hanlder.
1. initialize the exception handler (XExc_Init(); )
2. register the external interrupt handler(noncritical intc) to
Exception handler. (XExc_RegisterHandler( ..... ))
3. register uart interrupt handler to the external interrupt
handler.(Xintc_RegisterHandler (.... ))
4. And followed enabling commands (please see PPC_ML310_Tutorial_6_3.pdf
and Platfor Studio User Guide)
If your vectortable failed to calculate your interrupt handler,
I think you should check the handler registration part first.
good luck.
Sewook
"digi" <digitreaco@yahoo-dot-de.no-spam.invalid> wrote in message
news:NpmdnaUEYJ9LpIHfRVn_vg@giganews.com...
> Hallo to all!
>
> I use memec development boart with virtexIIpro with ppc_405. I have
> designed my own IPCore witch a interrupt signal.
> And there i have a problem witch the Interrupt Handler. When a
> Noncritical Interrup accur the ppc stops and only way go further is
> to turn it off. I have debugg it and i saw that, when the interrupt
> accur it goes to vectrortable 0x0500 store the register and then
> begin calculate the address of my handler. And there is the
> Problem!!! By calculating it stops and the PowerPC make notihng more
> :-(
>
> I think it could be a timing problem with my external SDRAM but i'm
> not sure.
> Can me somebody help there?
> Thanks!
>
Article: 79724Dig, As I recall, you were asking about HardCopy versus ASIC and I attempted to provide a reasonably balanced answer to that. The recent posts by Xilinx in this thread are simply FUD. I have no idea where this concept that "30-84% will fail" comes from - this is nonsense. The whole point of HardCopy is that we guarantee that the devices will work. Because the underlying structure of the logic is different in HardCopy, we have a comprehensive tool flow that highlights anything that a user should not do in the FPGA. The reason for this is that we are optimising for die area, and so the functionality of the FPGA is a superset of the HardCopy. Xilinx believes that the Structured ASIC market will not amount to anything, (and we hope they continue to believe this). Meanwhile, they offer EasyPath, which is a way of taking defective silicon which has failed final test and recycling it to see if the defects won't matter in your design. I have yet to meet a customer who thinks this sounds like a good idea. Note that this is a different approach from the properly planned use of redundancy which deliberately builds in additional resources up-front, which can be switched in if needed. On the performance issue, HardCopy devices will indeed be faster. Provided the designer has planned for this, it is of course a benefit. The tools will tell you how much faster the HC devices will be so that you can plan for it. This is not the same as a race hazard. EasyPath offers no performance improvement, no power improvement and the same need for configuration, so that you can't get rid of the config device. (This is frequently an issue for companies planning to make their own ASSPs). Regarding the cost equation, there is no way that EasyPath can make sense, simply from the die-size perspective. Here's a concrete example. Imagine a large FPGA (from either vendor), 20mmx20mm. The gross die per wafer on a 200mm wafer would be 56. Typical yield, calculated on the basis of generic formulae would give a yield of 20 die per wafer. But let's give Xilinx a LOT of credit and assume they can salvage all the defective die on the wafer so that there are 56 die they can sell. Now let's compare the situation with an equivalent HardCopy. I'll take a relatively low die-size reduction figure of 66%, which gives us a die size of 12x11mm. The gross die per wafer is now 199, and let's take a typical net die per wafer figure assuming an average yield in 0.13um. This gives us a NDW figure of 143. So in the absolute BEST case for Xilinx, they get 56 die versus the 143 we get, for a wafer which costs the same to produce. That's the production cost. To get the overall cost, you have to then factor in the NRE and amortise that across your volume. Hope this helps. Paul.
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