EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

Periodically delayed clock

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - FPGA - Periodically delayed clock

Goto page Previous  1, 2, 3, 4, 5  Next

Stef
Guest

Thu Nov 29, 2018 9:45 am   



On 2018-11-29 gnuarm.deletethisbit_at_gmail.com wrote in comp.arch.fpga:
Quote:
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
Guest

Thu Nov 29, 2018 10:45 am   



On Thursday, November 29, 2018 at 3:43:34 AM UTC-5, Stef wrote:
Quote:
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.

Quote:
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
Guest

Thu Nov 29, 2018 11:45 am   



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

Rick C. Hodgin
Guest

Thu Nov 29, 2018 11:45 am   



On Thursday, November 29, 2018 at 3:43:34 AM UTC-5, Stef wrote:
Quote:
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

David Brown
Guest

Thu Nov 29, 2018 1:45 pm   



On 29/11/18 10:53, Rick C. Hodgin wrote:
Quote:
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
Guest

Thu Nov 29, 2018 3:45 pm   



David Brown,

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

--
Rick C. Hodgin

David Brown
Guest

Thu Nov 29, 2018 4:45 pm   



On 29/11/18 15:05, Rick C. Hodgin wrote:
Quote:
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.

Rick C. Hodgin
Guest

Thu Nov 29, 2018 5:45 pm   



On Wednesday, November 28, 2018 at 3:42:39 PM UTC-5, Rick C. Hodgin wrote:
Quote:
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


Guest

Thu Nov 29, 2018 5:45 pm   



On Thursday, November 29, 2018 at 3:43:34 AM UTC-5, Stef wrote:
Quote:
On 2018-11-29 gnuarm.deletethisbit_at_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


Guest

Thu Nov 29, 2018 6:45 pm   



On Thursday, November 29, 2018 at 11:43:30 AM UTC-5, Rick C. Hodgin wrote:
Quote:
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. Smile

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

Rick C.

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

Rick C. Hodgin
Guest

Thu Nov 29, 2018 7:45 pm   



On Thursday, November 29, 2018 at 12:26:14 PM UTC-5, gnuarm.del...@gmail.com wrote:
> Most of us learn to walk before we learn to run. Give that a try. Smile

You think you're funny, Rick C. You are not.

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

I did that work in 2015. I recounted it from what I had saved at that time in my git repository, and in my reviewing it on-the-spot after posting here I concluded incorrectly that it was wrong from that timeframe. As it turns out, the way it was back then was correct, and I had thought things through properly.

I'm so tired of people telling me that I have to do things the way everyone else does in order to be successful. The truth is you DO NOT if you're good enough, if you have enough vision and follow-through. Things that are fundamental in nature's design rise up and speak for themselves in any project. There are a host of people moving forward all the time who come up with new ways of doing old things better than the old ways.

I've looked at the requirements of learning the tools that exist and I see variances and issues in the way things are coded, things that could be done away with, merged, rethought, refactored, improved upon, etc., and that's what I plan to do with Logician, to bring in a more common base of natural intuitive understanding from the way people think, and the way things are and exist fundamentally, without having to learn the mechanisms established in the industry previously where they don't make sense. Some of it is truly archaic and could use a fresh perspective.

Without people willing to help me in THAT effort of looking at fundamentals and rebuilding from the ground up for the future, I'll go it alone with sadness, and the lot of you can benefit from the product I ultimately produce if you so desire. If not, no worries. No harm, no foul.

I will NEVER EVER EVER say something negative to anyone in such a way as to smash or diminish their hopes, dreams, or goals. Any goals which are truly off-the-charts ludicrous will have that fact revealed on the journey, and for some people (possibly myself included), that's the ONLY way they'll EVER learn. But for the rest, beating someone down like that is horrific.

To rise up with a negative voice and squelch someone in their heartfelt, enthusiastic, honest, reaching-out, sincere efforts ... it's akin to the worst kind of criminal behavior one person can do to another. It damages things on the inside which can never be undamaged. It cuts and produces scars that remain for life, impacting countless other areas of their life for the rest of their life.

