On Sunday, January 29, 2023 at 10:31:45 AM UTC-7, MitchAlsup wrote:
> On Sunday, January 29, 2023 at 11:07:44 AM UTC-6, Quadibloc wrote:

> > So I was advocating FPGAs with real FPUs as a component, not synthesizing
> > an FPU on an FPGA, which is much slower.

> The IP to which might cost even more than the FPGA it goes in.

Wouldn't that be an argument that the cost of CPUs and GPUs
would (also) be prohibitive?

I am being serious here. An FPGA that included a large number of
full-bore 64-bit floating point ALUs could indeed be designed to
accelerate the inner loops of a lot of programs, particularly in
scientific computing, which is the field that makes the most use
of HPC.

That might still be a special-purpose device, but no more so - and
from some viewpoints, considerably less so - than the typical FPGA,
which seems only to be applicable to things which are otherwise
difficult to do on a CPU.

I suppose a joke to the effect that a special-purpose computing
device is one that's good for somebody else's purpose might fit in
here.

John Savard

On Sunday, January 29, 2023 at 3:11:06 PM UTC-6, Quadibloc wrote:
> On Sunday, January 29, 2023 at 10:31:45 AM UTC-7, MitchAlsup wrote:
> > On Sunday, January 29, 2023 at 11:07:44 AM UTC-6, Quadibloc wrote:
>
> > > So I was advocating FPGAs with real FPUs as a component, not synthesizing
> > > an FPU on an FPGA, which is much slower.
>
> > The IP to which might cost even more than the FPGA it goes in.
<
> Wouldn't that be an argument that the cost of CPUs and GPUs
> would (also) be prohibitive?
<
This falls into the category where there might be excellent engineering
reasons that something should be done with an FPGA added to a
system, but the practicality of getting there is impracticable (licensing,
legal, intellectual property $$$s,...)

EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> Scott Lurndal wrote:
>> MitchAlsup <MitchAlsup@aol.com> writes:
>>> On Saturday, January 28, 2023 at 6:11:30 PM UTC-6, JimBrakefield wrote:
>>>> https://www.youtube.com/watch?v=3D-XuMWvGUocI&t=3D123s=20
>>>> Starts at the 2 minute mark. He argues that computer performance=20
>>>> has plateaued and that FPGAs offer a route to higher performance.=20
>>> <
>>
>>> <
>>> I should note: you cannot debug HW by single stepping !! as there is no def=
>>> inition=20
>>> of what single stepping means at the gate level. No, HW designer use simula=
>>> tors=20
>>> where they can stop at =C2=BD clock intervals and then examine millions of =
>>> signals--
>>> some of them X (unknown value) and Z (high impeadence).
>>
>> Actually, that's how we debugged the Burroughs mainframes, by stepping a
>> single cycle at a time (using an external "maintenance processor" to
>> drive the processor logic using scan chains). This was late 70's.
>
> Luxury! I used a dual trace oscilloscope and an In-Circuit Emulator.

https://dilbert.com/strip/1992-09-08 comes to mind.

MitchAlsup <MitchAlsup@aol.com> writes:
>On Sunday, January 29, 2023 at 3:11:06 PM UTC-6, Quadibloc wrote:
>> On Sunday, January 29, 2023 at 10:31:45 AM UTC-7, MitchAlsup wrote:
>> > On Sunday, January 29, 2023 at 11:07:44 AM UTC-6, Quadibloc wrote:
>>
>> > > So I was advocating FPGAs with real FPUs as a component, not synthesizing
>> > > an FPU on an FPGA, which is much slower.
>>
>> > The IP to which might cost even more than the FPGA it goes in.
><
>> Wouldn't that be an argument that the cost of CPUs and GPUs
>> would (also) be prohibitive?
><
>This falls into the category where there might be excellent engineering
>reasons that something should be done with an FPGA added to a
>system, but the practicality of getting there is impracticable (licensing,
>legal, intellectual property $$$s,...)

Have you priced out a 3mm mask recently?

scott@slp53.sl.home (Scott Lurndal) writes:
>MitchAlsup <MitchAlsup@aol.com> writes:
>>On Sunday, January 29, 2023 at 3:11:06 PM UTC-6, Quadibloc wrote:
>>> On Sunday, January 29, 2023 at 10:31:45 AM UTC-7, MitchAlsup wrote:
>>> > On Sunday, January 29, 2023 at 11:07:44 AM UTC-6, Quadibloc wrote:
>>>
>>> > > So I was advocating FPGAs with real FPUs as a component, not synthesizing
>>> > > an FPU on an FPGA, which is much slower.
>>>
>>> > The IP to which might cost even more than the FPGA it goes in.
>><
>>> Wouldn't that be an argument that the cost of CPUs and GPUs
>>> would (also) be prohibitive?
>><
>>This falls into the category where there might be excellent engineering
>>reasons that something should be done with an FPGA added to a
>>system, but the practicality of getting there is impracticable (licensing,
>>legal, intellectual property $$$s,...)
>
>Have you priced out a 3mm mask recently?
^^ ---> nm.

