XPost: comp.lang.vhdl, comp.arch.fpga

Fereydoun Memarzanjany wrote via Google on 21/02/2024:
"
https://gist.github.com/Thraetaona/ba941e293d36d0f76db6b9f3476b823c

Having just started learning FPGA Hardware Description Languages by attempting to write a simple LED blinker, I found that the overwhelming majority of the Internet's solution to slowing down a fast clock (for making the pulsing of an LED visible to the
human eye) was either using vendor-specific, proprietary clock managers and PLLs or implementing some twenty-something-bit-wide counter as to count hundreds of thousands of clock cycles and generate a 1 Hz output.

Although there is a world of difference between counters in hardware-accelerated designs and those in software-emulated ones, I nonetheless viewed the number of daisy-chained components resulting from a mere counter as far-from-ideal and absurd; I began
searching for a more efficient method.

I came upon a rather obscure blog post from 2015 (http://www.markharvey.info/art/srldiv_04.10.2015/srldiv_04.10.2015.html) outlining the exact same issue while also referencing Xilinx systems designer Mr. Ken Chapman's proposal: using FPGAs' shift
register primitives (e.g., Xilinx's SRL32E) to alleviate that.

However, the method described therein would rely on the user to calculate the target frequency's factors between [2, 32) and painstakingly connect each and every instance of SRL32Es to one another, all in a manual manner, not to mention that the
resulting pulse would have a low, one-cycle-long duty.

Thus, I wrote `srl_prescaler.vhd`, a fully automated template generator in VHDL for an efficient, register-based cascaded clock divider based solely on SRL32 primitives alongside AND gates---the advantage of this module is that it is very generic and
easy-to-use:

```
prescaler : entity work.srl_prescaler
generic map (100e6, 1)
port map (clk_in_100mhz, ce_out_1hz);
```

In the above example, an input clock of 100 MHz (i.e., `100e6` & `clk_in_100mhz`) gets divided into a clock enable signal of 1 Hz (i.e., `1` & `ce_out_1hz`). Among the other improvements, a third optional parameter (i.e., the duty cycle) may also get
supplied as a real number (0.00, 1.00) to the generic map.

Overall, this small project makes an otherwise-niche method more accessible by actually making use of the many language features that VHDL has to offer (e.g., pre-computing factor results using functions, automating hardware creation via for...generate
clauses, latching using registers and guarded signals, etc.), serving as a simple yet practical learning point.

Visualized and Tabular Comparisons: https://gist.github.com/Thraetaona/ba941e293d36d0f76db6b9f3476b823c?permalink_comment_id=4856214#gistcomment-4856214

(Usenet is shutting down tomorrow on February 22, 2024; this should be one
of the last messages.)"


Dear Fereydoun,

Usenet did not shut down. Google is not Usenet. Google ignores new Usenet posts. However, news.eternal-September.org does not show this quoted
article so I saw it for the 1st time today via a different USENET server.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.vhdl, comp.arch.fpga

On 7/21/2024 9:16 AM, Nioclás Pól Caileán de Ghloucester wrote:

I found that the overwhelming majority of the Internet's solution to
slowing down a fast clock (for making the pulsing of an LED visible to
the human eye) was either using vendor-specific, proprietary clock
managers and PLLs or implementing some twenty-something-bit-wide counter
as to count hundreds of thousands of clock cycles and generate a 1 Hz
output.

If you did not have access to FPGA shift register primitives, what would
be the most efficient way to build a prescaler from discrete parts?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.vhdl, comp.arch.fpga

On 8/1/2024, Buzz McCool wrote:

On 7/21/2024 9:16 AM, Nioclás Pól Caileán de Ghloucester wrote:

I found that the overwhelming majority of the Internet's solution to
slowing down a fast clock (for making the pulsing of an LED visible to
the human eye) was either using vendor-specific, proprietary clock
managers and PLLs or implementing some twenty-something-bit-wide
counter as to count hundreds of thousands of clock cycles and generate
a 1 Hz output.

If you did not have access to FPGA shift register primitives, what would
be the most efficient way to build a prescaler from discrete parts?

Truthfully, the efficiency in question is rather minuscule to begin
with; in a design where you have tens or hundreds of thousands of
flip-flops and LUTs, attempting to optimize a prescaler to use less
flip-flops might not be worth it. However, you could still use clock
managers and PLLs, because they've been dedicated for exactly that task, although that would still require you to directly instantiate (as
opposed to infere) the primitives. Ultimately, using a simple counter
with as few bits as possible remains the simplest and most common method.

I wasn't actually expecting this Usenet thread to gain views after
Google shut down its client, but this indeed was a pleasant surprise.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.vhdl, comp.arch.fpga

On 7/21/2024, Nioclás Pól Caileán de Ghloucester wrote:

Fereydoun Memarzanjany wrote via Google on 21/02/2024:
"
https://gist.github.com/Thraetaona/ba941e293d36d0f76db6b9f3476b823c

Having just started learning FPGA Hardware Description Languages by attempting to write a simple LED blinker, I found that the overwhelming majority of the Internet's solution to slowing down a fast clock (for
making the pulsing of an LED visible to the human eye) was either using vendor-specific, proprietary clock managers and PLLs or implementing
some twenty-something-bit-wide counter as to count hundreds of thousands
of clock cycles and generate a 1 Hz output.

