Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Now on our website is our new PC104Plus board Hollybush1. Base board is Spartan-3 based but Virtex support is coming soon on an expansion module giving high speed serial and PowerPC support. You can use this board as a development board or as a OEM product. Details are here http://www.enterpoint.co.uk/moelbryn/hollybush1.html. We are taking this new board to DATE where you can see it in more details on stand F48 along with the other new products we have. John Adair Enterpoint Ltd. - Home of Hollybush1. The Flexible PC104+ Board. http://www.enterpoint.co.ukArticle: 98101
Austin Lesea wrote: > Matt, > > If you use a a cpld, you need to post in comp.arch.cpld > > Austin There is no comp.arch.cpld HendraArticle: 98102
"Duane Clark" <dclark@junkmail.com> wrote in message news:ZMjOf.18743$2O6.14086@newssvr12.news.prodigy.com... > For one project, the GPIO approach might be easiest. But it is a pain > when every time a new signal is desired, the EDK portion has to be > recompiled. > > What I did was to start with the GPIO core and then modify it to output > signals for address, read data, write data, and read/write control. Then > I have a register implementation as part of my ISE project, and that is > the only place I need to make changes. A little extra work up front, but > well worth it in my opinion. It's an interesting idea, but isn't the DCR doing essentially the same thing? What I don't like about GPIO or DCR for that matter is that I can't for example implement a self-clearing write-only bit... Well, on the other hand, perhaps, it's a bad design practice... /MikhailArticle: 98103
MM wrote: > "Duane Clark" <dclark@junkmail.com> wrote in message > news:ZMjOf.18743$2O6.14086@newssvr12.news.prodigy.com... >> For one project, the GPIO approach might be easiest. But it is a pain >> when every time a new signal is desired, the EDK portion has to be >> recompiled. >> >> What I did was to start with the GPIO core and then modify it to output >> signals for address, read data, write data, and read/write control. Then >> I have a register implementation as part of my ISE project, and that is >> the only place I need to make changes. A little extra work up front, but >> well worth it in my opinion. > > It's an interesting idea, but isn't the DCR doing essentially the same > thing? > > What I don't like about GPIO or DCR for that matter is that I can't for > example implement a self-clearing write-only bit... Well, on the other hand, > perhaps, it's a bad design practice... > It is certainly very similar to the DCR interface. But a separate bus is not needed. I would think something like this for both the PLB and OPB buses would be simple and useful enough for others to be part of the EDK pcores. I'm not sure what a write-only bit is ;) But the register method I use certainly allows all sorts of flexibility, and having a a bit be self clearing is easy to do this way. I am not sure where that would be difficult with the DCR bus, but then, I have not used the DCR bus. Partly my going this direction is driven by the method I use for performing VHDL simulations. I don't bother with the complex BFM PPC models provided by Xilinx, and don't simulate the processor memory. Instead, I wrote a simple functional model of my own which correctly handles the basic read and write bus operations on the PLB bus. I do use the Xilinx supplied models for the PLB and OPB buses, arbiters, etc. It is accurate enough that the components always work in the real system, and is simple to use and simulates fast. In part, I ended up with a system like that because it is the way I handle all bus models (PCI, VME, etc). I have over time developed a style for this kind of thing that I am comfortable with, and so I stick with it.Article: 98104
Hendra wrote: > Austin Lesea wrote: >> Matt, >> >> If you use a a cpld, you need to post in comp.arch.cpld >> >> Austin > > There is no comp.arch.cpld > I suspect he was being facetious, and just forgot the smiley ;)Article: 98105
Duane, Yes, I apologize for my sarcasm. I had just read the posting concerning newsgroups, and how to get the best answers from them. This post was a classic example of someone who had not even had the foresight to do any research on their own. Given that everyone who posts here has access to google (or any other search engine), it is generally annoying to see questions that could be answered by three minutes of browsing and reading. Sarcasm is the weapon of the weak, and I should have been more civil, Austin Duane Clark wrote: > Hendra wrote: > >> Austin Lesea wrote: >> >>> Matt, >>> >>> If you use a a cpld, you need to post in comp.arch.cpld >>> >>> Austin >> >> >> There is no comp.arch.cpld >> > > I suspect he was being facetious, and just forgot the smiley ;) >Article: 98106
When you wrote PortA address 17, you wrote into address 17 of RAM0 and RAM1. You also wrote 0 (meaning A is valid) into address 17 of VALID_BIT. When you read PortB address 17, you read address 17 of RAM1 and RAM3. You also read address 17 of VALID_BIT, which gives you back 0, telling you to select the output of RAM1. This gives you the value you just wrote to RAM1 when you wrote to PortA address 17. If you had written to address 17 via PortB last, then address 17 of VALID_BIT would have been set to 1, telling you to select the output of RAM3 instead. This would have been correct, since a write to portB would have written to RAM2 and RAM3. If you read portA address 17, you will read address 17 of RAM0 and RAM2 instead, and selected between those based on VALID_BIT. Or perhaps what you are missing is that each of these RAMs has a read port and a write port, which can be used simultaneously with independent addresses. This was one of the components that was described as being available. So PortB can be reading address 17 of RAM1 at the same time PortA is writing address 22 of RAM1.Article: 98107
Another clever solution. This requires the same amount of RAM as Ulf's scheme, but without requiring the 2Rd/2Wr VALID_BIT array. However, it may require a longer write cycle time, to allow completing the associated read and XOR with enough setup time for the write. But part of the write can overlap the read, so it should still be faster than the time-multiplexing approaches.Article: 98108
sharp@cadence.com wrote: > Another clever solution. This requires the same amount of RAM as Ulf's > scheme, but without requiring the 2Rd/2Wr VALID_BIT array. However, it > may require a longer write cycle time, to allow completing the > associated read and XOR with enough setup time for the write. But part > of the write can overlap the read, so it should still be faster than > the time-multiplexing approaches. What I did forget is that the memory may be synchronous read and write. If the read is asynchronous then this method still works but youre comment on timing is well taken. In the FPGA there's a nice, small setup time for memory address and data. An asynchronous read would require the address access time before that XOR. If the translation is from FPGA to ASIC, there may be enough margin in the timing to specify the read access and XOR from the address and the XOR alone from the data before the write strobe. If the ASIC memory is synchronous read without the async data, this method would require more RAMs and some feedback to account for just-written addresses. Is the memory 1Wr/2Rd memory primitive an asynchronous read?Article: 98109
but sarcasm is so much better than a pointy stick. Simon "austin" <austin@xilinx.com> wrote in message news:dude5h$ar25@xco-news.xilinx.com... > Duane, > > Yes, I apologize for my sarcasm. > > I had just read the posting concerning newsgroups, and how to get the > best answers from them. This post was a classic example of someone who > had not even had the foresight to do any research on their own. > > Given that everyone who posts here has access to google (or any other > search engine), it is generally annoying to see questions that could be > answered by three minutes of browsing and reading. > > Sarcasm is the weapon of the weak, and I should have been more civil, > > Austin > > Duane Clark wrote: > > > Hendra wrote: > > > >> Austin Lesea wrote: > >> > >>> Matt, > >>> > >>> If you use a a cpld, you need to post in comp.arch.cpld > >>> > >>> Austin > >> > >> > >> There is no comp.arch.cpld > >> > > > > I suspect he was being facetious, and just forgot the smiley ;) > >Article: 98110
http://sourceforge.net/projects/fpgac svn co https://svn.sourceforge.net/svnroot/fpgac/tags/fpgac.1.0.beta-2 fpgac.1.0.beta-2 CHANGES FROM FpgaC 1.0-beta to 1.0-beta-2F - A new html users manual has been updated for this release by John Bass. - Major changes to variable creation and naming have occured to implement declaration scoping more properly. Variable names can now be reused per Std C scoping rules. If you find problems, please bug report. - FOR loops and DO while loops have been added as alpha test by Rahul Menon please report any suprises. - Integer Multiply, Divide, and Mod/Remainder function interfaces have been added as alpha test for this release by John Bass. See users manual for details. - Preliminary intrinsic stubs for Floating point are now in the compiler. - Small LUT/BRAM based arrays and structures have been added as alpha test for this release by John Bass. See users manual for details. - A new concurrent process type has been added for testing. Functions declared with the type of fpgac_process will be started at load, and will loop implictly. See users manual for details. - Changes to support building on MS Windows Platforms by Isaac Pentinmaki - FpgaC specific keywords have been prefixed with fpgac_ to prevent naming conflicts. This was applied to all the #pragma names from the previous release. - new example code, including prototype work toward a PCI Target mode core.Article: 98111
"Antti Lukats" <antti@openchip.org> wrote in message news:ducf74$2d9$1@online.de... > "Marco T." <marc@blabla.com> schrieb im Newsbeitrag > news:dubove$q2j$1@nnrp.ngi.it... >> >> "Antti Lukats" <antti@openchip.org> wrote in message >> news:dubnbo$irm$1@online.de... >>> "Marco T." <marc@blabla.com> schrieb im Newsbeitrag >>> news:dubn68$pcc$1@nnrp.ngi.it... >>>> >>>> "Antti Lukats" <antti@openchip.org> wrote in message >>>> news:dubmqm$hct$1@online.de... >>>>> "Marco T." <marc@blabla.com> schrieb im Newsbeitrag >>>>> news:dubggf$n6a$1@nnrp.ngi.it... >>>>>> >>>>>> "Antti" <Antti.Lukats@xilant.com> wrote in message >>>>>> news:1141400003.663570.191020@i40g2000cwc.googlegroups.com... >>>>>>> yes >>>>>>> >>>>>> >>>>>> May I use the "configuration memory port" on the baseboard to write >>>>>> into atmel memory? >>>>>> >>>>> if that port has access to the atmel memory then yes? >>>>> >>>>> but why are you asking it, doesnt the memec board come with >>>>> documentation !? >>>>> >>>>> Antti >>>>> >>>> >>>> no documentation about it... >>>> >>>> Only one example that stores code into bram... not so useful. >>>> >>> >>> but they usually have some examples how to flash the serial rom at least >>> other memec boards have some docu, are you sure that there is nothing >>> relevant at memec online RDC ? did you look at all docs and examples at >>> RDC ?? >>> >>> Antti >>> >> >> >> There are two examples: the first that implements a webserver; the second >> is a demo that send datas to the serial connetor, tests the ddr, >> read/write datas into flash. >> But software is stored into bram and there is no documentation about >> storing software into flash. >> > > Dear Marco, > > c.a.f. is not memec-avnet support. > > memec uses Xilinx XAPP800 based solution for the FPGA config in several > boards, I assume also in the case of the mini module. For V4 board that I > have there is memec docu and script how to program the seiral flash over > SPI port using X_SPI, I assume something similar exists for the mini > module also > > as the minimodule has parallel flash so it is logical that memec guys > think that everyone uses parallel flash to store software applications, in > that case it is possible to use the flash_writer.tcl - it is very > unfriendly path but it works sometimes. > > if you want to use dataflash then just append your sw application code > after the config bitstream and thats it. in your soc you need to implement > spi bootloader what is about 30-40 lines of C code and can be written > within a few hours. Too bad that memec hasnt provided a demo with that 40 > lines, bad luck, you need to write them yourself. Of course you can use > some existing code but that may take more time than rewriting from > scratch. > > http://xilant.com/content/view/38/2/ > > there is a similar module where spi flash is used as config and sw storage > (linux image) i had absolutly no problems impementing the bootloader, well > actually the load process is 2 step, first a pre-boot loader (in BRAM) is > loading u-boot, then u-boot is taking aver to provide a more felxible > bootloader > > u-boot source code includes some dataflash support, for my case I had to > add the ST25 SPI support myself > > Antti > I know c.a.f. is not memec support and I'm sorry to have posted here. I have tried to contact reference design center through email, but I don't have receive any answer. So I thought to post into c.a.f. to know if someone has my trouble and in which way has solved it. I appreciate very much your help. I will try as you told. Many Thanks again. MarcoArticle: 98112
Hi all, my question is as follows, I am now going through a ppc design that I would like to run as follows : I need to use a internal BRAM for boot sequence and a NAND FLASH to contain all the code. the code will be placed and run on external SRAM. My question are as follows: 1) what should I choose as internal BRAM IF OCM or PLB_CTLR ? 2) Are there any better ways to design such a system ? Thanks in advance, Mordehay?Article: 98113
I own a notebook 700 MHz PIII / 256 MB / 10.4" / 1024*768. I am thinking of upgrading because ISE 6.3i runs very slooooowwwww with this notebook. Not to mention that at 1024*768, nothing much that I can see on the screen. I need higher resolution and faster CPU. 1. What screen resolution is the ideal one for ISE? 2. Which screen resolution that you usually use at work? 3. What is the ideal CPU speed and RAM if I limited my self to an FPGA less than 1.5 M gates with little constraint in the design. HendraArticle: 98114
I met problem while doing place for Spartan-3 in ISE 7.1 .They said.
Number of BUFGMUXs 2 out of 8 25%
Number of External IOBs 31 out of 221 14%
Number of LOCed IOBs 0 out of 31 0%
Number of Slices 9643 out of 13312 72%
Number of SLICEMs 52 out of 6656 1%
WARNING:Place:119 - Unable to find location. SLICEL component
ins_rsa_core_combine/U_reg[768] not placed.
......
......
.....
0,256 ins_rsa_core_combine/U_reg[1024]
ERROR:Place:120 - There were not enough sites to place all selected
components
I used large width register and adder in this design, the reg will map
into FF with the SLICES? And I can see SLICEM only used 52. If the
silces is not enough, why the tools did not use SLICEM?
kent
Article: 98115Kent I'm guessing you have a core here that is done for something like a Virtex-2. The SLICEM and SLICEL are something new in Spartan-3 where only 1 out of 2 slices can support a memory type use for LUTs in that slice. In an older Virtex2 all slices can support the memory function. So if you have a core that is a RPM or has equivalent constraints you may be trying to place a memory element where there is none and hence your error message. If it is constraints you can remove the LOC statement that causes the issue. Otherwise you are going to have to dig into the design with FPGA Editor and can edit the LOCs. John Adair Enterpoint Ltd. - Home of Hollybush1. The PC104+ Spartan3 Development Board. http://www.enterpoint.co.uk <kent.mou@gmail.com> wrote in message news:1141570916.501126.110560@i39g2000cwa.googlegroups.com... >I met problem while doing place for Spartan-3 in ISE 7.1 .They said. > Number of BUFGMUXs 2 out of 8 25% > Number of External IOBs 31 out of 221 14% > Number of LOCed IOBs 0 out of 31 0% > > Number of Slices 9643 out of 13312 72% > Number of SLICEMs 52 out of 6656 1% > WARNING:Place:119 - Unable to find location. SLICEL component > ins_rsa_core_combine/U_reg[768] not placed. > ...... > ...... > ..... > 0,256 ins_rsa_core_combine/U_reg[1024] > ERROR:Place:120 - There were not enough sites to place all selected > components > > I used large width register and adder in this design, the reg will map > into FF with the SLICES? And I can see SLICEM only used 52. If the > silces is not enough, why the tools did not use SLICEM? > > kent >Article: 98116
Martin, The PCI Compiler does not provide a way to handle interrupts in Avalon/SOPC Builder. Your options are to instantiate a small Nios II core, design your own IRQ management master.....or wait for the next release of the PCI Compiler core, which should certainly address this. - BrendanArticle: 98117
austin wrote: > > I am sorry that you feel compelled to post on this subject compulsively. > The only compulsive behavior demonstrated here is your continuing, insulting, and unwarranted attacks on me when I suggest a simple method to make your parts work better. You've had over five years to produce some sort of V2 app note on how to deal with high speed drivers, but haven't; instead, you flame up my posts when I point out problems and workarounds. > > I am sorry to see that you discredit yourself in public by posting a > spice fantasy. > Better a SPICE fantasy than an IBIS nightmare. I wouldn't trust any results until confirming them in the lab on actual hardware, which I stated quite clearly in those simple simulation models. Regardless of the exact accuracy of the simulation, the advantages of adding extra attenuation (when the drive strength is available) should be clear with either method of simulation. For SI work, IBIS is basically a faster SPICE with blinders on. It has merits in certain situations, like automatic SI verification of a massive autorouted line card, but I prefer to start in SPICE, verify in the lab by prototyping, then use those results to guide and cross-check any post-layout IBIS simulations. > >I am sorry I took your posting seriously enough to do a > real simulation and show that there is no problem > You didn't show us anything! You just made a lot of noise, insulted me yet again, and once again lacked the backbone to back up, with data, your ridiculous claims that there's nothing wrong with having a Cin of 10 pf (single ended) when dealing with sub-200 ps input edge rates from a fast driver. > > I am sorry that I have been unable to resolve this issue with you in a > mutually positive way. > Making parts with better Cpin would resolve things quite nicely. BrianArticle: 98118
Matt Clement wrote: > Hey guys/gals > > What are the advantages and disadvantages of using a CPLD instead of using > an FPGA for a design? The answer to the heading is "You wouldn't" - if 'a CPLD will do', in engineering terms means meet/exceed the price performance levels of a FPGA. The more general answer, of when to choose FPGA or CPLD, changes over time. 10 years ago, CPLDs were cheap, non volatile logic, but most had High Iccs. FPGAs were all SRAM based, and had low Static Iccs. Now, the distinction is much more blurred : # There are FPGAs with on Chip FLASH, [Lattice, Actel] # FPGA static Icc is no longer low, but can hit hundreds of mA (!) # Newest CPLDs from Altera, Lattice have FPGA fabric, but CPLD-like FLASH - but at the same time, they have moved up the 'smallest device' point, so there are no real low cost members in this family. # Lowest power devices are now the CMOS structure ones from Xilinx, Lattice, Atmel. # Above a certain Logic size, FPGAs tend to self-select over the thinning ranks of large CPLDs In many cases, designs have BOTH CPLD and FPGA, and the CPLD can be used to Boot the FPGA, via cheaper memory, and/or to control power off, to have deeper sleep modes. -jgArticle: 98119
Hi Isaac, igelado@gmail.com wrote: > No, I did not, because the misc_logic is written in Verilog and I have > no idea about Verilog, so I "ported" that piece of code to VHDL. The > code in Verilog is as follows: > > always @(posedge clk) > pci_int_or <= (~pci_inta) | (~pci_intb) | (~pci_intc) | (~pci_intd) > | (~pci_inte) | (~pci_intf) | (~pci_core_intr_a) | (sbr_int); > > Which I wrote in VHDL as: > process(clk) > if(clk'event and clk='1') then > pci_merge <= pci_sbr or not pci_inta or not pci_intb or not pci_inc > or not pci_ind or not pci_inte or not pci_intf ot not pci_core_intr_a; > end if; > end process; I'm not much of a verilog guy either, but your translation looks ok to me. > I think both codes are doing the same, aren't they? However, the base > configuration from Xilinix is using a really old opb2pci bridge (if I > try using it I get an error because it is deprecated) and I'm using the > latest one. Both cores have the same interrupt lines, but I do not know > if they are compatible. > > My first guess was that maybe in the current core the pci_int<a> lines > are active in high, so instead of merging the signals inverting the > pci_int<a> and making a logical or I didn't invert them. Unfortunately > the result was the same :(. Right now I am merging all the signals as > shown on the previous VHDL code but not using pci_inte, pci_intf > pci_core_intr_a, which I think there are not used by my hardware > configuration. With this schema only the PCI-IDE controller is getting > interrupts. I'm not sure what's going on here. Looking back to your first post on this topic, you mentioned that in Xilinx's design there were multiple interrupt signals connected: "Looking at the system.vhd I see that the SBR pin is connected to the interrupt 0, lines PCI<n>_INT are connected to interrupts 1 to 6, and the IP2INTC line is connected to interrupt 12. The problem is that I don't know which line is actually used to deliver the interrupts coming from the PCI devices. I've tried using all of them, but all attempts were failed." This contradicts the idea of merged interrupts that we've discussed subsequently. Maybe there's a clue in there somewhere? Sorry I can't be more help, this stuff is fiddly and probably won't work at all until you get it exactly right. ChipScope might help, to at least see what's going on inside with the various interrupt signals etc. Also, the time-honoured tradition of peppering your kernel with printk() calls should not be overlooked. Sometimes that's easier than trying to debug/single step the thing, particularly where interrupts are involved. The "Understanding the Linux kernel" book, and also "Linux Device Drivers" will give you pointers on where in the source you should be looking. Regards, JohnArticle: 98120
"Love Singhal" <lovesinghal@gmail.com> wrote in message news:1141379383.985179.15670@i40g2000cwc.googlegroups.com... > Hi Frank, > >From what I have read in the documents (I have not implemented the > complete flow yet), the support for partial reconfiguration has indeed > evolved in Virtex 4. > First, the Planahead tool handles modular based flow better than just > the floorplanner in the previous modular based flow. > Second, the Virtex 4 has fixed size frames (16 clbs) based partial > reconfiguration rather than a column based partial reconfiguration. > This basically means that there can be multiple frames in one column of > any Virtex 4 device. Thus, the whole column does not have to be > reconfigured all at once. This could reduce a lot of complexity for > interconnects that connects one side of reconfigurable region to > another side (they do not have to be routed using long wires only, for > example). > I think designs with partial reconfiguration could be implemented > better in Virtex 4 than in Virtex 2, but as I said, I have not yet > implemented the complete flow. > > Love Singhal > http://www.ics.uci.edu/~lsinghal > Frame based partial reconfiguration is really neat. Next time I will definitely try them out, but is the software available in Webpack 8?Article: 98121
Duane,
"Duane Clark" <dclark@junkmail.com> wrote in message
news:stpOf.27023$_S7.14217@newssvr14.news.prodigy.com...
>
> I'm not sure what a write-only bit is ;) But the register method I use
> certainly allows all sorts of flexibility, and having a a bit be self
> clearing is easy to do this way.
A write-only bit can be something as simple as this (please ignore syntax
errors if any :)):
process ()
begin
if rising_edge(clk) then
wr_only_bit <= bus_address_match and write_en else;
end;
end process;
If it needs to cross the clock domains it can be resynchronized to another
clock.
You got me confused. You said you started with the GPIO core and you are
saying that you can do self-clearing bits with it somehow. Could you please
elaborate a little bit?
> Partly my going this direction is driven by the method I use for
> performing VHDL simulations. I don't bother with the complex BFM PPC
> models provided by Xilinx, and don't simulate the processor memory.
> Instead, I wrote a simple functional model of my own which correctly
> handles the basic read and write bus operations on the PLB bus. I do use
> the Xilinx supplied models for the PLB and OPB buses, arbiters, etc. It
> is accurate enough that the components always work in the real system,
> and is simple to use and simulates fast. In part, I ended up with a
> system like that because it is the way I handle all bus models (PCI,
> VME, etc). I have over time developed a style for this kind of thing
> that I am comfortable with, and so I stick with it.
I've been using a similar approach when simulating local bus of a PCI
controller in my previous designs... However, I am again a little confused
about what exactly you are doing. On one hand you are saying that you wrote
a simple model of your own that handles basic PLB read/write operations. On
the other hand you are saying that you are using Xilinx supplied bus
models... I guess I am missing something, perhaps because I haven't looked
at the Xilinx models yet... But I would appreciate if you could explain what
you are doing in a little more detail...
Thanks,
/Mikhail
Article: 98122I am responsible for the partial reconfiguration software. Let me try to answer all of the questions posted: Q: Does the released ISE software support partial reconfiguration? A: In some cases, yes. Q: Does anyone have a commercial product that successfully employed partial reconfig? A: Yes, there are a few. Q: Why did Xilinx say partial reconfig worked when most of the time, it doesn't? A: We released software for partial reconfig about 4 years ago. At that time, there was a flow that worked if you did everything in the right way. There were a couple of people in my group that were assigned to help customers through the mine field. It was rare that our sales force told us about customers using partial reconfig, so we assumed that nobody was using it. Because of other priorities, and the apparent lack of interest, the partial reconfig software languished. Q: Is there a killer app that will drive Xilinx to put the effort needed to make partial reconfig a workable flow? A: Yes. There are software defined radio applications that are lucrative enough to get our attention. Q: Does Xilinx now have software that works for partial reconfig? A: Yes. We have a team that has modified the current software, created a new flow, and tested the software with different applications. In addition, PlanAhead makes it much easier to lay out your design and run DRCs to ensure that partial reconfig will work. Q: How do I get this software? A: Contact your local FAE. If you're at a university, contact the university program. Our Xilinx Labs research department is supporting the universities. Q: Why don't you release the software with ISE? A: The plan is to release it with ISE in version 9.1i. For now, we have an efficient team assigned to refine the flows and fix bugs as soon as they are found. Q: Is frame reconfiguration really cool? A: Yes. However, Virtex2 and Virtex2-Pro together with our new software let you do what could be considered a partial frame write. Even though you are writing the entire frame (column), Virtex devices don't glitch when you write exactly the same config bits. This allows you to have static logic above or below a reconfig region. We reconfigure the static region, but it continues to work. This also allows us to have static routes that pass through a reconfig region. The software reserves these routes when routing the reconfig region. Q: The software license fees are $3k - $5k. How can we use this for reconfigurable computing? A; I'm not sure where these prices came from. If you are creating a reconfigurable computer, contact me and we can discuss an OEM deal for much less money. Q: Should I feel comfortable adding partial reconfig to my current application? A: Personally, I would wait a couple of months. We are currently rolling out the software to our SDR customers and will be spending our effort supporting them. In addition, many of the FAEs have not been trained on the new partial reconfig flow. And they are the first line of support. SteveArticle: 98123
oh, I see. it seems that you only use the convenient building process of uClinux and in fact the source code is based on ppclinux dist. am I right? thank you! wickyArticle: 98124
"wicky" <wicky.zhang@gmail.com> schrieb im Newsbeitrag news:1141621361.704629.39410@j52g2000cwj.googlegroups.com... > oh, I see. it seems that you only use the convenient building process > of uClinux and in fact the source code is based on ppclinux dist. am I > right? > > thank you! > > wicky > exactly! 100% its just simplicity that counts build run and it works! antti
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