On Sunday, January 29, 2023 at 5:03:55 PM UTC-6, Scott Lurndal wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >On Sunday, January 29, 2023 at 3:11:06 PM UTC-6, Quadibloc wrote:
> >> On Sunday, January 29, 2023 at 10:31:45 AM UTC-7, MitchAlsup wrote:
> >> > On Sunday, January 29, 2023 at 11:07:44 AM UTC-6, Quadibloc wrote:
> >>
> >> > > So I was advocating FPGAs with real FPUs as a component, not synthesizing
> >> > > an FPU on an FPGA, which is much slower.
> >>
> >> > The IP to which might cost even more than the FPGA it goes in.
> ><
> >> Wouldn't that be an argument that the cost of CPUs and GPUs
> >> would (also) be prohibitive?
> ><
> >This falls into the category where there might be excellent engineering
> >reasons that something should be done with an FPGA added to a
> >system, but the practicality of getting there is impracticable (licensing,
> >legal, intellectual property $$$s,...)
<
> Have you priced out a 3mm mask recently?
<
22nm and 14nm are not that expensive right now.

Michael S <already5chosen@yahoo.com> writes:
>Pay attention that programming FPGAs in Verilog is almost exclusively
>USA trait. The rest of the world does it in VHDL.

Bernd Paysan from Europe wrote b16(-dsp) and b16-small in Verilog
<https://github.com/forthy42/b16-small>. It has been used in custom
silicon, not (to my knowledge) in FPGA, but does that make a
difference?

From the HOPL talk about Verilog, my impression is: Around 2000 all
the buzz was for VHDL, and that Verilog was doomed. Verilog survived
and won in large projects, because it was designed for efficient
implementation of simulators, while the design of VHDL necessarily
leads to less efficiency. For large projects this efficiency is very
important, while for smaller projects the VHDL simulators are fast
enough.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Monday, January 30, 2023 at 10:39:35 AM UTC+2, Anton Ertl wrote:
> Michael S <already...@yahoo.com> writes:
> >Pay attention that programming FPGAs in Verilog is almost exclusively
> >USA trait. The rest of the world does it in VHDL.
> Bernd Paysan from Europe wrote b16(-dsp) and b16-small in Verilog
> <https://github.com/forthy42/b16-small>. It has been used in custom
> silicon, not (to my knowledge) in FPGA, but does that make a
> difference?
>

It absolutely does.
FPGA development and ASIC development are different cultures.
Naturally, use of FPGAs for ASIC prototyping is part of ASIC culture.

I could imagine that "FPGAs as compute accelerators" is yet another
culture if there are enough people involved to form the culture.
Likely with different set of preferred tools. I know nothing about
it except that I know that it does not really work. But even that
knowledge is not 1st hand.

> From the HOPL talk about Verilog, my impression is: Around 2000 all
> the buzz was for VHDL, and that Verilog was doomed. Verilog survived
> and won in large projects, because it was designed for efficient
> implementation of simulators, while the design of VHDL necessarily
> leads to less efficiency. For large projects this efficiency is very
> important, while for smaller projects the VHDL simulators are fast
> enough.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Michael S <already5chosen@yahoo.com> writes:
>On Monday, January 30, 2023 at 10:39:35 AM UTC+2, Anton Ertl wrote:
>> Michael S <already...@yahoo.com> writes:
>> >Pay attention that programming FPGAs in Verilog is almost exclusively
>> >USA trait. The rest of the world does it in VHDL.
>> Bernd Paysan from Europe wrote b16(-dsp) and b16-small in Verilog
>> <https://github.com/forthy42/b16-small>. It has been used in custom
>> silicon, not (to my knowledge) in FPGA, but does that make a
>> difference?
>>

>
>I could imagine that "FPGAs as compute accelerators" is yet another
>culture if there are enough people involved to form the culture.
>Likely with different set of preferred tools. I know nothing about
>it except that I know that it does not really work. But even that
>knowledge is not 1st hand.

You "know that it does not really work". But not from first-hand
experience. So, what data (other than off-hand anecdotal data) do
you have to support your position?

https://www.researchgate.net/publication/354063174_FPGA-based_HPC_accelerators_An_evaluation_on_performance_and_energy_efficiency
"Results show that while FPGAs struggle to compete in absolute
terms with GPUs on memory- and compute- intensive kernels,
they require far less power and can deliver nearly the same
energy efficiency."

https://ieeexplore.ieee.org/document/9556357

"FPGAs are already known to provide interesting speedups in
several application fields, but to estimate their expected
performance in the context of typical HPC workloads is not
straightforward."

