Re: Cost of handling misaligned access

On 2/24/2025 4:33 PM, MitchAlsup1 wrote:

On Mon, 24 Feb 2025 19:52:49 +0000, Robert Finch wrote:
 

On 2025-02-24 12:28 p.m., Michael S wrote:

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.
>

Respecting I do not know that much about the work environment of FPGA
developers:
I have thought of FPGAs as more of a prototyping tool, or to be used in
one-off designs, proof-of-concept type things. In those cases one
probably does not care too much about manual operations, as was said one
would be more interested in productivity of developers that comes from
reliable tools and being able to deal with things at a high level.
>
The vendor’s have a number of pre-made components that can be plugged
into a design making it possible to sketch out a design very quickly
with a couple of caveats. One being one might be stuck to a particular
vendor.
>
CAMs can easily be implemented in FPGAs although they may have
multi-cycle latency.

 A CAM is a vector of XOR gate inputs that feed an AND gate.
 A 5-bit CAM with valid bit is 3-gates in CMOS and 2-gates of delay.
It is only when there are lots of bits being CAMed does the latency
increase markedly -- OR when there are lots of entries being CAMed
but this is a FAN-IN buffering problem not a gate delay or gate logic
problem.
 

                    One has only to research CAM implementation in
FPGAs. Register files with multiple ports are easily implemented with
replication.

 Read ports can be added by replication, write ports cannot.
 

This is why it ends up having an NR*NW cost curve...
So, each Read port needs its own copy, and each copy is duplicated again by the number of write ports.
Then we need tag bits for each register to track which version is the most recent. These bits generally end up needing to be stored as FF's.
Another option is to implement registers directly as FF's.
This has a different set of cost curves:
   Scales better relative to the number of write ports;
   But, the per-register is cost is a lot higher.
So, in the FF case, the cheaper option is to try to limit the number of registers.
Ironically, much above 6R3W (say, 8R4W), seemingly FF registers become the cheaper option (as one goes from 18 to 32 replications of all of the registers).
Another idea that has come up is to use a smaller number of "real" registers but then use them as a cache to a larger number of BRAM-backed registers.
However, this means one may end up with pipeline stalls and potential register thrashing depending on the register allocation.
Say, if one implemented a machine with say:
   16 FF-based registers;
   256 BRAM registers.
Though, thrashing could be reduced if the FF based registers are set-associative, but this would add to logic cost.
One other possibility being if each register is its own cache:
   8 Register Caches;
     Each holding 32 or 64 logical registers (as a 1R1W array).
   Each holds 2 registers active at a time,
     but shuffles them through the array.
Say, for example
   R8, R16, R32, R48       may alias.
   R9, R17, R33, R49       may alias;
   R2, R10, R18, R34, R50  ...
   R3, R11, R19, R35, R51  ...
   ...
This would have a lot less thrashing though, and potentially lower cost than 18 copies of the register arrays (and all the associated MUXing).
Though, likely worse performance.
Would also need to detect and not co-issue instructions with an access pattern where the same register-slot would be in-use for multiple registers in the same clock cycle (2-way associativity would otherwise not be sufficient to deal with a 6R3W register file with 64 active registers).
And, some scenarios, like:
   MOV.Q R32, (R8, R16)
Could not be handled at all (might need a special case in the compiler to deal with it somehow).
This would likely make sense for some sort of register-banks scheme.

             It may be nice to see a CAM component in a vendor library.
Register files sometimes have bypassing requirements that might make it
challenging to develop a generic component.

 Address CAMs are generally done in the "Can't be the same as" or
Is exactly" converting significant amounts of logic as Tag-compare.