Best CPU platform(s) for FPGA synthesis

jjohnson@cs.ucf.edu writes:

> Thanks everyone, this is real interesting, but please don't stop
> posting if you have more insights to share!

[snip]

> In 32-bit Linux, can it run 4GB per process and as many simultaneous
> processes of that size as the virtual memory will support?

As I recall, 32-bit Linux has a limit around 3.0-3.5GB per process.
On the 64-bit Linux , I have used 8+GB for a single process doing
gatelevel simulations.


Kai
-- 
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

Jon Beniston <jon@beniston.com> writes:

> On 27 Jul, 17:17, Kai Harrekilde-Petersen <k...@harrekilde.dk> wrote:
>> Jon Beniston <j...@beniston.com> writes:
>> >> > Static Timing Analysis (TimeQuest) is mostly double-precision floating-
>> >> > point?
>>
>> >> I seriously doubt it.  I don't see a need for floating point there
>> >> when delays can use scaled integers.
>>
>> > Dynamic range?
>>
>> Not a likely problem. Even a 32bit int would be big enough for holding
>> up to a ridiculous 4.3 seconds, assuming 1psec resolution.
>
> I think you're a factor of 1000 out.

Duh, brain fart indeed!

> For an ASIC STA, gate delays must be specified at a much finer
> resolution than 1ps.

I don't recall seeing sub-psec resolution in the 130nm libraries I
have seen, but that doesn't imply that it cannot be so.

But I stand by my argument: the actual resolution should not matter
much, as the total clock delays and cycle times should scale pretty
much as the library resolution.  Otherwise, there wouldn't be a point
in choosing such a fast technology (who in their right mind would use
a 45m process for implementing an 32kHz RTC, unless they had to?)


Kai
-- 
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

 jjohnson@cs.ucf.edu wrote:

> In 32-bit Linux, can it run 4GB per process and as many simultaneous
> processes of that size as the virtual memory will support?

Below is what I have read about it in "Self-Service Linux®"
http://www.phptr.com/content/images/013147751X/downloads/013147751X_book.pdf
I have no experience with it.

<quote>
3.2.2.1.6 The Kernel Segment

The only remaining segment in a process' address space to discuss is the 
kernel segment. The kernel segment starts at 0xc0000000 and is 
inaccessible by user processes. Every process contains this segment, 
which makes transferring data between the kernel and the process' 
virtual memory quick and easy. The details of this segment&rsquo;s contents, 
however, are beyond the scope of this book.

Note:

You may have realized that this segment accounts for one quarter of the 
entire address space for a process. This is called 3/1 split address 
space. Losing 1GB out of 4GB isn't a big deal for the average user, but 
for high-end applications such as database managers or Web servers, 
this can become an issue. The real solution is to move to a 64-bit 
platform where the address space is not limited to 4GB, but due to the 
large amount of existing 32-bit x86 hardware, it is advantageous to 
address this issue. There is a patch known as the 4G/4G patch, which 
can be found at ftp.kernel.org/pub/linux/kernel/people/akpm/patches/ or 
http://people.redhat.com/mingo/4g-patches. This patch moves the 1GB 
kernel segment out of each process&rsquo; address space, thus providing the 
entire 4GB address space to applications.
<end quote>

-- 
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

Patrick Dubois wrote:
> On Jul 26, 6:19 pm, jjohn...@cs.ucf.edu wrote:
>> AMD or Intel?
>> -------------------
>> Between AMD & Intel's latest multicore CPUs,
>> - Which offers the best integer performance?
>> - Which offers the best floating-point performance?
>> Specific models within the AMD/Intel family?
>>
>> Assume cost is no object, and each uses its highest-performing memory
>> interface, but disk access is (necessary evil) over a networked drive.
>> (Small % of total runtime anyway.)
>>
>> Multi-core, multi-processor, or both? 32-bit or 64-bit? Linux vs.
>> Windows? >2GB of RAM?
> 
> If cost is no object, then go with the Intel quad-core running at 3
> GHz : QX6850. Each core has 2 MB of L2 cache (8MB total), which is,
> according to several reports in this forum, the single most important
> factor.
> 
> I would say go with 4GB of ram, although if you're using the biggest
> chips, you might need more. Keep in mind that Windows 32-bit will only
> be able to use 3GB max of this 4 GB, and each application will only be
> able to access 2GB max. So you might consider Windows 64 bits or Linux
> 64 bits if necessary.
> 
> Patrick
> 

