R
Rick C
Guest
I have a clumsy section of code that is simply complex combinational with no good way around it. There are 14 inputs compared to several vectors, reduced to a single bit to control a few nested IF statements. In each IF statement there are WITH statements with six selections to assign values to a signal. This is all encapsulated in a function.
In most of the WITH statements there is one selection that is a don\'t care since it won\'t be used. I\'m wondering if VHDL has any way to make use of the don\'t care to optimize the decoding logic which I expect to be rather large.
In two of the IF branches a similar issue arises in that the selection signal of the WITH is actually irrelevant since none of the cases other than one will be used. I can leave out the WITH, but I\'m not sure that would produce more simple logic than if the selection signal were used with a don\'t care.
So other than trying synthesis with the code written with don\'t cares, how can I know if this will help or even work at all? The only info I can find on VHDL don\'t cares relates to specific language features like std_match() or case?
Using case? in place of with doesn\'t actually help since the optimization is not about the selection value. But that does make me realize I am only using six of eight possible values of the selection value. That signal is an integer range 0 to 5, but that will still be implemented as a 3 bit signal in the logic. So there are two possible inputs not specified. Will that create a latch in the combinational logic or will the range specification prevent that??? I suppose an others clause will help with that, but it still would be better with an assignment of a don\'t care.
Maybe it would be good to show some code.
subtype Alarm_Type is unsigned (Alarm_Sel_Max downto Tidal_Vol_Sel);
subtype Tone_Seq is natural range 0 to 5;
function Alarm_Tones (Sequence_Num : Tone_Seq;
Alarm_Src : Alarm_Type) return natural is
variable ret_val : natural range 0 to Step_Max := 0;
begin
if (Alarm_Src(Tick_Sel) then
ret_val := twokHz_step; -- Sequence_Num always = 0
elsif (Alarm_Src(Boop_Sel)) then
ret_val := G3_step; -- Sequence_Num always = 0
elsif (OR (Alarm_Src AND VentTones)) then
with Sequence_Num select ret_val : C4_step when 0,
A4_step when 1,
F4_step when 2,
(others => \'-\') when 3, -- tone 3 is a gap tone
A4_step when 4,
F4_step when 5;
elsif (OR (Alarm_Src AND OxygenTones)) then
with Sequence_Num select ret_val : C5_step when 0,
B4_step when 1,
and so forth for many lines...
The case of \"when 3\" above will recur in every subsequent ELSIF. So in the end, the explicit case of Sequence_Num = 3 as well as the unreachable cases of Sequence_Num = 6 and 7 can be optimized as the tool sees fit. This may end up being a rather complex bit of logic so I think it does need attention for optimization.
I have not yet installed the Gowin tools. Maybe I need to do that and try some cases. The synthesis docs don\'t talk about this at all.
--
Rick C.
- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
In most of the WITH statements there is one selection that is a don\'t care since it won\'t be used. I\'m wondering if VHDL has any way to make use of the don\'t care to optimize the decoding logic which I expect to be rather large.
In two of the IF branches a similar issue arises in that the selection signal of the WITH is actually irrelevant since none of the cases other than one will be used. I can leave out the WITH, but I\'m not sure that would produce more simple logic than if the selection signal were used with a don\'t care.
So other than trying synthesis with the code written with don\'t cares, how can I know if this will help or even work at all? The only info I can find on VHDL don\'t cares relates to specific language features like std_match() or case?
Using case? in place of with doesn\'t actually help since the optimization is not about the selection value. But that does make me realize I am only using six of eight possible values of the selection value. That signal is an integer range 0 to 5, but that will still be implemented as a 3 bit signal in the logic. So there are two possible inputs not specified. Will that create a latch in the combinational logic or will the range specification prevent that??? I suppose an others clause will help with that, but it still would be better with an assignment of a don\'t care.
Maybe it would be good to show some code.
subtype Alarm_Type is unsigned (Alarm_Sel_Max downto Tidal_Vol_Sel);
subtype Tone_Seq is natural range 0 to 5;
function Alarm_Tones (Sequence_Num : Tone_Seq;
Alarm_Src : Alarm_Type) return natural is
variable ret_val : natural range 0 to Step_Max := 0;
begin
if (Alarm_Src(Tick_Sel) then
ret_val := twokHz_step; -- Sequence_Num always = 0
elsif (Alarm_Src(Boop_Sel)) then
ret_val := G3_step; -- Sequence_Num always = 0
elsif (OR (Alarm_Src AND VentTones)) then
with Sequence_Num select ret_val : C4_step when 0,
A4_step when 1,
F4_step when 2,
(others => \'-\') when 3, -- tone 3 is a gap tone
A4_step when 4,
F4_step when 5;
elsif (OR (Alarm_Src AND OxygenTones)) then
with Sequence_Num select ret_val : C5_step when 0,
B4_step when 1,
and so forth for many lines...
The case of \"when 3\" above will recur in every subsequent ELSIF. So in the end, the explicit case of Sequence_Num = 3 as well as the unreachable cases of Sequence_Num = 6 and 7 can be optimized as the tool sees fit. This may end up being a rather complex bit of logic so I think it does need attention for optimization.
I have not yet installed the Gowin tools. Maybe I need to do that and try some cases. The synthesis docs don\'t talk about this at all.
--
Rick C.
- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209