Thread: [myhdl-list] Conversion error to vhdl
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Norbo <Nor...@gm...> - 2011-11-20 10:20:24
|
I have played a bit with myhdl and created the following:
----------------------------------------------------------
from myhdl import *
def bin2gray(A,B, C, width):
""" Gray encoder.
B -- input intbv signal, binary encoded
G -- output intbv signal, gray encoded
width -- bit width
"""
@always_comb
def logic():
C[0].next = A + B
return logic
def main():
width = 8
A = Signal(intbv(0)[width:])
B = Signal(intbv(0)[width:])
C = Signal(intbv(0)[width:])
toVHDL(bin2gray, A, B,C, width)
if __name__ == '__main__':
main()
---------------------------------------------
after conversion it gives me the following .vhd file:
--------------------------------------------------
-- File: bin2gray.vhd
-- Generated by MyHDL 0.7
-- Date: Sat Nov 19 22:54:16 2011
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
use std.textio.all;
use work.pck_myhdl_07.all;
entity bin2gray is
port (
A: in unsigned(7 downto 0);
B: in unsigned(7 downto 0);
C: out unsigned(7 downto 0)
);
end entity bin2gray;
-- Gray encoder.
--
-- B -- input intbv signal, binary encoded
-- G -- output intbv signal, gray encoded
-- width -- bit width
architecture MyHDL of bin2gray is
begin
C(0) <= to_std_logic(A + B);
end architecture MyHDL;
--------------------------------------
this seems not to be synthesisable because there is no "to_std_logic"
function for unsigned type
do i miss something?
|
|
From: Christopher F. <chr...@gm...> - 2011-11-20 14:37:54
|
On 11/19/11 4:22 PM, Norbo wrote: > I have played a bit with myhdl and created the following: [snip] > -------------------------------------------------- > -- File: bin2gray.vhd > -- Generated by MyHDL 0.7 > -- Date: Sat Nov 19 22:54:16 2011 > > > library IEEE; > use IEEE.std_logic_1164.all; > use IEEE.numeric_std.all; > use std.textio.all; > > use work.pck_myhdl_07.all; > > entity bin2gray is > port ( > A: in unsigned(7 downto 0); > B: in unsigned(7 downto 0); > C: out unsigned(7 downto 0) > ); > end entity bin2gray; > -- Gray encoder. If you notice the generated VHDL uses a library, pck_myhdl_07. This is an additional VHDL file that is generated with the conversion. You need to include this file (pck_myhdl07.vhd) in your synthesis tools. If it looks like the file did not generate correctly, delete the pck_myhdl_07 and rerun the conversion. If you have to do this let use know. Hope that helps, Chris |
|
From: Norbo <Nor...@gm...> - 2011-11-20 16:19:33
|
On Sun, 20 Nov 2011 15:37:29 +0100, Christopher Felton
<chr...@gm...> wrote:
> On 11/19/11 4:22 PM, Norbo wrote:
>> I have played a bit with myhdl and created the following:
> [snip]
>> --------------------------------------------------
>> -- File: bin2gray.vhd
>> -- Generated by MyHDL 0.7
>> -- Date: Sat Nov 19 22:54:16 2011
>>
>>
>> library IEEE;
>> use IEEE.std_logic_1164.all;
>> use IEEE.numeric_std.all;
>> use std.textio.all;
>>
>> use work.pck_myhdl_07.all;
>>
>> entity bin2gray is
>> port (
>> A: in unsigned(7 downto 0);
>> B: in unsigned(7 downto 0);
>> C: out unsigned(7 downto 0)
>> );
>> end entity bin2gray;
>> -- Gray encoder.
>
> If you notice the generated VHDL uses a library, pck_myhdl_07. This is
> an additional VHDL file that is generated with the conversion. You need
> to include this file (pck_myhdl07.vhd) in your synthesis tools.
>
> If it looks like the file did not generate correctly, delete the
> pck_myhdl_07 and rerun the conversion. If you have to do this let use
> know.
>
> Hope that helps,
> Chris
>
>
I deleted the file (pck_myhdl07.vhd) and it successfully regenerated,
after including this file
in the synthesis tool (lattice diamond) i had the same error (No matching
overload for to_std_logic). There seems to be no function to_std_logic in
the (pck_myhdl07.vhd).
The only "to_std_logic" functions in the generated pck_myhdl07.vhd pack
are:
function to_std_logic (arg: boolean) return std_logic;
function to_std_logic (arg: integer) return std_logic;
an version which takes an unsigned is missing. I also couldn't find such
an version of the "to_std_logic" function in the ieee library s
greetings,
Norbert
|
|
From: Oscar D. <osc...@gm...> - 2011-11-21 14:52:38
|
2011/11/19 Norbo <Nor...@gm...>: > I have played a bit with myhdl and created the following: > > ---------------------------------------------------------- > from myhdl import * > > def bin2gray(A,B, C, width): > > """ Gray encoder. > > B -- input intbv signal, binary encoded > G -- output intbv signal, gray encoded > width -- bit width > > """ > @always_comb > def logic(): > C[0].next = A + B It seems that you have a bug here. Why you assign the result of a sum to a single bit? that's the reason why the converter tried to use "to_std_logic" for the output. If you want a normal sum, it should be C.next = A + B and the VHDL converter will put synthesizable code: C <= (A + B); Or, if you want a binary to gray encoder, just use the example from the documentation http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design Best Regards -- Oscar Díaz Key Fingerprint = 904B 306C C3C2 7487 650B BFAC EDA2 B702 90E9 9964 gpg --keyserver subkeys.pgp.net --recv-keys 90E99964 I recommend using OpenDocument Format for daily use and exchange of documents. http://www.fsf.org/campaigns/opendocument |
|
From: Christopher F. <chr...@gm...> - 2011-11-21 16:28:39
|
On 11/21/2011 8:52 AM, Oscar Diaz wrote: > 2011/11/19 Norbo<Nor...@gm...>: >> I have played a bit with myhdl and created the following: >> >> ---------------------------------------------------------- >> from myhdl import * >> >> def bin2gray(A,B, C, width): >> >> """ Gray encoder. >> >> B -- input intbv signal, binary encoded >> G -- output intbv signal, gray encoded >> width -- bit width >> >> """ >> @always_comb >> def logic(): >> C[0].next = A + B > > It seems that you have a bug here. Why you assign the result of a sum > to a single bit? that's the reason why the converter tried to use > "to_std_logic" for the output. If you want a normal sum, it should be > > C.next = A + B > > and the VHDL converter will put synthesizable code: > > C<= (A + B); > Good eye Oscar! Yes, there are a couple issues with the bin2gray that was provided (I assumed the bin2gray was an example for conversion means and not an actual bin2gray?). I didn't notice at first glance but if you want to assign a single bit of a bit-vector you need to do: C.next[0] = A + B If you assign the bit correctly the conversion works (even though it functional doesn't work). Simulation will not work!. Not sure why the converter didn't flag this? Possible error detection enhancement. Also using the "+" operator instead of the bitwise "^" will cause problems in simulation. The "+" will overflow the range for a single bit. My previous reply can be ignored and should be ignored. If any changes need to be made they would be in the error catching/reporting and not modifications to the conversion. Regards, Chris > Or, if you want a binary to gray encoder, just use the example from > the documentation > > http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design > > > Best Regards > |
|
From: Norbo <Nor...@gm...> - 2011-11-22 21:15:31
|
On Mon, 21 Nov 2011 17:28:05 +0100, Christopher Felton <chr...@gm...> wrote: > On 11/21/2011 8:52 AM, Oscar Diaz wrote: >> 2011/11/19 Norbo<Nor...@gm...>: >>> I have played a bit with myhdl and created the following: >>> >>> ---------------------------------------------------------- >>> from myhdl import * >>> >>> def bin2gray(A,B, C, width): >>> >>> """ Gray encoder. >>> >>> B -- input intbv signal, binary encoded >>> G -- output intbv signal, gray encoded >>> width -- bit width >>> >>> """ >>> @always_comb >>> def logic(): >>> C[0].next = A + B >> >> It seems that you have a bug here. Why you assign the result of a sum >> to a single bit? that's the reason why the converter tried to use >> "to_std_logic" for the output. If you want a normal sum, it should be >> >> C.next = A + B >> >> and the VHDL converter will put synthesizable code: >> >> C<= (A + B); >> > > Good eye Oscar! > > Yes, there are a couple issues with the bin2gray that was provided (I > assumed the bin2gray was an example for conversion means and not an > actual bin2gray?). I didn't notice at first glance but if you want to > assign a single bit of a bit-vector you need to do: > > C.next[0] = A + B > > > If you assign the bit correctly the conversion works (even though it > functional doesn't work). Simulation will not work!. Not sure why the > converter didn't flag this? Possible error detection enhancement. > > Also using the "+" operator instead of the bitwise "^" will cause > problems in simulation. The "+" will overflow the range for a single > bit. > > My previous reply can be ignored and should be ignored. If any changes > need to be made they would be in the error catching/reporting and not > modifications to the conversion. > > Regards, > Chris > >> Or, if you want a binary to gray encoder, just use the example from >> the documentation >> >> http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design >> >> >> Best Regards >> Well the thing is: If i write: C[4:0].next = A+B in vhdl it gets -> C(4-1 downto 0) <= resize(A + B,4); or: C[1:0].next = A+B in vhdl it gets -> C(1-1 downto 0) <= resize(A + B,1); which in in my understanding this makes kind of sense because the result is cropped to the output size. (maybe a warning would be nice, but it could be difficult if the calculation gets longer) but when i write : C[0].next = A+B (which is actually the same as the above C[1:0].next = A+B) in vhdl it gets -> C(0) <= to_std_logic(A + B); and is not synthesisable. |
|
From: Christopher F. <chr...@gm...> - 2011-11-23 16:13:59
|
On 11/22/11 3:15 PM, Norbo wrote: > On Mon, 21 Nov 2011 17:28:05 +0100, Christopher Felton > <chr...@gm...> wrote: > >> On 11/21/2011 8:52 AM, Oscar Diaz wrote: >>> 2011/11/19 Norbo<Nor...@gm...>: >>>> I have played a bit with myhdl and created the following: >>>> >>>> ---------------------------------------------------------- >>>> from myhdl import * >>>> >>>> def bin2gray(A,B, C, width): >>>> >>>> """ Gray encoder. >>>> >>>> B -- input intbv signal, binary encoded >>>> G -- output intbv signal, gray encoded >>>> width -- bit width >>>> >>>> """ >>>> @always_comb >>>> def logic(): >>>> C[0].next = A + B >>> >>> It seems that you have a bug here. Why you assign the result of a sum >>> to a single bit? that's the reason why the converter tried to use >>> "to_std_logic" for the output. If you want a normal sum, it should be >>> >>> C.next = A + B >>> >>> and the VHDL converter will put synthesizable code: >>> >>> C<= (A + B); >>> >> >> Good eye Oscar! >> >> Yes, there are a couple issues with the bin2gray that was provided (I >> assumed the bin2gray was an example for conversion means and not an >> actual bin2gray?). I didn't notice at first glance but if you want to >> assign a single bit of a bit-vector you need to do: >> >> C.next[0] = A + B >> >> >> If you assign the bit correctly the conversion works (even though it >> functional doesn't work). Simulation will not work!. Not sure why the >> converter didn't flag this? Possible error detection enhancement. >> >> Also using the "+" operator instead of the bitwise "^" will cause >> problems in simulation. The "+" will overflow the range for a single >> bit. >> >> My previous reply can be ignored and should be ignored. If any changes >> need to be made they would be in the error catching/reporting and not >> modifications to the conversion. >> >> Regards, >> Chris >> >>> Or, if you want a binary to gray encoder, just use the example from >>> the documentation >>> >>> http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design >>> >>> >>> Best Regards >>> > > Well the thing is: > > If i write: > > C[4:0].next = A+B in vhdl it gets -> C(4-1 downto 0)<= resize(A + > B,4); > > or: > > C[1:0].next = A+B in vhdl it gets -> C(1-1 downto 0)<= resize(A + B,1); > which in in my understanding this makes kind of sense because the result > is cropped to the output size. (maybe a warning would be nice, but it > could be difficult if the calculation gets longer) > > > but when i write : > > C[0].next = A+B > (which is actually the same as the above C[1:0].next = A+B) > in vhdl it gets -> C(0)<= to_std_logic(A + B); > and is not synthesisable. > > As mentioned, the above is the incorrect syntax. The converted results are unreliable. To do bit indexing you need to do: C.next[0] = A[0] + B[1] If you do C[0].next that is used for a list of signals. If you run a simulation (testbench) this error will be identified. Review the following links: http://www.myhdl.org/doc/current/manual/intro.html#bit-indexing http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design Also, run a simple simulation. That will give you some more insight into the issue. Regards, Chris |
|
From: Norbo <Nor...@gm...> - 2011-11-30 11:48:34
|
On Wed, 23 Nov 2011 17:13:27 +0100, Christopher Felton <chr...@gm...> wrote: > On 11/22/11 3:15 PM, Norbo wrote: >> On Mon, 21 Nov 2011 17:28:05 +0100, Christopher Felton >> <chr...@gm...> wrote: >> >>> On 11/21/2011 8:52 AM, Oscar Diaz wrote: >>>> 2011/11/19 Norbo<Nor...@gm...>: >>>>> I have played a bit with myhdl and created the following: >>>>> >>>>> ---------------------------------------------------------- >>>>> from myhdl import * >>>>> >>>>> def bin2gray(A,B, C, width): >>>>> >>>>> """ Gray encoder. >>>>> >>>>> B -- input intbv signal, binary encoded >>>>> G -- output intbv signal, gray encoded >>>>> width -- bit width >>>>> >>>>> """ >>>>> @always_comb >>>>> def logic(): >>>>> C[0].next = A + B >>>> >>>> It seems that you have a bug here. Why you assign the result of a sum >>>> to a single bit? that's the reason why the converter tried to use >>>> "to_std_logic" for the output. If you want a normal sum, it should be >>>> >>>> C.next = A + B >>>> >>>> and the VHDL converter will put synthesizable code: >>>> >>>> C<= (A + B); >>>> >>> >>> Good eye Oscar! >>> >>> Yes, there are a couple issues with the bin2gray that was provided (I >>> assumed the bin2gray was an example for conversion means and not an >>> actual bin2gray?). I didn't notice at first glance but if you want to >>> assign a single bit of a bit-vector you need to do: >>> >>> C.next[0] = A + B >>> >>> >>> If you assign the bit correctly the conversion works (even though it >>> functional doesn't work). Simulation will not work!. Not sure why the >>> converter didn't flag this? Possible error detection enhancement. >>> >>> Also using the "+" operator instead of the bitwise "^" will cause >>> problems in simulation. The "+" will overflow the range for a single >>> bit. >>> >>> My previous reply can be ignored and should be ignored. If any changes >>> need to be made they would be in the error catching/reporting and not >>> modifications to the conversion. >>> >>> Regards, >>> Chris >>> >>>> Or, if you want a binary to gray encoder, just use the example from >>>> the documentation >>>> >>>> http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design >>>> >>>> >>>> Best Regards >>>> >> >> Well the thing is: >> >> If i write: >> >> C[4:0].next = A+B in vhdl it gets -> C(4-1 downto 0)<= resize(A + >> B,4); >> >> or: >> >> C[1:0].next = A+B in vhdl it gets -> C(1-1 downto 0)<= resize(A + >> B,1); >> which in in my understanding this makes kind of sense because the >> result >> is cropped to the output size. (maybe a warning would be nice, but it >> could be difficult if the calculation gets longer) >> >> >> but when i write : >> >> C[0].next = A+B >> (which is actually the same as the above C[1:0].next = A+B) >> in vhdl it gets -> C(0)<= to_std_logic(A + B); >> and is not synthesisable. >> >> > > As mentioned, the above is the incorrect syntax. The converted results > are unreliable. To do bit indexing you need to do: > > C.next[0] = A[0] + B[1] > > If you do C[0].next that is used for a list of signals. If you run a > simulation (testbench) this error will be identified. > > Review the following links: > http://www.myhdl.org/doc/current/manual/intro.html#bit-indexing > http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design > > Also, run a simple simulation. That will give you some more insight > into the issue. > > Regards, > Chris Sorry that i keep bagging, i really like myhdl and i really want to get it better so if i write: C.next[0] = A[0] + B[1] the line which is produced is: C(0) <= to_std_logic(to_unsigned(A(0), 1) + to_unsigned(B(0), 1)); and it is not synthesisable because of the to_std_logic. wheras: C.next[1:0] = A[0] + B[1] gets: C(1-1 downto 0) <= (to_unsigned(A(0), 1) + to_unsigned(B(1), 1)); and is synthesisable. thanks in advance |
|
From: Christopher F. <chr...@gm...> - 2011-11-30 12:39:57
|
On 11/30/11 5:48 AM, Norbo wrote: > On Wed, 23 Nov 2011 17:13:27 +0100, Christopher Felton > <chr...@gm...> wrote: > >> On 11/22/11 3:15 PM, Norbo wrote: >>> On Mon, 21 Nov 2011 17:28:05 +0100, Christopher Felton >>> <chr...@gm...> wrote: >>> >>>> On 11/21/2011 8:52 AM, Oscar Diaz wrote: >>>>> 2011/11/19 Norbo<Nor...@gm...>: >>>>>> I have played a bit with myhdl and created the following: >>>>>> >>>>>> ---------------------------------------------------------- >>>>>> from myhdl import * >>>>>> >>>>>> def bin2gray(A,B, C, width): >>>>>> >>>>>> """ Gray encoder. >>>>>> >>>>>> B -- input intbv signal, binary encoded >>>>>> G -- output intbv signal, gray encoded >>>>>> width -- bit width >>>>>> >>>>>> """ >>>>>> @always_comb >>>>>> def logic(): >>>>>> C[0].next = A + B >>>>> >>>>> It seems that you have a bug here. Why you assign the result of a sum >>>>> to a single bit? that's the reason why the converter tried to use >>>>> "to_std_logic" for the output. If you want a normal sum, it should be >>>>> >>>>> C.next = A + B >>>>> >>>>> and the VHDL converter will put synthesizable code: >>>>> >>>>> C<= (A + B); >>>>> >>>> >>>> Good eye Oscar! >>>> >>>> Yes, there are a couple issues with the bin2gray that was provided (I >>>> assumed the bin2gray was an example for conversion means and not an >>>> actual bin2gray?). I didn't notice at first glance but if you want to >>>> assign a single bit of a bit-vector you need to do: >>>> >>>> C.next[0] = A + B >>>> >>>> >>>> If you assign the bit correctly the conversion works (even though it >>>> functional doesn't work). Simulation will not work!. Not sure why the >>>> converter didn't flag this? Possible error detection enhancement. >>>> >>>> Also using the "+" operator instead of the bitwise "^" will cause >>>> problems in simulation. The "+" will overflow the range for a single >>>> bit. >>>> >>>> My previous reply can be ignored and should be ignored. If any changes >>>> need to be made they would be in the error catching/reporting and not >>>> modifications to the conversion. >>>> >>>> Regards, >>>> Chris >>>> >>>>> Or, if you want a binary to gray encoder, just use the example from >>>>> the documentation >>>>> >>>>> http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design >>>>> >>>>> >>>>> Best Regards >>>>> >>> >>> Well the thing is: >>> >>> If i write: >>> >>> C[4:0].next = A+B in vhdl it gets -> C(4-1 downto 0)<= resize(A + >>> B,4); >>> >>> or: >>> >>> C[1:0].next = A+B in vhdl it gets -> C(1-1 downto 0)<= resize(A + >>> B,1); >>> which in in my understanding this makes kind of sense because the >>> result >>> is cropped to the output size. (maybe a warning would be nice, but it >>> could be difficult if the calculation gets longer) >>> >>> >>> but when i write : >>> >>> C[0].next = A+B >>> (which is actually the same as the above C[1:0].next = A+B) >>> in vhdl it gets -> C(0)<= to_std_logic(A + B); >>> and is not synthesisable. >>> >>> >> >> As mentioned, the above is the incorrect syntax. The converted results >> are unreliable. To do bit indexing you need to do: >> >> C.next[0] = A[0] + B[1] >> >> If you do C[0].next that is used for a list of signals. If you run a >> simulation (testbench) this error will be identified. >> >> Review the following links: >> http://www.myhdl.org/doc/current/manual/intro.html#bit-indexing >> http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design >> >> Also, run a simple simulation. That will give you some more insight >> into the issue. >> >> Regards, >> Chris > > Sorry that i keep bagging, i really like myhdl and i really want to get it > better > so if i write: > > C.next[0] = A[0] + B[1] > > the line which is produced is: > > C(0)<= to_std_logic(to_unsigned(A(0), 1) + to_unsigned(B(0), 1)); > > and it is not synthesisable because of the to_std_logic. Correct, the conversion generated an equivilant assignment. Which is not synthesizable (it is syntactically correct and will compile with a VHDL simulator). But the two statements are equivalent. If you run a MyHDL simulation you will get more insight. As previously mentioned the example is not functionally correct. The synthesis tools will catch this, especially VHDL because it is strongly typed. > > > wheras: > C.next[1:0] = A[0] + B[1] > > gets: > C(1-1 downto 0)<= (to_unsigned(A(0), 1) + to_unsigned(B(1), 1)); > and is synthesisable. > This one works because you provided enough bits for the result. As mentioned, the MyHDL simulation would flag the error. Verifying your module is a simple task. You should have test code that verifies your logic before trying conversion! .chris > > thanks in advance > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d |
|
From: Norbo <Nor...@gm...> - 2011-11-30 15:53:13
|
On Wed, 30 Nov 2011 13:39:25 +0100, Christopher Felton <chr...@gm...> wrote: > On 11/30/11 5:48 AM, Norbo wrote: >> On Wed, 23 Nov 2011 17:13:27 +0100, Christopher Felton >> <chr...@gm...> wrote: >> >>> On 11/22/11 3:15 PM, Norbo wrote: >>>> On Mon, 21 Nov 2011 17:28:05 +0100, Christopher Felton >>>> <chr...@gm...> wrote: >>>> >>>>> On 11/21/2011 8:52 AM, Oscar Diaz wrote: >>>>>> 2011/11/19 Norbo<Nor...@gm...>: >>>>>>> I have played a bit with myhdl and created the following: >>>>>>> >>>>>>> ---------------------------------------------------------- >>>>>>> from myhdl import * >>>>>>> >>>>>>> def bin2gray(A,B, C, width): >>>>>>> >>>>>>> """ Gray encoder. >>>>>>> >>>>>>> B -- input intbv signal, binary encoded >>>>>>> G -- output intbv signal, gray encoded >>>>>>> width -- bit width >>>>>>> >>>>>>> """ >>>>>>> @always_comb >>>>>>> def logic(): >>>>>>> C[0].next = A + B >>>>>> >>>>>> It seems that you have a bug here. Why you assign the result of a >>>>>> sum >>>>>> to a single bit? that's the reason why the converter tried to use >>>>>> "to_std_logic" for the output. If you want a normal sum, it should >>>>>> be >>>>>> >>>>>> C.next = A + B >>>>>> >>>>>> and the VHDL converter will put synthesizable code: >>>>>> >>>>>> C<= (A + B); >>>>>> >>>>> >>>>> Good eye Oscar! >>>>> >>>>> Yes, there are a couple issues with the bin2gray that was provided (I >>>>> assumed the bin2gray was an example for conversion means and not an >>>>> actual bin2gray?). I didn't notice at first glance but if you want >>>>> to >>>>> assign a single bit of a bit-vector you need to do: >>>>> >>>>> C.next[0] = A + B >>>>> >>>>> >>>>> If you assign the bit correctly the conversion works (even though it >>>>> functional doesn't work). Simulation will not work!. Not sure why >>>>> the >>>>> converter didn't flag this? Possible error detection enhancement. >>>>> >>>>> Also using the "+" operator instead of the bitwise "^" will cause >>>>> problems in simulation. The "+" will overflow the range for a single >>>>> bit. >>>>> >>>>> My previous reply can be ignored and should be ignored. If any >>>>> changes >>>>> need to be made they would be in the error catching/reporting and not >>>>> modifications to the conversion. >>>>> >>>>> Regards, >>>>> Chris >>>>> >>>>>> Or, if you want a binary to gray encoder, just use the example from >>>>>> the documentation >>>>>> >>>>>> http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design >>>>>> >>>>>> >>>>>> Best Regards >>>>>> >>>> >>>> Well the thing is: >>>> >>>> If i write: >>>> >>>> C[4:0].next = A+B in vhdl it gets -> C(4-1 downto 0)<= resize(A >>>> + >>>> B,4); >>>> >>>> or: >>>> >>>> C[1:0].next = A+B in vhdl it gets -> C(1-1 downto 0)<= resize(A + >>>> B,1); >>>> which in in my understanding this makes kind of sense because the >>>> result >>>> is cropped to the output size. (maybe a warning would be nice, but it >>>> could be difficult if the calculation gets longer) >>>> >>>> >>>> but when i write : >>>> >>>> C[0].next = A+B >>>> (which is actually the same as the above C[1:0].next = A+B) >>>> in vhdl it gets -> C(0)<= to_std_logic(A + B); >>>> and is not synthesisable. >>>> >>>> >>> >>> As mentioned, the above is the incorrect syntax. The converted results >>> are unreliable. To do bit indexing you need to do: >>> >>> C.next[0] = A[0] + B[1] >>> >>> If you do C[0].next that is used for a list of signals. If you run a >>> simulation (testbench) this error will be identified. >>> >>> Review the following links: >>> http://www.myhdl.org/doc/current/manual/intro.html#bit-indexing >>> http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design >>> >>> Also, run a simple simulation. That will give you some more insight >>> into the issue. >>> >>> Regards, >>> Chris >> >> Sorry that i keep bagging, i really like myhdl and i really want to get >> it >> better >> so if i write: >> >> C.next[0] = A[0] + B[1] >> >> the line which is produced is: >> >> C(0)<= to_std_logic(to_unsigned(A(0), 1) + to_unsigned(B(0), 1)); >> >> and it is not synthesisable because of the to_std_logic. > > Correct, the conversion generated an equivilant assignment. Which is > not synthesizable (it is syntactically correct and will compile with a > VHDL simulator). But the two statements are equivalent. If you run a > MyHDL simulation you will get more insight. > > As previously mentioned the example is not functionally correct. The > synthesis tools will catch this, especially VHDL because it is strongly > typed. > >> >> >> wheras: >> C.next[1:0] = A[0] + B[1] >> >> gets: >> C(1-1 downto 0)<= (to_unsigned(A(0), 1) + to_unsigned(B(1), 1)); >> and is synthesisable. >> > > This one works because you provided enough bits for the result. As > mentioned, the MyHDL simulation would flag the error. Verifying your > module is a simple task. You should have test code that verifies your > logic before trying conversion! > > > .chris Case1: C.next[1:0] = A[0] + B[1] Case2: C.next[0] = A[0] + B[1] Documentation says: The Python convention of half-open ranges is followed: the bit with the highest index is not included (by the way in the documatation on the page 89 in the table there seems to be an error bv[i:j] => slice of bv from i downto j -----> should be changed to bv[i:j] => slice of bv from i-1 downto j ) The result intbv has the same length in both cases. And numberic_std library says: function "+" (L, R: UNSIGNED) return UNSIGNED => "plus"; -- Result subtype: UNSIGNED(MAX(L'LENGTH, R'LENGTH)-1 downto 0). so the result length of an addition of two unsigned has the same length as the longest of the both operators and the result type is a subtype of unsigned. greetings -- Using Opera's revolutionary email client: http://www.opera.com/mail/ |
|
From: Christopher F. <chr...@gm...> - 2011-12-03 18:40:02
|
On 11/30/11 9:52 AM, Norbo wrote: > On Wed, 30 Nov 2011 13:39:25 +0100, Christopher Felton > <chr...@gm...> wrote: > >> On 11/30/11 5:48 AM, Norbo wrote: >>> On Wed, 23 Nov 2011 17:13:27 +0100, Christopher Felton >>> <chr...@gm...> wrote: >>> >>>> On 11/22/11 3:15 PM, Norbo wrote: >>>>> On Mon, 21 Nov 2011 17:28:05 +0100, Christopher Felton >>>>> <chr...@gm...> wrote: >>>>> >>>>>> On 11/21/2011 8:52 AM, Oscar Diaz wrote: >>>>>>> 2011/11/19 Norbo<Nor...@gm...>: >>>>>>>> I have played a bit with myhdl and created the following: >>>>>>>> >>>>>>>> ---------------------------------------------------------- >>>>>>>> from myhdl import * >>>>>>>> >>>>>>>> def bin2gray(A,B, C, width): >>>>>>>> >>>>>>>> """ Gray encoder. >>>>>>>> >>>>>>>> B -- input intbv signal, binary encoded >>>>>>>> G -- output intbv signal, gray encoded >>>>>>>> width -- bit width >>>>>>>> >>>>>>>> """ >>>>>>>> @always_comb >>>>>>>> def logic(): >>>>>>>> C[0].next = A + B >>>>>>> >>>>>>> It seems that you have a bug here. Why you assign the result of a >>>>>>> sum >>>>>>> to a single bit? that's the reason why the converter tried to use >>>>>>> "to_std_logic" for the output. If you want a normal sum, it should >>>>>>> be >>>>>>> >>>>>>> C.next = A + B >>>>>>> >>>>>>> and the VHDL converter will put synthesizable code: >>>>>>> >>>>>>> C<= (A + B); >>>>>>> >>>>>> >>>>>> Good eye Oscar! >>>>>> >>>>>> Yes, there are a couple issues with the bin2gray that was provided (I >>>>>> assumed the bin2gray was an example for conversion means and not an >>>>>> actual bin2gray?). I didn't notice at first glance but if you want >>>>>> to >>>>>> assign a single bit of a bit-vector you need to do: >>>>>> >>>>>> C.next[0] = A + B >>>>>> >>>>>> >>>>>> If you assign the bit correctly the conversion works (even though it >>>>>> functional doesn't work). Simulation will not work!. Not sure why >>>>>> the >>>>>> converter didn't flag this? Possible error detection enhancement. >>>>>> >>>>>> Also using the "+" operator instead of the bitwise "^" will cause >>>>>> problems in simulation. The "+" will overflow the range for a single >>>>>> bit. >>>>>> >>>>>> My previous reply can be ignored and should be ignored. If any >>>>>> changes >>>>>> need to be made they would be in the error catching/reporting and not >>>>>> modifications to the conversion. >>>>>> >>>>>> Regards, >>>>>> Chris >>>>>> >>>>>>> Or, if you want a binary to gray encoder, just use the example from >>>>>>> the documentation >>>>>>> >>>>>>> http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design >>>>>>> >>>>>>> >>>>>>> Best Regards >>>>>>> >>>>> >>>>> Well the thing is: >>>>> >>>>> If i write: >>>>> >>>>> C[4:0].next = A+B in vhdl it gets -> C(4-1 downto 0)<= resize(A >>>>> + >>>>> B,4); >>>>> >>>>> or: >>>>> >>>>> C[1:0].next = A+B in vhdl it gets -> C(1-1 downto 0)<= resize(A + >>>>> B,1); >>>>> which in in my understanding this makes kind of sense because the >>>>> result >>>>> is cropped to the output size. (maybe a warning would be nice, but it >>>>> could be difficult if the calculation gets longer) >>>>> >>>>> >>>>> but when i write : >>>>> >>>>> C[0].next = A+B >>>>> (which is actually the same as the above C[1:0].next = A+B) >>>>> in vhdl it gets -> C(0)<= to_std_logic(A + B); >>>>> and is not synthesisable. >>>>> >>>>> >>>> >>>> As mentioned, the above is the incorrect syntax. The converted results >>>> are unreliable. To do bit indexing you need to do: >>>> >>>> C.next[0] = A[0] + B[1] >>>> >>>> If you do C[0].next that is used for a list of signals. If you run a >>>> simulation (testbench) this error will be identified. >>>> >>>> Review the following links: >>>> http://www.myhdl.org/doc/current/manual/intro.html#bit-indexing >>>> http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design >>>> >>>> Also, run a simple simulation. That will give you some more insight >>>> into the issue. >>>> >>>> Regards, >>>> Chris >>> >>> Sorry that i keep bagging, i really like myhdl and i really want to get >>> it >>> better >>> so if i write: >>> >>> C.next[0] = A[0] + B[1] >>> >>> the line which is produced is: >>> >>> C(0)<= to_std_logic(to_unsigned(A(0), 1) + to_unsigned(B(0), 1)); >>> >>> and it is not synthesisable because of the to_std_logic. >> >> Correct, the conversion generated an equivilant assignment. Which is >> not synthesizable (it is syntactically correct and will compile with a >> VHDL simulator). But the two statements are equivalent. If you run a >> MyHDL simulation you will get more insight. >> >> As previously mentioned the example is not functionally correct. The >> synthesis tools will catch this, especially VHDL because it is strongly >> typed. >> >>> >>> >>> wheras: >>> C.next[1:0] = A[0] + B[1] >>> >>> gets: >>> C(1-1 downto 0)<= (to_unsigned(A(0), 1) + to_unsigned(B(1), 1)); >>> and is synthesisable. >>> >> >> This one works because you provided enough bits for the result. As >> mentioned, the MyHDL simulation would flag the error. Verifying your >> module is a simple task. You should have test code that verifies your >> logic before trying conversion! >> >> >> .chris > > > Case1: > > C.next[1:0] = A[0] + B[1] > > Case2: > > C.next[0] = A[0] + B[1] > > Documentation says: > The Python convention of half-open ranges is followed: the bit with the > highest index is not included > (by the way in the documatation on the page 89 in the table there seems to > be an error > bv[i:j] => slice of bv from i downto j -----> should be changed to > bv[i:j] => slice of bv from i-1 downto j ) > > > The result intbv has the same length in both cases. And numberic_std > library says: > > function "+" (L, R: UNSIGNED) return UNSIGNED => "plus"; > -- Result subtype: UNSIGNED(MAX(L'LENGTH, R'LENGTH)-1 downto 0). > > so the result length of an addition of two unsigned has the same length as > the longest of the both operators and > the result type is a subtype of unsigned. > > greetings > > Let's backup a little. I think you have identified some areas for improvement but I don't think you have discovered something fundamentally broken. I believe your goal is to become more familiar with MyHDL and while trying it out you have found some items that you would like some clarification, correct? A couple examples might help. Your original and subsequent post had to do with bit assignments to an intbv. We can create examples for the bitwise operators and the numerical operators, run a simulation, and see what happens. And remove confusion by not using a module name that implies some functionality we are not trying to implement. ~~~[Code Example]~~~ from myhdl import * import traceback import sys def TryBitAssignXorOperator(a,b,c): @always_comb def hdl_assign(): c.next[0] = a[0] ^ b[0] return hdl_assign def TryBitAssignAddOperator(a,b,c): @always_comb def hdl_assign(): c.next[0] = a[0] + b[0] return hdl_assign def test(): Nbits = 3 a = Signal(intbv(0)[Nbits:]) b = Signal(intbv(0)[Nbits:]) c_xor = Signal(intbv(0)[Nbits:]) c_add = Signal(intbv(0)[Nbits:]) d_xor = TryBitAssignXorOperator(a,b,c_xor) d_add = TryBitAssignAddOperator(a,b,c_add) @instance def tb_stimulus(): for ii in xrange(2**Nbits): for jj in xrange(2**Nbits): a.next = ii b.next = jj yield delay(1) print("a:%s b:%s c_xor:%s c_add:%s" % \ (bin(a,Nbits), bin(b,Nbits), bin(c_xor,Nbits), bin(c_add,Nbits))) raise StopSimulation return d_xor, d_add, tb_stimulus if __name__ == '__main__': Simulation(test()).run() ~~~[End Code Example]~~~ ~~~[Output]~~~ a:000 b:000 c_xor:000 c_add:000 a:000 b:001 c_xor:001 c_add:001 a:000 b:010 c_xor:000 c_add:000 a:000 b:011 c_xor:001 c_add:001 a:000 b:100 c_xor:000 c_add:000 a:000 b:101 c_xor:001 c_add:001 a:000 b:110 c_xor:000 c_add:000 a:000 b:111 c_xor:001 c_add:001 a:001 b:000 c_xor:001 c_add:001 ... python2.7/site-packages/myhdl/_intbv.py", line 183, in __setitem__ " i == %s " % i ValueError: intbv[i] = v requires v in (0, 1) i == 0 ~~~[End Output]~~~ In this example you see that it fails the *add* when "a" and "b" are 1 (it doesn't print out a:001 b:001 because the exception occurs as soon as the assignment happens)! This is because the result of an intbv 1+1 requires two bits. An intbv is a constraint integer, it works more like VHDL signed/unsigned and not like std_logic_vector or Verilog's wire/reg. You can't do a single bit assignment to a value that requires more than 1 bit. It is my guess that the conversion doesn't handle this error case better because, usually, simulation is run and the error would be flagged in simulation. Hence, there has been no need to convert code like your example. What we can do is create an enhancement proposal that outlines a set of bit assign tests to extend to the conversion regression tests and specify useful error messages to be thrown if invalid conversion is attempted. I don't think this was the goal of your inquiry (was it?). But rather to get some more experience with MyHDL. In summary, what you are trying to do is invalid. Simulation will flag this correctly. Hope this helps, Chris |
|
From: Norbo <Nor...@gm...> - 2011-12-06 14:12:57
|
On Sat, 03 Dec 2011 19:39:26 +0100, Christopher Felton <chr...@gm...> wrote: > On 11/30/11 9:52 AM, Norbo wrote: >> On Wed, 30 Nov 2011 13:39:25 +0100, Christopher Felton >> <chr...@gm...> wrote: >> >>> On 11/30/11 5:48 AM, Norbo wrote: >>>> On Wed, 23 Nov 2011 17:13:27 +0100, Christopher Felton >>>> <chr...@gm...> wrote: >>>> >>>>> On 11/22/11 3:15 PM, Norbo wrote: >>>>>> On Mon, 21 Nov 2011 17:28:05 +0100, Christopher Felton >>>>>> <chr...@gm...> wrote: >>>>>> >>>>>>> On 11/21/2011 8:52 AM, Oscar Diaz wrote: >>>>>>>> 2011/11/19 Norbo<Nor...@gm...>: >>>>>>>>> I have played a bit with myhdl and created the following: >>>>>>>>> >>>>>>>>> ---------------------------------------------------------- >>>>>>>>> from myhdl import * >>>>>>>>> >>>>>>>>> def bin2gray(A,B, C, width): >>>>>>>>> >>>>>>>>> """ Gray encoder. >>>>>>>>> >>>>>>>>> B -- input intbv signal, binary encoded >>>>>>>>> G -- output intbv signal, gray encoded >>>>>>>>> width -- bit width >>>>>>>>> >>>>>>>>> """ >>>>>>>>> @always_comb >>>>>>>>> def logic(): >>>>>>>>> C[0].next = A + B >>>>>>>> >>>>>>>> It seems that you have a bug here. Why you assign the result of a >>>>>>>> sum >>>>>>>> to a single bit? that's the reason why the converter tried to use >>>>>>>> "to_std_logic" for the output. If you want a normal sum, it should >>>>>>>> be >>>>>>>> >>>>>>>> C.next = A + B >>>>>>>> >>>>>>>> and the VHDL converter will put synthesizable code: >>>>>>>> >>>>>>>> C<= (A + B); >>>>>>>> >>>>>>> >>>>>>> Good eye Oscar! >>>>>>> >>>>>>> Yes, there are a couple issues with the bin2gray that was provided >>>>>>> (I >>>>>>> assumed the bin2gray was an example for conversion means and not an >>>>>>> actual bin2gray?). I didn't notice at first glance but if you want >>>>>>> to >>>>>>> assign a single bit of a bit-vector you need to do: >>>>>>> >>>>>>> C.next[0] = A + B >>>>>>> >>>>>>> >>>>>>> If you assign the bit correctly the conversion works (even though >>>>>>> it >>>>>>> functional doesn't work). Simulation will not work!. Not sure why >>>>>>> the >>>>>>> converter didn't flag this? Possible error detection enhancement. >>>>>>> >>>>>>> Also using the "+" operator instead of the bitwise "^" will cause >>>>>>> problems in simulation. The "+" will overflow the range for a >>>>>>> single >>>>>>> bit. >>>>>>> >>>>>>> My previous reply can be ignored and should be ignored. If any >>>>>>> changes >>>>>>> need to be made they would be in the error catching/reporting and >>>>>>> not >>>>>>> modifications to the conversion. >>>>>>> >>>>>>> Regards, >>>>>>> Chris >>>>>>> >>>>>>>> Or, if you want a binary to gray encoder, just use the example >>>>>>>> from >>>>>>>> the documentation >>>>>>>> >>>>>>>> http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design >>>>>>>> >>>>>>>> >>>>>>>> Best Regards >>>>>>>> >>>>>> >>>>>> Well the thing is: >>>>>> >>>>>> If i write: >>>>>> >>>>>> C[4:0].next = A+B in vhdl it gets -> C(4-1 downto 0)<= >>>>>> resize(A >>>>>> + >>>>>> B,4); >>>>>> >>>>>> or: >>>>>> >>>>>> C[1:0].next = A+B in vhdl it gets -> C(1-1 downto 0)<= >>>>>> resize(A + >>>>>> B,1); >>>>>> which in in my understanding this makes kind of sense because the >>>>>> result >>>>>> is cropped to the output size. (maybe a warning would be nice, but >>>>>> it >>>>>> could be difficult if the calculation gets longer) >>>>>> >>>>>> >>>>>> but when i write : >>>>>> >>>>>> C[0].next = A+B >>>>>> (which is actually the same as the above C[1:0].next = A+B) >>>>>> in vhdl it gets -> C(0)<= to_std_logic(A + B); >>>>>> and is not synthesisable. >>>>>> >>>>>> >>>>> >>>>> As mentioned, the above is the incorrect syntax. The converted >>>>> results >>>>> are unreliable. To do bit indexing you need to do: >>>>> >>>>> C.next[0] = A[0] + B[1] >>>>> >>>>> If you do C[0].next that is used for a list of signals. If you run a >>>>> simulation (testbench) this error will be identified. >>>>> >>>>> Review the following links: >>>>> http://www.myhdl.org/doc/current/manual/intro.html#bit-indexing >>>>> http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design >>>>> >>>>> Also, run a simple simulation. That will give you some more insight >>>>> into the issue. >>>>> >>>>> Regards, >>>>> Chris >>>> >>>> Sorry that i keep bagging, i really like myhdl and i really want to >>>> get >>>> it >>>> better >>>> so if i write: >>>> >>>> C.next[0] = A[0] + B[1] >>>> >>>> the line which is produced is: >>>> >>>> C(0)<= to_std_logic(to_unsigned(A(0), 1) + to_unsigned(B(0), 1)); >>>> >>>> and it is not synthesisable because of the to_std_logic. >>> >>> Correct, the conversion generated an equivilant assignment. Which is >>> not synthesizable (it is syntactically correct and will compile with a >>> VHDL simulator). But the two statements are equivalent. If you run a >>> MyHDL simulation you will get more insight. >>> >>> As previously mentioned the example is not functionally correct. The >>> synthesis tools will catch this, especially VHDL because it is strongly >>> typed. >>> >>>> >>>> >>>> wheras: >>>> C.next[1:0] = A[0] + B[1] >>>> >>>> gets: >>>> C(1-1 downto 0)<= (to_unsigned(A(0), 1) + to_unsigned(B(1), 1)); >>>> and is synthesisable. >>>> >>> >>> This one works because you provided enough bits for the result. As >>> mentioned, the MyHDL simulation would flag the error. Verifying your >>> module is a simple task. You should have test code that verifies your >>> logic before trying conversion! >>> >>> >>> .chris >> >> >> Case1: >> >> C.next[1:0] = A[0] + B[1] >> >> Case2: >> >> C.next[0] = A[0] + B[1] >> >> Documentation says: >> The Python convention of half-open ranges is followed: the bit with the >> highest index is not included >> (by the way in the documatation on the page 89 in the table there seems >> to >> be an error >> bv[i:j] => slice of bv from i downto j -----> should be changed >> to >> bv[i:j] => slice of bv from i-1 downto j ) >> >> >> The result intbv has the same length in both cases. And numberic_std >> library says: >> >> function "+" (L, R: UNSIGNED) return UNSIGNED => "plus"; >> -- Result subtype: UNSIGNED(MAX(L'LENGTH, R'LENGTH)-1 downto 0). >> >> so the result length of an addition of two unsigned has the same length >> as >> the longest of the both operators and >> the result type is a subtype of unsigned. >> >> greetings >> >> > > Let's backup a little. I think you have identified some areas for > improvement but I don't think you have discovered something > fundamentally broken. I believe your goal is to become more familiar > with MyHDL and while trying it out you have found some items that you > would like some clarification, correct? > > A couple examples might help. Your original and subsequent post had to > do with bit assignments to an intbv. We can create examples for the > bitwise operators and the numerical operators, run a simulation, and see > what happens. And remove confusion by not using a module name that > implies some functionality we are not trying to implement. > > ~~~[Code Example]~~~ > from myhdl import * > import traceback > import sys > > def TryBitAssignXorOperator(a,b,c): > > @always_comb > def hdl_assign(): > c.next[0] = a[0] ^ b[0] > > return hdl_assign > > def TryBitAssignAddOperator(a,b,c): > > @always_comb > def hdl_assign(): > c.next[0] = a[0] + b[0] > > return hdl_assign > > def test(): > > Nbits = 3 > a = Signal(intbv(0)[Nbits:]) > b = Signal(intbv(0)[Nbits:]) > c_xor = Signal(intbv(0)[Nbits:]) > c_add = Signal(intbv(0)[Nbits:]) > > d_xor = TryBitAssignXorOperator(a,b,c_xor) > d_add = TryBitAssignAddOperator(a,b,c_add) > > @instance > def tb_stimulus(): > for ii in xrange(2**Nbits): > for jj in xrange(2**Nbits): > a.next = ii > b.next = jj > yield delay(1) > print("a:%s b:%s c_xor:%s c_add:%s" % \ > (bin(a,Nbits), bin(b,Nbits), > bin(c_xor,Nbits), > bin(c_add,Nbits))) > > > > raise StopSimulation > > return d_xor, d_add, tb_stimulus > > if __name__ == '__main__': > Simulation(test()).run() > > ~~~[End Code Example]~~~ > > ~~~[Output]~~~ > a:000 b:000 c_xor:000 c_add:000 > a:000 b:001 c_xor:001 c_add:001 > a:000 b:010 c_xor:000 c_add:000 > a:000 b:011 c_xor:001 c_add:001 > a:000 b:100 c_xor:000 c_add:000 > a:000 b:101 c_xor:001 c_add:001 > a:000 b:110 c_xor:000 c_add:000 > a:000 b:111 c_xor:001 c_add:001 > a:001 b:000 c_xor:001 c_add:001 > ... > python2.7/site-packages/myhdl/_intbv.py", line 183, in __setitem__ > " i == %s " % i > ValueError: intbv[i] = v requires v in (0, 1) > i == 0 > > ~~~[End Output]~~~ > > In this example you see that it fails the *add* when "a" and "b" are 1 > (it doesn't print out a:001 b:001 because the exception occurs as soon > as the assignment happens)! This is because the result of an intbv 1+1 > requires two bits. An intbv is a constraint integer, it works more like > VHDL signed/unsigned and not like std_logic_vector or Verilog's > wire/reg. You can't do a single bit assignment to a value that requires > more than 1 bit. > > It is my guess that the conversion doesn't handle this error case better > because, usually, simulation is run and the error would be flagged in > simulation. Hence, there has been no need to convert code like your > example. > > What we can do is create an enhancement proposal that outlines a set of > bit assign tests to extend to the conversion regression tests and > specify useful error messages to be thrown if invalid conversion is > attempted. I don't think this was the goal of your inquiry (was it?). > But rather to get some more experience with MyHDL. > > In summary, what you are trying to do is invalid. Simulation will flag > this correctly. > > Hope this helps, > Chris > Let's backup a little. I think you have identified some areas for > improvement but I don't think you have discovered something > fundamentally broken. I have too admit that even the title of this topic -> "conversion error to vhdl" is kind of rough, because we are all (at least in my case) taught in school, high school, whatever, that making an error is not so good. And even if you dont read the title consciously, your subconscious will put all the feelings and associations forward which are connected to it. Since some of them have been in school where we have been conditioned to errors such a title can have an enormous effect. For example making the reader think, that the writer think, that the reader have done something bad. But i think the only bad errors which are made, are made by people on purpose to hurt (in this or another way) someone. And the other errors, kind of must be there as a source of improvement or re-adjustment or whatsoever. So its about improvement. > I believe your goal is to become more familiar > with MyHDL true. Ok so what is about: c.next[0] = a[0] * b[0] <---- multiplikation instead of addition here the simulation runs successfully (100% testcoverage), and so the conversion no warning and no errors diplayed this gets converted to c(0) <= to_std_logic(to_unsigned(a(0), 1) * to_unsigned(b(0), 1)); which is not synthesisable. The thing about the simulation is that if you have a unit with a lot of inputs you cannot possible run all number of combinations on the input. If you have internal registers the thing gets even worse. So you can only get a Testcoverage below 100%, so there is the change to actually miss this case if you have an addition. Anyway it seem to be possible to get into a situation where the simulation will run successfully (lets say 99% coverage or in the case of the multiplikation even 100%), the conversion runs successfully, but the generated code is not synthesisable. I mean i like the fact that the bitwith of the operand of an addition is automatically enhanced to create an extra bit for the overflow bit if the code is generated in vhdl, but i think this should not necessarily include that if you want to reduce the bitwith of the result by giving a bitwith constraint to the result, that the conversion result is not valid. I think the easiest way to fix this is to just add a to_std_logic( a unsigned ) to the pck_myhdl_07.vhd generator code. But, maybe this has some other implications.? greetings Norbert |
|
From: Christopher F. <chr...@gm...> - 2011-12-08 12:19:46
|
On 12/6/11 8:12 AM, Norbo wrote: > On Sat, 03 Dec 2011 19:39:26 +0100, Christopher Felton > <chr...@gm...> wrote: > >> On 11/30/11 9:52 AM, Norbo wrote: >>> On Wed, 30 Nov 2011 13:39:25 +0100, Christopher Felton >>> <chr...@gm...> wrote: >>> >>>> On 11/30/11 5:48 AM, Norbo wrote: >>>>> On Wed, 23 Nov 2011 17:13:27 +0100, Christopher Felton >>>>> <chr...@gm...> wrote: >>>>> >>>>>> On 11/22/11 3:15 PM, Norbo wrote: >>>>>>> On Mon, 21 Nov 2011 17:28:05 +0100, Christopher Felton >>>>>>> <chr...@gm...> wrote: >>>>>>> >>>>>>>> On 11/21/2011 8:52 AM, Oscar Diaz wrote: >>>>>>>>> 2011/11/19 Norbo<Nor...@gm...>: >>>>>>>>>> I have played a bit with myhdl and created the following: >>>>>>>>>> >>>>>>>>>> ---------------------------------------------------------- >>>>>>>>>> from myhdl import * >>>>>>>>>> >>>>>>>>>> def bin2gray(A,B, C, width): >>>>>>>>>> >>>>>>>>>> """ Gray encoder. >>>>>>>>>> >>>>>>>>>> B -- input intbv signal, binary encoded >>>>>>>>>> G -- output intbv signal, gray encoded >>>>>>>>>> width -- bit width >>>>>>>>>> >>>>>>>>>> """ >>>>>>>>>> @always_comb >>>>>>>>>> def logic(): >>>>>>>>>> C[0].next = A + B >>>>>>>>> >>>>>>>>> It seems that you have a bug here. Why you assign the result of a >>>>>>>>> sum >>>>>>>>> to a single bit? that's the reason why the converter tried to use >>>>>>>>> "to_std_logic" for the output. If you want a normal sum, it should >>>>>>>>> be >>>>>>>>> >>>>>>>>> C.next = A + B >>>>>>>>> >>>>>>>>> and the VHDL converter will put synthesizable code: >>>>>>>>> >>>>>>>>> C<= (A + B); >>>>>>>>> >>>>>>>> >>>>>>>> Good eye Oscar! >>>>>>>> >>>>>>>> Yes, there are a couple issues with the bin2gray that was provided >>>>>>>> (I >>>>>>>> assumed the bin2gray was an example for conversion means and not an >>>>>>>> actual bin2gray?). I didn't notice at first glance but if you want >>>>>>>> to >>>>>>>> assign a single bit of a bit-vector you need to do: >>>>>>>> >>>>>>>> C.next[0] = A + B >>>>>>>> >>>>>>>> >>>>>>>> If you assign the bit correctly the conversion works (even though >>>>>>>> it >>>>>>>> functional doesn't work). Simulation will not work!. Not sure why >>>>>>>> the >>>>>>>> converter didn't flag this? Possible error detection enhancement. >>>>>>>> >>>>>>>> Also using the "+" operator instead of the bitwise "^" will cause >>>>>>>> problems in simulation. The "+" will overflow the range for a >>>>>>>> single >>>>>>>> bit. >>>>>>>> >>>>>>>> My previous reply can be ignored and should be ignored. If any >>>>>>>> changes >>>>>>>> need to be made they would be in the error catching/reporting and >>>>>>>> not >>>>>>>> modifications to the conversion. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Chris >>>>>>>> >>>>>>>>> Or, if you want a binary to gray encoder, just use the example >>>>>>>>> from >>>>>>>>> the documentation >>>>>>>>> >>>>>>>>> http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design >>>>>>>>> >>>>>>>>> >>>>>>>>> Best Regards >>>>>>>>> >>>>>>> >>>>>>> Well the thing is: >>>>>>> >>>>>>> If i write: >>>>>>> >>>>>>> C[4:0].next = A+B in vhdl it gets -> C(4-1 downto 0)<= >>>>>>> resize(A >>>>>>> + >>>>>>> B,4); >>>>>>> >>>>>>> or: >>>>>>> >>>>>>> C[1:0].next = A+B in vhdl it gets -> C(1-1 downto 0)<= >>>>>>> resize(A + >>>>>>> B,1); >>>>>>> which in in my understanding this makes kind of sense because the >>>>>>> result >>>>>>> is cropped to the output size. (maybe a warning would be nice, but >>>>>>> it >>>>>>> could be difficult if the calculation gets longer) >>>>>>> >>>>>>> >>>>>>> but when i write : >>>>>>> >>>>>>> C[0].next = A+B >>>>>>> (which is actually the same as the above C[1:0].next = A+B) >>>>>>> in vhdl it gets -> C(0)<= to_std_logic(A + B); >>>>>>> and is not synthesisable. >>>>>>> >>>>>>> >>>>>> >>>>>> As mentioned, the above is the incorrect syntax. The converted >>>>>> results >>>>>> are unreliable. To do bit indexing you need to do: >>>>>> >>>>>> C.next[0] = A[0] + B[1] >>>>>> >>>>>> If you do C[0].next that is used for a list of signals. If you run a >>>>>> simulation (testbench) this error will be identified. >>>>>> >>>>>> Review the following links: >>>>>> http://www.myhdl.org/doc/current/manual/intro.html#bit-indexing >>>>>> http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design >>>>>> >>>>>> Also, run a simple simulation. That will give you some more insight >>>>>> into the issue. >>>>>> >>>>>> Regards, >>>>>> Chris >>>>> >>>>> Sorry that i keep bagging, i really like myhdl and i really want to >>>>> get >>>>> it >>>>> better >>>>> so if i write: >>>>> >>>>> C.next[0] = A[0] + B[1] >>>>> >>>>> the line which is produced is: >>>>> >>>>> C(0)<= to_std_logic(to_unsigned(A(0), 1) + to_unsigned(B(0), 1)); >>>>> >>>>> and it is not synthesisable because of the to_std_logic. >>>> >>>> Correct, the conversion generated an equivilant assignment. Which is >>>> not synthesizable (it is syntactically correct and will compile with a >>>> VHDL simulator). But the two statements are equivalent. If you run a >>>> MyHDL simulation you will get more insight. >>>> >>>> As previously mentioned the example is not functionally correct. The >>>> synthesis tools will catch this, especially VHDL because it is strongly >>>> typed. >>>> >>>>> >>>>> >>>>> wheras: >>>>> C.next[1:0] = A[0] + B[1] >>>>> >>>>> gets: >>>>> C(1-1 downto 0)<= (to_unsigned(A(0), 1) + to_unsigned(B(1), 1)); >>>>> and is synthesisable. >>>>> >>>> >>>> This one works because you provided enough bits for the result. As >>>> mentioned, the MyHDL simulation would flag the error. Verifying your >>>> module is a simple task. You should have test code that verifies your >>>> logic before trying conversion! >>>> >>>> >>>> .chris >>> >>> >>> Case1: >>> >>> C.next[1:0] = A[0] + B[1] >>> >>> Case2: >>> >>> C.next[0] = A[0] + B[1] >>> >>> Documentation says: >>> The Python convention of half-open ranges is followed: the bit with the >>> highest index is not included >>> (by the way in the documatation on the page 89 in the table there seems >>> to >>> be an error >>> bv[i:j] => slice of bv from i downto j -----> should be changed >>> to >>> bv[i:j] => slice of bv from i-1 downto j ) >>> >>> >>> The result intbv has the same length in both cases. And numberic_std >>> library says: >>> >>> function "+" (L, R: UNSIGNED) return UNSIGNED => "plus"; >>> -- Result subtype: UNSIGNED(MAX(L'LENGTH, R'LENGTH)-1 downto 0). >>> >>> so the result length of an addition of two unsigned has the same length >>> as >>> the longest of the both operators and >>> the result type is a subtype of unsigned. >>> >>> greetings >>> >>> >> >> Let's backup a little. I think you have identified some areas for >> improvement but I don't think you have discovered something >> fundamentally broken. I believe your goal is to become more familiar >> with MyHDL and while trying it out you have found some items that you >> would like some clarification, correct? >> >> A couple examples might help. Your original and subsequent post had to >> do with bit assignments to an intbv. We can create examples for the >> bitwise operators and the numerical operators, run a simulation, and see >> what happens. And remove confusion by not using a module name that >> implies some functionality we are not trying to implement. >> >> ~~~[Code Example]~~~ >> from myhdl import * >> import traceback >> import sys >> >> def TryBitAssignXorOperator(a,b,c): >> >> @always_comb >> def hdl_assign(): >> c.next[0] = a[0] ^ b[0] >> >> return hdl_assign >> >> def TryBitAssignAddOperator(a,b,c): >> >> @always_comb >> def hdl_assign(): >> c.next[0] = a[0] + b[0] >> >> return hdl_assign >> >> def test(): >> >> Nbits = 3 >> a = Signal(intbv(0)[Nbits:]) >> b = Signal(intbv(0)[Nbits:]) >> c_xor = Signal(intbv(0)[Nbits:]) >> c_add = Signal(intbv(0)[Nbits:]) >> >> d_xor = TryBitAssignXorOperator(a,b,c_xor) >> d_add = TryBitAssignAddOperator(a,b,c_add) >> >> @instance >> def tb_stimulus(): >> for ii in xrange(2**Nbits): >> for jj in xrange(2**Nbits): >> a.next = ii >> b.next = jj >> yield delay(1) >> print("a:%s b:%s c_xor:%s c_add:%s" % \ >> (bin(a,Nbits), bin(b,Nbits), >> bin(c_xor,Nbits), >> bin(c_add,Nbits))) >> >> >> >> raise StopSimulation >> >> return d_xor, d_add, tb_stimulus >> >> if __name__ == '__main__': >> Simulation(test()).run() >> >> ~~~[End Code Example]~~~ >> >> ~~~[Output]~~~ >> a:000 b:000 c_xor:000 c_add:000 >> a:000 b:001 c_xor:001 c_add:001 >> a:000 b:010 c_xor:000 c_add:000 >> a:000 b:011 c_xor:001 c_add:001 >> a:000 b:100 c_xor:000 c_add:000 >> a:000 b:101 c_xor:001 c_add:001 >> a:000 b:110 c_xor:000 c_add:000 >> a:000 b:111 c_xor:001 c_add:001 >> a:001 b:000 c_xor:001 c_add:001 >> ... >> python2.7/site-packages/myhdl/_intbv.py", line 183, in __setitem__ >> " i == %s " % i >> ValueError: intbv[i] = v requires v in (0, 1) >> i == 0 >> >> ~~~[End Output]~~~ >> >> In this example you see that it fails the *add* when "a" and "b" are 1 >> (it doesn't print out a:001 b:001 because the exception occurs as soon >> as the assignment happens)! This is because the result of an intbv 1+1 >> requires two bits. An intbv is a constraint integer, it works more like >> VHDL signed/unsigned and not like std_logic_vector or Verilog's >> wire/reg. You can't do a single bit assignment to a value that requires >> more than 1 bit. >> >> It is my guess that the conversion doesn't handle this error case better >> because, usually, simulation is run and the error would be flagged in >> simulation. Hence, there has been no need to convert code like your >> example. >> >> What we can do is create an enhancement proposal that outlines a set of >> bit assign tests to extend to the conversion regression tests and >> specify useful error messages to be thrown if invalid conversion is >> attempted. I don't think this was the goal of your inquiry (was it?). >> But rather to get some more experience with MyHDL. >> >> In summary, what you are trying to do is invalid. Simulation will flag >> this correctly. >> >> Hope this helps, >> Chris > > > >> Let's backup a little. I think you have identified some areas for >> improvement but I don't think you have discovered something >> fundamentally broken. > > I have too admit that even the title of this topic -> "conversion error to > vhdl" is kind > of rough, because we are all (at least in my case) taught in school, high > school, whatever, that making an error > is not so good. And even if you dont read the title consciously, your > subconscious will put all the feelings and associations > forward which are connected to it. Since some of them have been in school > where we have been conditioned to errors such a title > can have an enormous effect. For example making the reader think, that the > writer think, that the reader have done something bad. > But i think the only bad errors which are made, are made by people on > purpose to hurt (in this or another way) someone. > And the other errors, kind of must be there as a source of improvement or > re-adjustment or whatsoever. So its about improvement. Not sure what this commentary is about. If you think you a detecting defensiveness, your not. I do find the MyHDL project useful and I am trying to contribute where I can. Jan Decaluwe has done a great job with MyHDL and improvements are the goal. On that note, Jan is the main developer and maintainer, and at this point all changes go through Jan. Jan is currently incommunicado, see this post, http://bit.ly/v0eI9C, for more information. > >> I believe your goal is to become more familiar >> with MyHDL > > true. > > > > Ok so what is about: > > c.next[0] = a[0] * b[0]<---- multiplikation instead of addition > > here the simulation runs successfully (100% testcoverage), and so the > conversion no warning and no errors diplayed > > this gets converted to > > c(0)<= to_std_logic(to_unsigned(a(0), 1) * to_unsigned(b(0), 1)); > > which is not synthesisable. The '*' is a valid example that fails. This should convert and a version of to_std_logic supporting unsigned should be added. But I don't think the change should be as simple as that. Per the previous discussions if the '+' is converted in the same matter the simulation and cosimulation (simulation of converted code) will not match. If the to_std_logic(unsigned) is to be added the non valid cases need to be caught and an error thrown. Which makes the change more complicated. > > > > The thing about the simulation is that if you have a unit with a lot of > inputs you cannot possible run > all number of combinations on the input. If you have internal registers > the thing gets even worse. So you can > only get a Testcoverage below 100%, so there is the change to actually > miss this case if you have an addition. This is kinda a can of worms. I don't think having a larger number of inputs is a good reason not to *test* with simulation. Yes, you might not ever be able to get 100% coverage. Which, in my mind, is a reason why you would not want the convert invalid code (the case of the '+'). Not obtaining 100% coverage is not a good reason not to achieve some coverage with simulation. > > Anyway it seem to be possible to get into a situation where the simulation > will run successfully (lets say 99% coverage or in the case of > the multiplikation even 100%), the conversion runs > successfully, but the generated code is not synthesisable. > I mean i like the fact that the bitwith of the operand of an addition is > automatically enhanced to create an extra bit for the overflow bit if the > code is generated in vhdl, but i think this should not necessarily include > that if you want to reduce the bitwith of the result by giving a > bitwith constraint to the result, that the conversion result is not valid. > > > > I think the easiest way to fix this is to just add a to_std_logic( a > unsigned ) to the pck_myhdl_07.vhd generator code. But, maybe this has > some other implications.? As discussed, the multiplication case is a valid error. This could be entered as a bug. The add/subtract doesn't hold as much water (converted HDL will not act the same as the MyHDL) but this can be an enhancement to throw an error instead of creating VHDL that will not compile/synthesize. We should also compare how the Verilog converter works but otherwise I think I am convinced that the to_std_logic(unsigned) should be added. We can make a patch but I think also a MEP should be created to address the '+'/'-'. If you want you can follow the guidelines here, http://bit.ly/ueKy5Y, and create a patch. Regards, Chris > > greetings Norbert > > > ------------------------------------------------------------------------------ > Cloud Services Checklist: Pricing and Packaging Optimization > This white paper is intended to serve as a reference, checklist and point of > discussion for anyone considering optimizing the pricing and packaging model > of a cloud services business. Read Now! > http://www.accelacomm.com/jaw/sfnl/114/51491232/ |
|
From: Norbo <Nor...@gm...> - 2011-12-12 19:40:39
|
hello
lets say e.g i have written code like:
########################Case 1: (code)#####################
from myhdl import *
from random import randrange
def TOP(outvalue):
sigTest=Signal(intbv(0)[4:])
@always_comb
def comb_setConst():
sigTest.next=4
@always_comb
def combi_sel():
if sigTest == 1:
outvalue.next=1
elif sigTest == 4:
outvalue.next=2
return instances()
def test_bench():
outsignal=Signal(intbv(0)[4:])
instanc_top=TOP(outsignal)
interval = delay(10)
@always(interval)
def stimulus():
print "Value of Output is", outsignal
return stimulus,instanc_top
if __name__ == '__main__':
hello_inst = test_bench()
sim = Simulation(hello_inst)
sim.run(10)
outsignal=Signal(intbv(0)[4:])
toVHDL(TOP,outsignal)
#############################################################
####################Console Output:#################################
Traceback (most recent call last):
File "notDriven.py", line 39, in <module>
hello_inst = test_bench()
File "notDriven.py", line 28, in test_bench
instanc_top=TOP(outsignal)
File "notDriven.py", line 12, in TOP
@always_comb
File "/usr/local/lib/python2.7/dist-packages/myhdl/_always_comb.py",
line 64, in always_comb
c = _AlwaysComb(func, symdict)
File "/usr/local/lib/python2.7/dist-packages/myhdl/_always_comb.py",
line 203, in __init__
raise AlwaysCombError(_error.EmptySensitivityList)
myhdl.AlwaysCombError: sensitivity list is empty
###########################################################
its because of this lines in the code
---------------------------
sigTest=Signal(intbv(0)[4:])
@always_comb
def comb_setConst():
sigTest.next=4
---------------------------
which in my understanding should be valid code
#################Case 2: (code)#################################
from myhdl import *
from random import randrange
ENUM_TYPE = enum('GIVE_ONE', 'GIVE_TWO')
def TOP(outvalue):
sel_value=Signal(ENUM_TYPE.GIVE_TWO)
#sel_value=Signal(intbv(0)[4:])
@always_comb
def combi_sel():
if sel_value == ENUM_TYPE.GIVE_ONE :
outvalue.next=1
elif sel_value == ENUM_TYPE.GIVE_TWO :
outvalue.next=2
return instances()
def test_bench():
outsignal=Signal(intbv(0)[4:])
instanc_top=TOP(outsignal)
interval = delay(10)
@always(interval)
def stimulus():
print "Value of Output is", outsignal
return stimulus,instanc_top
if __name__ == '__main__':
hello_inst = test_bench()
sim = Simulation(hello_inst)
print "-"*30 + "Simulation Started" + "-"*30
sim.run(10)
print "-"*30 + "Simulation Finished" + "-"*30
outsignal=Signal(intbv(0)[4:])
print "-"*30 + "Conversion To VHDL Started" + "-"*30
toVHDL(TOP,outsignal)
#############################################################
#############Console Output:###############################
------------------------------Simulation
Started------------------------------
Value of Output is 2
<class 'myhdl._SuspendSimulation'>: Simulated 10 timesteps
------------------------------Simulation
Finished------------------------------
------------------------------Conversion To VHDL
Started------------------------------
** ToVHDLWarning: Signal is not driven: sel_value
Traceback (most recent call last):
File "Case2.py", line 45, in <module>
toVHDL(TOP,outsignal)
File
"/usr/local/lib/python2.7/dist-packages/myhdl/conversion/_toVHDL.py", line
165, in __call__
_convertGens(genlist, siglist, vfile)
File
"/usr/local/lib/python2.7/dist-packages/myhdl/conversion/_toVHDL.py", line
392, in _convertGens
assert 0
AssertionError
####################################################
The Simulation runs but the conversion too vhdl or to Verilog aborts
if i dont use a ENUM Signal for the "sel_value" the conversion works
so the unit changes to:
#############Case 2.5 (code)#################
def TOP(outvalue):
#sel_value=Signal(ENUM_TYPE.GIVE_TWO)
sel_value=Signal(intbv(0)[4:])
@always_comb
def combi_sel():
if sel_value == ENUM_TYPE.GIVE_ONE :
outvalue.next=1
elif sel_value == ENUM_TYPE.GIVE_TWO :
outvalue.next=2
return instances()
######################################
then the simulation runs and the conversion works the only warning is
** ToVHDLWarning: Signal is not driven: sel_value
the resulting .vhd is not synthesisable because there is no "=" operator
for enum type and unsingned
|
|
From: Norbo <Nor...@gm...> - 2011-12-12 19:54:52
|
ok sorry forget about case 1 which is driving a constant and has been already discussed. greetings Norbert |
|
From: Christopher F. <chr...@gm...> - 2011-12-13 13:25:44
|
On 12/12/11 1:40 PM, Norbo wrote:
> hello
>
> <snip>
If you change the code, slightly it will convert without error. I did
not look at the generated VHDL (don't have a VHDL sim/syn on this
computer). The example you submitted, doesn't make too much sense
because the "select" signal is internal to you TOP module. Essentially
the circuit being described would have no inputs, hence the
"_error.EmptySensitivityList" error.
Hope this helps,
Chris
~~~~~[ Modified code ]~~~~
from myhdl import *
from random import randrange
ENUM_TYPE = enum('GIVE_ONE', 'GIVE_TWO')
def TOP(outvalue, sel_value):
@always_comb
def combi_sel():
if sel_value == ENUM_TYPE.GIVE_ONE :
outvalue.next=1
elif sel_value == ENUM_TYPE.GIVE_TWO :
outvalue.next=2
return instances()
def test_bench():
outsignal=Signal(intbv(0)[4:])
sel_value=Signal(ENUM_TYPE.GIVE_TWO)
instanc_top=TOP(outsignal, sel_value)
interval = delay(10)
@instance
def stimulus():
sel_value.next = ENUM_TYPE.GIVE_TWO
yield delay(1)
print "Value of Output is", outsignal
sel_value.next = ENUM_TYPE.GIVE_ONE
yield delay(1)
print "Value of Output is", outsignal
raise StopSimulation
return stimulus,instanc_top
if __name__ == '__main__':
hello_inst = test_bench()
sim = Simulation(hello_inst)
print "-"*30 + "Simulation Started" + "-"*30
sim.run(10)
print "-"*30 + "Simulation Finished" + "-"*30
outsignal=Signal(intbv(0)[4:])
sel_value=Signal(ENUM_TYPE.GIVE_TWO)
print "-"*30 + "Conversion To VHDL Started" + "-"*30
toVHDL(TOP,outsignal, sel_value)
|
|
From: Norbo <Nor...@gm...> - 2011-12-14 19:10:00
|
Am 13.12.2011, 14:25 Uhr, schrieb Christopher Felton
<chr...@gm...>:
> On 12/12/11 1:40 PM, Norbo wrote:
>> hello
>>
> > <snip>
>
> If you change the code, slightly it will convert without error. I did
> not look at the generated VHDL (don't have a VHDL sim/syn on this
> computer). The example you submitted, doesn't make too much sense
> because the "select" signal is internal to you TOP module. Essentially
> the circuit being described would have no inputs, hence the
> "_error.EmptySensitivityList" error.
>
> Hope this helps,
> Chris
>
> ~~~~~[ Modified code ]~~~~
> from myhdl import *
> from random import randrange
>
> ENUM_TYPE = enum('GIVE_ONE', 'GIVE_TWO')
>
> def TOP(outvalue, sel_value):
>
> @always_comb
> def combi_sel():
> if sel_value == ENUM_TYPE.GIVE_ONE :
> outvalue.next=1
> elif sel_value == ENUM_TYPE.GIVE_TWO :
> outvalue.next=2
>
> return instances()
>
>
> def test_bench():
> outsignal=Signal(intbv(0)[4:])
> sel_value=Signal(ENUM_TYPE.GIVE_TWO)
> instanc_top=TOP(outsignal, sel_value)
>
> interval = delay(10)
> @instance
> def stimulus():
> sel_value.next = ENUM_TYPE.GIVE_TWO
> yield delay(1)
> print "Value of Output is", outsignal
> sel_value.next = ENUM_TYPE.GIVE_ONE
> yield delay(1)
> print "Value of Output is", outsignal
>
> raise StopSimulation
>
> return stimulus,instanc_top
>
>
> if __name__ == '__main__':
> hello_inst = test_bench()
>
> sim = Simulation(hello_inst)
> print "-"*30 + "Simulation Started" + "-"*30
> sim.run(10)
> print "-"*30 + "Simulation Finished" + "-"*30
>
>
> outsignal=Signal(intbv(0)[4:])
> sel_value=Signal(ENUM_TYPE.GIVE_TWO)
>
> print "-"*30 + "Conversion To VHDL Started" + "-"*30
> toVHDL(TOP,outsignal, sel_value)
the Thing is that if a bool or a intbv is used the code in exactly the
same manner, it works.
For me the ability to put a konstant signal inside the module seems to be
quite usefull in some cases.
In the following there are some cases which might show some
inconsistencies.
The case that the bool is comparable with a intbv of 1 bit length would
may just be a nice to have. ;)
------------------------------------
def TOP(outvalue):
sel_value=Signal(bool(0))
@always_comb
def combi_sel():
if sel_value == bool(0) :
outvalue.next=1
elif sel_value == bool(1) :
outvalue.next=2
return instances()
Simulation Works, Conversion to VHDL Works, and Synthesis of VHDL Works
------------------------------------
------------------------------------
def TOP(outvalue):
sel_value=Signal(bool(0))
@always_comb
def combi_sel():
if sel_value == 0 :
outvalue.next=1
elif sel_value == 1 :
outvalue.next=2
return instances()
Simulation Works, Conversion to VHDL Fails!! (TypeError: Unexpected type)
Conversion to Verilog same Error
------------------------------------
------------------------------------
def TOP(outvalue):
sel_value=Signal(bool(0))
@always_comb
def combi_sel():
if sel_value == 0 :
outvalue.next=1
elif sel_value == bool(1) :
outvalue.next=2
return instances()
Simulation Works, Conversion to VHDL Works, and Synthesis of VHDL Works!!
------------------------------------
------------------------------------
def TOP(outvalue):
sel_value=Signal(intbv(0)[1:])
@always_comb
def combi_sel():
if sel_value == 0 :
outvalue.next=1
elif sel_value == 1 :
outvalue.next=2
return instances()
Simulation Works, Conversion to VHDL Works, Synthesis VHDL Works!!
------------------------------------
------------------------------------
def TOP(outvalue):
sel_value=Signal(intbv(0)[1:])
@always_comb
def combi_sel():
if sel_value == bool(0) :
outvalue.next=1
elif sel_value == bool(1) :
outvalue.next=2
return instances()
Simulation Works, Conversion to VHDL Works, Synthesis of VHDL Fails (No
matching overload for "=") !!
Synthesis of Veriolog Works !!
------------------------------------
------------------------------------
def TOP(outvalue):
sel_value=Signal(intbv(0)[1:])
@always_comb
def combi_sel():
if sel_value == 0 :
outvalue.next=1
elif sel_value == bool(1) :
outvalue.next=2
return instances()
Simulation Works, Conversion to VHDL Works, Synthesis of VHDL Fails (No
matching overload for "=") !!
------------------------------------
------------------------------------
ENUM_TYPE = enum('GIVE_ONE', 'GIVE_TWO')
def TOP(outvalue):
sel_value=Signal(ENUM_TYPE.GIVE_ONE)
@always_comb
def combi_sel():
if sel_value == ENUM_TYPE.GIVE_ONE:
outvalue.next=1
elif sel_value == ENUM_TYPE.GIVE_TWO :
outvalue.next=2
return instances()
Simulation Works, Conversion to VHDL Fails with error:
Traceback (most recent call last):
File "Case2.py", line 45, in <module>
toVHDL(TOP,outsignal)
File
"/usr/local/lib/python2.7/dist-packages/myhdl/conversion/_toVHDL.py", line
165, in __call__
_convertGens(genlist, siglist, vfile)
File
"/usr/local/lib/python2.7/dist-packages/myhdl/conversion/_toVHDL.py", line
392, in _convertGens
assert 0
AssertionError
Conversion to Veriolog Fails with:
Traceback (most recent call last):
File "Case2.py", line 45, in <module>
toVerilog(TOP,outsignal)
File
"/usr/local/lib/python2.7/dist-packages/myhdl/conversion/_toVerilog.py",
line 149, in __call__
_writeSigDecls(vfile, intf, siglist, memlist)
File
"/usr/local/lib/python2.7/dist-packages/myhdl/conversion/_toVerilog.py",
line 291, in _writeSigDecls
print >> f, "assign %s = %s;" % (s._name, int(s._val))
TypeError: int() argument must be a string or a number, not 'EnumItem'
------------------------------------
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X