Periodically delayed clock

[Rick C. Hodgin]

I'm preparing designs for a CPU that will be coded in Verilog on
a Terasic Cyclone V GX starter kit dev board.

I have a clock running at N MHz, and I have some logic that may
take longer than the allotted time to complete (as N increases
and the time to complete the logic each cycle decreases).

Rather than re-design my logic to use pipeline stages, I would
like to do something like add a BUSY flag that would be raised
when various logic units are busy, and lowered when they're no
longer busy, so the clock is held before the next cycle actually
triggers.

Would something as simple as this work (using an input clock,
busy, busy reset, and an output clock2 that drives the system):

CLK = Cyclic N MHz clock
BUSY = Asserted by various logic units when busy
BRST = ~CLK
CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):

__ __ __ __ __ __ __ __ __
CLK __| |__| |__| |__| |__| |__| |__| |__| |__| |__
______
BUSY ____________| |____________________________________
__ __ __ __ __ __ __ __ __ __
BRST |__| |__| |__| |__| |__| |__| |__| |__| |__|

__ __ __ __ __ __ __ __ __
CLK2 |__| |__| |________| |__| |__| |__| |__| |__|
held

It would also seem I need to trigger each test to go high only
on @negedge CLK so there are not partial clocks triggered, and
that it would need to track @negedge BRST for going low.

Is there an easier / different way to do this?

Thank you in advance.

--
Rick C. Hodgin

 

tirsdag den 27. november 2018 kl. 17.42.46 UTC+1 skrev Rick C. Hodgin:

I'm preparing designs for a CPU that will be coded in Verilog on
a Terasic Cyclone V GX starter kit dev board.

I have a clock running at N MHz, and I have some logic that may
take longer than the allotted time to complete (as N increases
and the time to complete the logic each cycle decreases).

Rather than re-design my logic to use pipeline stages, I would
like to do something like add a BUSY flag that would be raised
when various logic units are busy, and lowered when they're no
longer busy, so the clock is held before the next cycle actually
triggers.

Would something as simple as this work (using an input clock,
busy, busy reset, and an output clock2 that drives the system):

CLK = Cyclic N MHz clock
BUSY = Asserted by various logic units when busy
BRST = ~CLK
CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):

__ __ __ __ __ __ __ __ __
CLK __| |__| |__| |__| |__| |__| |__| |__| |__| |__
______
BUSY ____________| |____________________________________
__ __ __ __ __ __ __ __ __ __
BRST |__| |__| |__| |__| |__| |__| |__| |__| |__|

__ __ __ __ __ __ __ __ __
CLK2 |__| |__| |________| |__| |__| |__| |__| |__|
held

It would also seem I need to trigger each test to go high only
on @negedge CLK so there are not partial clocks triggered, and
that it would need to track @negedge BRST for going low.

Is there an easier / different way to do this?

Thank you in advance.

don't gate the clock unless you really really have to, it is a recipe for headaches

clock everything on the same clock and use a clock enable instead

 

On Tuesday, November 27, 2018 at 12:36:13 PM UTC-5, lasselangwad...@gmail.com wrote:

tirsdag den 27. november 2018 kl. 17.42.46 UTC+1 skrev Rick C. Hodgin:
I'm preparing designs for a CPU that will be coded in Verilog on
a Terasic Cyclone V GX starter kit dev board.

I have a clock running at N MHz, and I have some logic that may
take longer than the allotted time to complete (as N increases
and the time to complete the logic each cycle decreases).

Rather than re-design my logic to use pipeline stages, I would
like to do something like add a BUSY flag that would be raised
when various logic units are busy, and lowered when they're no
longer busy, so the clock is held before the next cycle actually
triggers.

Would something as simple as this work (using an input clock,
busy, busy reset, and an output clock2 that drives the system):

CLK = Cyclic N MHz clock
BUSY = Asserted by various logic units when busy
BRST = ~CLK
CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):

