8 bit micro controller by verilog

[ads-ee]

Re: verilog code for microcontroller

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.

I'm not against simple stuff like that, but if you look up that notation (see the wiki page) the plethora of single characters that get attached to some signal leave the name nearly unreadable. I also upper case port names so they are immediately distinguishable from internal signals of a module. constants always have pUPPERCASE (parameter) or gUPPERCASE (generic). Chip pins always have i, o, or b on the end of the name. That makes it easy to know if you have the signal in the code somewhere you better deal with it properly.

And for metastables, if they are part of the functionality, and it's important that I know it is metastable, then I use my_signal_meta for the metastable part, and my_signal after synchronization.

I actually use a separate module that has a synchronizer with a very distinctive name for the flip-flops and I've got all kinds of attributes on the reg declarations to make sure the FFs are located in the same slice/alm/etc.

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.

I agree with you about the writing it differently, I just like the lack of large white space in front of my lines of code. I could live with 4 spaces, but those that use 8??? an always block in my code is indented as it's inside a module so an "if" is another indent and the assignment is another indent...that's 24 spaces!!! :-O

 

[mrflibble]

Re: verilog code for microcontroller

I'm not against simple stuff like that, but if you look up that notation (see the wiki page) the plethora of single characters that get attached to some signal leave the name nearly unreadable. I also upper case port names so they are immediately distinguishable from internal signals of a module. constants always have pUPPERCASE (parameter) or gUPPERCASE (generic). Chip pins always have i, o, or b on the end of the name. That makes it easy to know if you have the signal in the code somewhere you better deal with it properly.

The waterfall of nonsense characters of which you speak is indeed something I steer clear of. Maybe it had it's place eons ago for programming against windoze api's or something, but I don't see it being useful in the HDL area.

The reason I gave the specific rst_async_n example is that for just about all my designs (all relatively simple stuff) the reset signals inside the fpga are synchronous and they are active high. So when a reset signal deviates from the "norm" (*) I prefer to have an exceedingly obvious way to signify that. As in, more than just a code comment.

(*) I realize such a "norm" could be highly subjective, based on what kind of work you are doing, and maybe even depending on fpga family. I mostly muck about on xilinx, and there reset is active high.

But this rst_async_n is the exception rather than the rule.

I actually use a separate module that has a synchronizer with a very distinctive name for the flip-flops and I've got all kinds of attributes on the reg declarations to make sure the FFs are located in the same slice/alm/etc.

*grin* devious mission accomplished. Originally I had included an extra bit on synchronizers. But then hey wait, if I already list this, synchronizers might not get discussed. And as I like to hear how other people handle synchronization and the nitty gritty of notation to keep things neat ... best remove that bit.

I also have a module I use for synchronizers. Designed it once, used many times. Well, and tweaked it a bit over time. And it is exactly as you say, with plenty of RLOCs to make sure the FFs get placed where I want. And to make sure that you get FFs at all instead of those pesky SRLs.

And as you say, with distinctive names. Makes it easier to attach those attributes AND makes it easier for me to recognize them. Beats deciphering some of the crazy automatic names the tools sometimes come up with.

I agree with you about the writing it differently, I just like the lack of large white space in front of my lines of code. I could live with 4 spaces, but those that use 8??? an always block in my code is indented as it's inside a module so an "if" is another indent and the assignment is another indent...that's 24 spaces!!! :-O

Ouchie! Who the hell uses 8 spaces? In the past I've experimented a bit with indent size, and I found 4 to be a happy medium that works well (for me) for the various languages used.

The only indent that needs to die horribly in languages I use is the bleeping tab in python. Requiring tabs was not a good idea in Makefiles, and it didn't suddenly become a good idea in this millenium. <rant/>


PS: How is using pUPPERCASE (parameter) or gUPPERCASE (generic) not on the slippery Hungarian slope? The i, o, b at the end for chip pins indeed is useful. On that subject, what do you do for differential signals? MY_OUTPUT_SIGNALop and MY_OUTPUT_SIGNALon for the pos and neg output?

 