https://evision-systems.com/high-performance-computing/

FPGAs have been promient at SC for the last twenty years,
see the program for SC22, e.g.

Advances in FPGA Programming and Technology for HPC

"FPGAs have gone from niche components to being a central
part of many data centers worldwide to being considered for
core HPC installations. The last year has seen tremendous advances in
FPGA programmability and technology, and FPGAs for general HPC is
apparently within reach."

Task Scheduling on FPGA-Based Accelerators without Partial Reconfiguration

etc.

jgd@cix.co.uk (John Dallman) writes:
>In article <UWSBL.445233$8_id.34107@fx09.iad>, scott@slp53.sl.home (Scott
>Lurndal) wrote:
>
>> You "know that it does not really work". But not from first-hand
>> experience.
>
>From the last time I looked at add-on accelerators, how fast does data
>get in and out of them? What's the minimum size block of doubles when you
>can save time, overall, on getting the data into the FPGA, processing it,
>and getting it back out again?

Most use PCI-Express. So the bandwidth depends on which generation
and the number of lanes. Many FPGA have hard PCI-E gen 4 or Gen5
using 25Gbps SERDES.

On Monday, January 30, 2023 at 2:39:35 AM UTC-6, Anton Ertl wrote:
> Michael S <already...@yahoo.com> writes:
> >Pay attention that programming FPGAs in Verilog is almost exclusively
> >USA trait. The rest of the world does it in VHDL.
> Bernd Paysan from Europe wrote b16(-dsp) and b16-small in Verilog
> <https://github.com/forthy42/b16-small>. It has been used in custom
> silicon, not (to my knowledge) in FPGA, but does that make a
> difference?
>
> From the HOPL talk about Verilog, my impression is: Around 2000 all
> the buzz was for VHDL, and that Verilog was doomed. Verilog survived
> and won in large projects, because it was designed for efficient
> implementation of simulators, while the design of VHDL necessarily
> leads to less efficiency. For large projects this efficiency is very
> important, while for smaller projects the VHDL simulators are fast
> enough.
<
In other words--with todays fast CPUs--one can dispense with the
pipeline timing simulators written in C and proceed directly to System
Verilog which can be used as pipeline timing simulator, FPGA output
ASIC, and Standard cell library implementations. Saving design team
effort.
<
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Monday, January 30, 2023 at 2:43:49 PM UTC-6, Scott Lurndal wrote:
> j...@cix.co.uk (John Dallman) writes:
> >In article <UWSBL.445233$8_id....@fx09.iad>, sc...@slp53.sl.home (Scott
> >Lurndal) wrote:
> >
> >> You "know that it does not really work". But not from first-hand
> >> experience.
> >
> >From the last time I looked at add-on accelerators, how fast does data
> >get in and out of them? What's the minimum size block of doubles when you
> >can save time, overall, on getting the data into the FPGA, processing it,
> >and getting it back out again?
<
> Most use PCI-Express. So the bandwidth depends on which generation
> and the number of lanes. Many FPGA have hard PCI-E gen 4 or Gen5
> using 25Gbps SERDES.
<
Yes, but (the BIG but) the cores on the "chip(s)" access DRAM with ½
cache line width busses at full core speeds, while PCIe has a) lots
of added latency, b) way less than 256-bits per cycle, and c) slower
cycles than the cores.
<
So, it if is DRAM bound application, FPGAs are not going to win
accessing DRAM via PCIe.

MitchAlsup <MitchAlsup@aol.com> writes:
>On Monday, January 30, 2023 at 2:43:49 PM UTC-6, Scott Lurndal wrote:
>> j...@cix.co.uk (John Dallman) writes:=20
>> >In article <UWSBL.445233$8_id....@fx09.iad>, sc...@slp53.sl.home (Scott=
>=20
>> >Lurndal) wrote:=20
>> >=20
>> >> You "know that it does not really work". But not from first-hand=20
>> >> experience.=20
>> >=20
>> >From the last time I looked at add-on accelerators, how fast does data=
>=20
>> >get in and out of them? What's the minimum size block of doubles when yo=
>u=20
>> >can save time, overall, on getting the data into the FPGA, processing it=
>,=20
>> >and getting it back out again?
><
>> Most use PCI-Express. So the bandwidth depends on which generation=20
>> and the number of lanes. Many FPGA have hard PCI-E gen 4 or Gen5=20
>> using 25Gbps SERDES.
><
>Yes, but (the BIG but) the cores on the "chip(s)" access DRAM with =C2=BD
>cache line width busses at full core speeds, while PCIe has a) lots
>of added latency, b) way less than 256-bits per cycle, and c) slower=20
>cycles than the cores.
><
>So, it if is DRAM bound application, FPGAs are not going to win=20
>accessing DRAM via PCIe.

