Verilog_Guy
Newbie level 3
- Joined
- Nov 18, 2014
- Messages
- 4
- Helped
- 0
- Reputation
- 0
- Reaction score
- 0
- Trophy points
- 1
- Activity points
- 62
Code Verilog - [expand] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 localparam FOO = 8; typedef struct packed { logic [FOO-1:0] bar; } my_struct_t; // ---------------------------- module my_top_module( input clk, input rst_n, output [7:0] led ); my_struct_t my_struct; assign my_struct.bar = 8'h01; my_core_module my_core_module_inst ( .my_struct (my_struct), .whatever (led) ); endmodule // my_top_module // ---------------------------- module my_core_module( input my_struct_t my_struct, output [7:0] whatever ); assign whatever = ~ my_struct.bar[7:0]; // big fat assumption that FOO >= 8 , but this is only an example. endmodule // my_core_module
Am I missing anything? Anyone here with insight as to the what the architects of System Verilog were thinking (or better yet have pull to get this fixed in a future version of System Verilog)?
I suspect the ANSI versus non-ANSI port declaration is a bit of a red herring. Why? Because the non-ANSI way is the only way in which you are allowed to cram your horrible Do Not Use This workaround of doing the typedef declaration in that module. Isn't the idea behind re-use is that you make something you actually want to re-use? XD To that end you probably want something that is not going to be hard to maintain. And plonking your typedef's in there is a nice example of what not to do IMO. Can you think of a programming language where the equivalent is a good idea or even close to a best practice?
Anyways, I will assume that you arrived at that particular recipe not because you thought it was a great idea, but purely because it was a recipe that roughly did what you wanted and it's the only one that actually got synthesized. If you did this because you thought it was a good idea, I probably am missing something. In that case could you explain why you chose this particular construct? IMO you want to do the typedef (parameterized or not) somewhere else exactly once, and then use it in the various modules.
As for packages not accepting parameters.... Yes, no, sortof? There is nothing stopping you to parameterize the stuff inside your package. Maybe it's a matter of expectations. If you expect to be able to provide a parameter when you do an import my_pkg::*, then think again. Or better, look at other (programming) languages. You don't provide the parameters on the import-like expression in languages like C++/java/python/whatever either. Instead you should be looking at static package members to hold the parameters for you. You could even pull in the default values (or overriding values) for those with external parameters that you give a nice hierarchical name. That way you can specify them on your synthesis/simulation command line a la -G/-g/-defparam/-D or some such.
So packages do not accept parameters on the import or `include statement. Nope. And rightfully so IMO. But you can still parameterize the members inside that package. Package is nothing more than a convenient container and a namespace.
As for interfaces, why only use interfaces for big projects? Interfaces are damn handy and I wish verilog would have had that waaaay earlier.
And structs not being parameterized is indeed bloody stupid, and an oversight of the design committee IMO. If I take for example C++ then classes and structs are very closely related, and you can template both of them.
You could try a paramerized class as a wrapper for your struct to get the job done. But no doubt the synthesis tools will barf despite the fact that everything is static and could have been resolved compile time.
But from a practical point of view none of that has to be a showstopper, since you are dumping everything inside a package. And you can simply have a parameter as package member, and use that. Not as elegant as a properly parameterized struct, but gets the job done.
I have no idea! The lack of parameters for struct while providing it for class is indeed just silly. And even that would not be so bad if you could use class as workaround. But that's only going to work if you want simulation only. Synthesis is probably going to be a no-go. Speaking of synthesis, any particular reason why you are not using a packed struct there?
Having to use verilog-1995 port declarations as a workaround for shortcomings in SystemVerilog ... That's just depressing.The typedef you see plonked in the code was to provide a simple example for this forum. In practice, I have all my typedefs pulled in to a single include file (the include file is acting as a package, if you will). So as far as maintainability, I see no issues. And yes, I hate having resort to non-ANSI declarations, but nonetheless it does seem to work.
I wouldn't exactly call verilog or SV better than say C++ or java. I would actually call it worse.I've always thought of parameter passing / overriding as one of the best features of Verilog. Something that made it better than C++/java/python/whatever. Maybe the relevant question is this: is Verilog trying to become these other languages? To that end, are parameters going away, and their restricted usage in structs and unions the first step toward this end?
Sounds good. I was really trying understand if structs / unions were crippled (purposefully or not) in System Verilog, or if I was missing something. Sounds like they are crippled. So it is what it is and I have to search for other ways of doing what I want to do. We've got to work with the language we are given, not the one we want. :smile: And as you say, maybe packages are a better alternative than resorting to non-ansi. Your points are noted.
I swear, one of these days I am going to need either glasses, sleep or more coffee ._.I do show a packed struct in my example. Perhaps you missed it?
Which one would that be?I do know of at least one synthesis tool that supports it.
Isn't that just adding an extra layer of potential mistakes? Or put differently, what is the advantage of doing so?Since you are using packed structs, it might be better to pass simple vectors through the ports and assign them locally to struct variables inside your modules.
But take the case of two packed structs with the same overall size, but completely different field layouts. SystemVerilog will gladly let you assign one to the other without any warning. The only advantage of packed structs is that it gives you symbolic names for bit-vector slices.
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?