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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01/10/2020 10:19:27, Rick C wrote:

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.

Could you concatenate the signals into a composite signal and then use a
case statement. That might be neater? Not sure if 'don't care' works
with all synthesis packages


--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, October 3, 2020 at 8:18:02 AM UTC-4, Mike Perkins wrote:

On 01/10/2020 10:19:27, Rick C wrote:

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.

Could you concatenate the signals into a composite signal and then use a case statement. That might be neater? Not sure if 'don't care' works
with all synthesis packages

The structure is not the issue. The don't care you are referring to would be associated with bits in the selection specification for each case and would actually apply to the case? statement. No?

I'm trying to find info on whether assignment to a don't care value is indicated in the VHDL spec as well as which tools support it. While there is a lot of info on VHDL-2018 supporting don't care in conditionals, not so much on assigning don't care to
signals and variables.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, October 3, 2020 at 11:06:06 AM UTC-4, gnuarm.del...@gmail.com wrote:

On Saturday, October 3, 2020 at 8:18:02 AM UTC-4, Mike Perkins wrote:

I'm trying to find info on whether assignment to a don't care value is indicated in the VHDL spec as well as which tools support it.

Don't care is not a VHDL spec thing. Don't care is part of the std_logic_1164 package. Your example code is not valid because ret_val is defined as a natural, not a std_logic_vector so the assignment of "(others => '-') when 3" to ret_val is invalid.
You can work around this by defining ret_val as type unsigned in which case the "(others => '-') when 3" will work, but all of your other definitions such as 'C4_step' will have to change to unsigned as well.

To your question about what happens when synthesis encounters such an assignment, the answer I believe will be tool specific. If I recall correctly, when Quartus comes across an assignment such as "x <= '-';" it will issue a warning that it is
converting a metavalue (the '-') to '0'. I could be wrong, but I don't think it will do any analysis to say, would it be better to assign '1', '0' or just leave 'x' unchanged. This is probably the analysis that you would like it to do. Maybe search
for "metavalue assignment" or "assigning a metavalue to a signal" or some such thing with your synthesis tool to see if it says what it does.

Kevin Jennings

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)