[vead]

I don't know how to decide Input and output but I try
Top module:mc8051
there are many sub module
mc8051_acc
mc8051_alu
mc8051_pc
mc8051_port

question:- how to connect top module with other sub module


we can define Input and output port for micro controller

can someone help with basics

 

[ads-ee]

Re: verilog code for microcontroller

PS: How is using pUPPERCASE (parameter) or gUPPERCASE (generic) not on the slippery Hungarian slope? The i, o, b at the end for chip pins indeed is useful. On that subject, what do you do for differential signals? MY_OUTPUT_SIGNALop and MY_OUTPUT_SIGNALon for the pos and neg output?

I only use the p so that I know at a glance it's a parameter or localparam and not a module port. I uppercase my port names so I immediately know that it's going in or out of the module. I'm exceedingly lazy and don't like to search all over the file to figure out if a signal is coming/going out of the module.

The i,o,b at the end was done because I don't like typing pin_module_port or ipin_module_port or opin_module_port, so instead I type MODULE_PORTi, MODULE_PORTo. And for those pesky differential ports MODULE_PORTo_n, MODULE_PORTo_p.

Most of this just came about because months later I get asked to add something to my design and I pull up the code and found myself searching around the file over and over looking to see where some signal name is defined and if it's a reg/wire/port/parameter. Got tired of moving around the file so much I started adding "clues" to where something comes from. Nothing as crazy as Hungarian, but just some small number of general stuff... *_n for the oddball active low. _n/_p for those diff ports, i/o/b for I/O pins, pUPPERCASE for parameters, using the module name as the instance name with a _1/2/3/4 etc on the end of the name, easier to trace through your netlist when you have the module name and not something like inst_1.

mrfibble, we seem to have very similar coding standards that have been developed over many trials and tribulations. At the very least if I had to pick up code you left behind I wouldn't be cursing your name 20 times a day (been there, done that). ;-)

Top module:mc8051
there are many sub module
mc8051_acc
mc8051_alu
mc8051_pc
mc8051_port

There isn't really a good reason as I see to name all your submodules mc8051_<module_name>.

Having a simple acc module instantiated in your mc8051 module should be fine.

 

[mrflibble]

Re: verilog code for microcontroller

I'm exceedingly lazy and don't like to search all over the file to figure out if a signal is coming/going out of the module.

Exceeding laziness is a Good Thing [tm]. But I find that the biggest reason for having to hunt through files is ... shit tools.

Most of this just came about because months later I get asked to add something to my design and I pull up the code and found myself searching around the file over and over looking to see where some signal name is defined and if it's a reg/wire/port/parameter. Got tired of moving around the file so much I started adding "clues" to where something comes from. Nothing as crazy as Hungarian, but just some small number of general stuff... *_n for the oddball active low. _n/_p for those diff ports, i/o/b for I/O pins, pUPPERCASE for parameters, using the module name as the instance name with a _1/2/3/4 etc on the end of the name, easier to trace through your netlist when you have the module name and not something like inst_1.

This is very recognizable. Did I mention shit tools yet? *scrolls up* So I did. Well, shit tools. They are the main reason for having to hunt through files in a way that is annoying. IMO there is nothing wrong with the following:

- Curse you, treacherous brain! Now, what did that signal do exactly?
- Hover over signal name, get popup with quick summary of signal properties.
- If needed, hover over signal, press key shortcut, and jump to the relevant code with declaration.
- For bonus point you get a quick glance at the surrounding code. Helps jog the memory.
- Key press shortcut again to go back to code you were working on.

I mean, I currently have exactly this behavior when I am working on some embedded C++ code. Is it so much more difficult to make tools that do this for systemverilog? No it's not. The syntax has no inherent higher complexity to excuse the lack of decent code navigation. HDL tools seem to be sloooooowly moving in this direction, but they are still light-years behind IDE's for regular boring software development.

