Hi,

I am still Ph.D. candidate at some university, but teacher under my studying will retire March next year. So I think of my giving up the getting, and concentrate on to my job (research of microarchitecture and its compiler), but not yet decide.

I have designed CGRA with SystemVerilog, core parts are finished and work on HDL simulator. Global buffers and etc are in functional testing phase. Some time I consider to make the properties be an open source, but concern about its license.

I am indeed strayed to choose my way.

*CGRA (coarse-grained reconfigurable architecture/array) can be said as FPGA replacing CLB(LUT; 1-bit processing unit) with common ALU and FPU.

-
S.Takano

On Monday, August 21, 2023 at 2:36:04 PM UTC-5, S.Takano wrote:
> Hi,
>
> I am still Ph.D. candidate at some university, but teacher under my studying will retire March next year. So I think of my giving up the getting, and concentrate on to my job (research of microarchitecture and its compiler), but not yet decide.
>
> I have designed CGRA with SystemVerilog, core parts are finished and work on HDL simulator. Global buffers and etc are in functional testing phase. Some time I consider to make the properties be an open source, but concern about its license.
>
> I am indeed strayed to choose my way.
>
> *CGRA (coarse-grained reconfigurable architecture/array) can be said as FPGA replacing CLB(LUT; 1-bit processing unit) with common ALU and FPU.
<
What does it mean to be reconfigurable ??
<
Can you illustrate an application where CGRA is significantly better than either a vector of general purpose CPSs or several handful of GPU shader Cores ??
<
Can you annotate why it need reconfigurability ??
>
> -
> S.Takano

On Tuesday, August 29, 2023 at 9:43:23 PM UTC-4, MitchAlsup wrote:
> On Monday, August 21, 2023 at 2:36:04 PM UTC-5, S.Takano wrote:
> > Hi,
> >
> > I am still Ph.D. candidate at some university, but teacher under my studying will retire March next year. So I think of my giving up the getting, and concentrate on to my job (research of microarchitecture and its compiler), but not yet decide.
> >
> > I have designed CGRA with SystemVerilog, core parts are finished and work on HDL simulator. Global buffers and etc are in functional testing phase.. Some time I consider to make the properties be an open source, but concern about its license.
> >
> > I am indeed strayed to choose my way.
> >
> > *CGRA (coarse-grained reconfigurable architecture/array) can be said as FPGA replacing CLB(LUT; 1-bit processing unit) with common ALU and FPU.
> <
Are you talking about having a sea of ALU's and FPU hardware available in an FPGA in place of or in addition to CLBs? I have sometimes wished there was simply an ALU or FPU component in the FPGA rather than having to code one myself. There are already multipliers built into FPGAs an ALU or FPU might be handy. But I would think it might be too much of a solution. For example having a fixed number of bits. But it would be cool if it could work.

OR is this source for a SystemVerilog component implemented with FPGA fabric?

At first, I would like to introduce an algorithm composition from softwares, next difference from others (cpu&gpu).
Algorithm can be represented by programming, and then it is compiled to a binary code (let us say bit stream). The compilation involves analyses of control-flow and data-flow. The control-flow is flow of instrctiictiins that the basice block is regarded as a graph node, nodes are connected by conditional/unconditional branch instrctioion. Flow is diceded by the instruction. Other hand, data-flow is flow of data, just like a logic circuit’s signal flow.

CPU is based on the control-flow, and breaks up the basic block into set of peices to get an instruction-level parallelism as we know a superscalar processor, a unit of handling is a thread. GPU is also based on the control-flow and it also takes the threading. One thread is copied and pasted to so many cores, and takes into account for thread-level parallelism. So sometime GPU is regarded as a limited many-core.

CGRA is a data-flow based computing, sometime called a spatial computing(and traditionals are temporal computing). It is same as FPGA at a concept level, but it has ALU/FPU (so called a coarsed-grained, and FPGA is called a fined-grained), have not a single bit processing unit. So we can see CGRA as data-flow “
graph” based execution modelthat gains data-level parallelism well. So some time classified to control-flow execution on the temporal computing for CPU&GPU, and data-flow execution on the spatial computing for FPGA/CGRA.

