Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 149750

Article: 149750
Subject: Re: Synthesis/place and route with Solid-State Drives
From: Gabor <gabor@alacron.com>
Date: Mon, 22 Nov 2010 14:05:35 -0800 (PST)
Links: << >>  << T >>  << A >>
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,
Gabor

Article: 149751
Subject: Re: Procedures and Registers
From: makeuptest <spamgoeshere2@yahoo.com>
Date: Mon, 22 Nov 2010 14:27:34 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Thanks

Article: 149752
Subject: Re: Synthesis/place and route with Solid-State Drives
From: Tim Wescott <tim@seemywebsite.com>
Date: Mon, 22 Nov 2010 15:11:18 -0800
Links: << >>  << T >>  << A >>
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.html

Article: 149753
Subject: Re: Spartan3 device with long availability
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Mon, 22 Nov 2010 23:39:33 +0000 (UTC)
Links: << >>  << T >>  << A >>
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
Subject: Re: Debugging with a single LED
From: Philip Pemberton <usenet10@philpem.me.uk>
Date: 22 Nov 2010 23:58:48 GMT
Links: << >>  << T >>  << A >>
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 year

Article: 149755
Subject: Re: Debugging with a single LED
From: kevin93 <kevin@whitedigs.com>
Date: Mon, 22 Nov 2010 18:30:50 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

kevin

Article: 149756
Subject: Re: Multiple Reset Inputs
From: "jt_eaton" <z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Mon, 22 Nov 2010 21:12:36 -0600
Links: << >>  << T >>  << A >>
>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.com

Article: 149757
Subject: Re: Procedures and Registers
From: Mike Treseler <mtreseler@gmail.com>
Date: Mon, 22 Nov 2010 23:17:35 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Debugging with a single LED
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Tue, 23 Nov 2010 11:47:12 -0000
Links: << >>  << T >>  << A >>
> 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.



Nial 



Article: 149759
Subject: Re: Synthesis/place and route with Solid-State Drives
From: jc <jcappello@optimal-design.com>
Date: Tue, 23 Nov 2010 04:18:31 -0800 (PST)
Links: << >>  << T >>  << A >>
> 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

Article: 149760
Subject: Re: Synthesis/place and route with Solid-State Drives
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Tue, 23 Nov 2010 08:42:20 -0600
Links: << >>  << T >>  << A >>
>> 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.com

Article: 149761
Subject: Re: minimum clock period of a combinational circuit
From: Chris Maryan <kmaryan@gmail.com>
Date: Tue, 23 Nov 2010 06:43:19 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Chris



Article: 149762
Subject: Re: minimum clock period of a combinational circuit
From: Gabor <gabor@alacron.com>
Date: Tue, 23 Nov 2010 07:18:23 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

-- Gabor

Article: 149763
Subject: Re: Spartan3 device with long availability
From: Gabor <gabor@alacron.com>
Date: Tue, 23 Nov 2010 07:24:29 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Subject: Brain Cramps...
From: rickman <gnuarm@gmail.com>
Date: Tue, 23 Nov 2010 08:08:06 -0800 (PST)
Links: << >>  << T >>  << A >>
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: 149765
Subject: Intel Atom + FPGA
From: "stephen.craven@gmail.com" <stephen.craven@gmail.com>
Date: Tue, 23 Nov 2010 08:23:08 -0800 (PST)
Links: << >>  << T >>  << A >>
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

Article: 149766
Subject: Re: Intel Atom + FPGA
From: rickman <gnuarm@gmail.com>
Date: Tue, 23 Nov 2010 08:39:06 -0800 (PST)
Links: << >>  << T >>  << A >>
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!

Rick

Article: 149767
Subject: Re: Synthesis/place and route with Solid-State Drives
From: kkoorndyk <kris.koorndyk@gmail.com>
Date: Tue, 23 Nov 2010 08:42:39 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Subject: Re: Brain Cramps...
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Tue, 23 Nov 2010 09:08:33 -0800
Links: << >>  << T >>  << A >>
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 order

Article: 149769
Subject: Re: Brain Cramps...
From: rickman <gnuarm@gmail.com>
Date: Tue, 23 Nov 2010 09:28:56 -0800 (PST)
Links: << >>  << T >>  << A >>
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?

Rick

Article: 149770
Subject: Re: Intel Atom + FPGA
From: Gabor <gabor@alacron.com>
Date: Tue, 23 Nov 2010 10:35:09 -0800 (PST)
Links: << >>  << T >>  << A >>
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/

-- Gabor


Article: 149771
Subject: Re: Synthesis/place and route with Solid-State Drives
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 23 Nov 2010 18:47:35 +0000 (UTC)
Links: << >>  << T >>  << A >>
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?

-- glen

Article: 149772
Subject: Re: Intel Atom + FPGA
From: Prevailing over Technology <steve.knapp@prevailing-technology.com>
Date: Tue, 23 Nov 2010 10:56:46 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Subject: Re: Synthesis/place and route with Solid-State Drives
From: Prevailing over Technology <steve.knapp@prevailing-technology.com>
Date: Tue, 23 Nov 2010 11:01:06 -0800 (PST)
Links: << >>  << T >>  << A >>

> 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
Subject: PlanAhead
From: "Roger" <rogerwilson@hotmail.com>
Date: Tue, 23 Nov 2010 22:00:54 -0000
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search