Regarding the instance names, do you also use module_name_1 even if there is just a single instance? If so, any particular reason? I tend to use module_name_inst when it's a single instance.

In the aforementioned C++ I would use for example static ArbGenerator myArbGenerator; for a statically allocated singleton class. Singleton what with it having hardware resources on the mcu behind it and all that. In verilog I also used to use my_module_name for a single instance of module_name. But I moved to module_name_inst because finding related signals using alphabetic sort of signal names turns out to be a useful feature.

mrfibble, we seem to have very similar coding standards that have been developed over many trials and tribulations. At the very least if I had to pick up code you left behind I wouldn't be cursing your name 20 times a day (been there, done that). ;-)

Victory! I strive to have my name cursed a maximum of 12 times a day.

 

[ads-ee]

Re: verilog code for microcontroller

Exceeding laziness is a Good Thing [tm].

Regarding the instance names, do you also use module_name_1 even if there is just a single instance? If so, any particular reason? I tend to use module_name_inst when it's a single instance.

OMG! That's three extra characters! And two more than your previous naming convention. :-o

See the first line of your quote...all those extra characters to type is giving my carpal tunnels sympathy pains. ;-)

Seriously, it's just by habit from a company I worked years for that had a requirement that all instances be numbered even the singletons.

 

[mrflibble]

Re: verilog code for microcontroller

OMG! That's three extra characters! And two more than your previous naming convention. :-o

See the first line of your quote...all those extra characters to type is giving my carpal tunnels sympathy pains. ;-)

Seriously, it's just by habit from a company I worked years for that had a requirement that all instances be numbered even the singletons.

;-)

Do you remember what the rationale was behind this requirement? Right now I don't really see the benefit, but maybe I am missing something.

 

[ads-ee]

Re: verilog code for microcontroller

Do you remember what the rationale was behind this requirement? Right now I don't really see the benefit, but maybe I am missing something.

It was government contract work. I'm sure that explains it all.

 

[mrflibble]

Requirement #1: we must have some requirements.
Requirement #2: the checkboxes must look pretty.

It explains all but one thing; why you still use it. Bad habits become old habits followed by old habits die hard?

 

[vead]

Re: verilog code for microcontroller

I only use the p so that I know at a glance it's a parameter or localparam and not a module port. I uppercase my port names so I immediately know that it's going in or out of the module. I'm exceedingly lazy and don't like to search all over the file to figure out if a signal is coming/going out of the module.

The i,o,b at the end was done because I don't like typing pin_module_port or ipin_module_port or opin_module_port, so instead I type MODULE_PORTi, MODULE_PORTo. And for those pesky differential ports MODULE_PORTo_n, MODULE_PORTo_p.

Most of this just came about because months later I get asked to add something to my design and I pull up the code and found myself searching around the file over and over looking to see where some signal name is defined and if it's a reg/wire/port/parameter. Got tired of moving around the file so much I started adding "clues" to where something comes from. Nothing as crazy as Hungarian, but just some small number of general stuff... *_n for the oddball active low. _n/_p for those diff ports, i/o/b for I/O pins, pUPPERCASE for parameters, using the module name as the instance name with a _1/2/3/4 etc on the end of the name, easier to trace through your netlist when you have the module name and not something like inst_1.

mrfibble, we seem to have very similar coding standards that have been developed over many trials and tribulations. At the very least if I had to pick up code you left behind I wouldn't be cursing your name 20 times a day (been there, done that). ;-)





There isn't really a good reason as I see to name all your submodules mc8051_<module_name>.

Having a simple acc module instantiated in your mc8051 module should be fine.

I think thats not enough information to write code

 

[mrflibble]

I don't know how to decide Input and output but I try
Top module:mc8051
there are many sub module
mc8051_acc
mc8051_alu
mc8051_pc
mc8051_port

question:- how to connect top module with other sub module

And this is enough information to connect the modules together?