May God's light shine upon each of our souls the light of truth and hope, and so brightly that all darkness is ended within each of us.

--
Rick C. Hodgin

David Brown
Guest

Thu Nov 29, 2018 10:45 pm   



On 29/11/2018 18:52, Rick C. Hodgin wrote:
Quote:
On Thursday, November 29, 2018 at 12:26:14 PM UTC-5, gnuarm.del...@gmail.com wrote:
Most of us learn to walk before we learn to run. Give that a try. :)

You think you're funny, Rick C. You are not.

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

I did that work in 2015. I recounted it from what I had saved at that time in my git repository, and in my reviewing it on-the-spot after posting here I concluded incorrectly that it was wrong from that timeframe. As it turns out, the way it was back then was correct, and I had thought things through properly.

I'm so tired of people telling me that I have to do things the way everyone else does in order to be successful. The truth is you DO NOT if you're good enough, if you have enough vision and follow-through. Things that are fundamental in nature's design rise up and speak for themselves in any project. There are a host of people moving forward all the time who come up with new ways of doing old things better than the old ways.

I've looked at the requirements of learning the tools that exist and I see variances and issues in the way things are coded, things that could be done away with, merged, rethought, refactored, improved upon, etc., and that's what I plan to do with Logician, to bring in a more common base of natural intuitive understanding from the way people think, and the way things are and exist fundamentally, without having to learn the mechanisms established in the industry previously where they don't make sense. Some of it is truly archaic and could use a fresh perspective.

Without people willing to help me in THAT effort of looking at fundamentals and rebuilding from the ground up for the future, I'll go it alone with sadness, and the lot of you can benefit from the product I ultimately produce if you so desire. If not, no worries. No harm, no foul.

I will NEVER EVER EVER say something negative to anyone in such a way as to smash or diminish their hopes, dreams, or goals. Any goals which are truly off-the-charts ludicrous will have that fact revealed on the journey, and for some people (possibly myself included), that's the ONLY way they'll EVER learn. But for the rest, beating someone down like that is horrific.

To rise up with a negative voice and squelch someone in their heartfelt, enthusiastic, honest, reaching-out, sincere efforts ... it's akin to the worst kind of criminal behavior one person can do to another. It damages things on the inside which can never be undamaged. It cuts and produces scars that remain for life, impacting countless other areas of their life for the rest of their life.

May God's light shine upon each of our souls the light of truth and hope, and so brightly that all darkness is ended within each of us.


You have a very strange way of thanking people who give you sound
advice. No one has suggested you don't learn to run - merely that you
learn to walk first. No one has suggested that you should not dream, or
reach for the stars - merely that jumping off a cliff is not a good way
to learn to fly.

Lashing out at people who try to help, and insulting them in such
hyperbolic terms is not going to make your projects progress any faster.
It is just going to mean fewer people to help you on your way.

And for someone who says they will "NEVER EVER EVER say something
negative to anyone", you really do write impressively strongly worded
and highly negative posts sometimes. (And this one is not nearly as bad
as some of the ones you have directed at me.)


Guest

Thu Nov 29, 2018 11:45 pm   



On Thursday, November 29, 2018 at 12:52:16 PM UTC-5, Rick C. Hodgin wrote:
Quote:
On Thursday, November 29, 2018 at 12:26:14 PM UTC-5, gnuarm.del...@gmail.com wrote:
Most of us learn to walk before we learn to run. Give that a try. :)

You think you're funny, Rick C. You are not.


Not trying to be rude, I'm serious. You have gaping holes in your knowledge of digital logic design. If you don't know the significance of clock enables and are just learning the faculties of logic gates there is no point really in trying to teach you how to design a CPU.


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

I did that work in 2015. I recounted it from what I had saved at that time in my git repository, and in my reviewing it on-the-spot after posting here I concluded incorrectly that it was wrong from that timeframe. As it turns out, the way it was back then was correct, and I had thought things through properly.


I don't know what you are referring to here... at all. "it" has no meaning to me unless you explain "it".


