From: alessandro.strazzero on
Dear everybody,

in the following piece of code ...

if sRxOld /= iRx then
if vHIGH >= T_500ns then
sBit <= 'U';
elsif vLOW >= T_500ns then
sBit <= 'U';
elsif vLH = '1' then
sBit <= '0';
else
sBit <= '1';
end if;
else
sBit <= 'X';
end if;

.... I assign the sBit signal of type std_ulogic to 'U', '0', '1' and
'X'. Then, anywhere in the code, I have a sequential
statement like this: if sBit /= 'X' then ...

My question is: when the VHDL is synthesized how the 'X' state is
represented ? Is the FPGA able to
distinguish between the 'X' state and '0' or '1' state ?

Best Regards

/Alessandro
From: colin on
On 22 July, 10:14, "alessandro.strazz...(a)gmail.com"
<alessandro.strazz...(a)gmail.com> wrote:
> Dear everybody,
>
> in the following piece of code ...
>
>                         if sRxOld /= iRx then
>                           if vHIGH >= T_500ns then
>                             sBit <= 'U';
>                           elsif vLOW >= T_500ns then
>                             sBit <= 'U';
>                           elsif vLH = '1' then
>                             sBit <= '0';
>                           else
>                             sBit  <= '1';
>                           end if;
>                         else
>                           sBit <= 'X';
>                         end if;
>
> ... I assign the sBit signal of type std_ulogic to 'U', '0', '1' and
> 'X'. Then, anywhere in the code, I have a sequential
> statement like this: if sBit /= 'X' then ...
>
> My question is: when the VHDL is synthesized how the 'X' state is
> represented ? Is the FPGA able to
> distinguish between the 'X' state and '0' or '1' state ?
>
> Best Regards
>
> /Alessandro

Any input can only see a "1" or a "0". Although if the input is near
the voltage where it has to decide then it will take a random amount
of time to make up its mind and noise could make it change its mind.

I wonder why we don't get this sort of thing as often as we used to?

Colin
From: Rob Gaddi on
On 7/22/2010 6:20 AM, colin wrote:
> On 22 July, 10:14, "alessandro.strazz...(a)gmail.com"
> <alessandro.strazz...(a)gmail.com> wrote:
>> Dear everybody,
>>
>> in the following piece of code ...
>>
>> if sRxOld /= iRx then
>> if vHIGH>= T_500ns then
>> sBit<= 'U';
>> elsif vLOW>= T_500ns then
>> sBit<= 'U';
>> elsif vLH = '1' then
>> sBit<= '0';
>> else
>> sBit<= '1';
>> end if;
>> else
>> sBit<= 'X';
>> end if;
>>
>> ... I assign the sBit signal of type std_ulogic to 'U', '0', '1' and
>> 'X'. Then, anywhere in the code, I have a sequential
>> statement like this: if sBit /= 'X' then ...
>>
>> My question is: when the VHDL is synthesized how the 'X' state is
>> represented ? Is the FPGA able to
>> distinguish between the 'X' state and '0' or '1' state ?
>>
>> Best Regards
>>
>> /Alessandro
>
> Any input can only see a "1" or a "0". Although if the input is near
> the voltage where it has to decide then it will take a random amount
> of time to make up its mind and noise could make it change its mind.
>
> I wonder why we don't get this sort of thing as often as we used to?
>
> Colin

Although this brings up a (fairly tool dependent) question that I've
had. If I assign a don't care output '-' (or an X or a U for that
matter) what happens? For instance, I just used in a project:

-- Start by setting up the address
C_addr <= (others => '-');

case TO_INTEGER(FCTL_I.ADDR) is
when REG_FIRST_COEF to REG_LAST_COEF =>
C_addr(7) <= '0';
C_addr(6 downto 5) <= UNSIGNED(fcsel_channel);
C_addr(4) <= fcsel_rt;
C_addr(3 downto 0) <= FCTL_I.ADDR(3 downto 0);

when REG_FIRST_CAL to REG_LAST_CAL =>
C_addr(7) <= '1';
C_addr(6 downto 5) <= UNSIGNED(fcsel_channel);
C_addr(0) <= FCTL_I.ADDR(0);

when others =>
C_we <= (others => false);

end case;

Now, I know what would happen if I were sitting around drawing Karnaugh
maps for these terms; C_addr(4) would always be equal to fcsel_rt,
regardless of FCTL_I.ADDR. What I don't know is whether or not XST is
smart enough to handle that don't care correctly, or whether all don't
care values get mapped to '0'. What about Quartus? What about
Synplicity? What about more complicated cases such as the following
inferred RAM, in which the bottom 7 bits of addr can always be used to
address the RAM?