The last time I checked the speed of a full FPGA build, the cache did 
indeed have the single largest effect, which is hardly surprising. A 
cache access is typically one internal bus cycle (not a cpu cycle) which 
is an order of magnitude faster than an external memory access cycle.

Properly optimised code that uses the I-Cache properly will run much 
faster than inline code, incidentally.

Cheers

PeteS

On Jul 27, 7:17 pm, jjohn...@cs.ucf.edu wrote:
> Thanks everyone, this is real interesting, but please don't stop
> posting if you have more insights to share!

>
> I originally suspected P&R might have a lot of floating-point
> calculations (even prior to signal-integrity considerations) if they
> were doing any kind of physical synthesis (e.g., delay calculation
> based on distance and fanout); ditto for STA, because that's usually
> an integral part of the P&R loops. I also suspected that if floating-
> point operations (at least multiplies, add/subtract, and MACs) could
> be done in a single cycle, there would be no advantage to using
> integer arithmetic instead (especially if manual, or somewhat explicit
> integer scaling is required).
>
> On the other hand, in something like a router, you can get more exact
> location info wrt stuff like grid coordinates than you can with
> floating-point. As far as dynamic range is concerned, I seem to recall
> that SystemC standardized on 64-bit time to run longer simulations,
> but SystemC is a different animal in that regard anyway. Nonetheless,
> I also seem to recall that its implementation of time was 64-bit
> integers (scaled), because the average FPU operations are really only
> linear over the 53-bit mantissa part. Assuming they want linear
> representation of time ticks, I can see the appeal of using 64-bit
> integers in simulation.

Any operations on large netlists are completely memory and pointer
dominated.
There are lot's of random access pointer indirections in data sets
that are much larger
than the cache. The computations done once you have the data do not
matter at all.
You need hundreds of CPU cycles to access the delay parameters of two
gates in a netlist.
Summing them up can be done for free while the CPU waits on the next
load instruction.

On the other hand, if your dynamic range is needed for summing up
small values floating point
does not help at all.
1e12 + 1 = 1e12 in 32-bit floating point. For opperations like that 32-
bit integer actually has 6 bits
more dynamic range.

> As far as event-driven simulations are concerned, I totally understand
> how hard it is to make good use of multithreading or multiprocessing,

Why? In a larger design there will allways be many active processes at
each
timestep. These can be distributed to individual processors.
All operations can be on shared memory because each signal has only
one driver.

Kolja Sulimma

jjohnson@cs.ucf.edu wrote:
> That appears to be related to the number of processors inside one box.
> If a single CPU is just hyperthreaded, the processor takes care of
> instruction distribution unrelated to a variable like number_of_cpus,
> right? 

No. Hyperthreading means that the hardware is only virtually doubled.
The CPU maintains the state and the register set of two independent
threads and tries to utilize all its function units. If one thread has
to wait for data from the memory some instructions of the other thread
can be issued to the function units. Likewise, if one thread spends its
time in the FPU, the other thread can use the remaining function units.
If both threads execute the same type of instructions a hyperthreaded
CPU rarely has an advantage.

Running on a hyperthreaded CPU the operating system sees two cores and
has to schedule its workload like there were two physical cores to gain
any benefit. If your software only has one thread hyperthreading like
multicores won't speed it up.

> And if there are two single-core processors in a box, obviously
> it will utilize "number_of_cpus=2" as expected. Does anyone know how
> that works with dual-core CPUs? i.e, if I have two quad-core CPUs in
> one box, will setting "number_of_cpus=7" make optimal use of 7 cores
> while leaving me one to work in a shell or window?

I don't know how Quartus makes use of the available CPUs but basically
as seen from software there is no difference between two single cores
and one dual-core.

> In 32-bit Windows, is that 3GB limit for everything running at one
> time? i.e., is 4GB a waste on a Windows machine? Can it run multiple
> 2GB processes and go beyond 3 or 4GB? Or is 3GB an absolute O/S limit,
> and 2GB an absolute process limit in Windows?