__ __ __ __ __ __ __ __ __
CLK __| |__| |__| |__| |__| |__| |__| |__| |__| |__
______
BUSY ____________| |____________________________________
__ __ __ __ __ __ __ __ __ __
BRST |__| |__| |__| |__| |__| |__| |__| |__| |__|

__ __ __ __ __ __ __ __ __
CLK2 |__| |__| |________| |__| |__| |__| |__| |__|
held

It would also seem I need to trigger each test to go high only
on @negedge CLK so there are not partial clocks triggered, and
that it would need to track @negedge BRST for going low.

Is there an easier / different way to do this?

Thank you in advance.


don't gate the clock unless you really really have to, it is a recipe for headaches

clock everything on the same clock and use a clock enable instead

+1

Clock gating adds logic and delay to the clock path. This makes timing analysis very hard to do and the automatic tools will all but give up. Certainly you won't be able to trust them anymore. In your simulations the added delays can muck up things as well.

As LL has said, use clock enables and multiple clock cycles.

Rick C.

Tesla referral code - https://ts.la/richard11209

 

[Rick C. Hodgin]

On Tuesday, November 27, 2018 at 1:13:25 PM UTC-5, gnuarm.del...@gmail.com wrote:

On Tuesday, November 27, 2018 at 12:36:13 PM UTC-5, lasselangwad...@gmail..com wrote:
don't gate the clock unless you really really have to, it is a recipe for headaches

clock everything on the same clock and use a clock enable instead

+1

Clock gating adds logic and delay to the clock path. This makes timing analysis very hard to do and the automatic tools will all but give up. Certainly you won't be able to trust them anymore. In your simulations the added delays can muck up things as well.

As LL has said, use clock enables and multiple clock cycles.

LL, Rick C, thank you for your reply.

I'm not sure what "clock enables" means. Is there an example?

--
Rick C. Hodgin

 

On Tuesday, November 27, 2018 at 2:12:27 PM UTC-5, Rick C. Hodgin wrote:

On Tuesday, November 27, 2018 at 1:13:25 PM UTC-5, gnuarm.del...@gmail.com wrote:
On Tuesday, November 27, 2018 at 12:36:13 PM UTC-5, lasselangwad...@gmail.com wrote:
don't gate the clock unless you really really have to, it is a recipe for headaches

clock everything on the same clock and use a clock enable instead

+1

Clock gating adds logic and delay to the clock path. This makes timing analysis very hard to do and the automatic tools will all but give up. Certainly you won't be able to trust them anymore. In your simulations the added delays can muck up things as well.

As LL has said, use clock enables and multiple clock cycles.

LL, Rick C, thank you for your reply.

I'm not sure what "clock enables" means. Is there an example?

FFs can have enables on them so they don't take action until the enable is high. In VHDL code it looks like this...

if (rising_edge(fast_clk)) then
if (clock_enable_a = '1') then
Q_out <= D_in;
end if;
end if;

You can use separate clock enables for separate sections of your circuit as needed. The clock enables are treated like any other logic circuit in your design with timing constraints of 1 clock cycle. The logic feeding the D input to an clock enabled FF only needs to be constrained as the clock enable logic dictates, 2 clock cycles, 3 clock cycles, etc. according to the operation of your design.

Rick C.

Tesla referral code + https://ts.la/richard11209

 

[Rick C. Hodgin]

On Tuesday, November 27, 2018 at 4:05:54 PM UTC-5, gnuarm.del...@gmail.com wrote:

On Tuesday, November 27, 2018 at 2:12:27 PM UTC-5, Rick C. Hodgin wrote:
I'm not sure what "clock enables" means. Is there an example?

FFs can have enables on them so they don't take action until the enable is high. In VHDL code it looks like this...

if (rising_edge(fast_clk)) then
if (clock_enable_a = '1') then
Q_out <= D_in;
end if;
end if;

You can use separate clock enables for separate sections of your circuit as needed. The clock enables are treated like any other logic circuit in your design with timing constraints of 1 clock cycle. The logic feeding the D input to an clock enabled FF only needs to be constrained as the clock enable logic dictates, 2 clock cycles, 3 clock cycles, etc. according to the operation of your design.

