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 Nov 22, 4:28=A0pm, Benjamin Couillard <benjamin.couill...@gmail.com> wrote: > Hi everyone > > I've heard from a friend of a friend that running synthesis and > implementation with a solid-state drive can yield substantial speed > gains compared with the same process run on a machine with a regular > hard drive. Are there any FPGA designers here that have tried it? If > so, is there any truth to that statement and can you tell how much > performance has been gained? > > Best regards I can think of only two cases that would have "substantial" speed-up: 1) Small designs where the file access is a significant portion of the processing. 2) Large designs that surpass the physical memory of the machine and used paged virtual memory. For the first case, while the percentage of processing time is substantial, the overall time is low. In the second case, you really want more physical memory on the machine and if possible, more cache. However if your architecture has its maximum allowable memory already then the SSD would probably help. For most of my designs, the largest portion of the run time happens with very little disk activity, so I'm not ready to run out and buy high speed solid-state drives. Regards, GaborArticle: 149751
On Nov 22, 12:00=A0am, KJ <kkjenni...@sbcglobal.net> wrote: > On Nov 21, 10:34=A0pm, makeuptest <spamgoeshe...@yahoo.com> wrote: > > > > > That was all well and good. =A0But when I tried to test it, none of the > > internal variables that should have created registers were being > > remembered. =A0I ran a simulation and the variables were getting reset > > initially, but on the next entry to the procedure they were back to > > being undefined. > > Procedures do not inherently 'remember' the values of internal > variables or signals as you would have in a process. =A0Instead you must > make the signal available on the interface of the procedure and hook > up a real signal to that port. > > This generally means that you must actually add two signals to the > interface of the procedure: =A0one is an 'input' to the procedure which > represents the current state of the signal; the other is an 'output' > of the procedure which represent the next state of the signal. > > > Do I have a basic misunderstanding about how procedures operate? > > Yes...you can't hide signals within a procedure. > > Kevin Jennings Yes, I finally found a reference that says variables won't retain their values between invocations in a procedure. I guess that is different from a process, but now that I think about it, that only makes sense. In order to have a register created, the process would have to pass the value out and back in. ThanksArticle: 149752
On 11/22/2010 02:05 PM, Gabor wrote: > On Nov 22, 4:28 pm, Benjamin Couillard<benjamin.couill...@gmail.com> > wrote: >> Hi everyone >> >> I've heard from a friend of a friend that running synthesis and >> implementation with a solid-state drive can yield substantial speed >> gains compared with the same process run on a machine with a regular >> hard drive. Are there any FPGA designers here that have tried it? If >> so, is there any truth to that statement and can you tell how much >> performance has been gained? >> >> Best regards > > I can think of only two cases that would have "substantial" speed-up: > > 1) Small designs where the file access is a significant portion of the > processing. > > 2) Large designs that surpass the physical memory of the machine > and used paged virtual memory. > > For the first case, while the percentage of processing time is > substantial, the overall time is low. > > In the second case, you really want more physical memory on > the machine and if possible, more cache. However if your > architecture has its maximum allowable memory already then > the SSD would probably help. > > For most of my designs, the largest portion of the run time happens > with very little disk activity, so I'm not ready to run out and buy > high speed solid-state drives. About 20 years ago someone advised me that nearly all PC's that are set up to 'factory' specifications can be sped up for more economically with more RAM than by going to a faster processor (and motherboard). CPU speed is _sexy_, RAM size isn't, so a manufacturer is rewarded more for selling you a fast CPU than adequate RAM. 20 years later, it's still true: maxing a motherboard out on RAM is nearly always cheaper than stepping up one or two levels of CPU speed, and nearly always gives a bigger speed boost for all of my real-world applications than going to that faster CPU. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 149753
John Adair <g1@enterpoint.co.uk> wrote: > Uwe > Spartan-6 availability is improving very rapidly and in many cases is > now on shorter lead time than Spartan-3 parts. We have a considerable > amount here now of the parts we use most awaiting some time on our > line to build more development boards. 4-6 weeks is usually the > standard lead time value, usually quoted in better times, on Spartan > families if you buy them in any numbers. We are looking at QFP package. And lead time is _constant_ 6 weeks in the future ... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 149754
On Mon, 22 Nov 2010 08:07:28 -0800, saar drimer wrote: > Are the JTAG pins available? > > If so, Chipscope with VirtualIO should be the easiest for this kind of > debug. You can desolder the PIC and manually loopback/short the pads and > then change the stimulus through the chipscope GUI and see if the > signals propagate. With one design you can then test all routes. If this > is an Altera device, use SignalTap. I thought SignalTap was monitor-only and couldn't twiddle pins? Hmm. Thanks, -- Phil. usenet10@philpem.me.uk http://www.philpem.me.uk/ If mail bounces, replace "10" with the last two digits of the current yearArticle: 149755
On Nov 20, 3:22=A0pm, Philip Pemberton <usene...@philpem.me.uk> wrote: > Here's a good mind bender for the gurus... ... > Phil. > usene...@philpem.me.ukhttp://www.philpem.me.uk/ I often have a similar architecture for communication with my FPGAs. Do the wires go direct from the PIC to the FPGA? If so then shorts at the FPGA will affect the lines at the output of the PIC and it will be able to detect them. 1) Write diagnostic code for the PIC that verifies the state of the FPGA communication lines after setting them - this is to detect shorts on the lines to the FPGA. Run through all combinations of the lines that do not cause the FPGA to be active on the shared bus (maybe do it with the FPGA unconfigured). 2) Now write diagnostic code that writes to a loopback register on the FPGA and run through all combinations to verify all the data bits. This will detect any opens in the lines. If you have intermittent faults you may need to run these tests many times in a loop to detect occasional failures. Opens can sometimes be tricky as the capacitance of the line may hold the state - one solution is to arrange to set the bus to a different state (e.g inverted) between the write and the read to ensure you are really reading the data from the FPGA. You can speed up these tests by doing walking ones or zeros rather than all combinations (be aware of which particular lines may short). Once you have these running reliably you can be pretty confident that you have communication working. kevinArticle: 149756
>I generally implement resets with asynchronous assertion and >synchronous de-assertion. With a single reset, this is simple. >However, what happens if there are multiple reset inputs but I only >want one internal reset? > >I was always under the impression that one should not have any >combinational logic in the asynchronous reset path, as it could lead >to static hazards (and reset glitches). So, how do you combine two >resets into one without using combinational logic somewhere? > >I was thinking of two scenarios: >1. AND the two resets coming into the FPGA, and connect to the >asynchronous reset of a synchronizer. The output of the synchronizer >is the single internal reset. >2. Individually synchronize the two resets coming into the FPGA (note >that each reset input feeds the asynchronous reset of the >synchronizer). AND the output of each of the synchronizers and feed >this single signal into the asynchronous reset of a final flip-flop. >The output of this flip-flop is the single internal reset. > >In both cases we achieve asynchronous assertion and synchronous de- >assertion ... however, in both cases there is combinational logic in >the asynchronous reset path. > >Any suggestions how these multiple resets should be combined? > For multiple resets you always run them into a metastable synchroniser first and then combine them into one and resync it through a flop . Nice thing about resets is that you can delay them quite a bit and they still work fine. You also want to design for a multicycle reset. If all your sync logic will guarantee that all resets will be at least 4 cycles wide then you can use that in you module design. Don't put reset logic on a flop if it's upstream flops have a reset that will force it into reset within 3 additional clocks. You also want to cascade your resets. If you have a power on reset and a soft reset then you want the power on reset to cascade down and also force the soft reset when it is active. If you have any logic is must run during the power on reset then you must create a special simulation_test reset. That should cascade down to force both the power_on and soft resets. John Eaton --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149757
On 11/22/2010 2:27 PM, makeuptest wrote:
> In order to have a register created, the process would
> have to pass the value out and back in.
>
For example, see the procedure "retime" here:
http://mysite.ncnetwork.net/reszotzl/rise_count.vhd
-- Mike Treseler
Article: 149758> So far the best idea I've come up with (actually a friend came up with > it) is to load a bitstream which reads the state of the other 10 lines. > The FPGA clocks out 20 '0' bits, a '1', then the state of the 10 pins. > This allows the PIC/PC combination to automatically test the whole set of > remaining combinations. > > Can anyone think of an easier way to do this? YES! Tis exactly the sort of situation the 1 pin interface was designed for... http://www.1pin-interface.com/ All you need is one unused FPGA pin routed to a header (with a ground) to give bi-directional control and status to the FPGA. If you're loading a custom debug build you can use any exisitng header pin that has a fairly local GND. NialArticle: 149759
> 20 years later, it's still true: maxing a motherboard out on RAM is > nearly always cheaper than stepping up one or two levels of CPU speed, > and nearly always gives a bigger speed boost for all of my real-world > applications than going to that faster CPU. > > Tim Wescott I agree that maxing out on ram takes precedence over hard drive access when optimizing real-time performance on algorithms such as FPGA routes. In a ram-limited situation where a route has a workstation constantly going to HDD, improving the hard drive technology first when there are empty ram slots is akin to a golfer paying a fortune on shoes while sticking with 30-year-old sticks. The shoes may help a little bit, but won't have near the impact of a new set of high-tech clubs. JohnArticle: 149760
>> 20 years later, it's still true: maxing a motherboard out on RAM is >> nearly always cheaper than stepping up one or two levels of CPU speed, >> and nearly always gives a bigger speed boost for all of my real-world >> applications than going to that faster CPU. >> >> Tim Wescott > >I agree that maxing out on ram takes precedence over hard drive access >when optimizing real-time performance on algorithms such as FPGA >routes. In a ram-limited situation where a route has a workstation >constantly going to HDD, improving the hard drive technology first >when there are empty ram slots is akin to a golfer paying a fortune on >shoes while sticking with 30-year-old sticks. The shoes may help a >little bit, but won't have near the impact of a new set of high-tech >clubs. >John > With 32-bit Windows, the maximum amount of RAM that the system can use is no more than 4Gbyte. This PC has 3Gbyte. Does your P&R tool run on a 64-bit OS? Can you afford the licence? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149761
On Nov 22, 2:19=A0pm, "dila77" <dila77@n_o_s_p_a_m.live.com> wrote: > Hi, > please, how can I find out the minimum clock period (the maximum clock > frequency in MHz) of a combinational circuit (for example, for a full > adder) ? > After the synthesizing and implementation I got the following message: > > Clock Information: > ------------------ > No clock signals found in this design > Asynchronous Control Signals Information: > ---------------------------------------- > No asynchronous control signals found in this design > Timing Summary: > --------------- > Speed Grade: -4 > =A0 =A0Minimum period: No path found > =A0 =A0Minimum input arrival time before clock: No path found > =A0 =A0Maximum output required time after clock: No path found > =A0 =A0Maximum combinational path delay: 9.033ns > > Is there any way to know the minimum clock period ? > > Thanks :) > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com You likely have no flip-flops in your design - i.e. you wrote something like begin Y <=3D A + B; end clock frequency is driven by the maximum amount of time required to get from one FF to another. What you probably want to do is put an FF on your inputs (A and B), and your output (Y), all clocked by the same clock signal. Alternatively, the maximum data rate through your adder is the reciprocal of the max combinatorial delay - but this essentially assumes there are ideal FFs on the input and output and that setup and hold times are met. Welcome to the wonderful world of digital logic. ChrisArticle: 149762
On Nov 23, 9:43=A0am, Chris Maryan <kmar...@gmail.com> wrote: > On Nov 22, 2:19=A0pm, "dila77" <dila77@n_o_s_p_a_m.live.com> wrote: > > > > > Hi, > > please, how can I find out the minimum clock period (the maximum clock > > frequency in MHz) of a combinational circuit (for example, for a full > > adder) ? > > After the synthesizing and implementation I got the following message: > > > Clock Information: > > ------------------ > > No clock signals found in this design > > Asynchronous Control Signals Information: > > ---------------------------------------- > > No asynchronous control signals found in this design > > Timing Summary: > > --------------- > > Speed Grade: -4 > > =A0 =A0Minimum period: No path found > > =A0 =A0Minimum input arrival time before clock: No path found > > =A0 =A0Maximum output required time after clock: No path found > > =A0 =A0Maximum combinational path delay: 9.033ns > > > Is there any way to know the minimum clock period ? > > > Thanks :) > > > --------------------------------------- =A0 =A0 =A0 =A0 > > Posted throughhttp://www.FPGARelated.com > > You likely have no flip-flops in your design - i.e. you wrote > something like > begin > =A0 Y <=3D A + B; > end > clock frequency is driven by the maximum amount of time required to > get from one FF to another. What you probably want to do is put an FF > on your inputs (A and B), and your output (Y), all clocked by the same > clock signal. > > Alternatively, the maximum data rate through your adder is the > reciprocal of the max combinatorial delay - but this essentially > assumes there are ideal FFs on the input and output and that setup and > hold times are met. > > Welcome to the wonderful world of digital logic. > > Chris But also note that the delay listed in the synthesis report is only approximate, and if your design has nothing else in it, it represents a pin to pin delay including the input and output buffers. The actual delay through a combinatorial adder inside the chip will be much less than the reported 9 ns. -- GaborArticle: 149763
On Nov 22, 6:39=A0pm, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > John Adair <g...@enterpoint.co.uk> wrote: > > Uwe > > Spartan-6 availability is improving very rapidly and in many cases is > > now on shorter lead time than Spartan-3 parts. We have a considerable > > amount here now of the parts we use most awaiting some time on our > > line to build more development boards. 4-6 weeks is usually the > > standard lead time value, usually quoted in better times, on Spartan > > families if you buy them in any numbers. > > We are looking at QFP package. And lead time is _constant_ 6 weeks in the > future ... > > -- > Uwe Bonnes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b...@elektron.ikp.physik.tu-dar= mstadt.de > > Institut fuer Kernphysik =A0Schlossgartenstrasse 9 =A064289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Ah, yes... Alice through the looking-glass! You can have jam "every other day" (which means never today).Article: 149764
Geeze! There are times I wonder how I manage to live without full
time care! I chased the strangest bug and could not find it to save
my life. If it had been a snake...
The simulation was exactly what I wanted and I've been doing this a
long time, so I'm not accustomed to the chip not working just like the
simulation. I downloaded the design and things aren't working like
they should. The data from the 232 interface was not synching as if
it were not the correct rate. Putting a probe on the data shows it is
clocking way too fast, a bit is coming out at the rate of the 16x baud
clock! I brought out several timing strobes they were all over the
map, all two fast, but not even steady. More like the clock was
glitching all over the place...
To make a long story short... opps, too late for that... I eventually
read the compiler warnings. I had seen a warning earlier about
finding 9 feedback paths or words to that effect and that didn't quite
wake me up. It was complaining about the lack of signals in the
sensitivity list of a clocked process... or so I thought. Instead of
(rising_edge(clk)) I had used ('1' = clk). Aldec used the sensitivity
list without complaining and so it simulated perfectly. The real
world saw it differently... async logic running at top speed! No
wonder the chip was warmer than usual...
A couple of hours down the drain... yes, a couple of hours! I kept
adding debug points even though none of them made any sense.
Rick
Article: 149765All, I apologize if this is a repost, but I saw this today and thought it relevant to the group: http://www.thinq.co.uk/2010/11/22/intel-launches-fpga-equipped-atom/ "Intel is quite clearly serious about offering competition to ARM in the embedded market, and has just announced a new Atom processor series that offers a unique selling point: an integral FPGA." The FPGA is from Altera. StephenArticle: 149766
On Nov 23, 11:23 am, "stephen.cra...@gmail.com" <stephen.cra...@gmail.com> wrote: > All, > > I apologize if this is a repost, but I saw this today and thought it > relevant to the group: > > http://www.thinq.co.uk/2010/11/22/intel-launches-fpga-equipped-atom/ > > "Intel is quite clearly serious about offering competition to ARM in > the embedded market, and has just announced a new Atom processor > series that offers a unique selling point: an integral FPGA." > > The FPGA is from Altera. > > Stephen I have seen this, I don't recall if it was posted here or not. It looks like Intel has realized that their CPUs can be much more interesting if the peripheral I/O is made more flexible. I have been expecting to see embedded CPUs combined with FPGAs for some time, but I thought it would be driven by the FPGA companies. Now I see that this is less likely because of a combination of their mindset (too many variants to be practical in marketing terms) and their perceived market (most of the money is in big chips to big customers). Of course that is ignoring the products from Cypress and Actel (now Microsemi), but they are still just getting out of the gate. I have been noticing for some time that Moore's law is providing transistors and gates that we don't really need. x86 CPUs can no longer make use of the transistors to speed up the processors. So instead they have started to multiply the number of processors without a good way to utilize them. FPGAs are starting to reach the point of being more than enough LUTs and registers for nearly all designs at reasonable prices. The logical next step is more system integration. So Intel has seen the marketing advantage of providing a powerful CPU with user customizable I/O or specialized supplementary processing. They also see the market for low power processing. I think in another five years the market will have turned so that low power will dominate nearly all CPU and FPGA apps... and I don't mean FPGAs which only use half a watt. I mean devices like the Silicon Blue chips with near zero static current and low per-MHz power. More and more things are becoming hand held and portable. How much longer will people continue to use boat anchor electronics when they can take it all with them? BTW, if you want to see a possible direction low power may be taking, check out the Green Arrays 144 processor chip. Low power is what it is all about! In fact, that may be the next big thing, Field Programmable Processor Arrays, FPPAs! RickArticle: 149767
On Nov 22, 5:28=A0pm, Benjamin Couillard <benjamin.couill...@gmail.com> wrote: > Hi everyone > > I've heard from a friend of a friend that running synthesis and > implementation with a solid-state drive can yield substantial speed > gains compared with the same process run on a machine with a regular > hard drive. Are there any FPGA designers here that have tried it? If > so, is there any truth to that statement and can you tell how much > performance has been gained? > > Best regards I ran some benchmarks on our development servers last Spring. Assuming your machine has enough RAM, the only file I/O occurs at the start and end of each step - all of the heavy processing is handled in memory. If you don't have enough RAM and are constantly swapping data to the disk, that's another story. Xilinx's memory recommendations for the larger V-5 devices reach peaks of over 7GB and typical use of 4.8GB on a 64-bit OS. For the largest V-6 devices they recommend typical of 10GB with peaks of 18.7GB. With some of the respectable sized V-5s, you should be fine with 3GB. As part of the benchmarking exercise, I compared builds on the following: * Pentium 4 3.2GHz, 2MB, 800 MHz FSB, 4GB DDR2 667 * Intel Core2 Duo E6700 2.67 GHz, 4MB, 1066 MHz FSB, 4GB of DDR2 667 * Intel Xeon 5150 Dual core 2.66GHz, 4MB, 1333 MHz FSB, 6GB DDR2 667 I was seeing about 55% and 65% performance increases on the two newer boxes compared to the P4 box. Since the implementation tools run entirely in memory, you'll get the best improvement by upgrading your hardware and putting in as much RAM as you can.Article: 149768
On 11/23/2010 8:08 AM, rickman wrote: > Geeze! There are times I wonder how I manage to live without full > time care! I chased the strangest bug and could not find it to save > my life. If it had been a snake... > > [snip] > > A couple of hours down the drain... yes, a couple of hours! I kept > adding debug points even though none of them made any sense. > > Rick There's a lesson to be learned from all that, Rick, but I'll be damned if I know what it is. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 149769
On Nov 23, 12:08=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > On 11/23/2010 8:08 AM, rickman wrote: > > > Geeze! =A0There are times I wonder how I manage to live without full > > time care! =A0I chased the strangest bug and could not find it to save > > my life. =A0If it had been a snake... > > =A0> [snip] > > > A couple of hours down the drain... yes, a couple of hours! =A0I kept > > adding debug points even though none of them made any sense. > > > Rick > > There's a lesson to be learned from all that, Rick, but I'll be damned > if I know what it is. Don't program in your sleep! Did I mention that much of this was done very late? RickArticle: 149770
On Nov 23, 11:39=A0am, rickman <gnu...@gmail.com> wrote: > On Nov 23, 11:23 am, "stephen.cra...@gmail.com" > > <stephen.cra...@gmail.com> wrote: > > All, > > > I apologize if this is a repost, but I saw this today and thought it > > relevant to the group: > > >http://www.thinq.co.uk/2010/11/22/intel-launches-fpga-equipped-atom/ > > > "Intel is quite clearly serious about offering competition to ARM in > > the embedded market, and has just announced a new Atom processor > > series that offers a unique selling point: an integral FPGA." > > > The FPGA is from Altera. > > > Stephen > > I have seen this, I don't recall if it was posted here or not. > > It looks like Intel has realized that their CPUs can be much more > interesting if the peripheral I/O is made more flexible. =A0I have been > expecting to see embedded CPUs combined with FPGAs for some time, but > I thought it would be driven by the FPGA companies. =A0Now I see that > this is less likely because of a combination of their mindset (too > many variants to be practical in marketing terms) and their perceived > market (most of the money is in big chips to big customers). =A0Of > course that is ignoring the products from Cypress and Actel (now > Microsemi), but they are still just getting out of the gate. > > I have been noticing for some time that Moore's law is providing > transistors and gates that we don't really need. =A0x86 CPUs can no > longer make use of the transistors to speed up the processors. =A0So > instead they have started to multiply the number of processors without > a good way to utilize them. =A0FPGAs are starting to reach the point of > being more than enough LUTs and registers for nearly all designs at > reasonable prices. =A0The logical next step is more system integration. > > So Intel has seen the marketing advantage of providing a powerful CPU > with user customizable I/O or specialized supplementary processing. > They also see the market for low power processing. =A0I think in another > five years the market will have turned so that low power will dominate > nearly all CPU and FPGA apps... and I don't mean FPGAs which only use > half a watt. =A0I mean devices like the Silicon Blue chips with near > zero static current and low per-MHz power. > > More and more things are becoming hand held and portable. =A0How much > longer will people continue to use boat anchor electronics when they > can take it all with them? > > BTW, if you want to see a possible direction low power may be taking, > check out the Green Arrays 144 processor chip. =A0Low power is what it > is all about! =A0In fact, that may be the next big thing, Field > Programmable Processor Arrays, FPPAs! > > Rick Mathstar has been there. Google for FPOA (field programmable object array) which has arrays of tiny sequencers spattered with multipliers. By the way there is an article on the new Intel Atom w/ FPGA. It's just a re- packaging with an Altera FPGA on board. Check out the article in Embedded Technology Journal. http://www.techfocusmedia.net/index.php/embeddedtechnologyjournal/ -- GaborArticle: 149771
RCIngham <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: (snip) > With 32-bit Windows, the maximum amount of RAM that the system can use is > no more than 4Gbyte. This PC has 3Gbyte. That isn't quite right. That is the most it can use for a single task, but if you have many other programs running then those can also be using memory. Also, the disk cache is in there somewhere. I believe for 32 bit windows, the most for a single task is 3GB, plus 1GB for OS stuff. Most IA32 processors have a 36 bit physical address, though many boards will only go up to 4GB. > Does your P&R tool run on a 64-bit OS? > Can you afford the licence? -- glenArticle: 149772
On Nov 23, 8:23=A0am, "stephen.cra...@gmail.com" <stephen.cra...@gmail.com> wrote: > All, > > I apologize if this is a repost, but I saw this today and thought it > relevant to the group: > > http://www.thinq.co.uk/2010/11/22/intel-launches-fpga-equipped-atom/ > > "Intel is quite clearly serious about offering competition to ARM in > the embedded market, and has just announced a new Atom processor > series that offers a unique selling point: an integral FPGA." > > The FPGA is from Altera. > > Stephen The "Embedded Technology Journal" has a good article on the Stellarton combo, discussing the advantages and disadvantages. The section on how the CPU communicates to the FPGA is particularly interesting. http://www.techfocusmedia.net/embeddedtechnologyjournal/feature_articles/20= 101123-stellarton According to the article, the FPGA in the package is an Altera Aria II GX FPGA "with about 55,000 logic elements." Looking at the Altera product table, I see a device with 45,000 equivalent logic elements (LEs) and one with 63,000. The FPGA is likely one of these two or Altera is planning another intermediate device. http://www.altera.com/products/devices/arria-fpgas/arria-ii-gx/overview/aii= gx-overview.html The Altera presentation on Quartus II shows a roadmap with the Intel Stellarton along with support for NIOS II, MIPS, ARM Cortex-M1, and ARM Cortex-A9. http://www.altera.com/b/embedded-fpga-design-flow.html eweek Linux Devices also had a good story on the combo and Altera's processor roadmap or their "embedded initiative." http://www.linuxfordevices.com/c/a/News/Altera-embedded-initiative/Article: 149773
> With 32-bit Windows, the maximum amount of RAM that the system can use is > no more than 4Gbyte. This PC has 3Gbyte. For you FPGA veterans out there, remember when we used to complain about the 640K limit on DOS? My how things have changed.Article: 149774
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.
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