CGRA benefits from the reconfiguration. The reconfiguration is to change data-flow graph on a chip, it can be classified to a static reconfiguration that reconfigures only at kicking start, and a dynamic reconfiguration meaning of runtime reconfiguration. For example, FIR filter that can have multiple steps of multiply-add, the steps can be on the chips, the steps feed vector/stream data and outputs filtered data as a vector/stream. So, ideally it provides one filtered output per clock cycle because there is no overhead such as the branch instructions.

Someone seems to want change the number of steps because the number decides utilization rate for the data-flow graph of the filter. For example, 5 steps filter needs more than 5 continuous input data to keep its utilization (we can imagine one input data makes almost steps are idling). When the someone needs N-step configuration, then replicates one-step configution N times on a chip and connect them.

Another example is software having complex data hazards that makes difficult to execute on temporal computing. We can see such examples in scientific applications, a kernel of a molecular dynamics involving huge data-shuffling through arrays on memory, for example. Because CGRA is data-flow graph based execution, it simply bind the graph on the array of FPU is sufficient.

If there is some pattern in a loop part in the algorithm, but has complex data hazards, then just replicating one pattern (so can be an instance) on the chip and connecting them is sufficient, there is no data transfer through memory.

FPGA has DSP(integer multiply-add), and can configure floating-point arithmetic logic with 5-7 DSPs. But physical layout of DSPs on a chip makes difficult to increase clock frequency. And most recent FPGA has DSP array (I think it is one of “integer”-specific many-core, and introduced a legacy matters in FPGA).

I have difficult to say that my HDL(SystemVerilog HDL) coded one is CGRA, but there is no another example.

> Are you talking about having a sea of ALU's and FPU hardware available in an FPGA in place of or in addition to CLBs? I have sometimes wished there was simply an ALU or FPU component in the FPGA rather than having to code one myself.

CGRA is the one.

>There are already multipliers built into FPGAs an ALU or FPU might be handy. But I would think it might be too much of a solution. For example having a fixed number of bits. But it would be cool if it could work.

I remember when ARM processor changed from 16(32?)-bit to 32(64)-but data word, they traded utilization/efficiency of silicon resource for execution performance. If variable bit-width ALU/FPU is supported, then such the CGRA would not have high clock frequency well, because it involves many overheads in terms of silicon resource and takes time (makes longer path length) in order to gather elements to assemble the demanded ALU/FPU.

> OR is this source for a SystemVerilog component implemented with FPGA fabric?

Yes, I developed my own CGRA that runs on functional simulation on Xilinx Vivado(xsim). Small scale size runs at over 133MHz on FPGA (in case of no pin assignment, and no FPU), I expect that it runs at 666 or 800MHz with ASIC implementation.

On Wednesday, August 30, 2023 at 4:29:08 AM UTC-5, S.Takano wrote:
> At first, I would like to introduce an algorithm composition from softwares, next difference from others (cpu&gpu).
> Algorithm can be represented by programming, and then it is compiled to a binary code (let us say bit stream). The compilation involves analyses of control-flow and data-flow. The control-flow is flow of instrctiictiins that the basice block is regarded as a graph node, nodes are connected by conditional/unconditional branch instrctioion. Flow is diceded by the instruction. Other hand, data-flow is flow of data, just like a logic circuit’s signal flow.
>
> CPU is based on the control-flow, and breaks up the basic block into set of peices to get an instruction-level parallelism as we know a superscalar processor, a unit of handling is a thread. GPU is also based on the control-flow and it also takes the threading. One thread is copied and pasted to so many cores, and takes into account for thread-level parallelism. So sometime GPU is regarded as a limited many-core.
>
> CGRA is a data-flow based computing, sometime called a spatial computing(and traditionals are temporal computing). It is same as FPGA at a concept level, but it has ALU/FPU (so called a coarsed-grained, and FPGA is called a fined-grained), have not a single bit processing unit. So we can see CGRA as data-flow “
> graph” based execution modelthat gains data-level parallelism well. So some time classified to control-flow execution on the temporal computing for CPU&GPU, and data-flow execution on the spatial computing for FPGA/CGRA.
>
> CGRA benefits from the reconfiguration. The reconfiguration is to change data-flow graph on a chip, it can be classified to a static reconfiguration that reconfigures only at kicking start, and a dynamic reconfiguration meaning of runtime reconfiguration. For example, FIR filter that can have multiple steps of multiply-add, the steps can be on the chips, the steps feed vector/stream data and outputs filtered data as a vector/stream. So, ideally it provides one filtered output per clock cycle because there is no overhead such as the branch instructions.
>
> Someone seems to want change the number of steps because the number decides utilization rate for the data-flow graph of the filter. For example, 5 steps filter needs more than 5 continuous input data to keep its utilization (we can imagine one input data makes almost steps are idling). When the someone needs N-step configuration, then replicates one-step configution N times on a chip and connect them.
>
> Another example is software having complex data hazards that makes difficult to execute on temporal computing. We can see such examples in scientific applications, a kernel of a molecular dynamics involving huge data-shuffling through arrays on memory, for example. Because CGRA is data-flow graph based execution, it simply bind the graph on the array of FPU is sufficient..
>
> If there is some pattern in a loop part in the algorithm, but has complex data hazards, then just replicating one pattern (so can be an instance) on the chip and connecting them is sufficient, there is no data transfer through memory.
>
> FPGA has DSP(integer multiply-add), and can configure floating-point arithmetic logic with 5-7 DSPs. But physical layout of DSPs on a chip makes difficult to increase clock frequency. And most recent FPGA has DSP array (I think it is one of “integer”-specific many-core, and introduced a legacy matters in FPGA).
>
> I have difficult to say that my HDL(SystemVerilog HDL) coded one is CGRA, but there is no another example.

