01-25-2017 05:44 AM
I would like to know how can I check values coming from input ports and change them based on some conditions.
In my verilog code, I have an input port for instance this declaration:
input wire [15:0] countTo
This value will be set by the user later, but I would like to limit it (lower than 2^16 - 1 of course).
For example, if the user sends a value greater than '5000', the variable 'countTo' must be 5000.
Thank you for the attention!
01-25-2017 09:21 AM
Here's how I'd do it - create a "qualified" input that meets your qualifications:
localparam [ 15 : 0 ] MAX_COUNT = 5000; wire assert_countTo_out_of_range = countTo > MAX_COUNT; wire [ 15 : 0 ] countTo_qualified = assert_countTo_out_of_range ? MAX_COUNT : countTo;
Now I'd also do something with that assertion. At the very least in simulation throw an error. Due to your specific circumstances, you may need to somehow bring the assertion out to some sort or real logic exception handler too. It all depends on your circumstances.
Notice I saturate the qualfied value. That may or may not be the appropriate action, again it depends on your requirements.
01-25-2017 09:48 AM
Thank you! I'll try it!
Do you know if it's possible to do something like that using initial blocks like this?
module myModule( input wire [15:0] toCount ); localparam [15:0] MAX_COUNT = 5000; reg [15:0] toCount_reg; initial begin if (toCount > MAX_COUNT) begin toCount_reg = MAX_COUNT; end else begin toCount_reg = toCount; end end
01-25-2017 09:54 AM
You don't want it in an initial block - for multiple reasons.
1. It's a wire - it can change values after initialization.
2. It's not (generally) synthesizable.
I'm guessing you think there's some sort of optimization by having it in an initial rather than code as I did? Or?? I can speak towards optimizations if you wish, just not sure what you're aiming for by coding as an initial.
01-25-2017 03:02 PM
I don't think you can have an initial block that depends on initial conditions like that; even if you could, it would only apply to the toCount input that was provided at power-up (if toCount later changed to 30,000, that would not get limited). Putting it in an "always &(*)" block would make it work continuously, and shouldn't take any more hardware - whichever way you write it, the FPGA sis till going to contain the comparator and mux.
01-25-2017 03:08 PM
Putting it in an "always &(*)" block would make it work continuously, and shouldn't take any more hardware - whichever way you write it, the FPGA sis till going to contain the comparator and mux.
Well, that's not entirely true, and I was hinting at that in my reply. If the "toCount" input is a tied off constant, then synthesis will happily, and completely optimize away the whole thing - comparator, mux, and all - and do it correctly. This sort of synthesis optimization of constants is a very mature technology, and works very well.