Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Fereydoun Memarzanjany <thraetaona@ieee.org>
Newsgroups: comp.lang.vhdl,comp.arch.fpga,comp.arch.embedded
Subject: Re: A Simple VHDL Abstraction of an Efficient Clock Prescaler Using
 Cascading Shift Registers
Date: Tue, 6 Aug 2024 22:18:12 -0600
Organization: A noiseless patient Spider
Lines: 72
Message-ID: <v8usi3$26hka$1@dont-email.me>
References: <5ccd7c07-93d6-424d-909b-b13ebe6cf1f2n@googlegroups.com>
 <8fd3081d-4977-c809-2c81-c200605ac323@insomnia247.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 07 Aug 2024 06:18:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="311e58f894bccfb40be344c4f43061b5";
	logging-data="2311818"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19seT+BSDzcVCKZDmKXkN7r1vRvurF2G3Q="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:IOtwd+CTdPczoHfq8dwBOeHfjec=
In-Reply-To: <8fd3081d-4977-c809-2c81-c200605ac323@insomnia247.nl>
Content-Language: en-US
Bytes: 4879

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.