if (addr < 128) then
dout <= RAM(addr);
else
dout <= (others => '-');
end if;

--
Rob Gaddi, Highland Technology
Email address is currently out of order
From: Brian Drummond on
On Thu, 22 Jul 2010 09:50:33 -0700, Rob Gaddi <rgaddi(a)technologyhighland.com>
wrote:

>Although this brings up a (fairly tool dependent) question that I've
>had. If I assign a don't care output '-' (or an X or a U for that
>matter) what happens? For instance, I just used in a project:
>
> -- Start by setting up the address
> C_addr <= (others => '-');
>
> case TO_INTEGER(FCTL_I.ADDR) is
> when REG_FIRST_COEF to REG_LAST_COEF =>
> C_addr(7) <= '0';
> C_addr(6 downto 5) <= UNSIGNED(fcsel_channel);
> C_addr(4) <= fcsel_rt;
> C_addr(3 downto 0) <= FCTL_I.ADDR(3 downto 0);
>
> when REG_FIRST_CAL to REG_LAST_CAL =>
> C_addr(7) <= '1';
> C_addr(6 downto 5) <= UNSIGNED(fcsel_channel);
> C_addr(0) <= FCTL_I.ADDR(0);
>
> when others =>
> C_we <= (others => false);
>
> end case;
>
>Now, I know what would happen if I were sitting around drawing Karnaugh
>maps for these terms; C_addr(4) would always be equal to fcsel_rt,
>regardless of FCTL_I.ADDR. What I don't know is whether or not XST is
>smart enough to handle that don't care correctly, or whether all don't
>care values get mapped to '0'. What about Quartus? What about
>Synplicity?

I wouldn't necessarily trust even different versions of XST to do the same
thing. As long as there is no extra cost in LUTs to either approach, the synth
tool can do either. But I probably wouldn't care.

If I did, I would code to more accurately reflect what I wanted : in this case,
that would probably involve a separate case statement (or IF, or simple
assignment for bits 4,5,6) for each bit group in the signal.

- Brian
From: Gabor on
On Jul 22, 3:14 pm, Brian Drummond <brian_drumm...(a)btconnect.com>
wrote:
> On Thu, 22 Jul 2010 09:50:33 -0700, Rob Gaddi <rga...(a)technologyhighland.com>
> wrote:
>
>
>
> >Although this brings up a (fairly tool dependent) question that I've
> >had.  If I assign a don't care output '-' (or an X or a U for that
> >matter) what happens?  For instance, I just used in a project:
>
> >     -- Start by setting up the address
> >     C_addr  <= (others => '-');
>
> >     case TO_INTEGER(FCTL_I.ADDR) is
> >         when REG_FIRST_COEF to REG_LAST_COEF =>
> >             C_addr(7)           <= '0';
> >             C_addr(6 downto 5)  <= UNSIGNED(fcsel_channel);
> >             C_addr(4)           <= fcsel_rt;
> >             C_addr(3 downto 0)  <= FCTL_I.ADDR(3 downto 0);
>
> >         when REG_FIRST_CAL to REG_LAST_CAL =>
> >             C_addr(7)           <= '1';
> >             C_addr(6 downto 5)  <= UNSIGNED(fcsel_channel);
> >             C_addr(0)           <= FCTL_I.ADDR(0);
>
> >         when others =>
> >             C_we <= (others => false);
>
> >     end case;
>
> >Now, I know what would happen if I were sitting around drawing Karnaugh
> >maps for these terms; C_addr(4) would always be equal to fcsel_rt,
> >regardless of FCTL_I.ADDR.  What I don't know is whether or not XST is
> >smart enough to handle that don't care correctly, or whether all don't
> >care values get mapped to '0'.  What about Quartus?  What about
> >Synplicity?  
>
> I wouldn't necessarily trust even different versions of XST to do the same
> thing. As long as there is no extra cost in LUTs to either approach, the synth
> tool can do either. But I probably wouldn't care.
>
> If I did, I would code to more accurately reflect what I wanted : in this case,
> that would probably involve a separate case statement (or IF, or simple
> assignment for bits 4,5,6) for each bit group in the signal.
>
> - Brian

Actually I have found that XST is pretty good at minimizing logic
when left with don't cares. It's not just a matter of LUT's. In this
case
any dependence on FCTL_I.ADDR would add connections to
the LUT and reducing routing is another possibly more important
optimization. In fact in this case you should end up with no
LUT at all unless this logic gets flattened together with other
code.