Have you looked at CXL at all? That's all transported by PCIe and
is expected to be used for DRAM-bound applications. The FPGA
can accesses _coherently_ the PCI host memory directly, no DMA
required.

On Monday, January 30, 2023 at 3:25:06 PM UTC-6, Scott Lurndal wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >On Monday, January 30, 2023 at 2:43:49 PM UTC-6, Scott Lurndal wrote:
> >> j...@cix.co.uk (John Dallman) writes:=20
> >> >In article <UWSBL.445233$8_id....@fx09.iad>, sc...@slp53.sl.home (Scott=
> >=20
> >> >Lurndal) wrote:=20
> >> >=20
> >> >> You "know that it does not really work". But not from first-hand=20
> >> >> experience.=20
> >> >=20
> >> >From the last time I looked at add-on accelerators, how fast does data=
> >=20
> >> >get in and out of them? What's the minimum size block of doubles when yo=
> >u=20
> >> >can save time, overall, on getting the data into the FPGA, processing it=
> >,=20
> >> >and getting it back out again?
> ><
> >> Most use PCI-Express. So the bandwidth depends on which generation=20
> >> and the number of lanes. Many FPGA have hard PCI-E gen 4 or Gen5=20
> >> using 25Gbps SERDES.
> ><
> >Yes, but (the BIG but) the cores on the "chip(s)" access DRAM with =C2=BD
> >cache line width busses at full core speeds, while PCIe has a) lots
> >of added latency, b) way less than 256-bits per cycle, and c) slower=20
> >cycles than the cores.
> ><
> >So, it if is DRAM bound application, FPGAs are not going to win=20
> >accessing DRAM via PCIe.
>
> Have you looked at CXL at all? That's all transported by PCIe and
> is expected to be used for DRAM-bound applications. The FPGA
> can accesses _coherently_ the PCI host memory directly, no DMA
> required.
<
I have looked at it in brief. What CLX to me is is coherence across
PCIe PHYs (i.e., pins).
It still has PCIe latency which is more like 50 clocks instead of 10
clocks to the DRAM controller.
And it has PCIe width limitations which the on-die DRAM controller
does not.
So, you go from <say> two (2) 128-bit HBM at 2GHz DDR channels
down to 8-differential-pins at 5GHz and you start to see the BW
problem. The latency through PCIe is "not all that great".
<
If you can afford to spend 128-PCIe-pins on DRAM, you can probably
make CLX word reasonably for BW limited applications but not for
latency bound applications.
<
You may or may not get the added reliability of PCIe data transfers.
<
On-die DRAM has the advantage by spending lots of pins on the
DRAM DIMM profile busses connecting the DIMMs to the die.
If you can afford this number of pins for PCIe DRAM, then you can
get into the comparative performance game; but latency remains
a stumbling block.

On Monday, January 30, 2023 at 4:08:37 PM UTC-6, MitchAlsup wrote:
> On Monday, January 30, 2023 at 3:25:06 PM UTC-6, Scott Lurndal wrote:
> > MitchAlsup <Mitch...@aol.com> writes:
> > >On Monday, January 30, 2023 at 2:43:49 PM UTC-6, Scott Lurndal wrote:
> > >> j...@cix.co.uk (John Dallman) writes:=20
> > >> >In article <UWSBL.445233$8_id....@fx09.iad>, sc...@slp53.sl.home (Scott=
> > >=20
> > >> >Lurndal) wrote:=20
> > >> >=20
> > >> >> You "know that it does not really work". But not from first-hand=20
> > >> >> experience.=20
> > >> >=20
> > >> >From the last time I looked at add-on accelerators, how fast does data=
> > >=20
> > >> >get in and out of them? What's the minimum size block of doubles when yo=
> > >u=20
> > >> >can save time, overall, on getting the data into the FPGA, processing it=
> > >,=20
> > >> >and getting it back out again?
> > ><
> > >> Most use PCI-Express. So the bandwidth depends on which generation=20
> > >> and the number of lanes. Many FPGA have hard PCI-E gen 4 or Gen5=20
> > >> using 25Gbps SERDES.
> > ><
> > >Yes, but (the BIG but) the cores on the "chip(s)" access DRAM with =C2=BD
> > >cache line width busses at full core speeds, while PCIe has a) lots
> > >of added latency, b) way less than 256-bits per cycle, and c) slower=20
> > >cycles than the cores.
> > ><
> > >So, it if is DRAM bound application, FPGAs are not going to win=20
> > >accessing DRAM via PCIe.
> >
> > Have you looked at CXL at all? That's all transported by PCIe and
> > is expected to be used for DRAM-bound applications. The FPGA
> > can accesses _coherently_ the PCI host memory directly, no DMA
> > required.
> <
> I have looked at it in brief. What CLX to me is is coherence across
> PCIe PHYs (i.e., pins).
> It still has PCIe latency which is more like 50 clocks instead of 10
> clocks to the DRAM controller.
> And it has PCIe width limitations which the on-die DRAM controller
> does not.
> So, you go from <say> two (2) 128-bit HBM at 2GHz DDR channels
> down to 8-differential-pins at 5GHz and you start to see the BW
> problem. The latency through PCIe is "not all that great".
> <
> If you can afford to spend 128-PCIe-pins on DRAM, you can probably
> make CLX word reasonably for BW limited applications but not for
> latency bound applications.
> <
> You may or may not get the added reliability of PCIe data transfers.
> <
> On-die DRAM has the advantage by spending lots of pins on the
> DRAM DIMM profile busses connecting the DIMMs to the die.
> If you can afford this number of pins for PCIe DRAM, then you can
> get into the comparative performance game; but latency remains
> a stumbling block.