Part of my goals on this project are to create a static design that can be clocked down to 0 MHz and still maintain it state, to clock at 1 Hz and still work, to clock on a mechanical external trigger, and to run on the various system clocks.

My thinking has been that if I'm able to get it working properly at my target clock speed, then everything else should work if I underclock it, and even bring it down to a halt.

With such a design, would the ability to have variable clock pulse widths still be something to be avoided? Or is the whole idea of such a wildly variable clock speed a pipe dream?

--
Rick C. Hodgin

 

On Tuesday, November 27, 2018 at 4:24:16 PM UTC-5, Rick C. Hodgin wrote:

On Tuesday, November 27, 2018 at 4:05:54 PM UTC-5, gnuarm.del...@gmail.com wrote:
On Tuesday, November 27, 2018 at 2:12:27 PM UTC-5, Rick C. Hodgin wrote:
I'm not sure what "clock enables" means. Is there an example?

FFs can have enables on them so they don't take action until the enable is high. In VHDL code it looks like this...

if (rising_edge(fast_clk)) then
if (clock_enable_a = '1') then
Q_out <= D_in;
end if;
end if;

You can use separate clock enables for separate sections of your circuit as needed. The clock enables are treated like any other logic circuit in your design with timing constraints of 1 clock cycle. The logic feeding the D input to an clock enabled FF only needs to be constrained as the clock enable logic dictates, 2 clock cycles, 3 clock cycles, etc. according to the operation of your design.

Part of my goals on this project are to create a static design that can be clocked down to 0 MHz and still maintain it state, to clock at 1 Hz and still work, to clock on a mechanical external trigger, and to run on the various system clocks.

My thinking has been that if I'm able to get it working properly at my target clock speed, then everything else should work if I underclock it, and even bring it down to a halt.

With such a design, would the ability to have variable clock pulse widths still be something to be avoided? Or is the whole idea of such a wildly variable clock speed a pipe dream?

Absolutely avoid variable width clock pulses for the reasons given. Clock enables are the perfect way to slow your speed, enabling the design only on the clock cycles you wish to advance the processing. By removing the enable the entire design stops. Raise the enable for one clock cycle and the design advances one step.

It is always good to consider how you will debug a design in the chip. But you should be testing in simulation to get rid of 99.99% of the bugs before you ever load it into an FPGA.

Rick C.

Tesla referral code -- https://ts.la/richard11209

 

[HT-Lab]

On 27/11/2018 17:36, lasselangwadtchristensen@gmail.com wrote:

tirsdag den 27. november 2018 kl. 17.42.46 UTC+1 skrev Rick C. Hodgin:
I'm preparing designs for a CPU that will be coded in Verilog on
a Terasic Cyclone V GX starter kit dev board.

I have a clock running at N MHz, and I have some logic that may
take longer than the allotted time to complete (as N increases
and the time to complete the logic each cycle decreases).

Rather than re-design my logic to use pipeline stages, I would
like to do something like add a BUSY flag that would be raised
when various logic units are busy, and lowered when they're no
longer busy, so the clock is held before the next cycle actually
triggers.

Would something as simple as this work (using an input clock,
busy, busy reset, and an output clock2 that drives the system):

CLK = Cyclic N MHz clock
BUSY = Asserted by various logic units when busy
BRST = ~CLK
CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):

__ __ __ __ __ __ __ __ __
CLK __| |__| |__| |__| |__| |__| |__| |__| |__| |__
______
BUSY ____________| |____________________________________
__ __ __ __ __ __ __ __ __ __
BRST |__| |__| |__| |__| |__| |__| |__| |__| |__|

__ __ __ __ __ __ __ __ __
CLK2 |__| |__| |________| |__| |__| |__| |__| |__|
held

It would also seem I need to trigger each test to go high only
on @negedge CLK so there are not partial clocks triggered, and
that it would need to track @negedge BRST for going low.

Is there an easier / different way to do this?

Thank you in advance.


don't gate the clock unless you really really have to, it is a recipe for headaches

clock everything on the same clock and use a clock enable instead

I also agree with statement,however for completeness most (if not all)
modern synthesis tools will remove the AND gate in front of the clock
input and re-connect the "gate signal" to the FF's CE pin (there are
other constructs as well).

FPGA are used for ASIC prototyping and for this reason most synthesis
tools can handle ASIC coding styles like gate clocks, ripple counters,
clock muxes and they even convert DesignWare blocks.

My additional advice to Rick would be spend some time on adding pipeline
stages and simply stall the units if no input data is available or feed
them with NOPs. If you want to give units more clock cycles delays then
look into multicyle path constructs and constraints (which can sometimes
be a real pain). You might also want to add some assertions (on the path
control logic) to confirm the path is always multicyle (>1 clock cycle).

Good luck,
Hans
www.ht-lab.com

 

[Rick C. Hodgin]

How would I implement a clock enable differently than I'm doing here?


CLK = Cyclic N MHz clock
BUSY = Asserted by various logic units when busy
BRST = ~CLK
CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):

__ __ __ __ __ __ __ __ __
CLK __| |__| |__| |__| |__| |__| |__| |__| |__| |__
______
BUSY ____________| |____________________________________
__ __ __ __ __ __ __ __ __ __
BRST |__| |__| |__| |__| |__| |__| |__| |__| |__|

__ __ __ __ __ __ __ __ __
CLK2 |__| |__| |________| |__| |__| |__| |__| |__|
held

It's like my BUSY signal would effectively be ~ENABLE, wouldn't it?
CLK still runs consistent and periodic, but the advances are triggered
off CLK2, which could be renamed TRIGGER or something.

??

--
Rick C. Hodgin

 

On Wednesday, November 28, 2018 at 10:43:17 AM UTC-5, Rick C. Hodgin wrote:

How would I implement a clock enable differently than I'm doing here?


CLK = Cyclic N MHz clock
BUSY = Asserted by various logic units when busy
BRST = ~CLK
CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):

__ __ __ __ __ __ __ __ __
CLK __| |__| |__| |__| |__| |__| |__| |__| |__| |__
______
BUSY ____________| |____________________________________
__ __ __ __ __ __ __ __ __ __
BRST |__| |__| |__| |__| |__| |__| |__| |__| |__|

__ __ __ __ __ __ __ __ __
CLK2 |__| |__| |________| |__| |__| |__| |__| |__|
held

It's like my BUSY signal would effectively be ~ENABLE, wouldn't it?
CLK still runs consistent and periodic, but the advances are triggered
off CLK2, which could be renamed TRIGGER or something.

??

--
Rick C. Hodgin

I don't see an implementation. I see a timing diagram where you appear to be gating the clock. I'm not sure what you are thinking or what you are trying to say.

I gave you a snippet of code that showed a clock enable. Did you understand the code? How about if you write some code that will implement your idea and compare that to the code I gave you?

Rick C.

Tesla referral code -+ https://ts.la/richard11209

 

[Rick C. Hodgin]

On Wednesday, November 28, 2018 at 11:32:07 AM UTC-5, gnuarm.del...@gmail.com wrote:

On Wednesday, November 28, 2018 at 10:43:17 AM UTC-5, Rick C. Hodgin wrote:

CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):

I don't see an implementation. I see a timing diagram where you appear to be gating the clock. I'm not sure what you are thinking or what you are trying to say.

The CLK2 output is the trigger for the next event.

> I gave you a snippet of code that showed a clock enable. Did you understand the code? How about if you write some code that will implement your idea and compare that to the code I gave you?

The little bit above is close to the code, but there are some caveats on which edge to trigger.

I'll put on my thinking cap and get back to you.

--
Rick C. Hodgin

 

On Wednesday, November 28, 2018 at 12:22:12 PM UTC-5, Rick C. Hodgin wrote:

On Wednesday, November 28, 2018 at 11:32:07 AM UTC-5, gnuarm.del...@gmail..com wrote:
On Wednesday, November 28, 2018 at 10:43:17 AM UTC-5, Rick C. Hodgin wrote:

CLK2 = trigger clock (on ~CLK && ~BUSY && BRST):

I don't see an implementation. I see a timing diagram where you appear to be gating the clock. I'm not sure what you are thinking or what you are trying to say.

The CLK2 output is the trigger for the next event.

You seem to be speaking in your own terms. I don't know what a "trigger" means. Digital design signals generally have clocks and logic. Logic can be clock enables or data. By "trigger" do you mean a clock enable? If you are talking about a clock enable, it should not be generated by gating the clock.

Let me make this simple. NEVER GATE THE CLOCK when working in FPGAs. In fact, I will make this even more general, NEVER USE THE CLOCK AS PART OF THE LOGIC. There may be a very few cases where it makes sense to use the clock as part of your logic, but they are exceedingly few and you have to understand all the implications. I'm not willing to go through all the important issues with someone who is dealing with the basics of logic design. So for now learn the basics, then maybe you can learn the rest later.

So for now consider all logic to be the same, based on other logic signals only and not the clock. This also applies to your busy reset.

I gave you a snippet of code that showed a clock enable. Did you understand the code? How about if you write some code that will implement your idea and compare that to the code I gave you?

The little bit above is close to the code, but there are some caveats on which edge to trigger.

I'll put on my thinking cap and get back to you.

Don't try to worry about "which clock edge". Always work with the positive edge until you better understand what you are doing. Like using the clock in logic, there are few situations where working on the opposite edge of the clock will gain you any advantages and it adds significantly to the issues of verifying timing.

The clock should be used for one thing only, to drive the clock input of FFs, preferably all triggered from the same edge.

Rick C.

Tesla referral code +- https://ts.la/richard11209

 

[Rick C. Hodgin]

On Wednesday, November 28, 2018 at 12:44:02 PM UTC-5, gnuarm.del...@gmail.com wrote:
> You seem to be speaking in your own terms. I don't know what a "trigger" means.

The trigger is the signal given to advance the stepper. Here is an illustrated example from a reference CPU design written for the purposes of instruction and education:

Scott CPU -- Begins at 2:33 into the video.
Click the link directly to advance to that point:

https://www.youtube.com/watch?v=NKYgZH7SBjk&t=2m33s

I already have a five-stage pipeline. As clock speeds go faster, some operations will take longer to compute than the clock allows. It is only on those stages that I want there to be a delay here.

So my thinking has been: I'll take the clock, which is steady at whatever clock speed it's running, and then not use it as input into that stepper component, but will introduce delays to consume an extra clock cycle where required due to the delays on certain instructions.

I apologize for using my own terminology. I have never taken classes on this subject. This is all me figuring out how it should be done in logic, and then trying (with much difficulty) to translate it into the needs of real-world tools. I also encounter resistance when I approach others with my thinking, rather than the hard and fast specs / terms other people are used to hearing. To be honest, it's a little bit frustrating for me because I have been able to figure all of this out on my own, and what I'm getting lost on is the mechanics of making it happen in real-world tools, and not the theory underlying it.

--
Rick C. Hodgin

 

On Wednesday, November 28, 2018 at 1:13:21 PM UTC-5, Rick C. Hodgin wrote:

On Wednesday, November 28, 2018 at 12:44:02 PM UTC-5, gnuarm.del...@gmail..com wrote:
You seem to be speaking in your own terms. I don't know what a "trigger" means.

The trigger is the signal given to advance the stepper. Here is an illustrated example from a reference CPU design written for the purposes of instruction and education:

Scott CPU -- Begins at 2:33 into the video.
Click the link directly to advance to that point:

https://www.youtube.com/watch?v=NKYgZH7SBjk&t=2m33s

I already have a five-stage pipeline. As clock speeds go faster, some operations will take longer to compute than the clock allows. It is only on those stages that I want there to be a delay here.

So my thinking has been: I'll take the clock, which is steady at whatever clock speed it's running, and then not use it as input into that stepper component, but will introduce delays to consume an extra clock cycle where required due to the delays on certain instructions.

I apologize for using my own terminology. I have never taken classes on this subject. This is all me figuring out how it should be done in logic, and then trying (with much difficulty) to translate it into the needs of real-world tools. I also encounter resistance when I approach others with my thinking, rather than the hard and fast specs / terms other people are used to hearing. To be honest, it's a little bit frustrating for me because I have been able to figure all of this out on my own, and what I'm getting lost on is the mechanics of making it happen in real-world tools, and not the theory underlying it.

Ok, you are trying to generate an output called "trigger". You might try another name. So what is your question?

Thinking in your own terms and names means you will find it hard to communicate with others. I have given you enough information to understand how to delay your circuit using a clock enable. Is there anything you don't understand regarding what I have given you?

Personally I think your problem is you are trying to build an aircraft carrier before you understand how to build a hinge. It would be much better if you tried working on much simpler projects and worked up to your massive CPU design. But you are free to learn any way you want.

So what is your question?

Rick C.

Tesla referral code ++ https://ts.la/richard11209

 

onsdag den 28. november 2018 kl. 19.13.21 UTC+1 skrev Rick C. Hodgin:

On Wednesday, November 28, 2018 at 12:44:02 PM UTC-5, gnuarm.del...@gmail..com wrote:
You seem to be speaking in your own terms. I don't know what a "trigger" means.

The trigger is the signal given to advance the stepper. Here is an illustrated example from a reference CPU design written for the purposes of instruction and education:

Scott CPU -- Begins at 2:33 into the video.
Click the link directly to advance to that point:

https://www.youtube.com/watch?v=NKYgZH7SBjk&t=2m33s

I already have a five-stage pipeline. As clock speeds go faster, some operations will take longer to compute than the clock allows. It is only on those stages that I want there to be a delay here.

So my thinking has been: I'll take the clock, which is steady at whatever clock speed it's running, and then not use it as input into that stepper component, but will introduce delays to consume an extra clock cycle where required due to the delays on certain instructions.

I apologize for using my own terminology. I have never taken classes on this subject. This is all me figuring out how it should be done in logic, and then trying (with much difficulty) to translate it into the needs of real-world tools. I also encounter resistance when I approach others with my thinking, rather than the hard and fast specs / terms other people are used to hearing. To be honest, it's a little bit frustrating for me because I have been able to figure all of this out on my own, and what I'm getting lost on is the mechanics of making it happen in real-world tools, and not the theory underlying it.

I think you are meeting resistance because you are try to do things in a way
people learned long time ago was a bad idea, and that getting lost in the mechanics probably means you haven't quite figured it out.


all you need is clk and busy, don't gate the clock and only use rising edge


always@(posedge clk)
begin
if(!bsy)
cnt <= cnt + 1;
end
_ _ _ _
clk ___| |_| |_| |_| |_
___
bsy _______| |_______
___ ___ _______ ___
cnt _0_|_1_|_2_____|_3_

 

[Rick C. Hodgin]

On Wednesday, November 28, 2018 at 1:48:41 PM UTC-5, lasselangwad...@gmail.com wrote:

I think you are meeting resistance because you are try to do things in a way
people learned long time ago was a bad idea, and that getting lost in the mechanics probably means you haven't quite figured it out.

No doubt. I don't have a mentor or tutor to help guide me, so I'm having to do it all on my own. I think in terms of ideal scenarios, and not practical real-world scenarios, and I have no doubts I'll get caught up in the translation form the ideal into a real-world implementation.

all you need is clk and busy, don't gate the clock and only use rising edge

always@(posedge clk)
begin
if(!bsy)
cnt <= cnt + 1;
end
_ _ _ _
clk ___| |_| |_| |_| |_
___
bsy _______| |_______
___ ___ _______ ___
cnt _0_|_1_|_2_____|_3_

I'll work on getting correct technology. And I ask for a little grace until I get it all sorted please.

Thank you.

--
Rick C. Hodgin

 

[Rick C. Hodgin]

