thaks for reply but that's not my question so please read what I am sayingI'm pretty sure that there're a lot of easier things to go with "learn by doing". Start with turning on a Led, then create a secuence, then add a button, then more leds.
thaks for reply but that's not my question so please read what I am saying
I checked out there is not any source codeThere is a core called J1: https://hackaday.com/2010/12/01/j1-a-small-fast-cpu-core-for-fpga/
It is a small code, and it is easy to understand, with graphs, explanation, a functional code and even an article about it. It will make you life easier, I guess.
I checked out there is not any source code
j1 verilog source, all 187 lines of it.
Without all that wasteful white space it's only 41 lines of "real" code. ;-)
It could have been a very efficient 1 line of code, if they had properly used /**/ comments. ;-)
Heheh. It is a bit verbose, but not overly so IMO. As in it is easy to read and comprehend. Not something that can be said all that often about free code in the wild.
You would probably really hate my verilog codin style then. I also put the module port declarations on seperate lines.As opposed to putting it on two lines line in j1.v.
With that said, is there something like a style guide I could read to improve things?
Yup, that's why I do the single line per port as well. That way you can add a short & sweet comment describing what that signal does.I've developed my own style of coding from years of working and it typically requires the use of 1 port=1 line of code with a comment on the end of the line to define what that ytxfpno_nstvyg signal name means. (Of course my coding style forbids cryptic names like that with Hungarian/Romanian/Ukrainian/etc notation nonsense).
Well, it's 4 spaces over here. If I have to intend so much that I cannot read it anymore then that is a big hint that I should probably write it a bit differently.Pretty much all of my coding style guidelines I use are directly related to maintainability and code reuse. I also use only 2 spaces (real spaces) for all indentation as I dislike having to scan across 4 and 8 (space) tabs. Don't get me started on those ilk that love to use tabs and spaces in the same file for indentation (drawn and quartered is not a severe enough penalty for them) ;-)
Heheh, 1 line of behavioral, depending on comment style no doubt. ;-) But yes, it is indeed an interesting bit of code. I have it on the Stuff To Read [tm] list as well, to see what can be learned from it.Actually the fact that the processor is a functional 8-bit processor in less than 187 lines of actual code was very interesting. I was going to look it over in more detail to see how it was structured and what it's capabilities are. It's certainly smaller than the picoblaze, of course pico isn't written very behaviorally, so maybe it's only 1 line of behavioral code. ;-)
Yup, that's why I do the single line per port as well. That way you can add a short & sweet comment describing what that signal does.
As for the "No Ukranian notation" XD, how do you handle things like active low, asynchronous, metastables, stuff like that? For example, for an async reset that's active low, I would use rst_async_n.
Well, it's 4 spaces over here. If I have to intend so much that I cannot read it anymore then that is a big hint that I should probably write it a bit differently.And indeed, those that mix tabs + spaces need to get out and shot. Mmmh, shoot first, then be drawn & quartered, or drawn & quartered, and then shot. And then tarred & feathered. And THEN run out of town naked. That'll teach 'm to be fruit baskets.
ads-ee said:Actually the fact that the processor is a functional 8-bit processor in less than 187 lines of actual code was very interesting. I was going to look it over in more detail to see how it was structured and what it's capabilities are. It's certainly smaller than the picoblaze, of course pico isn't written very behaviorally, so maybe it's only 1 line of behavioral code.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?