Most high performance FPGAs show support for external DDR memory.
Looks like a complicated topic, in particular,
https://www.xilinx.com/products/intellectual-property/ddr4.html
appears to be licensed IP.
I would find a board or module with DDR and with example RTL.
Similar situation for Intel/Altera.

On 1/30/2023 2:58 PM, MitchAlsup wrote:
> On Monday, January 30, 2023 at 2:39:35 AM UTC-6, Anton Ertl wrote:
>> Michael S <already...@yahoo.com> writes:
>>> Pay attention that programming FPGAs in Verilog is almost exclusively
>>> USA trait. The rest of the world does it in VHDL.
>> Bernd Paysan from Europe wrote b16(-dsp) and b16-small in Verilog
>> <https://github.com/forthy42/b16-small>. It has been used in custom
>> silicon, not (to my knowledge) in FPGA, but does that make a
>> difference?
>>
>> From the HOPL talk about Verilog, my impression is: Around 2000 all
>> the buzz was for VHDL, and that Verilog was doomed. Verilog survived
>> and won in large projects, because it was designed for efficient
>> implementation of simulators, while the design of VHDL necessarily
>> leads to less efficiency. For large projects this efficiency is very
>> important, while for smaller projects the VHDL simulators are fast
>> enough.
> <
> In other words--with todays fast CPUs--one can dispense with the
> pipeline timing simulators written in C and proceed directly to System
> Verilog which can be used as pipeline timing simulator, FPGA output
> ASIC, and Standard cell library implementations. Saving design team
> effort.
> <

In my case, I am mostly using a combination of an emulator and simulations.

The emulator is written in C, and also models the pipeline timing,
branch predictor, cache hierarchy, and similar. Modeling this stuff
isn't ideal for emulation performance, but given its main goal is mostly
to emulate a CPU running at 50MHz, it works. To be useful, it does
generally need to be fast enough to keep up with real-time.

Early on, this is easier, but with some newer and "more complicated"
instructions, maintaining real-time emulation speed is more difficult
(this would mostly include things like Binary16 SIMD ops and
compressed-texture instructions and similar, which are relatively
expensive to emulate).

The simulations mostly run the Verilog code (via Verilator), and are
further divided:
Partial simulation only simulates the CPU core, with the bus and all
MMIO devices being implemented in a mix of C and C++;
Full simulation runs everything that would run in the FPGA in Verilog,
mostly providing an interface at the level of external components (DDR
RAM module, SDcard pins, VGA pins, ...).

Former is ~ 200x slower than real-time (*1), latter is ~ 1000x slower
than real-time.

Generally seems to work...

*1: Despite operating in kHz territory, for the most part its
command-like interface is still surprisingly responsive.
However, something like Doom is "one frame every 10 to 15 seconds or
so.", and GLQuake is roughly "one frame per minute".

....

I guess arguably, if one had an FPGA accelerator card, they could use it
to run Verilog at somewhat faster speeds than if using a simulation...

But, likely, one would be limited to one simulation at a time, vs on my
PC where I can often run 5 or 6 simulations at the same time (mostly to
keep watch for bugs and crashes).

Some bugs remain elusive though. Despite my efforts, I have not resolved
the "alias models in GLQuake sometimes get mangled" bug.

Have at least resolved the "robot enemies are broken in ROTT" bug:
It turns out a bug in the "expression reducer" was causing expressions
to sometimes be reduced in ways which did not respect lexical binding
semantics (so it would resolve a symbol in terms of an outer scope
before the inner scope copes into being; in cases where the intended
inner scope variable shadows a definition in an outer scope).

This turns out to have also been the cause of "Third demo in Doom
desyncs on BJX2 in a different way than on x86" bug.

Had also found and fixed another bug where "label lookup for a given
address" in BGBCC would sometimes fail if the label was at the same
address as a line-number. This was also resulting in a few minor bugs
(mostly involving the WEXifier incorrectly shuffling instructions across
label boundaries).

