Sujet : Re: A Simple VHDL Abstraction of an Efficient Clock Prescaler Using Cascading Shift Registers
De : thraetaona (at) *nospam* ieee.org (Fereydoun Memarzanjany)
Groupes : comp.lang.vhdl comp.arch.fpga comp.arch.embeddedDate : 07. Aug 2024, 06:18:12
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v8usi3$26hka$1@dont-email.me>
References : 1 2
User-Agent : Mozilla Thunderbird
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.