You probably want to review Charles LaForest's octavo project: http://fpgacpu.ca/octavo/
It was an attempt at maximum performance ISA in FPGA fabric.
And was a barrel processor.

However the xilinx/AMD microblaze and the Altera/intel nios-II run at similar speeds and LUT counts in their minimal configurations
without being barrel processors.

Another person in this arena is Jan Gray, https://fpga.org/ and more recently: https://github.com/grayresearch
who does hand layout of his FPGA cores for maximum speed/minimal LUT count.

It's been a while since I've looked at these works, so above should be considered "approximate".

On Monday, August 21, 2023 at 2:36:04 PM UTC-5, S.Takano wrote:
> I am still Ph.D. candidate at some university, but teacher under my studying will retire March next year. So I think of my giving up the getting, and concentrate on to my job (research of microarchitecture and its compiler), but not yet decide.
<
Long term, the difference is:: <in my observed opinion>::
a) one you get paid more for doing what he wants
b) other you get paid less for doing what you want
<
With (b) having the potential for a really big payoff at low probability.
<
> -
> S.Takano

On Wednesday, August 30, 2023 at 12:42:48 PM UTC-5, JimBrakefield wrote:
> On Wednesday, August 30, 2023 at 4:29:08 AM UTC-5, S.Takano wrote:
> > At first, I would like to introduce an algorithm composition from softwares, next difference from others (cpu&gpu).
> > Algorithm can be represented by programming, and then it is compiled to a binary code (let us say bit stream). The compilation involves analyses of control-flow and data-flow. The control-flow is flow of instrctiictiins that the basice block is regarded as a graph node, nodes are connected by conditional/unconditional branch instrctioion. Flow is diceded by the instruction. Other hand, data-flow is flow of data, just like a logic circuit’s signal flow.
> >
> > CPU is based on the control-flow, and breaks up the basic block into set of peices to get an instruction-level parallelism as we know a superscalar processor, a unit of handling is a thread. GPU is also based on the control-flow and it also takes the threading. One thread is copied and pasted to so many cores, and takes into account for thread-level parallelism. So sometime GPU is regarded as a limited many-core.
> >
> > CGRA is a data-flow based computing, sometime called a spatial computing(and traditionals are temporal computing). It is same as FPGA at a concept level, but it has ALU/FPU (so called a coarsed-grained, and FPGA is called a fined-grained), have not a single bit processing unit. So we can see CGRA as data-flow “
> > graph” based execution modelthat gains data-level parallelism well. So some time classified to control-flow execution on the temporal computing for CPU&GPU, and data-flow execution on the spatial computing for FPGA/CGRA.
> >
> > CGRA benefits from the reconfiguration. The reconfiguration is to change data-flow graph on a chip, it can be classified to a static reconfiguration that reconfigures only at kicking start, and a dynamic reconfiguration meaning of runtime reconfiguration. For example, FIR filter that can have multiple steps of multiply-add, the steps can be on the chips, the steps feed vector/stream data and outputs filtered data as a vector/stream. So, ideally it provides one filtered output per clock cycle because there is no overhead such as the branch instructions.
> >
> > Someone seems to want change the number of steps because the number decides utilization rate for the data-flow graph of the filter. For example, 5 steps filter needs more than 5 continuous input data to keep its utilization (we can imagine one input data makes almost steps are idling). When the someone needs N-step configuration, then replicates one-step configution N times on a chip and connect them.
> >
> > Another example is software having complex data hazards that makes difficult to execute on temporal computing. We can see such examples in scientific applications, a kernel of a molecular dynamics involving huge data-shuffling through arrays on memory, for example. Because CGRA is data-flow graph based execution, it simply bind the graph on the array of FPU is sufficient.
> >
> > If there is some pattern in a loop part in the algorithm, but has complex data hazards, then just replicating one pattern (so can be an instance) on the chip and connecting them is sufficient, there is no data transfer through memory.
> >
> > FPGA has DSP(integer multiply-add), and can configure floating-point arithmetic logic with 5-7 DSPs. But physical layout of DSPs on a chip makes difficult to increase clock frequency. And most recent FPGA has DSP array (I think it is one of “integer”-specific many-core, and introduced a legacy matters in FPGA).
> >
> > I have difficult to say that my HDL(SystemVerilog HDL) coded one is CGRA, but there is no another example.
> You probably want to review Charles LaForest's octavo project: http://fpgacpu.ca/octavo/
> It was an attempt at maximum performance ISA in FPGA fabric.
> And was a barrel processor.
>
> However the xilinx/AMD microblaze and the Altera/intel nios-II run at similar speeds and LUT counts in their minimal configurations
> without being barrel processors.
>
> Another person in this arena is Jan Gray, https://fpga.org/ and more recently: https://github.com/grayresearch
> who does hand layout of his FPGA cores for maximum speed/minimal LUT count.
>
> It's been a while since I've looked at these works, so above should be considered "approximate".