>> - anton
>> --
>> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
>> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

MitchAlsup <MitchAlsup@aol.com> writes:
>On Monday, January 30, 2023 at 2:39:35 AM UTC-6, Anton Ertl wrote:
>> From the HOPL talk about Verilog, my impression is: Around 2000 all
>> the buzz was for VHDL, and that Verilog was doomed. Verilog survived
>> and won in large projects, because it was designed for efficient
>> implementation of simulators, while the design of VHDL necessarily
>> leads to less efficiency. For large projects this efficiency is very
>> important, while for smaller projects the VHDL simulators are fast
>> enough.
><
>In other words--with todays fast CPUs--one can dispense with the
>pipeline timing simulators written in C and proceed directly to System
>Verilog which can be used as pipeline timing simulator, FPGA output
>ASIC, and Standard cell library implementations. Saving design team
>effort.

I am not an expert, but

1) "todays fast CPUs" don't help, because programs are now written to
require faster CPUs, and therefore faster simulators. If the
simulator is slower by a factor X, the development of faster CPUs
means that the simulator is still a factor X slower than the CPU you
want to simulate.

2) I expect you still want architecture simulators, microarchitecture
simulators, and circuit-level simulators. You seem to be discussing
microarchitecture simulators above. Switching from C to System
Verilog for that may be useful for consistency between the
microarchitecture simulator and the circuit-level simulator (in
Verilog), but otherwise has little to do with what I wrote.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Monday, January 30, 2023 at 10:39:35 AM UTC+2, Anton Ertl wrote:
> Michael S <already...@yahoo.com> writes:
> >Pay attention that programming FPGAs in Verilog is almost exclusively
> >USA trait. The rest of the world does it in VHDL.
> Bernd Paysan from Europe wrote b16(-dsp) and b16-small in Verilog
> <https://github.com/forthy42/b16-small>. It has been used in custom
> silicon, not (to my knowledge) in FPGA, but does that make a
> difference?
>
> From the HOPL talk about Verilog, my impression is: Around 2000 all
> the buzz was for VHDL, and that Verilog was doomed. Verilog survived
> and won in large projects, because it was designed for efficient
> implementation of simulators, while the design of VHDL necessarily
> leads to less efficiency.

According to my understanding, VHDL is hard to simulate efficiently
with interpreted simulators. On so called compiled-code simulators
the speed of simulation either does not depend at all on the HDL
used or depends very little.

> For large projects this efficiency is very
> important, while for smaller projects the VHDL simulators are fast
> enough.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

JimBrakefield <jim.brakefield@ieee.org> writes:
>On Monday, January 30, 2023 at 4:08:37 PM UTC-6, MitchAlsup wrote:
>> On Monday, January 30, 2023 at 3:25:06 PM UTC-6, Scott Lurndal wrote:
>> > MitchAlsup <Mitch...@aol.com> writes:

>> <
>> If you can afford to spend 128-PCIe-pins on DRAM, you can probably
>> make CLX word reasonably for BW limited applications but not for
>> latency bound applications.

A x16 requires 82 pins. A x4, 21. PCIe 5.0 bandwidth is 4GB/sec per lane,
so x4 gives you 16GB/sec; x16 64GB/sec.

On 31/01/2023 12:29, Michael S wrote:
> On Monday, January 30, 2023 at 10:39:35 AM UTC+2, Anton Ertl wrote:
>> Michael S <already...@yahoo.com> writes:
>>> Pay attention that programming FPGAs in Verilog is almost exclusively
>>> USA trait. The rest of the world does it in VHDL.
>> Bernd Paysan from Europe wrote b16(-dsp) and b16-small in Verilog
>> <https://github.com/forthy42/b16-small>. It has been used in custom
>> silicon, not (to my knowledge) in FPGA, but does that make a
>> difference?
>>
>> From the HOPL talk about Verilog, my impression is: Around 2000 all
>> the buzz was for VHDL, and that Verilog was doomed. Verilog survived
>> and won in large projects, because it was designed for efficient
>> implementation of simulators, while the design of VHDL necessarily
>> leads to less efficiency.
>
> According to my understanding, VHDL is hard to simulate efficiently
> with interpreted simulators. On so called compiled-code simulators
> the speed of simulation either does not depend at all on the HDL
> used or depends very little.
>
>> For large projects this efficiency is very
>> important, while for smaller projects the VHDL simulators are fast
>> enough.

My understanding is that for big projects, neither Verilog nor VHDL are
used because both languages are designed for modelling analogue
circuits, not designing digital circuits. There are a variety of
high-level digital design languages that are used that are far easier to
write correctly (and in some cases, prove correctness). Simulation is
orders of magnitude more efficient. They generally output VHDL and/or
Verilog so that synthesis tools can generate FPGA bitstreams.

