Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Cost of handling misaligned access
Date: Mon, 24 Feb 2025 16:09:35 -0600
Organization: A noiseless patient Spider
Lines: 255
Message-ID: <vpiqn3$1fa7m$1@dont-email.me>
References: <5lNnP.1313925$2xE6.991023@fx18.iad> <vnosj6$t5o0$1@dont-email.me>
 <2025Feb3.075550@mips.complang.tuwien.ac.at> <volg1m$31ca1$1@dont-email.me>
 <voobnc$3l2dl$1@dont-email.me>
 <0fc4cc997441e25330ff5c8735247b54@www.novabbs.org>
 <vp0m3f$1cth6$1@dont-email.me>
 <74142fbdc017bc560d75541f3f3c5118@www.novabbs.org>
 <20250218150739.0000192a@yahoo.com>
 <0357b097bbbf6b87de9bc91dd16757e3@www.novabbs.org>
 <vp2sv2$1skve$1@dont-email.me>
 <a34ce3b43fab761d13b2432f9e255fab@www.novabbs.org>
 <vp518t$2bhib$1@dont-email.me>
 <a56e446b2e2df9f01eb558aa68279d35@www.novabbs.org>
 <vp5mnu$2fjhi$1@dont-email.me> <BP4uP.273689$6Mub.167898@fx45.iad>
 <vpasaa$3itge$1@dont-email.me> <OTluP.690994$rHoc.634573@fx17.iad>
 <vpd8b0$3afn$1@dont-email.me> <vpdn4k$6130$1@dont-email.me>
 <bQHuP.45701$wlqe.8411@fx06.iad> <20250224000824.00003afd@yahoo.com>
 <Cu1vP.328842$Rpt8.322847@fx33.iad> <20250224192813.000066c6@yahoo.com>
 <vpiiml$1e5tf$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 24 Feb 2025 23:09:40 +0100 (CET)
Injection-Info: dont-email.me; posting-host="c7745e0997ca9983189a0f9691c1ff81";
	logging-data="1550582"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19agHNhymb1/siaz4JVUUaUQPVwyM0wlCI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:KYcKcMI+dHhRZigQAABU6fz3gzI=
In-Reply-To: <vpiiml$1e5tf$1@dont-email.me>
Content-Language: en-US
Bytes: 12622

On 2/24/2025 1:52 PM, 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.
> 

It is likely not worth it to invest effort into things that one 
effectively can't distribute either.

Vivado projects seem to contain lots of absolute paths, and so you can't 
just upload them to github or similar and expect anyone to be able to 
make much use of them unless they also cloned the original PC's drives 
and directory structure...


Also, as noted, having a design that isn't tied down to a specific 
device (or FPGA vendor) is useful as well.

If people can use whatever hardware they have, that could be an advantage.

Though, I am left with the issue that I would need to rework how my 
register files work to match the patterns needed for Altera FPGAs.


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

Yeah.

I personally steer clear of these.

They tend to give you some sort of opaque binary blob along with a 
Verilog wrapper stub that can mostly be used in a similar way to a header.

If used, pretty much every one of these would need redundant fall-back 
code to be able to remain portable.


Like, contrary to "recommendation" I didn't use MIG for the DDR RAM 
modules. I am running the RAM in a non-standard way, and not as fast as 
it could be, but it works.

Granted, it is debatable whether it would have been easier to deal with 
the DDR RAM chip or to deal with the AXI bus or similar. In theory, 
could also switch over to using SERDES, but hasn't seemed "worth it" yet.

In theory, I could also try to develop a faster memory bus. But, it 
seems that, proportional to CPU clock speed, my memory bandwidth is 
already "monstrously fast" vs early 2000s systems (like, the 2000s being 
apparently an era of Fast-CPU, slow RAM).

Vs, say, slow CPU, fast RAM, if one actually uses the RAM at its 
intended speed.



A also mostly use Verilator for simulation, which does limit things.
Vivado does have a built-in simulator, but it only gives signal 
waveforms, which is not so useful.

If their simulator allowed, say, plugging in a virtual VGA monitor and 
PS2 keyboard, or hooking up a bus interface to scripted devices for 
bench-testing, would be more interested.

Then thought about it, and imagined a sort of wonky hybrid of Verilog 
and JavaScript. Could almost be more usable than writing them in C++ 
(what Verilator demands).


========== REMAINDER OF ARTICLE TRUNCATED ==========