Need to walk back a little. After a web search on "CGRA fpga" it appears to be an active research area at several prominent universities.
CGRA was active in the past, the new efforts have more powerful software tool ambitions (IMHO).
And, these new efforts include the creation of custom "FPGA" silicon.

And there appears to be overlap with:
PYNQ (python on Zynq FPGAs) and partial reconfiguration
Jason Cong's group at UCLA (trying to make programmers into FPGA designers)
Jan Gray's accelerators for RISC-V
Also? https://www.oneapi.io/wp-content/uploads/sites/74/Ronan-Keryell-Porting-SYCL-with-oneAPI-DPC-to-Xilinx-FPGA-Versal-ACAP-CGRA.pdf
"3nm devices deserve 3nm C++"

On Wednesday, August 30, 2023 at 7:52:18 PM UTC-5, JimBrakefield wrote:

> "3nm devices deserve 3nm C++"
<
Is that the <relatively slim> C++ of 1989 or the <relatively bloated> C++ of today ??
<
Do you really want silicon to be {constructing and destructing} {transistors and wires} by itself ??
<

MitchAlsup <MitchAlsup@aol.com> writes:
>On Wednesday, August 30, 2023 at 7:52:18=E2=80=AFPM UTC-5, JimBrakefield wr=
>ote:
>
>> "3nm devices deserve 3nm C++"
><
>Is that the <relatively slim> C++ of 1989 or the <relatively bloated> C++ o=
>f today ??

FWIW, one can still program in C++ using only the features of C++2.1. The
bloat is optional.

On Wednesday, August 30, 2023 at 8:41:20 PM UTC-5, MitchAlsup wrote:
> On Wednesday, August 30, 2023 at 7:52:18 PM UTC-5, JimBrakefield wrote:
>
> > "3nm devices deserve 3nm C++"
> <
> Is that the <relatively slim> C++ of 1989 or the <relatively bloated> C++ of today ??
> <
> Do you really want silicon to be {constructing and destructing} {transistors and wires} by itself ??
> <