> I'm so tired of people telling me that I have to do things the way everyone else does in order to be successful. The truth is you DO NOT if you're good enough, if you have enough vision and follow-through. Things that are fundamental in nature's design rise up and speak for themselves in any project. There are a host of people moving forward all the time who come up with new ways of doing old things better than the old ways.

You can do things any way you want. No one is telling you to do anything in a specific way. We don't understand what you are talking about because you can't be bothered to learn the common terminology or any of the basic concepts. If you want to learn it all on your own, inventing all the concepts yourself and giving everything a name you invented, then why are you here asking questions?


Quote:
I've looked at the requirements of learning the tools that exist and I see variances and issues in the way things are coded, things that could be done away with, merged, rethought, refactored, improved upon, etc., and that's what I plan to do with Logician, to bring in a more common base of natural intuitive understanding from the way people think, and the way things are and exist fundamentally, without having to learn the mechanisms established in the industry previously where they don't make sense. Some of it is truly archaic and could use a fresh perspective.

Without people willing to help me in THAT effort of looking at fundamentals and rebuilding from the ground up for the future, I'll go it alone with sadness, and the lot of you can benefit from the product I ultimately produce if you so desire. If not, no worries. No harm, no foul.


No, I have no interest in reinventing things that aren't broken. I have work to do and know how to get my work done using the tools available. If you want to design your own tools, obviously getting work done is secondary. Regardless that isn't how you started this thread. You started by explaining what you were trying to do and how you were trying to do it and asked, "Is there an easier / different way to do this?" All we have done is to try to explain why using clock enables is an easier way to do what you were doing.


Quote:
I will NEVER EVER EVER say something negative to anyone in such a way as to smash or diminish their hopes, dreams, or goals. Any goals which are truly off-the-charts ludicrous will have that fact revealed on the journey, and for some people (possibly myself included), that's the ONLY way they'll EVER learn. But for the rest, beating someone down like that is horrific.

To rise up with a negative voice and squelch someone in their heartfelt, enthusiastic, honest, reaching-out, sincere efforts ... it's akin to the worst kind of criminal behavior one person can do to another. It damages things on the inside which can never be undamaged. It cuts and produces scars that remain for life, impacting countless other areas of their life for the rest of their life.


No one here has intentionally tried to be negative or to diminish your hopes. What we have tried to do explain how you are on a long, painful road and that we can help you find an easier way if you will listen. If you want to follow the rough road, that's your choice. I'm not making any judgements at all about your destination. That's all up to you.

If you want to discuss digital logic design, please ask questions. I'm not interested in discussing how people are diminishing your hopes or anything at all about god. This group is not about that. Sorry if you were hurt by anything I wrote.

Rick C.

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


Guest

Fri Nov 30, 2018 1:45 am   



torsdag den 29. november 2018 kl. 18.52.16 UTC+1 skrev Rick C. Hodgin:
Quote:
On Thursday, November 29, 2018 at 12:26:14 PM UTC-5, gnuarm.del...@gmail.com wrote:
Most of us learn to walk before we learn to run. Give that a try. :)

You think you're funny, Rick C. You are not.

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

I did that work in 2015. I recounted it from what I had saved at that time in my git repository, and in my reviewing it on-the-spot after posting here I concluded incorrectly that it was wrong from that timeframe. As it turns out, the way it was back then was correct, and I had thought things through properly.

I'm so tired of people telling me that I have to do things the way everyone else does in order to be successful. The truth is you DO NOT if you're good enough, if you have enough vision and follow-through. Things that are fundamental in nature's design rise up and speak for themselves in any project. There are a host of people moving forward all the time who come up with new ways of doing old things better than the old ways.

I've looked at the requirements of learning the tools that exist and I see variances and issues in the way things are coded, things that could be done away with, merged, rethought, refactored, improved upon, etc., and that's what I plan to do with Logician, to bring in a more common base of natural intuitive understanding from the way people think, and the way things are and exist fundamentally, without having to learn the mechanisms established in the industry previously where they don't make sense. Some of it is truly archaic and could use a fresh perspective.

Without people willing to help me in THAT effort of looking at fundamentals and rebuilding from the ground up for the future, I'll go it alone with sadness, and the lot of you can benefit from the product I ultimately produce if you so desire. If not, no worries. No harm, no foul.

