Re: Cost of handling misaligned access

Liste des GroupesRevenir à c arch 
Sujet : Re: Cost of handling misaligned access
De : already5chosen (at) *nospam* yahoo.com (Michael S)
Groupes : comp.arch
Date : 24. Feb 2025, 18:28:13
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20250224192813.000066c6@yahoo.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
User-Agent : Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
On Mon, 24 Feb 2025 11:52:38 -0500
EricP <ThatWouldBeTelling@thevillage.com> wrote:

Michael S wrote:
On Sun, 23 Feb 2025 11:13:53 -0500
EricP <ThatWouldBeTelling@thevillage.com> wrote: 
It looks to me that Vivado intends that after you get your basic
design working, this module optimization is *exactly* what one is
supposed to do.
>
In this case the prototype design establishes that you need
multiple 64-bit adders and the generic ones synthesis spits out
are slow. So you isolate that module off, use Verilog to drive the
basic LE selections, then iterate doing relative LE placement
specifiers, route the module, and when you get the fastest 64-bit
adder you can then lock down the netlist and save the module
design.
>
Now you have a plug-in 64-bit adder module that runs at (I don't
know the speed difference between Virtex and your Spartan-7 so
wild guess) oh, say, 4 ns, to use multiple places... fetch,
decode, alu, agu.
>
Then plug that into your ALU, add in SUB, AND, OR, XOR, functions,
isolate that module, optimize placement, route, lock down netlist,
and now you have a 5 ns plug-in ALU module.
>
Doing this you build up your own IP library of optimized hardware
modules.
>
As more and more modules are optimized the system synthesis gets
faster because much of the fine grain work and routing is already
done.
 
 
 
It sounds like your 1st hand FPGA design experience is VERY
outdated. 
 
Never have, likely never will.
Nothing against them - looks easier than wire-wrapping TTL and 4000
CMOS. Though people do seem to spend an awful lot of time working
around certain deficiencies like the lack of >1 write ports on
register files, and the lack of CAM's. One would think market forces
would induce at least one supplier to add these and take the fpga
market by storm.
 

Your view is probably skewed by talking to soft core hobbyists.
Please realize that most professionals do not care about
high-performance soft core. Soft core is for control plane functions
rather than for data plane. Important features are ease of use,
reliability, esp. of software tools and small size. Performance is
rated low. Performance per clock is rated even lower. So, professional
do not develop soft cores by themselves. And OTS cores that they use
are not superscalar. Quite often not even fully pipelined.
It means, no, small SRAM banks with two independent write ports is not
a feature that FPGA pros would be excited about.

Also fpga's do seem prone to monopolistic locked-in pricing
(though not really different from any relational database vendor).

Cheap Chinese clones of X&A FPGAs from late 2000s and very early 2010s
certainly exist. I didn't encounter Chinese clones of slightly newer
devices, like Xilinx 7-series. But I didn't look hard for them. So,
wouldn't be surprised if they exist, too.
Right now, and almost full decade back, neither X nor A cares about low
end. They just continue to ship old chips, mostly charging old price or
rising a little.

At least with TTL one could do an RFQ to 5 or 10 different suppliers.
 
I'm just trying to figure out what these other folks are doing to get
bleeding edge performance from essentially the same tools and similar
chips.
 
I assume you are referring to the gui IDE interface for things like
floor planning where you click on a LE cells and set some attributes.
I also think I saw reference to locking down parts of the net list.
But there are a lot of documents to go through.
 

No, I mean florplanning, as well as most other manual physical-level
optimization are not used at all in 99% percents of FPGA designs that
started after year 2005.