At the rate things are going, one can tape out an ASIC faster than place and route into an FPGA.

On 8/31/2023 7:48 AM, JimBrakefield wrote:
> On Wednesday, August 30, 2023 at 8:41:20 PM UTC-5, MitchAlsup wrote:
>> On Wednesday, August 30, 2023 at 7:52:18 PM UTC-5, JimBrakefield wrote:
>>
>>> "3nm devices deserve 3nm C++"
>> <
>> Is that the <relatively slim> C++ of 1989 or the <relatively bloated> C++ of today ??
>> <
>> Do you really want silicon to be {constructing and destructing} {transistors and wires} by itself ??
>> <
>
> At the rate things are going, one can tape out an ASIC faster than place and route into an FPGA.

But even if that is true, the time (and the cost) from tape out/place
and route to getting silicon to test is >>> for ASIC than for an FPGA.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>On 8/31/2023 7:48 AM, JimBrakefield wrote:
>> On Wednesday, August 30, 2023 at 8:41:20 PM UTC-5, MitchAlsup wrote:
>>> On Wednesday, August 30, 2023 at 7:52:18 PM UTC-5, JimBrakefield wrote:
>>>
>>>> "3nm devices deserve 3nm C++"
>>> <
>>> Is that the <relatively slim> C++ of 1989 or the <relatively bloated> C++ of today ??
>>> <
>>> Do you really want silicon to be {constructing and destructing} {transistors and wires} by itself ??
>>> <
>>
>> At the rate things are going, one can tape out an ASIC faster than place and route into an FPGA.

A mask set for 7nm runs about USD10,000,000. A mask set for 3nm is USD40,000,000. Best
get it right the first time.

On Thursday, August 31, 2023 at 2:42:48 AM UTC+9, JimBrakefield wrote:
> You probably want to review Charles LaForest's octavo project: http://fpgacpu.ca/octavo/
> It was an attempt at maximum performance ISA in FPGA fabric.
> And was a barrel processor.
>
> However the xilinx/AMD microblaze and the Altera/intel nios-II run at similar speeds and LUT counts in their minimal configurations
> without being barrel processors.
>
> Another person in this arena is Jan Gray, https://fpga.org/ and more recently: https://github.com/grayresearch
> who does hand layout of his FPGA cores for maximum speed/minimal LUT count.
>
> It's been a while since I've looked at these works, so above should be considered "approximate".

Jim-san,

Thank you for your advices, I will check these web sites after posting comments here.

Regads,
S.Takano

On Thursday, August 31, 2023 at 9:52:18 AM UTC+9, JimBrakefield wrote:
> CGRA was active in the past, the new efforts have more powerful software tool ambitions (IMHO).
> And, these new efforts include the creation of custom "FPGA" silicon.

Right, CGRA research have started in 90s, after released of FPGAs.
I was a watcher of FPGA/FCCM/FPL conferences (major conferences for FPGA/CGRA in the world), and I did research presentation at the FPL when I was graduate student in 90s. My hobby 2 papers are accepted to ACM Transactions on Reconfigurable Technology and Systems (TRETS). But I have stopped the watching since 2015.

> And there appears to be overlap with:
> PYNQ (python on Zynq FPGAs) and partial reconfiguration
> Jason Cong's group at UCLA (trying to make programmers into FPGA designers)

I have Pynq Z1 and Z2 borads (these are reasonable price for hobby) and connected to Cong-san. Pynq system supports an "offloading" task by python program to accelerator in FPGA part in zynq chip, and ARM core can control the part. This is very nice concept (reseached since in 2010).

> Jan Gray's accelerators for RISC-V
> Also? https://www.oneapi.io/wp-content/uploads/sites/74/Ronan-Keryell-Porting-SYCL-with-oneAPI-DPC-to-Xilinx-FPGA-Versal-ACAP-CGRA.pdf
> "3nm devices deserve 3nm C++"

Thank you for info!

Regards,
S.Takano

On Thursday, August 31, 2023 at 3:36:28 AM UTC+9, MitchAlsup wrote:
> Long term, the difference is:: <in my observed opinion>::
> a) one you get paid more for doing what he wants
> b) other you get paid less for doing what you want
> With (b) having the potential for a really big payoff at low probability.