Although there is a world of difference between counters in hardware-accelerated designs and those in software-emulated ones, I nonetheless viewed the number of daisy-chained components resulting from
a mere counter as far-from-ideal and absurd; I began searching for a
more efficient method.

I came upon a rather obscure blog post from 2015 (http://www.markharvey.info/art/srldiv_04.10.2015/srldiv_04.10.2015.html) outlining the exact same issue while also referencing Xilinx systems designer Mr. Ken Chapman's proposal: using FPGAs' shift register primitives (e.g., Xilinx's SRL32E) to

alleviate that.

However, the method described therein would rely on the user to
calculate the target frequency's factors between [2, 32) and
painstakingly connect each and every instance of SRL32Es to one another,
all in a manual manner, not to mention that the resulting pulse would
have a low, one-cycle-long duty.

Thus, I wrote `srl_prescaler.vhd`, a fully automated template generator
in VHDL for an efficient, register-based cascaded clock divider based
solely on SRL32 primitives alongside AND gates---the advantage of this
module is that it is very generic and easy-to-use:

```
            prescaler : entity work.srl_prescaler
                generic map (100e6, 1)
                port map (clk_in_100mhz, ce_out_1hz);
```

In the above example, an input clock of 100 MHz (i.e., `100e6` & `clk_in_100mhz`) gets divided into a clock enable signal of 1 Hz (i.e.,
`1` & `ce_out_1hz`).  Among the other improvements, a third optional parameter (i.e., the duty cycle) may also get supplied as a real number (0.00, 1.00) to the generic map.

Overall, this small project makes an otherwise-niche method more
accessible by actually making use of the many language features that
VHDL has to offer (e.g., pre-computing factor results using functions, automating hardware creation via for...generate clauses, latching using registers and guarded signals, etc.), serving as a simple yet practical learning point.

Visualized and Tabular Comparisons: https://gist.github.com/Thraetaona/ba941e293d36d0f76db6b9f3476b823c?permalink_comment_id=4856214#gistcomment-4856214

(Usenet is shutting down tomorrow on February 22, 2024; this should be
one of the last messages.)"

Dear Fereydoun,

Usenet did not shut down. Google is not Usenet. Google ignores new
Usenet posts. However, news.eternal-September.org does not show this
quoted article so I saw it for the 1st time today via a different USENET server.

Yes, it was my oversight. Usenet is largely decentralized so it cannot
really be "shut down" because of Google.

Thanks for reminding me about the comments here. I wasn't actually
expecting anyone to continue seeing this thread; I'll respond to them now.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.lang.vhdl, comp.arch.fpga

On Tue, 6 Aug 2024, Fereydoun Memarzanjany wrote:
"[. . .] I'll respond to them now."

Welcome back!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/1/2024 12:17 PM, Buzz McCool wrote:

On 7/21/2024 9:16 AM, Nioclás Pól Caileán de Ghloucester wrote:

I found that the overwhelming majority of the Internet's solution to slowing >> down a fast clock (for making the pulsing of an LED visible to the human eye)
was either using vendor-specific, proprietary clock managers and PLLs or
implementing some twenty-something-bit-wide counter as to count hundreds of >> thousands of clock cycles and generate a 1 Hz output.

That depends on what you want to use to "trigger" the LED's illumination. Monostables (in many forms) can generate an interval that is "close enough
for the purposes of human perception" with very little (if ANY!) silicon.

If you did not have access to FPGA shift register primitives, what would be the
most efficient way to build a prescaler from discrete parts?

How do you define "efficient"?

Shift counters are incredibly simple with the drawback of front-loading
all of the combinatorial logic. Certain divisors are, thus, more costly
than others.

Binary ripple counters use the least resources but suffer from
propagation delays making decoding of states a bit trickier.

You will always need at least log2N flip-flops and could end up
using slightly more.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/13/2024 12:23 PM, Don Y wrote:

On 8/1/2024 12:17 PM, Buzz McCool wrote:

On 7/21/2024 9:16 AM, Nioclás Pól Caileán de Ghloucester wrote:

I found that the overwhelming majority of the Internet's solution to slowing
down a fast clock (for making the pulsing of an LED visible to the human >>> eye) was either using vendor-specific, proprietary clock managers and PLLs >>> or implementing some twenty-something-bit-wide counter as to count hundreds >>> of thousands of clock cycles and generate a 1 Hz output.

That depends on what you want to use to "trigger" the LED's illumination. Monostables (in many forms) can generate an interval that is "close enough for the purposes of human perception" with very little (if ANY!) silicon.

If you did not have access to FPGA shift register primitives, what would be >> the most efficient way to build a prescaler from discrete parts?

How do you define "efficient"?

Shift counters are incredibly simple with the drawback of front-loading
all of the combinatorial logic.  Certain divisors are, thus, more costly than others.

Binary ripple counters use the least resources but suffer from
propagation delays making decoding of states a bit trickier.

You will always need at least log2N flip-flops and could end up
using slightly more.

[Of course, the c.a.e solution would be a 6 pin MCU counting time
in software]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)