3 GB is a practical limit because the PCI bus and other memory-mapped
devices typically occupy some hundred megabytes of address space. So you
can't use this memory space to access RAM. There are techniques to map
memory to other address regions beyond the 4 GB border but you need
special chipsets and proper operating system support.

Andreas

On Jul 28, 10:51 pm, Andreas Hofmann <ahn...@gmx.net> wrote:

> 3 GB is a practical limit because the PCI bus and other memory-mapped
> devices typically occupy some hundred megabytes of address space. So you
> can't use this memory space to access RAM.
These are usually not mapped into the address space of a user process.

Kolja Sulimma

>> 3 GB is a practical limit because the PCI bus and other memory-mapped
>> devices typically occupy some hundred megabytes of address space. So you
>> can't use this memory space to access RAM.

> These are usually not mapped into the address space of a user process.

	Nope, but the (32-bit) kernel needs to see the mmap'ed peripherals + the  
userspace RAM if implementation of stuff like file reading, etc is to be  
efficient (without juggling with pages)...

PFC wrote:
> 
>>> 3 GB is a practical limit because the PCI bus and other memory-mapped
>>> devices typically occupy some hundred megabytes of address space. So you
>>> can't use this memory space to access RAM.
> 
>> These are usually not mapped into the address space of a user process.
> 
>     Nope, but the (32-bit) kernel needs to see the mmap'ed peripherals + 
> the userspace RAM if implementation of stuff like file reading, etc is 
> to be efficient (without juggling with pages)...

Anandtech ran an article which does quite a good job in explaining the 2 
and 3 GB barriers.
http://www.anandtech.com/gadgets/showdoc.aspx?i=3034

<sharp@cadence.com> wrote in message 
news:1185490882.415577.205710@b79g2000hse.googlegroups.com...
> On Jul 26, 6:19 pm, jjohn...@cs.ucf.edu wrote:
>> Is Quartus (and the others) more efficient in any one particular
>> environment? I prefer Linux, but the OS is now secondary to pure
>> runtime performance (unless it is a major contributor). Can any of
>> them make use of more than 2GB or RAM? More than 4GB?
>
> 64-bit Linux can make use of more than 4GB of RAM.  But don't use 64-
> bit executables unless your design is too big for 32-bit tools,
> because they will run slower on the same machine.

Interesting -- on an AMD Athlon X2/5200+ running RHEL Linux 4 update 4 
x86_64,
just about all Synopsys Design Compiler jobs run FASTER in 64-bit mode than
32-bit mode, between 5-10% faster.  THe penalty is slightly larger 
RAM-footprint,
just as you noted.  The X2/5200+ is spec'd the same as an Opteron 1218 
(2.6GHz,
2x1MB L2 cache..)

This trend was pretty much consistent across all our Linux EDA-tools.

On Solaris SPARC, 64-bit mode was definitely slower than 32-bit mode, by 
about
10-20%.  For the life of me, I can't understand why the AMD would run 64-bit
mode faster than its 32-bit mode -- but for every other machine 
architecture,
64-bit mode is almost always slower.

I forgot to re-run my 32bit vs 64-bit benchmark on Intel Core2 Duo machines.
FOr 64-bit, the Intel E6850 (4MB L2 cache, 3.0GHz) ran anywhere
from 50-60% faster than the AMD X2/5200+.  Don't worry, no production 
machines
were overclocked (for obvious official, sign/off reasons.)  It was just a 
admin's
corner cubicle experiment.

> Most of these tools are not multi-threaded, so the only way you will
> get a speedup is if you have multiple jobs at the same time.  Event-
> driven simulation in particular is not amenable to multi-threading,
> despite much wishful thinking for the last few decades.

When I ran two separate (unrelated) jobs simultaneously on the AMD and Intel
machines, the AMD machine handled dual-tasking much better.  AMD only
dropped 5-7%, for each job.  The E6600 fared a lot worse -- anywhere from
10-30% performance drop.  (Though not as bad as the Pentium/3 and
Pentium/4 based Xeons.)

I'm wondering if the E6600's unified 4MB L2-cache thrashes badly in 
dual-tasking.
Or maybe the better way to look at it, in single-tasking the 4MB L2-cache is
4X more than the AMD Opteron's 1MB cache per CPU-core.