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
On 24 nov, 10:40, Petter Gustad <newsmailco...@gustad.com> wrote: > jc <jcappe...@optimal-design.com> writes: > > A great way to test your ram limits, as I found out, is to run Xilinx' > > SmartXplorer. It will run on as many processor cores as you specify, > > I did run something which was an earlier version of SmartXplorer on > Solaris probably 10 years ago. In addition to running P&R's on a > multicore CPU you could also run on multiple hosts (actually to run on > multicore you specified the machine name multiple times using > different casing). I ran the tool mostly across multiple machines as > it scaled better in terms of memory cost. It was much cheaper to fit a > set of smaller machines with a smaller amount of memory than to > upgrade the big servers. > > I haven't used SmartXplorer so I don't know if you can run on multiple > hosts. > > > in several hours (not days). In my search for a memory upgrade, I > > realize that this particular system is limited to 16G ram because of > > the OS (Windows 7 Home Premium 64-bit). From what kkoorndyk stated > > According tohttp://www.xilinx.com/ise/ossupport/index.htm > Windows 7 will not be fully supported until ISE 13. > > > about Xilinx recommendations, I'm going to need an OS upgrade if I > > want to handle semi-packed V6 designs completely in ram. Sigh. > > Upgrade to Linux... > > Petter > -- > .sig removed by request. Do you have a suggestion for Linux? For example, can we use Ubuntu or should we stick with the "Xilinx-approved" linux flavors?Article: 149801
On Nov 16, 6:09=A0am, David Brown <da...@westcontrol.removethisbit.com> wrote: > On 15/11/2010 19:21, rickman wrote: > > My gut feeling here is that you are not going to get significant > resonance between the power plane and the bypass capacitors, especially > if the power "plane" is actually just a polygon, and therefore fairly > small, while the capacitors are large. =A0The power "plane" is then far > too small in comparison to have a noticeable effect on the bypass > capacitor, and therefore the bypass capacitor will work as expected. > The power "plane" (viewed as a capacitor) is mainly for bypassing very > high frequencies - these will be isolated from the bypass capacitors by > the capacitors' inductance and ESR, thus it will also continue to work > as expected. I have no idea why your gut feels the way it does. All you need to do is gin up a simple spice circuit and check its response vs. frequency.... at high frequencies, say 100 MHz to 5 GHz. You will see this clearly. The idealized circuit does perform worse than a real circuit because this is one of the times when the parasitic effects can help you. The ESR of the cap prevents it from having a sharp Q and a very high impedance at resonance. But it will have a resonance and it can easily create a problem at some specific frequency. The seat of the pants analysis you gave has nothing to do with the resonance effect. In fact, you seem to think the inductance of the bypass caps "isolate" them from a resonance effect while it is this inductance that *creates* the resonance when coupled with the power planes capacitance. > And again the disclaimer - I haven't worked with this sort of thing in > practice (the fastest card I have made was about 200 MHz), nor have I > studied the theory or the maths here in detail. =A0My theories are based > on reading articles and guides, thinking about how things work, reading > c.a.f., etc. =A0I am posting here to ask and learn, and perhaps also to > make the experts here think. Please do some searches on power supply decoupling and resonance effects. I am sure Lee Ritchey is not the only person who knows about this. I heard it from others before him, but didn't take it seriously. One thing about power supply system design and decoupling... it is not hard to make one that works. But to know that it will work before you build it, that takes some knowledge. The old rule of thumb of adding a cap per power pin is pretty useless. So too are all the other "guidelines" that aren't based on theory, simulation and testing... all three. There are lots of things that may sound good until you actually verify them. The single most surprising fact I got from the high speed digital design course was that not only are much fewer caps needed than expected, but they don't need to be especially close to the power and ground pins of the chip! RickArticle: 149802
I'm trying to define a macro for a simple two-flop synchronizer in an ISE
project:
`define XCLK_SYNC_2DFF(q, d, clk) \
reg __sync__``q; \
always @(posedge clk) \
begin \
__sync__``q <= d; \
q <= __sync__``q; \
end \
XST errors out on this; I believe the `` is SystemVerilog syntax which XST
doest not support. But the following doesn't work either:
`define XCLK_SYNC_2DFF(q, d, clk) \
reg sync; \
always @(posedge clk) \
begin \
sync <= d; \
q <= sync; \
end \
Limited though the utility of such a macro may be, shouldn't the
preprocessor just dump the lines above, substituting for q, d and clk
wherever it sees a `XCLK_SYNC_2DFF invocation in the source? Does
Verilog-2001 specifically forbid creation of temp regs/wires within macros?
Is there any way to code this macro while keeping XST happy? Or should I
just create a separate module/inline the code?
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 149803"Chris Maryan" wrote in message news:6092db29-96e8-45ce-8870-9069272dc561@o4g2000yqd.googlegroups.com... On Nov 23, 5:00 pm, "Roger" <rogerwil...@hotmail.com> wrote: > The latest Xilinx PlanAhead seems to do everything that a project needs > from > VHDL input to bit stream. So what's ISE for now? > > Thanks, > Rog. My understanding is that the plan is for PlanAhead to replace ISE. Though I'm not sure at what point this will happen. Chris Chris, Thanks for the reply. I suspected this might be the case. Did you hear this from Xilinx? Rog.Article: 149804
On 11/24/2010 07:01 AM, gnirre wrote: > > So Stellarton is basically a product that is the optimal choice for > almost no application, almost always too small, or too expensive. > > So why did Intel have this one built? Who ordered it? Which is the One > Single App where an Atom E and 60 000 fpga gates is the optimal > combination? Well, I sort of have one. I make some boards that interface to X86 systems through the parallel port, and generate signals to run stepper or servo drives. I currently use a Xilinx Spartan IIE 50K gate part, and have to add several voltage regulators and a bunch of voltage level translators. I definitely don't want to get into CPU board design, the high data rates to memory, etc. make any design somewhat speculative, and I really want to avoid multiple revisions. Also, I'm not set up to do anything finer than 0.4 mm lead pitch on leaded parts, no BGA capability. If there were a board that brought out the necessary number of pins, then I'd still need to supply the level translator chips. So, really, the only benefit is a better interface between CPU and the FPGA, as opposed to the parallel port in EPP mode. So, while it would be possible to use this platform, I'm not sure it buys me anything. I can get an Atom mini-ITX motherboard with memory, power supply and SSD for a little over $100, and it still had an EPP parallel port. Oh, the application is a CNC motion control program called EMC2, it runs under Linux with RTAI. JonArticle: 149805
On Wed, 24 Nov 2010 13:50:39 -0600, "currentsource" wrote: >I'm trying to define a macro for a simple >two-flop synchronizer in an ISE project: > >`define XCLK_SYNC_2DFF(q, d, clk) \ >reg __sync__``q; \ >always @(posedge clk) \ > begin \ > __sync__``q <= d; \ > q <= __sync__``q; \ > end \ > >XST errors out on this; I believe >the `` is SystemVerilog syntax Right, it's the "token gluing" operator as you've seen. > But the following doesn't work either: > >`define XCLK_SYNC_2DFF(q, d, clk) \ >reg sync; \ >always @(posedge clk) \ > begin \ > sync <= d; \ > q <= sync; \ > end \ > Really? I can easily imagine that it will fail to compile if you use the macro more than once in the same scope, because it will create more than one "reg sync". But a single use of it should be OK - provided you DON'T put a semicolon on the end of the macro invocation. Surely it would be easier just to make a module? That's what they're for, after all. The extra layer of hierarchy is completely free in hardware, and has a negligible impact on simulation performance. And it saves all the macro kruft. Jonathan BromleyArticle: 149806
On Wed, 24 Nov 2010 11:22:33 -0800 (PST), rickman wrote:
> Instead of (rising_edge(clk)) I had used ('1' = clk).
...
>With the way a simulation works,
>comparing the clock to '1' gives exactly the same results as
>rising_edge. Given the function of the sensitivity list, it seems
>like the rising_edge function should be redundant.
BE CAREFUL!
If there was no asynch reset in your process, then what probably
happened was that the tool saw
process (clock) begin if clock='1' then...
Not recognizing a standard clocked process, the tool would
then assume it had a combinational process. Betcha there
was a warning somewhere in the synth report about automatically
completing the incomplete sensitivity list. Consequently you
got a pile of transparent latches, enabled (made transparent)
by clock='1'.
On the other hand...
If you have an asynch reset in your sensitivity list, it is
simply not true that rising_edge is redundant.
Consider
process (clock, reset) begin
if (reset = '1' then
do-reset-ish-things;
elsif clock = '1' then
do-clocked-things;
end if;
end process;
Suppose clock is held at '1', with no edges, and you take
reset from true to false. The process trips, reset='0' so
the reset action doesn't happen, clock='1' so the clocked
action DOES happen. Bzzzt! you got a spurious extra clock
action on the trailing edge of reset.
That is why the old-fashioned (pre std_logic_1164) style
of VHDL clocked process, still seen in some dinosaur code
today, looks like this:
process (clock, reset) begin
if (reset = '1' then
do-reset-ish-things;
elsif clock'event and (clock = '1') then
do-clocked-things;
end if;
end process;
Note the extra clock'event test! The rising_edge
function includes exactly this test.
This is also the reason why Verilog clocked process
sensitivity lists look like
always @(posedge clock or posedge reset)
The "posedge reset" often mystifies beginners - hey,
it's a level-sensitive reset, isn't it? - but exactly
the same problem arises of a spurious clock action in
simulation on the trailing edge of reset. Indeed, it's
even worse in Verilog because you don't test the clock
level (posedge did that for you!) so the spurious action
occurs regardless of the value of clock.
Many synth tools will simply choke on any non-standard
form of clocked process; your tool evidently made the
best it could of it, with appropriately disastrous results.
Sorry to hear about your wasted time. Sounds to me like
a good argument for tools NOT to complete the sensitivity
list automatically when they think they've found a
combinational process.
--
Jonathan Bromley
Article: 149807Benjamin Couillard <benjamin.couillard@gmail.com> writes: > Do you have a suggestion for Linux? For example, can we use Ubuntu or > should we stick with the "Xilinx-approved" linux flavors? I would suggest that you use the Xilinx approved ones. However, I've used mostly Gentoo Linux with both Altera and Xilinx (as well as with lots of Synopsys software), which have worked quite well. There has been times where I've hacked some of the scripts which tries to detect the platform type, mostly it's the installation software which have caused problems. I tend to use a script based flow. I only use the GUI occasionally, hence my usage might be somewhat "nicer" than the typical Windows user. But I always keep a Red Hat installation in VirtualBox so that I can verify any problems before I report them and then say "yes" if I'm asked if I'm on a supported operating system. Petter -- .sig removed by request.Article: 149808
gnirre <gnirre@gmail.com> writes: > So why did Intel have this one built? Who ordered it? Which is the One > Single App where an Atom E and 60 000 fpga gates is the optimal > combination? I don't know which is the one single application for this device. But it would be nice to use the FPGA to connect to video/audio interfaces and do image processing, then let the Atom to run the GUI and the network stack. Petter -- .sig removed by request.Article: 149809
On 11/24/2010 3:06 AM, Piotr Wyderski wrote: > Thomas Entner wrote: >> - In the past, Hard-Core-CPU + FPGA-combinations from Altera and >> Xilinx were no success. > > I don't think the Virtex family is a failure. I have heard people at Xilinx say that the embedded PowerPC CPUs in the Virtex line were a failure. $ wise.Article: 149810
In article <nYKdnXW5a-Bi7HDRnZ2dnUVZ_q6dnZ2d@giganews.com>, Jon Elson <jmelson@wustl.edu> wrote: >> So why did Intel have this one built? Who ordered it? Which is the One >> Single App where an Atom E and 60 000 fpga gates is the optimal >> combination? >Well, I sort of have one. I make some boards that interface to X86 >systems through the parallel port, and generate signals to run stepper >or servo drives. I currently use a Xilinx Spartan IIE 50K gate part, >and have to add several voltage regulators and a bunch of voltage level >translators. I definitely don't want to get into CPU board design, the >high data rates to memory, etc. make any design somewhat speculative, >and I really want to avoid multiple revisions. Also, I'm not set up to >do anything finer than 0.4 mm lead pitch on leaded parts, no BGA >capability. If there were a board that brought out the necessary number >of pins, then I'd still need to supply the level translator chips. > >So, really, the only benefit is a better interface between CPU and the >FPGA, as opposed to the parallel port in EPP mode. I think two lanes of PCI-E is a qualitatively better interface than the parallel port in EPP mode (4 gigabit per second each way); on the other hand you obviously don't need gigabit interface rates to go to servo motors, and the Atom+Altera chip will be using low-voltage IO and on aggressive lead-free BGAs so you still have the soldering issues and need the level translators. TomArticle: 149811
Is it acceptable to have 2D input ports using System Verilog? I know it's not possible in Verilog. The only workaround I could think of is to 'flatten' out the input port and use it; but that seems to be messy inside loops. Is there any other workaround?Article: 149812
On Nov 24, 6:46=A0pm, John Smith <redditor...@gmail.com> wrote: > Is it acceptable to have 2D input ports using System Verilog? Sure. It allows just about anything: arrays, structures, interfaces (obviously). Now, whether your synthesis tool handles these constructs is another question that needs to be asked of the vendor.Article: 149813
Hi Kindly if there is any tutorial/example available on xilinx XPS ethernet MAC lite (for Virtex4 PPC), let me know it. Thanks --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149814
Andy "Krazy" Glew wrote:
> I have heard people at Xilinx say that the embedded PowerPC CPUs in the
> Virtex line were a failure. $ wise.
OK -- if *you* say that, I take it for granted.
Best regards
Piotr Wyderski
Article: 149815On 11/20/2010 10:27, Thomas Heller wrote: > Which series / package should I choose for long availability? What's long in your terms? I'm in the measurement equipment industry, our oldest products have been on the market for fifteen years and they contain Xilinx FPGAs that have been introduced about seventeen years ago, which have been discontinued lately. Usually, we aim for parts which are targeted at the automotive industry since they have the tendency to have a longer lifetime. - Philip -- Some of the best things in life are total mistakes. (Rachel Porter)Article: 149816
On Nov 24, 8:22=A0pm, rickman <gnu...@gmail.com> wrote: > > I wish I had a smart(er) editor that understood VHDL a bit more. Hi Rick, You might want to take a look at Sigasi: http://www.sigasi.com We have a VHDL development environment with a VHDL parser inside. This way, as you put it, the VHDL editor "understands" what you type. > I have some search/replace regex strings I copy and paste from one file > to another which change an entity port list into a port map or a > signal list. =A0This helps with the tedium of instantiation. Thirty second screencast on instantiations: http://www.sigasi.com/screencast/entity-instantiation kind regards -- Philippe Faes SigasiArticle: 149817
On 24/11/2010 20:38, rickman wrote: > On Nov 16, 6:09 am, David Brown<da...@westcontrol.removethisbit.com> > wrote: >> On 15/11/2010 19:21, rickman wrote: >> >> My gut feeling here is that you are not going to get significant >> resonance between the power plane and the bypass capacitors, especially >> if the power "plane" is actually just a polygon, and therefore fairly >> small, while the capacitors are large. The power "plane" is then far >> too small in comparison to have a noticeable effect on the bypass >> capacitor, and therefore the bypass capacitor will work as expected. >> The power "plane" (viewed as a capacitor) is mainly for bypassing very >> high frequencies - these will be isolated from the bypass capacitors by >> the capacitors' inductance and ESR, thus it will also continue to work >> as expected. > > I have no idea why your gut feels the way it does. All you need to do > is gin up a simple spice circuit and check its response vs. > frequency.... at high frequencies, say 100 MHz to 5 GHz. You will see > this clearly. The idealized circuit does perform worse than a real > circuit because this is one of the times when the parasitic effects > can help you. The ESR of the cap prevents it from having a sharp Q > and a very high impedance at resonance. But it will have a resonance > and it can easily create a problem at some specific frequency. > > The seat of the pants analysis you gave has nothing to do with the > resonance effect. In fact, you seem to think the inductance of the > bypass caps "isolate" them from a resonance effect while it is this > inductance that *creates* the resonance when coupled with the power > planes capacitance. > Yes, that is pretty much how I thought - but you have given me cause to think again. I will have to take your advice and try some simulations - that's probably the best way for me to see what's happening, where the resonances are coming from, and the sort of effect they have. Until I have proved otherwise, I'll take your word over my gut feeling here. > >> And again the disclaimer - I haven't worked with this sort of thing in >> practice (the fastest card I have made was about 200 MHz), nor have I >> studied the theory or the maths here in detail. My theories are based >> on reading articles and guides, thinking about how things work, reading >> c.a.f., etc. I am posting here to ask and learn, and perhaps also to >> make the experts here think. > > Please do some searches on power supply decoupling and resonance > effects. I am sure Lee Ritchey is not the only person who knows about > this. I heard it from others before him, but didn't take it > seriously. > The thing about searching on-line for this sort of thing is that there is no consistency in the answers. Either there are several different ways to do good bypassing, or the reality is that it doesn't matter too much. But it's easy to find "experts" (some of whom may actually /be/ expert) advocating multiple large power planes, or no power planes, lots of capacitors or few capacitors, lots of capacitor values or few capacitors, capacitors placed on the backside under the component or capacitors just roughly in the neighbourhood. A bit of spice simulation is what I need here. > One thing about power supply system design and decoupling... it is not > hard to make one that works. But to know that it will work before you > build it, that takes some knowledge. The old rule of thumb of adding > a cap per power pin is pretty useless. So too are all the other > "guidelines" that aren't based on theory, simulation and testing... > all three. There are lots of things that may sound good until you > actually verify them. The single most surprising fact I got from the > high speed digital design course was that not only are much fewer caps > needed than expected, but they don't need to be especially close to > the power and ground pins of the chip! > On the boards I have worked on (which were not more than about 200 MHz), I didn't have nearly as many as one capacitor per power pin, and I scattered them around to a fair extent. So my "gut feeling" gave me a similar result in the end.Article: 149818
> Upgrade to Linux... > > Petter > You won't find me defending windows for its lack of robustness (among other nuisances), and I understand the impact Linux has had on EDA and general development environments, but I did notice from the links kkoorndyk provided that Xilinx' memory recommendations are identical for Windows and Linux, at least for Virtex-5... JohnArticle: 149819
Philippe <philippe.faes@gmail.com> writes: > On Nov 24, 8:22 pm, rickman <gnu...@gmail.com> wrote: >> >> I wish I had a smart(er) editor that understood VHDL a bit more. > > Hi Rick, > > You might want to take a look at Sigasi: http://www.sigasi.com Seconded... Although I haven't bought a license (sorry Philippe!), as during my eval, I still kept ending up back in Emacs, I will be recommending it to my "less text-based" colleagues :) And I may still get one for myself for the refactoring tools. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 149820
jc <jcappello@optimal-design.com> writes: >> Upgrade to Linux... >> >> Petter >> > > You won't find me defending windows for its lack of robustness (among > other nuisances), and I understand the impact Linux has had on EDA and > general development environments, but I did notice from the links > kkoorndyk provided that Xilinx' memory recommendations are identical > for Windows and Linux, at least for Virtex-5... > John My comment was out of context. I was thinking about some earlier message which indicated that it was a cost related to upgrading to large memory support on the Windows platform. Here Linux would help. I did not mean that Xilinx SW on Linux requires any less memory than on Windows. Petter -- .sig removed by request.Article: 149821
On 24/11/2010 22:22, Petter Gustad wrote: > Benjamin Couillard<benjamin.couillard@gmail.com> writes: > >> Do you have a suggestion for Linux? For example, can we use Ubuntu or >> should we stick with the "Xilinx-approved" linux flavors? > I have no experience with fpga design in Linux, but if Xilinx approves Red Hat, then Fedora, Centos or Scientific Linux would alternatives that are pretty close to Red Hat enterprise versions. I'd avoid SUSE at the moment, even if it's approved by Xilinx - it's future is somewhat insecure. > I would suggest that you use the Xilinx approved ones. However, I've > used mostly Gentoo Linux with both Altera and Xilinx (as well as with > lots of Synopsys software), which have worked quite well. There has > been times where I've hacked some of the scripts which tries to detect > the platform type, mostly it's the installation software which have > caused problems. > > I tend to use a script based flow. I only use the GUI occasionally, > hence my usage might be somewhat "nicer" than the typical Windows > user. > > But I always keep a Red Hat installation in VirtualBox so that I can > verify any problems before I report them and then say "yes" if I'm > asked if I'm on a supported operating system. > > PetterArticle: 149822
Hi all,
I am trying to build external SEU generator for our experimental purposes.
The basic idea is similar to the SEU generation makro from Xilinx, the
only difference is that I want to generate SEU through JTAG interface (so
the generator is not able to damage itself).
The generator requires to readback the configuration frame from the FPGA,
make some change (only one bit to simulate SEU) and write it back.
Unfortunatelly, I failed in the first part. I am not able to readback
anything from the FPGA. I am using the ML506 development board and I am
sure I missed something essential. I am hoping, that there is someone who
has any experiences with the readback and is able to tell how I could
readback something from FPGA (configuration prefferably).
I am trying to use chipscope to readback status register from the FPGA as
it is described in UG191 table 7-5 (I readed also AppNote138 and 139) but
I receive only IDcode of the device:
I open the connection to the JTAG and it works (I am able to reconfigure
device)
set Chain [csejtag_tap autodetect_chain $handle $CSEJTAG_SCAN_DEFAULT]
;#discover all JTAG chain connected to the cable
set CFG_IN "3C5" ;# define instruction for JTAG controller
set CFG_OUT "3C4"
set DUMMY "FFFFFFFF"
#bitstream commands
set SYNC "AA995566"
set NOP "20000000"
set READSTAT "2800E001"
#step1
csejtag_tap navigate $handle $CSEJTAG_TEST_LOGIC_RESET 5 0 ;# Resets
JTAG controller
csejtag_tap navigate $handle $CSEJTAG_RUN_TEST_IDLE 0 0 ;# Resets JTAG
controller
csejtag_tap navigate $handle $CSEJTAG_SELECT_IR_SCAN 0 0 ;# Resets JTAG
controller
csejtag_tap navigate $handle $CSEJTAG_SHIFT_IR 0 0 ;# Resets JTAG
controller
#step2
csejtag_tap shift_device_ir $handle 4 $CSEJTAG_SHIFT_WRITE
$CSEJTAG_SELECT_DR_SCAN 0 10 $CFG_IN ;#Loads CFG_IN into the
configuration register of the JTAG
csejtag_tap navigate $handle $CSEJTAG_SHIFT_DR 0 0
#step3
csejtag_tap shift_device_dr $handle 4 $CSEJTAG_SHIFT_WRITE
$CSEJTAG_SHIFT_DR 0 32 $SYNC
csejtag_tap shift_device_dr $handle 4 $CSEJTAG_SHIFT_WRITE
$CSEJTAG_SHIFT_DR 0 32 $NOP
csejtag_tap shift_device_dr $handle 4 $CSEJTAG_SHIFT_WRITE
$CSEJTAG_SHIFT_DR 0 32 $READSTAT
csejtag_tap shift_device_dr $handle 4 $CSEJTAG_SHIFT_WRITE
$CSEJTAG_SHIFT_DR 0 32 $NOP
csejtag_tap shift_device_dr $handle 4 $CSEJTAG_SHIFT_WRITE
$CSEJTAG_SELECT_IR_SCAN 0 32 $NOP
csejtag_tap navigate $handle $CSEJTAG_SHIFT_IR 0 0
#step4
csejtag_tap shift_device_ir $handle 4 $CSEJTAG_SHIFT_WRITE
$CSEJTAG_SELECT_DR_SCAN 0 10 $CFG_OUT
csejtag_tap navigate $handle $CSEJTAG_SHIFT_DR 0 0
#step5
set stat [ csejtag_tap shift_device_dr $handle 4 $CSEJTAG_SHIFT_READ
$CSEJTAG_SELECT_IR_SCAN 0 32 $DUMMY]
puts $stat
puts $DUMMY
Thank you for any help or related comment.
Jan
Article: 149823On Wed, 24 Nov 2010, Roger wrote: > > > "Chris Maryan" wrote in message > news:6092db29-96e8-45ce-8870-9069272dc561@o4g2000yqd.googlegroups.com... > > On Nov 23, 5:00 pm, "Roger" <rogerwil...@hotmail.com> wrote: >> The latest Xilinx PlanAhead seems to do everything that a project needs >> from >> VHDL input to bit stream. So what's ISE for now? >> >> Thanks, >> Rog. > > My understanding is that the plan is for PlanAhead to replace ISE. > Though I'm not sure at what point this will happen. > > Chris > > Chris, > > Thanks for the reply. I suspected this might be the case. Did you hear this > from Xilinx? > > Rog. > I do not have the experience with the newest PlanAhead but we tried the dynamic reconfiguration on the ISE11 with PlanAhead and it was not possible to turn RTL project into partial reconfiguration flow. So i suspect, that the ISE and planAhead will be moving in different direction. But it is just my understanding, maybe it was just a bug. JanArticle: 149824
On Nov 24, 3:01=A0pm, gnirre <gni...@gmail.com> wrote: > On Nov 24, 12:03=A0am, Thomas Entner <thomas.ent...@entner- > > > > So Stellarton is basically a product that is the optimal choice for > almost no application, almost always too small, or too expensive. > > So why did Intel have this one built? Being cynical, because they have MCM technology. Unlike current generation, Intel's next generation desktop/laptop processors are single die so the MCM packaging guys @Intel will have to go unless there is something new to keep them busy. > Who ordered it? Which is the One > Single App The whole point behind the combo is : Not One App But Many. > where an Atom E and 60 000 fpga gates is the optimal > combination? > > - Jan T=E5ngring, journalist ~60,000 equivalent logic elements. That's something like 1.5M to 2M gates just in fabric without counting embedded memory, multipliers, "hard" PCIe IP block, transceivers etc... Intel site doesn't tell us which Altera chip they are using, but from description it looks like EP2AGX65.
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