Date Sujet#  Auteur
13 Feb 25 * Re: Cost of handling misaligned access48Marcus
13 Feb 25 +- Re: Cost of handling misaligned access1Thomas Koenig
14 Feb 25 +* Re: Cost of handling misaligned access41BGB
14 Feb 25 i`* Re: Cost of handling misaligned access40MitchAlsup1
18 Feb 25 i `* Re: Cost of handling misaligned access39BGB
18 Feb 25 i  +* Re: Cost of handling misaligned access33MitchAlsup1
18 Feb 25 i  i+- Re: Cost of handling misaligned access1BGB
18 Feb 25 i  i`* Re: Cost of handling misaligned access31Michael S
18 Feb 25 i  i +- Re: Cost of handling misaligned access1Thomas Koenig
18 Feb 25 i  i +* Re: Cost of handling misaligned access26MitchAlsup1
18 Feb 25 i  i i`* Re: Cost of handling misaligned access25Terje Mathisen
18 Feb 25 i  i i `* Re: Cost of handling misaligned access24MitchAlsup1
19 Feb 25 i  i i  `* Re: Cost of handling misaligned access23Terje Mathisen
19 Feb 25 i  i i   `* Re: Cost of handling misaligned access22MitchAlsup1
19 Feb 25 i  i i    `* Re: Cost of handling misaligned access21BGB
20 Feb 25 i  i i     +- Re: Cost of handling misaligned access1Robert Finch
20 Feb 25 i  i i     +* Re: Cost of handling misaligned access5MitchAlsup1
20 Feb 25 i  i i     i+* Re: Cost of handling misaligned access2BGB
20 Feb 25 i  i i     ii`- Re: Cost of handling misaligned access1BGB
21 Feb 25 i  i i     i`* Re: Cost of handling misaligned access2Robert Finch
21 Feb 25 i  i i     i `- Re: Cost of handling misaligned access1BGB
21 Feb 25 i  i i     `* Re: Cost of handling misaligned access14BGB
22 Feb 25 i  i i      +- Re: Cost of handling misaligned access1Robert Finch
22 Feb 25 i  i i      `* Re: Cost of handling misaligned access12Robert Finch
23 Feb 25 i  i i       +* Re: Cost of handling misaligned access10BGB
23 Feb 25 i  i i       i`* Re: Cost of handling misaligned access9Michael S
24 Feb 25 i  i i       i +- Re: Cost of handling misaligned access1BGB
24 Feb 25 i  i i       i `* Re: Cost of handling misaligned access7Michael S
24 Feb 25 i  i i       i  +* Re: Cost of handling misaligned access4Robert Finch
24 Feb 25 i  i i       i  i+- Re: Cost of handling misaligned access1BGB
24 Feb 25 i  i i       i  i`* Re: Cost of handling misaligned access2MitchAlsup1
25 Feb 25 i  i i       i  i `- Re: Cost of handling misaligned access1BGB
25 Feb 25 i  i i       i  `* Re: Cost of handling misaligned access2MitchAlsup1
25 Feb 25 i  i i       i   `- Re: Cost of handling misaligned access1BGB
23 Feb 25 i  i i       `- Re: Cost of handling misaligned access1Robert Finch
18 Feb 25 i  i `* Re: Cost of handling misaligned access3BGB
19 Feb 25 i  i  `* Re: Cost of handling misaligned access2MitchAlsup1
19 Feb 25 i  i   `- Re: Cost of handling misaligned access1BGB
18 Feb 25 i  `* Re: Cost of handling misaligned access5Robert Finch
18 Feb 25 i   `* Re: Cost of handling misaligned access4BGB
18 Feb 25 i    `* Re: Cost of handling misaligned access3Brett
18 Feb 25 i     `* Re: Cost of handling misaligned access2Marcus
18 Feb 25 i      `- Re: Cost of handling misaligned access1BGB
17 Feb 25 `* Re: Cost of handling misaligned access5Terje Mathisen
17 Feb 25  +- Re: Cost of handling misaligned access1Thomas Koenig
17 Feb 25  `* Re: Cost of handling misaligned access3MitchAlsup1
17 Feb 25   `* Re: Cost of handling misaligned access2Terje Mathisen
17 Feb 25    `- Re: Cost of handling misaligned access1MitchAlsup1

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal