Periodically delayed clock

[Rick C. Hodgin]

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

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.

I understand concepts. I even know flip-flop, but the FF abbreviation wasn't on my radar.

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

I have thought of them as bit storage. And as I understand their use, they are explicitly set to 0 or 1, and do not actually flip flop. They maintain the state specified as of the time of their last setting, so they output continually as a bit buffer.

I think D_in would be wired to my BUSY signal, and the SET input would be asserted on each clock's rising edge. This would consistently set the FF to 0 or 1 based on the BUSY input, and it would sustain throughout the entire clock cycle, being re-SET each time to the new state.

--
Rick C. Hodgin

 

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

On Wednesday, November 28, 2018 at 2:49:23 PM UTC-5, gnuarm.del...@gmail.com wrote:
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.

I understand concepts. I even know flip-flop, but the FF abbreviation wasn't on my radar.

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

I have thought of them as bit storage. And as I understand their use, they are explicitly set to 0 or 1, and do not actually flip flop. They maintain the state specified as of the time of their last setting, so they output continually as a bit buffer.

I think D_in would be wired to my BUSY signal, and the SET input would be asserted on each clock's rising edge. This would consistently set the FF to 0 or 1 based on the BUSY input, and it would sustain throughout the entire clock cycle, being re-SET each time to the new state.

rewind ....

the code was:

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

that is a flopflip with clok enable; at every rising edge of fast_clk
D_in get "stored" and appears on Q_out, IF and only if clock_enable is high

you busy signal goes to clock_enable

 

[Rick C. Hodgin]

On Wednesday, November 28, 2018 at 3:21:36 PM UTC-5, lasselangwad...@gmail.com wrote:

rewind ....

the code was:

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

that is a flopflip with clok enable; at every rising edge of fast_clk
D_in get "stored" and appears on Q_out, IF and only if clock_enable is high

you busy signal goes to clock_enable

I understand. I'll try to work with that way of thinking.

If anyone's interested, here's my thinking on this type of circuit. I think a construction like this would make more sense in hardware definition source code:

// Declared in global space
BitObj goEnable;
goEnable.D_in = BUSY;
goEnable.set = @risingedge CLK;

// You can then reference this in your code anywhere:
Q_out = goEnable.out;

The BitObj object would be a known class/construct that has two inputs, one output (logically), and it can then be logically wielded in that way. It can be setup as a static object somewhere in global space (a singleton), and is then defined to be wired up as indicated with the Q_out reference.

In addition, other circuits later on could reference it simply by saying:

my_other_signal = goEnable.out;

And I would use that existing C/C++ knowledge base for how to write these things. They are more along the things I would write into Logician. We are, after all, creating an fully artificially constructed environment per our definition. It's fully logically constructed from the ground up given the constraints of the environment we're in (limitations / requirements of our target device if on an FPGA, or in our process technology for manufacturing real silicon-based ICs).

The compiler should be able to work out how it should all be physically wired up, and provide information / metrics about where there are inefficiencies, hot spots, etc.

I desire to work at that level of logic, and to have a more common set of tools to be able to translate it from the ideal virtual world of design into the physical needs of the target device. I want the compiler / toolset to do that for me, and I desire to work with a more common / centralized knowledge base to other disciplines (such as C/C++ coding styles). The use of "then" and "end if;" for example ... replace them with { and }.

Just my thinking on this. It's one of the reasons I've had difficulty learning existing tools. I can envision another way to do it, and it frustrates me that it isn't already written that way because it seems more logical.

Same thing with basic gates. I have renamed them to things that make sense to me:

Flip -- Logical NOT for Signal or Data (1 yields 0, 0 yields 1)
Any1 -- Logical OR for Signal or Data (1 on any input 1)
All1 -- Logical AND for Signal or Data (1 on all input 1)
Any0 -- Logical NAND for Signal or Data (1 on any input 0)
All0 -- Logical NOR for Signal or Data (1 on all input 0)
Diff -- Logical XNOR for Signal or Data (1 on inputs are different)
Same -- Logical XOR for Signal or Data (1 on inputs are same)

I think a student learning those terms would pick them up in 11 seconds, compared to trying to remember what the traditional terms mean, etc.

I have lots of ideas like this and I think if people would give me a chance I could positively impact this area of hardware prototyping and design.

--
Rick C. Hodgin

 

[Rick C. Hodgin]

On Wednesday, November 28, 2018 at 3:39:20 PM UTC-5, Rick C. Hodgin wrote:

Any0 -- Logical NAND for Signal or Data (1 on any input 0)
All0 -- Logical NOR for Signal or Data (1 on all input 0)

Oops. These two should be reversed:

Any0 -- Logical NOR for Signal or Data (1 on any input 0)
All0 -- Logical NAND for Signal or Data (1 on all input 0)

--
Rick C. Hodgin

 

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

On Wednesday, November 28, 2018 at 3:21:36 PM UTC-5, lasselangwad...@gmail.com wrote:
rewind ....

the code was:

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

that is a flopflip with clok enable; at every rising edge of fast_clk
D_in get "stored" and appears on Q_out, IF and only if clock_enable is high

you busy signal goes to clock_enable

I understand. I'll try to work with that way of thinking.

If anyone's interested, here's my thinking on this type of circuit. I think a construction like this would make more sense in hardware definition source code:

// Declared in global space
BitObj goEnable;
goEnable.D_in = BUSY;
goEnable.set = @risingedge CLK;

D_in is you data input, BUSY should be a enable signal telling it to ignore
the clock edges

// You can then reference this in your code anywhere:
Q_out = goEnable.out;

The BitObj object would be a known class/construct that has two inputs, one output (logically), and it can then be logically wielded in that way. It can be setup as a static object somewhere in global space (a singleton), and is then defined to be wired up as indicated with the Q_out reference.

In addition, other circuits later on could reference it simply by saying:

my_other_signal = goEnable.out;

And I would use that existing C/C++ knowledge base for how to write these things. They are more along the things I would write into Logician. We are, after all, creating an fully artificially constructed environment per our definition. It's fully logically constructed from the ground up given the constraints of the environment we're in (limitations / requirements of our target device if on an FPGA, or in our process technology for manufacturing real silicon-based ICs).

The compiler should be able to work out how it should all be physically wired up, and provide information / metrics about where there are inefficiencies, hot spots, etc.

I desire to work at that level of logic, and to have a more common set of tools to be able to translate it from the ideal virtual world of design into the physical needs of the target device. I want the compiler / toolset to do that for me, and I desire to work with a more common / centralized knowledge base to other disciplines (such as C/C++ coding styles). The use of "then" and "end if;" for example ... replace them with { and }.

Just my thinking on this. It's one of the reasons I've had difficulty learning existing tools. I can envision another way to do it, and it frustrates me that it isn't already written that way because it seems more logical..

Same thing with basic gates. I have renamed them to things that make sense to me:

Flip -- Logical NOT for Signal or Data (1 yields 0, 0 yields 1)
Any1 -- Logical OR for Signal or Data (1 on any input 1)
All1 -- Logical AND for Signal or Data (1 on all input 1)
Any0 -- Logical NAND for Signal or Data (1 on any input 0)
All0 -- Logical NOR for Signal or Data (1 on all input 0)
Diff -- Logical XNOR for Signal or Data (1 on inputs are different)
Same -- Logical XOR for Signal or Data (1 on inputs are same)

I think a student learning those terms would pick them up in 11 seconds, compared to trying to remember what the traditional terms mean, etc.

I have lots of ideas like this and I think if people would give me a chance I could positively impact this area of hardware prototyping and design.

you are trying to reinvent the wheel by refining "circular ring with spokes
from rim to hub" to "round thing with some sticks in the middle" without fully understanding how a wheel works

 

[Rick C. Hodgin]

On Wednesday, November 28, 2018 at 4:06:59 PM UTC-5, lasselangwad...@gmail.com wrote:

onsdag den 28. november 2018 kl. 21.39.20 UTC+1 skrev Rick C. Hodgin:
On Wednesday, November 28, 2018 at 3:21:36 PM UTC-5, lasselangwad...@gmail.com wrote:
rewind ....

the code was:

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

that is a flopflip with clok enable; at every rising edge of fast_clk
D_in get "stored" and appears on Q_out, IF and only if clock_enable is high

you busy signal goes to clock_enable

I understand. I'll try to work with that way of thinking.

If anyone's interested, here's my thinking on this type of circuit. I think a construction like this would make more sense in hardware definition source code:

// Declared in global space
BitObj goEnable;
goEnable.D_in = BUSY;
goEnable.set = @risingedge CLK;

D_in is you data input, BUSY should be a enable signal telling it to ignore
the clock edges


// You can then reference this in your code anywhere:
Q_out = goEnable.out;

I think BUSY should be the data input, and clock should be the enable, because you want a full clock cycle resolution on the delay, and if BUSY is asserted at the start of a cycle, it should delay the entire cycle.

--
Rick C. Hodgin

 

On Wednesday, November 28, 2018 at 3:06:57 PM UTC-5, Rick C. Hodgin wrote:

On Wednesday, November 28, 2018 at 2:49:23 PM UTC-5, gnuarm.del...@gmail.com wrote:
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.

I understand concepts. I even know flip-flop, but the FF abbreviation wasn't on my radar.

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

I have thought of them as bit storage. And as I understand their use, they are explicitly set to 0 or 1, and do not actually flip flop. They maintain the state specified as of the time of their last setting, so they output continually as a bit buffer.

I think D_in would be wired to my BUSY signal, and the SET input would be asserted on each clock's rising edge. This would consistently set the FF to 0 or 1 based on the BUSY input, and it would sustain throughout the entire clock cycle, being re-SET each time to the new state.

This is a very slow and painful way to educate you. I think what you are calling the SET input is what the rest of the universe calls the clock. No?

Where else would this FF be used?

Rick C.

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

 

On Wednesday, November 28, 2018 at 3:21:36 PM UTC-5, lasselangwad...@gmail.com wrote:

onsdag den 28. november 2018 kl. 21.06.57 UTC+1 skrev Rick C. Hodgin:
On Wednesday, November 28, 2018 at 2:49:23 PM UTC-5, gnuarm.del...@gmail.com wrote:
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.

I understand concepts. I even know flip-flop, but the FF abbreviation wasn't on my radar.

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

I have thought of them as bit storage. And as I understand their use, they are explicitly set to 0 or 1, and do not actually flip flop. They maintain the state specified as of the time of their last setting, so they output continually as a bit buffer.

I think D_in would be wired to my BUSY signal, and the SET input would be asserted on each clock's rising edge. This would consistently set the FF to 0 or 1 based on the BUSY input, and it would sustain throughout the entire clock cycle, being re-SET each time to the new state.


rewind ....

the code was:

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

that is a flopflip with clok enable; at every rising edge of fast_clk
D_in get "stored" and appears on Q_out, IF and only if clock_enable is high

you busy signal goes to clock_enable

After being enabled... no?

Rick C.

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

 

On Wednesday, November 28, 2018 at 4:58:31 PM UTC-5, Rick C. Hodgin wrote:

On Wednesday, November 28, 2018 at 4:06:59 PM UTC-5, lasselangwad...@gmail.com wrote:
onsdag den 28. november 2018 kl. 21.39.20 UTC+1 skrev Rick C. Hodgin:
On Wednesday, November 28, 2018 at 3:21:36 PM UTC-5, lasselangwad...@gmail.com wrote:
rewind ....

the code was:

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

that is a flopflip with clok enable; at every rising edge of fast_clk
D_in get "stored" and appears on Q_out, IF and only if clock_enable is high

you busy signal goes to clock_enable

I understand. I'll try to work with that way of thinking.

If anyone's interested, here's my thinking on this type of circuit. I think a construction like this would make more sense in hardware definition source code:

// Declared in global space
BitObj goEnable;
goEnable.D_in = BUSY;
goEnable.set = @risingedge CLK;

D_in is you data input, BUSY should be a enable signal telling it to ignore
the clock edges


// You can then reference this in your code anywhere:
Q_out = goEnable.out;

I think BUSY should be the data input, and clock should be the enable, because you want a full clock cycle resolution on the delay, and if BUSY is asserted at the start of a cycle, it should delay the entire cycle.

Ok, I am throwing in the towel. You need to read some basic logic design text books. You have no understanding at all of how this stuff works and you don't seem to be interested in learning from those who do.

Rick C.

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

 

On Thursday, November 29, 2018 at 1:55:37 AM UTC-5, gnuarm.del...@gmail.com wrote:

On Wednesday, November 28, 2018 at 3:21:36 PM UTC-5, lasselangwad...@gmail.com wrote:
onsdag den 28. november 2018 kl. 21.06.57 UTC+1 skrev Rick C. Hodgin:
On Wednesday, November 28, 2018 at 2:49:23 PM UTC-5, gnuarm.del...@gmail.com wrote:
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.

I understand concepts. I even know flip-flop, but the FF abbreviation wasn't on my radar.

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

I have thought of them as bit storage. And as I understand their use, they are explicitly set to 0 or 1, and do not actually flip flop. They maintain the state specified as of the time of their last setting, so they output continually as a bit buffer.

I think D_in would be wired to my BUSY signal, and the SET input would be asserted on each clock's rising edge. This would consistently set the FF to 0 or 1 based on the BUSY input, and it would sustain throughout the entire clock cycle, being re-SET each time to the new state.


rewind ....

the code was:

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

that is a flopflip with clok enable; at every rising edge of fast_clk
D_in get "stored" and appears on Q_out, IF and only if clock_enable is high

you busy signal goes to clock_enable

After being enabled... no?

Rick C.

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

Sorry, it's late and I meant to say "inverted", not "enabled".

 

[Stef]

On 2018-11-29 gnuarm.deletethisbit@gmail.com wrote in comp.arch.fpga:

On Wednesday, November 28, 2018 at 4:58:31 PM UTC-5, Rick C. Hodgin wrote:
On Wednesday, November 28, 2018 at 4:06:59 PM UTC-5, lasselangwad...@gmail.com wrote:
onsdag den 28. november 2018 kl. 21.39.20 UTC+1 skrev Rick C. Hodgin:
On Wednesday, November 28, 2018 at 3:21:36 PM UTC-5, lasselangwad...@gmail.com wrote:
rewind ....

the code was:

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

that is a flopflip with clok enable; at every rising edge of fast_clk
D_in get "stored" and appears on Q_out, IF and only if clock_enable is high

you busy signal goes to clock_enable

I understand. I'll try to work with that way of thinking.

If anyone's interested, here's my thinking on this type of circuit. I think a construction like this would make more sense in hardware definition source code:

// Declared in global space
BitObj goEnable;
goEnable.D_in = BUSY;
goEnable.set = @risingedge CLK;

D_in is you data input, BUSY should be a enable signal telling it to ignore
the clock edges


// You can then reference this in your code anywhere:
Q_out = goEnable.out;

I think BUSY should be the data input, and clock should be the enable, because you want a full clock cycle resolution on the delay, and if BUSY is asserted at the start of a cycle, it should delay the entire cycle.

Ok, I am throwing in the towel. You need to read some basic logic design text books. You have no understanding at all of how this stuff works and you don't seem to be interested in learning from those who do.

A simple simulator on how a DFF (Data Flip-Flop) (without clock enable) works:
http://electronics-course.com/d-flip-flop

Change the inputs on the symbol to see what happens. Or edit the timing
diagram by clicking and then hit 'simulate'

BTW: Be carefull with the ripple counter stuff at the end of the article.
That is not something you would want to use in an FPGA design.


--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

cursor address, n:
"Hello, cursor!"
-- Stan Kelly-Bootle, "The Devil's DP Dictionary"

 

[Rick C. Hodgin]

On Thursday, November 29, 2018 at 3:43:34 AM UTC-5, Stef wrote:

A simple simulator on how a DFF (Data Flip-Flop) (without clock enable) works:
http://electronics-course.com/d-flip-flop

Change the inputs on the symbol to see what happens. Or edit the timing
diagram by clicking and then hit 'simulate'

I realized after I posted the D_in should be ~BUSY rather than BUSY.

But, that simulation is as I indicated: @risingEdge of CLK strobes
the FF to set the value, and holds it until strobed again on the
next rising edge.

For the enable circuit, I would want that sustain for a full clock
cycle, so the ~BUSY input is tested and set at the clock's rising
edge, resulting in an enable that's high or low for the full duration
of that clock cycle.

The output Q is then AND gated with clock to signal the mext cycle,
which will only occur when BUSY is not asserted.

If ~BUSY and CLK were swapped, the FF would seem to be a pass-thru,
signaling CLK continuously whenever BUSY is not asserted, meaning it
would potentially signal a partial cycle when BUSY is de-asserted
mid-cycle. That would be undesirable because that cycle's workload
may not complete in a partial cycle, resulting in error.

That's my understanding. I would accept correction if I'm wrong.
I'm not here to be hard-headed ... it's just that I honestly believe
I understand it, and if I don't I'd like to be taught so I can know
the truth.

BTW: Be carefull with the ripple counter stuff at the end of the article.
That is not something you would want to use in an FPGA design.

Is that the same as a ripple carry counter? Why are they not good
in an FPGA?

--
Rick C. Hodgin

 

[Rick C. Hodgin]

On Thursday, November 29, 2018 at 3:43:34 AM UTC-5, Stef wrote:

BTW: Be carefull with the ripple counter stuff at the end of the article.
That is not something you would want to use in an FPGA design.

I see what you mean by ripple counter now.

Thank you.

--
Rick C. Hodgin

 

[Rick C. Hodgin]

On Wednesday, November 28, 2018 at 4:58:31 PM UTC-5, Rick C. Hodgin wrote:
> I think BUSY should be the data input, and clock should be the enable, because you want a full clock cycle resolution on the delay, and if BUSY is asserted at the start of a cycle, it should delay the entire cycle.

BUSY here should be ~BUSY. And when I say "clock should be the enable," I meant CLK should strobe the set input on the FF. In that way, Q is sustained for an entire clock cycle and there are no partial clocks visible on Q.

--
Rick C. Hodgin

 

[David Brown]

On 29/11/18 10:53, Rick C. Hodgin wrote:

On Wednesday, November 28, 2018 at 4:58:31 PM UTC-5, Rick C. Hodgin
wrote:
I think BUSY should be the data input, and clock should be the
enable, because you want a full clock cycle resolution on the
delay, and if BUSY is asserted at the start of a cycle, it should
delay the entire cycle.

BUSY here should be ~BUSY. And when I say "clock should be the
enable," I meant CLK should strobe the set input on the FF. In that
way, Q is sustained for an entire clock cycle and there are no
partial clocks visible on Q.

I get the feeling that you have a partial understanding of how
flip-flops work, but are missing some details. You also understand much
of the higher level logic, but are unaware of the practical issues in
FPGA design (such as clock distribution and timings). And you have your
terminology completely garbled. Imagine that "clock", "enable",
"strobe", "set", "input" and "FF" are all keywords - they all have very
specific meanings in this context. The "enable" input to a flip-flop
has a specific function, as does the "set" input - when you use these
words to mean something else, confusion and frustration is inevitable.

There really is no choice here. You /must/ get yourself a book on logic
design with FPGA's - or at least go through a comprehensive set of
tutorials. You need to study hard at the basics, and learn the
terminology. You have to do the simple exercises - make the two-bit
counter, the grey encoder/decoder, the traffic lights. And the sooner
you do it, the better - otherwise you will be talking to yourself with
no way to get help from others, and you will re-make all the same
mistakes of every logic designer for the past four decades.

I know you want to dive in and make your cpu design. But you need to
take a step back and learn how this works, and learn the basics first -
it will get you to your goal faster in the long run.

And once you have learned the basics of VHDL or Verilog, and can make
your flip-flops and make simple designs with them, and verified them
with simulation (using standard tools, not your own ones), and verified
them on a real board, then you are ready to start thinking bigger.

 

[Rick C. Hodgin]

David Brown,

Your advice has prompted me to write my own tools sooner rather than later.

--
Rick C. Hodgin

 

[David Brown]

On 29/11/18 15:05, Rick C. Hodgin wrote:

David Brown,

Your advice has prompted me to write my own tools sooner rather than later.

That will give you a few things:

1. You will have terminology that you understand.
2. You will have a high-level view that fits your ideas and desires.
3. You will not be able to talk to anyone else, or learn from anywhere
else, or work with anyone else.
4. You will make lots of key, fundamental mistakes.
5. Your results will be massively inefficient.
6. You will never be finished.

You /cannot/ create better tools or a better way to work with hardware
design until you have a far clearer understanding of how it is done
today, and what existing tools do. You cannot avoid learning by
inventing your own systems - that is a recipe for disaster.


I gave a strong recommendation for how you can make progress. You are
so keen on running (no one can fault your optimism or enthusiasm!) that
you have not learned how to walk.


One thing I did not say in my last post is where you should go once you
have an understanding of Verilog or VHDL, and how digital logic works
and how it is designed. My recommendation is that you then leave these
and use higher level tools that generate Verilog and/or VHDL as an
output. I would suggest MyHDL as a starting choice, but there are
others. And it is certainly possible for you to write your own tools at
that level - this is common amongst processor designers. But you need
to understand what is going on underneath before you can do this
correctly - you need to understand how the fundamental parts of digital
logic work, how to make successful synchronous logic, and how to get the
results you want from an FPGA.

 

On Thursday, November 29, 2018 at 3:43:34 AM UTC-5, Stef wrote:

On 2018-11-29 gnuarm.deletethisbit@gmail.com wrote in comp.arch.fpga:
On Wednesday, November 28, 2018 at 4:58:31 PM UTC-5, Rick C. Hodgin wrote:
On Wednesday, November 28, 2018 at 4:06:59 PM UTC-5, lasselangwad...@gmail.com wrote:
onsdag den 28. november 2018 kl. 21.39.20 UTC+1 skrev Rick C. Hodgin:
On Wednesday, November 28, 2018 at 3:21:36 PM UTC-5, lasselangwad....@gmail.com wrote:
rewind ....

the code was:

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

that is a flopflip with clok enable; at every rising edge of fast_clk
D_in get "stored" and appears on Q_out, IF and only if clock_enable is high

you busy signal goes to clock_enable

I understand. I'll try to work with that way of thinking.

If anyone's interested, here's my thinking on this type of circuit.. I think a construction like this would make more sense in hardware definition source code:

// Declared in global space
BitObj goEnable;
goEnable.D_in = BUSY;
goEnable.set = @risingedge CLK;

D_in is you data input, BUSY should be a enable signal telling it to ignore
the clock edges


// You can then reference this in your code anywhere:
Q_out = goEnable.out;

I think BUSY should be the data input, and clock should be the enable, because you want a full clock cycle resolution on the delay, and if BUSY is asserted at the start of a cycle, it should delay the entire cycle.

Ok, I am throwing in the towel. You need to read some basic logic design text books. You have no understanding at all of how this stuff works and you don't seem to be interested in learning from those who do.

A simple simulator on how a DFF (Data Flip-Flop) (without clock enable) works:
http://electronics-course.com/d-flip-flop

Change the inputs on the symbol to see what happens. Or edit the timing
diagram by clicking and then hit 'simulate'

BTW: Be carefull with the ripple counter stuff at the end of the article.
That is not something you would want to use in an FPGA design.

You also don't want to use the preset or clear inputs. They are async and so tricky to use in a design. Sometimes async inputs are used in HDL to control the state of FFs on configuration, but that can be tricky too. Much better to either use synchronous inputs or none at all and let the logic start up by defining all possible inputs.

When using an async input you have to make no assumptions about the timing with respect to the clock which makes it very hard to do properly.

Rick C.

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

 

[Rick C. Hodgin]

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

On Wednesday, November 28, 2018 at 3:39:20 PM UTC-5, Rick C. Hodgin wrote:
Any0 -- Logical NAND for Signal or Data (1 on any input 0)
All0 -- Logical NOR for Signal or Data (1 on all input 0)

Oops. These two should be reversed:

Any0 -- Logical NOR for Signal or Data (1 on any input 0)
All0 -- Logical NAND for Signal or Data (1 on all input 0)

Nope. I was correct in my first posting. It should be:

Any0 -- Logical NAND for Signal or Data (1 on any input 0)
All0 -- Logical NOR for Signal or Data (1 on all input 0)

Truth table:

NAND / NOR /
Any 0 All 0

a b | o a b | o
---------- ----------
0 0 | 1 0 0 | 1
0 1 | 1 0 1 | 0
1 0 | 1 1 0 | 0
1 1 | 0 1 1 | 0

--
Rick C. Hodgin

 

On Thursday, November 29, 2018 at 11:43:30 AM UTC-5, Rick C. Hodgin wrote:

On Wednesday, November 28, 2018 at 3:42:39 PM UTC-5, Rick C. Hodgin wrote:
On Wednesday, November 28, 2018 at 3:39:20 PM UTC-5, Rick C. Hodgin wrote:
Any0 -- Logical NAND for Signal or Data (1 on any input 0)
All0 -- Logical NOR for Signal or Data (1 on all input 0)

Oops. These two should be reversed:

Any0 -- Logical NOR for Signal or Data (1 on any input 0)
All0 -- Logical NAND for Signal or Data (1 on all input 0)

Nope. I was correct in my first posting. It should be:

Any0 -- Logical NAND for Signal or Data (1 on any input 0)
All0 -- Logical NOR for Signal or Data (1 on all input 0)

Truth table:

NAND / NOR /
Any 0 All 0

a b | o a b | o
---------- ----------
0 0 | 1 0 0 | 1
0 1 | 1 0 1 | 0
1 0 | 1 1 0 | 0
1 1 | 0 1 1 | 0

--
Rick C. Hodgin

Most of us learn to walk before we learn to run. Give that a try.

Do you have a simple question using terminology we all share and understand?

Rick C.

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