Groups | Search | Server Info | Login | Register


Groups > comp.arch.fpga > #38626

Re: A Simple VHDL Abstraction of an Efficient Clock Prescaler Using Cascading Shift Registers

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 2024-08-06 22:18 -0600
Organization A noiseless patient Spider
Message-ID <v8usi3$26hka$1@dont-email.me> (permalink)
References <5ccd7c07-93d6-424d-909b-b13ebe6cf1f2n@googlegroups.com> <8fd3081d-4977-c809-2c81-c200605ac323@insomnia247.nl>

Cross-posted to 3 groups.

Show all headers | View raw


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.

Back to comp.arch.fpga | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Re: A Simple VHDL Abstraction of an Efficient Clock Prescaler Using Cascading Shift Registers Nioclás Pól Caileán de Ghloucester <Master_Fontaine_is_dishonest@Strand_in_London.Gov.UK> - 2024-07-21 18:16 +0200
  Re: A Simple VHDL Abstraction of an Efficient Clock Prescaler Using Cascading Shift Registers Buzz McCool <buzz_mccool@yahoo.com> - 2024-08-01 12:17 -0700
    Re: A Simple VHDL Abstraction of an Efficient Clock Prescaler Using Cascading Shift Registers Fereydoun Memarzanjany <thraetaona@ieee.org> - 2024-08-06 22:24 -0600
  Re: A Simple VHDL Abstraction of an Efficient Clock Prescaler Using Cascading Shift Registers Fereydoun Memarzanjany <thraetaona@ieee.org> - 2024-08-06 22:18 -0600
    Re: A Simple VHDL Abstraction of an Efficient Clock Prescaler Using Cascading Shift Registers Nioclás Pól Caileán de Ghloucester <Master_Fontaine_is_dishonest@Strand_in_London.Gov.UK> - 2024-08-07 20:51 +0200

csiph-web