I appriciate your advice, Mitch-san, absolutely yes. I can challange getting Ph.D.

On Thursday, August 31, 2023 at 3:36:28 AM UTC+9, MitchAlsup wrote:
> Long term, the difference is:: <in my observed opinion>::
> a) one you get paid more for doing what he wants
> b) other you get paid less for doing what you want
> With (b) having the potential for a really big payoff at low probability.

I appriciate your advice, Mitch-san, absolutely yes. I can challange getting Ph.D. again if I still getting enough salary and current company has a payment support progam. (But there is a "student programs" for buying items (both of software and hardware, I bought an FPGA board with discount), this is good point for staying as a student.)

I will concider whether release my HDL code as an open-source hardware or not. And research at company is a compiler technology focusing on CGRAs, I had a plan to combine my CGRA hardware (student) and CGRA compiler, to establish a system.

Best,
S.Takano

On Thursday, August 31, 2023 at 11:48:45 PM UTC+9, JimBrakefield wrote:
> At the rate things are going, one can tape out an ASIC faster than place and route into an FPGA.

In general, logic circuit configured on the FPGA is 3-4 older ASIC equivalent (in terms of a logic gate count), and typycal clock freq of the configured logic is 100-200MHz.

Best,
S.Takano

On Friday, September 1, 2023 at 12:40:03 AM UTC+9, Stephen Fuld wrote:
> > At the rate things are going, one can tape out an ASIC faster than place and route into an FPGA.
> But even if that is true, the time (and the cost) from tape out/place
> and route to getting silicon to test is >>> for ASIC than for an FPGA.

In 90s, Xilinx has claimed that FPGAs have benefit of a time-to-market (early releasing), so a base communication equipments for a cell phones take FPGAs (updating user logic circuit is possible by the reconfiguration after releasing the system).

Best,
S.Takano

On Friday, September 1, 2023 at 1:05:58 AM UTC+9, Scott Lurndal wrote:
> >> At the rate things are going, one can tape out an ASIC faster than place and route into an FPGA.
> A mask set for 7nm runs about USD10,000,000. A mask set for 3nm is USD40,000,000. Best
> get it right the first time.

System perspective, a part of major cost is software side (1.25x or more) to make system in case of ASIC. And ASIC takes longer verification time (major part of logic circuit development in terms of time).

Best,
S.Takano

> S.Takano
<
The thing I never got about CGRAs is how do you size the design effort ??
<
What happens when the size you choose ends up being 1 too few in the function unit department ?
Or one too few in the memory BW department ?
??

On Sunday, September 3, 2023 at 5:48:59 AM UTC+9, MitchAlsup wrote:
> The thing I never got about CGRAs is how do you size the design effort ??