An example of such a language would be SpinalHDL, which has been used
for RISC-V implementations: <https://github.com/SpinalHDL>

scott@slp53.sl.home (Scott Lurndal) writes:
>JimBrakefield <jim.brakefield@ieee.org> writes:
>>On Monday, January 30, 2023 at 4:08:37 PM UTC-6, MitchAlsup wrote:
>>> On Monday, January 30, 2023 at 3:25:06 PM UTC-6, Scott Lurndal wrote:
>>> > MitchAlsup <Mitch...@aol.com> writes:
>
>>> <
>>> If you can afford to spend 128-PCIe-pins on DRAM, you can probably
>>> make CLX word reasonably for BW limited applications but not for
>>> latency bound applications.
>
>A x16 requires 82 pins. A x4, 21. PCIe 5.0 bandwidth is 4GB/sec per lane,
>so x4 gives you 16GB/sec; x16 64GB/sec.

It is effectively a NUMA system, not much different from westmere latencies.

On 2023-01-31 18:29, David Brown wrote:
> On 31/01/2023 12:29, Michael S wrote:
>> On Monday, January 30, 2023 at 10:39:35 AM UTC+2, Anton Ertl wrote:
>>> Michael S <already...@yahoo.com> writes:
>>>> Pay attention that programming FPGAs in Verilog is almost exclusively
>>>> USA trait. The rest of the world does it in VHDL.
>>> Bernd Paysan from Europe wrote b16(-dsp) and b16-small in Verilog
>>> <https://github.com/forthy42/b16-small>. It has been used in custom
>>> silicon, not (to my knowledge) in FPGA, but does that make a
>>> difference?
>>>
>>>  From the HOPL talk about Verilog, my impression is: Around 2000 all
>>> the buzz was for VHDL, and that Verilog was doomed. Verilog survived
>>> and won in large projects, because it was designed for efficient
>>> implementation of simulators, while the design of VHDL necessarily
>>> leads to less efficiency.
>>
>> According to my understanding, VHDL is hard to simulate efficiently
>> with interpreted simulators. On so called compiled-code simulators
>> the speed of simulation either does not depend at all on the HDL
>> used or depends very little.
>>
>>> For large projects this efficiency is very
>>> important, while for smaller projects the VHDL simulators are fast
>>> enough.
>
> My understanding is that for big projects, neither Verilog nor VHDL are
> used because both languages are designed for modelling analogue
> circuits, not designing digital circuits.

Not so for VHDL, at least. For example, the standard ESA on-board
spacecraft processors for the last decade and currently are/were the
ERC32 and LEON series of SPARC v8 processors which were designed in VHDL
by ESA and Gaisler Research. Those are of course digital, not analogue.
Whether they can be considered "big" is subjective.

> There are a variety of high-level digital design languages that are
> used that are far easier to write correctly (and in some cases, prove
> correctness). Simulation is orders of magnitude more efficient.
> They generally output VHDL and/or Verilog so that synthesis tools can
> generate FPGA bitstreams.
>
> An example of such a language would be SpinalHDL, which has been used
> for RISC-V implementations: <https://github.com/SpinalHDL>

How could that work if VHDL and Verilog were intended for analogue
circuits? RISC-V is a digital system.

