Using std_ulogic at synthesis level
in [FPGA]
|
From: alessandro.strazzero on 22 Jul 2010 05:14 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 22 Jul 2010 09:20 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 22 Jul 2010 12:50 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 22 Jul 2010 15:14 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 22 Jul 2010 16:18
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. |