I do not got “size” you noted, but if the size mean time and cost for the design;
I think recent trend in computer architecture is “architecture can be complex, logic circuit must be simple”, but my philosophy is “architecture must be simple, logic circuit should be simple”. My skill for design is poor, so I keep simplicity. My CGRA architecture core takes only 3 modules (processing element, memory element, and interconect element, this concept reduce design&verification time and cost I think.

> What happens when the size you choose ends up being 1 too few in the function unit department ?

If the “size” means how much functional units are in the ALU/FPU, typical CGRA has processing element having only a multiply-add unit and tiny register file targetting for digital signal processing. Recent deep learning needs huge multipy-add for matrix-vector/matrix-matrix multiplication, so they trade the functions for the targetting applications.

Because my concept is to keep simplification, ALU/FPU should keep 4 arithmetics, logics, shifts, same as CPUs have. And then assembling needing complex function by gathering processing elements and memory elements, just like a schemic diagram of a digital logic circuit is binded on CGRA (array consisting of the elements). I think this is similar to RISC processors.

> Or one too few in the memory BW department ?
Yes, this is very good point. Case of FPGA, there is hundreds of on-chip memories in general, so configured logic circuit can read from and write in them in parallel (so benefits data-level parallelism).
Some CGRAs also take this approach, processing after loading source data onto many on-chip memories from external memory, and write intermediate results into the on-chip memories, loading for reference from the on-chip memories, and storing…, just repeat this loop, so this approach reduces accesses to external memory.

Best,
S.Takano

On 8/30/23 1:42 PM, JimBrakefield wrote:
[snip]
> Another person in this arena is Jan Gray, https://fpga.org/ and more recently: https://github.com/grayresearch
> who does hand layout of his FPGA cores for maximum speed/minimal LUT count.

Manual layout is possible? From the little I have read, I thought
the FPGA configuration bitstreams used a non-disclosed format and
the FPGA vendor tools did not provide such specific control. My
"knowledge" about FPGAs is very limited.

I would not be surprised if redundancy provided for manufacturing
yield could effect timing, though non-fatal process variation
might well be more significant. (As others have noted, a defect is
a variation that exceeded acceptable bounds.) With process
variation, it seems reasonably conceivable that the best mapping
for one FPGA (or region within an FPGA) might not be the best for
another (though few might care about small variations, especially
when testing different possibilities would be relatively
expensive).

Impenetrable abstractions can provide some advantages (e.g., not
being constrained by important users who exploit implementation-
specific behaviors), though I would rather be able to trust users
to accept guarantee limitations.

On Monday, September 4, 2023 at 12:06:44 PM UTC-5, Paul A. Clayton wrote:
> On 8/30/23 1:42 PM, JimBrakefield wrote:
> [snip]
> > Another person in this arena is Jan Gray, https://fpga.org/ and more recently: https://github.com/grayresearch
> > who does hand layout of his FPGA cores for maximum speed/minimal LUT count.
> Manual layout is possible? From the little I have read, I thought
> the FPGA configuration bitstreams used a non-disclosed format and
> the FPGA vendor tools did not provide such specific control. My
> "knowledge" about FPGAs is very limited.
>
> I would not be surprised if redundancy provided for manufacturing
> yield could effect timing, though non-fatal process variation
> might well be more significant. (As others have noted, a defect is
> a variation that exceeded acceptable bounds.) With process
> variation, it seems reasonably conceivable that the best mapping
> for one FPGA (or region within an FPGA) might not be the best for
> another (though few might care about small variations, especially
> when testing different possibilities would be relatively
> expensive).
>
> Impenetrable abstractions can provide some advantages (e.g., not
> being constrained by important users who exploit implementation-
> specific behaviors), though I would rather be able to trust users
> to accept guarantee limitations.

Not fully knowledgeable
|> Manual layout is possible?

http://www.fpgacpu.org/usenet/floorplanning.html (1998)
http://www.fpgacpu.org/usenet/generators.html (2000)
Designing a Simple FPGA-Optimized RISC CPU and System-on-a-Chip (2002) (best exhibit of his approach)
Mapping CMPs to Xilinx FPGAs (2005)

These articles are about 20 years ago.
And the tools have improved since.
And am not knowledgeable on the Vivado floor planning tool.

On 9/4/23 2:03 PM, JimBrakefield wrote:
> On Monday, September 4, 2023 at 12:06:44 PM UTC-5, Paul A. Clayton wrote:
>> On 8/30/23 1:42 PM, JimBrakefield wrote:
>> [snip]
>>> Another person in this arena is Jan Gray, https://fpga.org/ and more recently: https://github.com/grayresearch
>>> who does hand layout of his FPGA cores for maximum speed/minimal LUT count.
>> Manual layout is possible?

[snip]
> Not fully knowledgeable
> |> Manual layout is possible?
>
> http://www.fpgacpu.org/usenet/floorplanning.html (1998)
> http://www.fpgacpu.org/usenet/generators.html (2000)
> Designing a Simple FPGA-Optimized RISC CPU and System-on-a-Chip (2002) (best exhibit of his approach)
> Mapping CMPs to Xilinx FPGAs (2005)
>
> These articles are about 20 years ago.
> And the tools have improved since.
> And am not knowledgeable on the Vivado floor planning tool.

Thanks, that was interesting and somewhat informative.

(I suspect explaining the abilities and limitations abstractly to
one who has no FPGA programming experience would be difficult;
complete unfamiliarity with the tools and techniques introduces a
communication barrier. "Explain it like I am five years old"
coupled with "so I could do a Master's thesis around it next year"
is probably not a reasonable expectation.☺ That people use their
time to explain technical matters — for free — is admirable, yet
people have biological (and more specifically human) needs.
Admiring someone correlates with concern for their well-being.)