I will NEVER EVER EVER say something negative to anyone in such a way as to smash or diminish their hopes, dreams, or goals. Any goals which are truly off-the-charts ludicrous will have that fact revealed on the journey, and for some people (possibly myself included), that's the ONLY way they'll EVER learn. But for the rest, beating someone down like that is horrific.

To rise up with a negative voice and squelch someone in their heartfelt, enthusiastic, honest, reaching-out, sincere efforts ... it's akin to the worst kind of criminal behavior one person can do to another. It damages things on the inside which can never be undamaged. It cuts and produces scars that remain for life, impacting countless other areas of their life for the rest of their life.

May God's light shine upon each of our souls the light of truth and hope, and so brightly that all darkness is ended within each of us.



I see why you "encounter resistance when I approach others with my thinking"


Guest

Sun Dec 02, 2018 1:45 am   



On Thursday, November 29, 2018 at 7:02:04 PM UTC-5, lasselangwad...@gmail.com wrote:
Quote:
torsdag den 29. november 2018 kl. 18.52.16 UTC+1 skrev Rick C. Hodgin:
On Thursday, November 29, 2018 at 12:26:14 PM UTC-5, gnuarm.del...@gmail.com wrote:
Most of us learn to walk before we learn to run. Give that a try. :)

You think you're funny, Rick C. You are not.

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

I did that work in 2015. I recounted it from what I had saved at that time in my git repository, and in my reviewing it on-the-spot after posting here I concluded incorrectly that it was wrong from that timeframe. As it turns out, the way it was back then was correct, and I had thought things through properly.

I'm so tired of people telling me that I have to do things the way everyone else does in order to be successful. The truth is you DO NOT if you're good enough, if you have enough vision and follow-through. Things that are fundamental in nature's design rise up and speak for themselves in any project. There are a host of people moving forward all the time who come up with new ways of doing old things better than the old ways.

I've looked at the requirements of learning the tools that exist and I see variances and issues in the way things are coded, things that could be done away with, merged, rethought, refactored, improved upon, etc., and that's what I plan to do with Logician, to bring in a more common base of natural intuitive understanding from the way people think, and the way things are and exist fundamentally, without having to learn the mechanisms established in the industry previously where they don't make sense. Some of it is truly archaic and could use a fresh perspective.

Without people willing to help me in THAT effort of looking at fundamentals and rebuilding from the ground up for the future, I'll go it alone with sadness, and the lot of you can benefit from the product I ultimately produce if you so desire. If not, no worries. No harm, no foul.

I will NEVER EVER EVER say something negative to anyone in such a way as to smash or diminish their hopes, dreams, or goals. Any goals which are truly off-the-charts ludicrous will have that fact revealed on the journey, and for some people (possibly myself included), that's the ONLY way they'll EVER learn. But for the rest, beating someone down like that is horrific..

To rise up with a negative voice and squelch someone in their heartfelt, enthusiastic, honest, reaching-out, sincere efforts ... it's akin to the worst kind of criminal behavior one person can do to another. It damages things on the inside which can never be undamaged. It cuts and produces scars that remain for life, impacting countless other areas of their life for the rest of their life.

May God's light shine upon each of our souls the light of truth and hope, and so brightly that all darkness is ended within each of us.



I see why you "encounter resistance when I approach others with my thinking"


I'm sorry this thread ended this way. I was hoping to help him make some progress on his design and his understanding of how to design logic. But I can't say I am surprised. He seems to have difficulties in understanding how others think in general. So it shouldn't be a surprise that he had trouble understanding the concepts we tried to explain to him. I guess that is also why he hasn't learned very much from all the many sources available on the web and in books.

I think that is the main reason why this group is relatively dead now. Most people have found other, very easy ways to learn digital logic design. Rich seems intent on literally reinventing the wheel in terms of digital logic design. Nothing he finds is good enough because it isn't the way he has already started thinking without even trying to understand how others do it.

Rick C.

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

Goto page Previous  1, 2, 3, 4, 5  Next

elektroda.net NewsGroups Forum Index - FPGA - Periodically delayed clock

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map