On Wednesday, November 28, 2018 at 1:41:05 PM UTC-5, gnuarm.del...@gmail.com wrote:
> Thinking in your own terms and names means you will find it hard to communicate with others.

I agree. I'll work on it. Will you help me get there?

> I have given you enough information to understand how to delay your circuit using a clock enable. Is there anything you don't understand regarding what I have given you?

if (rising_edge(fast_clk)) then
if (clock_enable_a = '1') then
Q_out <= D_in;
end if;
end if;

What is D_in here?

--
Rick C. Hodgin

 

On Wednesday, November 28, 2018 at 2:14:05 PM UTC-5, Rick C. Hodgin wrote:

On Wednesday, November 28, 2018 at 1:41:05 PM UTC-5, gnuarm.del...@gmail.com wrote:
Thinking in your own terms and names means you will find it hard to communicate with others.

I agree. I'll work on it. Will you help me get there?

I have given you enough information to understand how to delay your circuit using a clock enable. Is there anything you don't understand regarding what I have given you?

if (rising_edge(fast_clk)) then
if (clock_enable_a = '1') then
Q_out <= D_in;
end if;
end if;

What is D_in here?

--
Rick C. Hodgin

FF
+--------+
| |
>----| D_in |
| |
| Q_out |---->
| |
>----|> |
| |
+--------+

Is this more clear?

Rick C.

Tesla referral code --- https://ts.la/richard11209

 

[Rick C. Hodgin]

On Wednesday, November 28, 2018 at 2:19:21 PM UTC-5, gnuarm.del...@gmail.com wrote:

On Wednesday, November 28, 2018 at 2:14:05 PM UTC-5, Rick C. Hodgin wrote:
On Wednesday, November 28, 2018 at 1:41:05 PM UTC-5, gnuarm.del...@gmail.com wrote:
Thinking in your own terms and names means you will find it hard to communicate with others.

I agree. I'll work on it. Will you help me get there?

I have given you enough information to understand how to delay your circuit using a clock enable. Is there anything you don't understand regarding what I have given you?

if (rising_edge(fast_clk)) then
if (clock_enable_a = '1') then
Q_out <= D_in;
end if;
end if;

What is D_in here?

--
Rick C. Hodgin

FF
+--------+
| |
----| D_in |
| |
| Q_out |----
| |
----|> |
| |
+--------+

Is this more clear?

I understood the throughput. I don't know what "FF" means, and I don't
know where D_in comes from. What's it wired to?

--
Rick C. Hodgin

 

On Wednesday, November 28, 2018 at 2:42:35 PM UTC-5, Rick C. Hodgin wrote:

On Wednesday, November 28, 2018 at 2:19:21 PM UTC-5, gnuarm.del...@gmail.com wrote:
On Wednesday, November 28, 2018 at 2:14:05 PM UTC-5, Rick C. Hodgin wrote:
On Wednesday, November 28, 2018 at 1:41:05 PM UTC-5, gnuarm.del...@gmail.com wrote:
Thinking in your own terms and names means you will find it hard to communicate with others.

I agree. I'll work on it. Will you help me get there?

I have given you enough information to understand how to delay your circuit using a clock enable. Is there anything you don't understand regarding what I have given you?

if (rising_edge(fast_clk)) then
if (clock_enable_a = '1') then
Q_out <= D_in;
end if;
end if;

What is D_in here?

--
Rick C. Hodgin

FF
+--------+
| |
----| D_in |
| |
| Q_out |----
| |
----|> |
| |
+--------+

Is this more clear?

I understood the throughput. I don't know what "FF" means, and I don't
know where D_in comes from. What's it wired to?

--
Rick C. Hodgin

FF means Flip Flop, the basic element of storage in digital logic. D_in comes from your logic. It is any signal you want it to be.

I don't know if we are simply having communication problems because you are not familiar with the most fundamental nomenclature of digital logic design or if you don't understand the concepts of digital logic. I find both ideas equally implausible.

What do you call a flip flop? What would you use as the data input?

Rick C.

Tesla referral code --+ https://ts.la/richard11209