On Tuesday, January 31, 2023 at 4:09:09 AM UTC-6, Anton Ertl wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >On Monday, January 30, 2023 at 2:39:35 AM UTC-6, Anton Ertl wrote:
> >> From the HOPL talk about Verilog, my impression is: Around 2000 all
> >> the buzz was for VHDL, and that Verilog was doomed. Verilog survived
> >> and won in large projects, because it was designed for efficient
> >> implementation of simulators, while the design of VHDL necessarily
> >> leads to less efficiency. For large projects this efficiency is very
> >> important, while for smaller projects the VHDL simulators are fast
> >> enough.
> ><
> >In other words--with todays fast CPUs--one can dispense with the
> >pipeline timing simulators written in C and proceed directly to System
> >Verilog which can be used as pipeline timing simulator, FPGA output
> >ASIC, and Standard cell library implementations. Saving design team
> >effort.
> I am not an expert, but
>
> 1) "todays fast CPUs" don't help, because programs are now written to
> require faster CPUs, and therefore faster simulators. If the
> simulator is slower by a factor X, the development of faster CPUs
> means that the simulator is still a factor X slower than the CPU you
> want to simulate.
<
It is not so much speed as having every nuance of the microarchitecture;
such as:: interrupts, exceptions, privilege's, protection, all cycle accurate
with the microarchitecture. You want the simulator able to BOOT the Hyper-
Visor and fork off GuestOSs (in less than an hour.) You want the simulator
to be capable of debugging the Operating System, the compilers, the linker
the dynamic linker, the file system, and the network, as well as the I/O MMU.
>
> 2) I expect you still want architecture simulators, microarchitecture
> simulators, and circuit-level simulators. You seem to be discussing
> microarchitecture simulators above. Switching from C to System
> Verilog for that may be useful for consistency between the
> microarchitecture simulator and the circuit-level simulator (in
> Verilog), but otherwise has little to do with what I wrote.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Tuesday, January 31, 2023 at 11:02:36 AM UTC-6, Niklas Holsti wrote:
> On 2023-01-31 18:29, David Brown wrote:
> > On 31/01/2023 12:29, Michael S wrote:
> >> On Monday, January 30, 2023 at 10:39:35 AM UTC+2, Anton Ertl wrote:
> >>> Michael S <already...@yahoo.com> writes:
> >>>> Pay attention that programming FPGAs in Verilog is almost exclusively
> >>>> USA trait. The rest of the world does it in VHDL.
> >>> Bernd Paysan from Europe wrote b16(-dsp) and b16-small in Verilog
> >>> <https://github.com/forthy42/b16-small>. It has been used in custom
> >>> silicon, not (to my knowledge) in FPGA, but does that make a
> >>> difference?
> >>>
> >>> From the HOPL talk about Verilog, my impression is: Around 2000 all
> >>> the buzz was for VHDL, and that Verilog was doomed. Verilog survived
> >>> and won in large projects, because it was designed for efficient
> >>> implementation of simulators, while the design of VHDL necessarily
> >>> leads to less efficiency.
> >>
> >> According to my understanding, VHDL is hard to simulate efficiently
> >> with interpreted simulators. On so called compiled-code simulators
> >> the speed of simulation either does not depend at all on the HDL
> >> used or depends very little.
> >>
> >>> For large projects this efficiency is very
> >>> important, while for smaller projects the VHDL simulators are fast
> >>> enough.
> >
> > My understanding is that for big projects, neither Verilog nor VHDL are
> > used because both languages are designed for modelling analogue
> > circuits, not designing digital circuits.
> Not so for VHDL, at least. For example, the standard ESA on-board
> spacecraft processors for the last decade and currently are/were the
> ERC32 and LEON series of SPARC v8 processors which were designed in VHDL
> by ESA and Gaisler Research. Those are of course digital, not analogue.
> Whether they can be considered "big" is subjective.
> > There are a variety of high-level digital design languages that are
> > used that are far easier to write correctly (and in some cases, prove
> > correctness). Simulation is orders of magnitude more efficient.
> > They generally output VHDL and/or Verilog so that synthesis tools can
> > generate FPGA bitstreams.
> >
> > An example of such a language would be SpinalHDL, which has been used
> > for RISC-V implementations: <https://github.com/SpinalHDL>
<
> How could that work if VHDL and Verilog were intended for analogue
> circuits? RISC-V is a digital system.
<
Neither one is suitable for analog--design of Operational Amplifiers,
analog comparators, analog multipliers:: but they may be suitable
for some parts of A/D and D/A converters.

MitchAlsup <MitchAlsup@aol.com> writes:
>On Tuesday, January 31, 2023 at 4:09:09 AM UTC-6, Anton Ertl wrote:
>> MitchAlsup <Mitch...@aol.com> writes:
>> >On Monday, January 30, 2023 at 2:39:35 AM UTC-6, Anton Ertl wrote:
>> >> From the HOPL talk about Verilog, my impression is: Around 2000 all
>> >> the buzz was for VHDL, and that Verilog was doomed. Verilog survived
>> >> and won in large projects, because it was designed for efficient
>> >> implementation of simulators, while the design of VHDL necessarily
>> >> leads to less efficiency. For large projects this efficiency is very
>> >> important, while for smaller projects the VHDL simulators are fast
>> >> enough.
>> ><
>> >In other words--with todays fast CPUs--one can dispense with the
>> >pipeline timing simulators written in C and proceed directly to System
>> >Verilog which can be used as pipeline timing simulator, FPGA output
>> >ASIC, and Standard cell library implementations. Saving design team
>> >effort.
>> I am not an expert, but
>>
>> 1) "todays fast CPUs" don't help, because programs are now written to
>> require faster CPUs, and therefore faster simulators. If the
>> simulator is slower by a factor X, the development of faster CPUs
>> means that the simulator is still a factor X slower than the CPU you
>> want to simulate.
><
>It is not so much speed as having every nuance of the microarchitecture;
>such as:: interrupts, exceptions, privilege's, protection, all cycle accurate
>with the microarchitecture. You want the simulator able to BOOT the Hyper-
>Visor and fork off GuestOSs (in less than an hour.) You want the simulator
>to be capable of debugging the Operating System, the compilers, the linker
>the dynamic linker, the file system, and the network, as well as the I/O MMU.

Indeed, although even more important is to support the custom
logical blocks in the simulator to allow driver development in
advance of tapeout.