Thread: Re: [myhdl-list] Restrictions for conversion (Page 2)
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Jan D. <ja...@ja...> - 2012-05-23 20:43:04
|
On 05/23/2012 12:47 PM, Christopher Felton wrote: >> >>> Norbo prototyped this and it all seemed good but we have been discussing >>> the overall behavior. I think this is where we sit right now. >>> >>> 1. Initial value support should be added, it resolves >>> the time 0 mismatch. It has been verified with >>> the latest versions of Quartus and ISE. >> >> Yes. > > The one implementation detail we ran into, was that the continuous > assign statements in Verilog will need to be replaced with an @always block. Ok, I see, I glanced over the discussions between Norbo and you. A word of caution though: there are subtle semantic differences between assign, always(*) and always_comb in Verilog. I *think* always_comb should be ok, after all I once modeled it in MyHDL after this. Several new issues arise: do all synthesis tools that we target (also the free ones from X/A) support always_comb, which is basically a SystemVerilog construct? And if they do, do they support it in a template for RAM inference? A prudent way forward initially might be to add the initialization only to what is currently converted as a reg. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Norbo <Nor...@gm...> - 2012-05-24 09:35:50
|
Am 23.05.2012, 04:37 Uhr, schrieb Christopher Felton <chr...@gm...>: > That was somewhat missed phrased, "... reasonable method ...". > Currently initial values are not supported (enabled), for basic types or > arrays (memories). Currently you cannot do either. I should have > said, pre-init RAM is not supported in MyHDL. > > Known, reasonable, RAM pre-init methods are available for Verilog/VHDL. > It seems reasonable to include with the initial value support. > > Norbo prototyped this and it all seemed good but we have been discussing > the overall behavior. I think this is where we sit right now. > > 1. Initial value support should be added, it resolves > the time 0 mismatch. It has been verified with > the latest versions of Quartus and ISE. I don't see a reason (other than irritating the VHDL or Verilog Simulation or synthesis tool) to write a initial value to a Signal that gets its value in a combinatorical process. Such a Signal gets its value at a beginning from a zero time delta cycle there is "time 0 missmatch" for such a signal. I also don't see whats this thing about the "time 0 mimatch". If i have a memory where the initial values are not written then i get a missmatch every time i read from the memmory wheater it is time 0 or time 5trillion. The only missmatch i see is from a Flip-Flop output signal. In this case i think the missmatch is a good thing, because it allows to check if a Flip-Flob is not not reseted. greetings Norbo |
|
From: Jan D. <ja...@ja...> - 2012-05-24 10:31:00
|
On 05/24/2012 11:35 AM, Norbo wrote: > I don't see a reason (other than irritating the VHDL or Verilog Simulation > or synthesis tool) to write a initial value > to a Signal that gets its value in a combinatorical process. Such a Signal > gets its value at a beginning from a zero time delta cycle there > is "time 0 missmatch" for such a signal. > > I also don't see whats this thing about the "time 0 mimatch". The problem is that there may be an event in in Verilog/VHDL while there may be no event in MyHDL. E.g. going from X->0 as opposed to 0->0. This may lead to subtle difficulties, typically in test benches. At least in mine. > If i have a > memory where the initial values are not written then i get a missmatch > every time i read from the memmory wheater it is time 0 or time 5trillion. This would be an argument to write the initial values. > The only missmatch i see is from a Flip-Flop output signal. In this case i > think the missmatch is a good thing, because it allows to check if a > Flip-Flob is not > not reseted. This has been covered before: at best it is a half-hearted solution for which much better formal alternatives are available. Some background perhaps: the type system in MyHDL was not inspired by Verilog, but by VHDL, in particular its abstract types such as integer, boolean and enum. The simple reason is that I largely prefer such types over low-level "representational" types such as signed/unsigned or the Verilog types. In particular, intbv is intended to be a better constrained integer type: with indexing support and without limits on the constraints. However, it keeps the fact that abstract types are initialized to some implicit or explicit value that belongs to the type. And again, there is also bool and enum whose use I would like to encourage in synthesizable MyHDL. I have also given considerable thought on the value of 'X' in digital design. A full explanation is very extensive, but my conclusion is that 'X' has no place in RTL design, and its value at the gate level is doubtful at best. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Tom D. <td...@di...> - 2012-05-24 14:02:52
|
On 05/24/2012 05:30 AM, Jan Decaluwe wrote: > On 05/24/2012 11:35 AM, Norbo wrote: > > >> I don't see a reason (other than irritating the VHDL or Verilog Simulation >> or synthesis tool) to write a initial value >> to a Signal that gets its value in a combinatorical process. Such a Signal >> gets its value at a beginning from a zero time delta cycle there >> is "time 0 missmatch" for such a signal. >> >> I also don't see whats this thing about the "time 0 mimatch". > The problem is that there may be an event in in Verilog/VHDL > while there may be no event in MyHDL. E.g. going from X->0 > as opposed to 0->0. > > This may lead to subtle difficulties, typically in test > benches. At least in mine. > >> If i have a >> memory where the initial values are not written then i get a missmatch >> every time i read from the memmory wheater it is time 0 or time 5trillion. > This would be an argument to write the initial values. > >> The only missmatch i see is from a Flip-Flop output signal. In this case i >> think the missmatch is a good thing, because it allows to check if a >> Flip-Flob is not >> not reseted. > This has been covered before: at best it is a half-hearted > solution for which much better formal alternatives are > available. > > Some background perhaps: the type system in MyHDL was not inspired > by Verilog, but by VHDL, in particular its abstract types such as > integer, boolean and enum. The simple reason is that I largely > prefer such types over low-level "representational" types such > as signed/unsigned or the Verilog types. > > In particular, intbv is intended to be a better constrained > integer type: with indexing support and without limits on the > constraints. However, it keeps the fact that abstract types > are initialized to some implicit or explicit value that > belongs to the type. > > And again, there is also bool and enum whose use I would like > to encourage in synthesizable MyHDL. > > I have also given considerable thought on the value of > 'X' in digital design. A full explanation is very extensive, > but my conclusion is that 'X' has no place in RTL design, > and its value at the gate level is doubtful at best. That peaks my interest. How do you get them out of RTL design? |
|
From: Christopher F. <chr...@gm...> - 2012-05-24 14:15:24
|
On 5/24/2012 9:02 AM, Tom Dillon wrote: > On 05/24/2012 05:30 AM, Jan Decaluwe wrote: >> On 05/24/2012 11:35 AM, Norbo wrote: >> >> >>> I don't see a reason (other than irritating the VHDL or Verilog Simulation >>> or synthesis tool) to write a initial value >>> to a Signal that gets its value in a combinatorical process. Such a Signal >>> gets its value at a beginning from a zero time delta cycle there >>> is "time 0 missmatch" for such a signal. >>> >>> I also don't see whats this thing about the "time 0 mimatch". >> The problem is that there may be an event in in Verilog/VHDL >> while there may be no event in MyHDL. E.g. going from X->0 >> as opposed to 0->0. >> >> This may lead to subtle difficulties, typically in test >> benches. At least in mine. >> >>> If i have a >>> memory where the initial values are not written then i get a missmatch >>> every time i read from the memmory wheater it is time 0 or time 5trillion. >> This would be an argument to write the initial values. >> >>> The only missmatch i see is from a Flip-Flop output signal. In this case i >>> think the missmatch is a good thing, because it allows to check if a >>> Flip-Flob is not >>> not reseted. >> This has been covered before: at best it is a half-hearted >> solution for which much better formal alternatives are >> available. >> >> Some background perhaps: the type system in MyHDL was not inspired >> by Verilog, but by VHDL, in particular its abstract types such as >> integer, boolean and enum. The simple reason is that I largely >> prefer such types over low-level "representational" types such >> as signed/unsigned or the Verilog types. >> >> In particular, intbv is intended to be a better constrained >> integer type: with indexing support and without limits on the >> constraints. However, it keeps the fact that abstract types >> are initialized to some implicit or explicit value that >> belongs to the type. >> >> And again, there is also bool and enum whose use I would like >> to encourage in synthesizable MyHDL. >> >> I have also given considerable thought on the value of >> 'X' in digital design. A full explanation is very extensive, >> but my conclusion is that 'X' has no place in RTL design, >> and its value at the gate level is doubtful at best. > > That peaks my interest. How do you get them out of RTL design? > Use MyHDL :) |
|
From: Tom D. <td...@di...> - 2012-05-24 16:15:06
|
On 05/24/2012 09:17 AM, Jan Decaluwe wrote: > On 05/24/2012 04:14 PM, Christopher Felton wrote: >> On 5/24/2012 9:02 AM, Tom Dillon wrote: >> Use MyHDL :) > Right :-) > So there are no Xs in MyHDL. Then what we are really talking about is making sure the downstream tools don't put them in where they weren't? For instance, you have a state machine initialized to a known state in MyHDL. How do you know the synthesis results to say an ASIC will produce logic to match that? |
|
From: Jan D. <ja...@ja...> - 2012-05-24 17:37:26
|
On 05/24/2012 06:14 PM, Tom Dillon wrote: > > > On 05/24/2012 09:17 AM, Jan Decaluwe wrote: >> On 05/24/2012 04:14 PM, Christopher Felton wrote: >>> On 5/24/2012 9:02 AM, Tom Dillon wrote: >>> Use MyHDL :) >> Right :-) >> > So there are no Xs in MyHDL. Then what we are really talking about is > making sure the downstream tools don't put them in where they weren't? > > For instance, you have a state machine initialized to a known state in > MyHDL. How do you know the synthesis results to say an ASIC will produce > logic to match that? A formal check of flip-flop types inferred (fast, cheap, my preference), or gate level simulation, or formal verification of gate level against RTL. This would be identical to a pure VHDL flow, where the use of an enumerated type to specify states is standard practice. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.co |
|
From: Tom D. <td...@di...> - 2012-05-24 18:11:25
|
On 05/24/2012 12:37 PM, Jan Decaluwe wrote: > On 05/24/2012 06:14 PM, Tom Dillon wrote: >> >> On 05/24/2012 09:17 AM, Jan Decaluwe wrote: >>> On 05/24/2012 04:14 PM, Christopher Felton wrote: >>>> On 5/24/2012 9:02 AM, Tom Dillon wrote: >>>> Use MyHDL :) >>> Right :-) >>> >> So there are no Xs in MyHDL. Then what we are really talking about is >> making sure the downstream tools don't put them in where they weren't? >> >> For instance, you have a state machine initialized to a known state in >> MyHDL. How do you know the synthesis results to say an ASIC will produce >> logic to match that? > A formal check of flip-flop types inferred (fast, cheap, my preference), > or gate level simulation, or formal verification of gate level against RTL. > > This would be identical to a pure VHDL flow, where the use > of an enumerated type to specify states is standard practice. I get it. I thought there was some kind of magic here that would keep you from having to verify your synthesis results and allow you to neglect good design practices up front. |
|
From: Jan D. <ja...@ja...> - 2012-05-24 14:18:11
|
On 05/24/2012 04:14 PM, Christopher Felton wrote: > On 5/24/2012 9:02 AM, Tom Dillon wrote: > Use MyHDL :) Right :-) -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Christopher F. <chr...@gm...> - 2012-05-23 02:40:20
|
On 5/22/12 4:32 PM, Jan Decaluwe wrote: > On 05/22/2012 05:34 PM, Christopher Felton wrote: > >> >> FPGAs support pre-init RAM. Synthesis will extract the array initial >> values from the HDL and during configuration program the BRAM (internal >> FPGA RAM). When the FPGA comes out of reset (not logic reset, FPGA post >> config reset) the RAM will contain the initial values. The RAM is a RAM >> so the values can be overridden by the logic, i.e not a ROM. This is >> only possible in an FPGA and is supported by X&A synthesis tools. >> >> I don't know a reasonable method to achieve the pre-init RAM, currently. > > Do you mean no reasonable method from MyHDL, or no reasonable method > at all? > > And if there is a reasonable method, how does it work? > Didn't include the reference, for Quartus the pre-init RAM templates can be found in the following. http://www.altera.com/literature/hb/qts/qts_qii51007.pdf Regards, Chris |
|
From: Jan D. <ja...@ja...> - 2012-05-23 09:02:30
|
On 05/23/2012 04:37 AM, Christopher Felton wrote: > On 5/22/12 4:32 PM, Jan Decaluwe wrote: >> On 05/22/2012 05:34 PM, Christopher Felton wrote: >> >>> >>> FPGAs support pre-init RAM. Synthesis will extract the array initial >>> values from the HDL and during configuration program the BRAM (internal >>> FPGA RAM). When the FPGA comes out of reset (not logic reset, FPGA post >>> config reset) the RAM will contain the initial values. The RAM is a RAM >>> so the values can be overridden by the logic, i.e not a ROM. This is >>> only possible in an FPGA and is supported by X&A synthesis tools. >>> >>> I don't know a reasonable method to achieve the pre-init RAM, currently. >> >> Do you mean no reasonable method from MyHDL, or no reasonable method >> at all? > > That was somewhat missed phrased, "... reasonable method ...". > Currently initial values are not supported (enabled), for basic types or > arrays (memories). Currently you cannot do either. I should have > said, pre-init RAM is not supported in MyHDL. > > Known, reasonable, RAM pre-init methods are available for Verilog/VHDL. > It seems reasonable to include with the initial value support. Yes. Now, from the altera literature it seems they also support $readmemb, which would make it possible to initialize a RAM with arbitrary values. But I don't know how to do that with VHDL. Would it be sufficient to support memory initialization to an identical value for each location? > Norbo prototyped this and it all seemed good but we have been discussing > the overall behavior. I think this is where we sit right now. > > 1. Initial value support should be added, it resolves > the time 0 mismatch. It has been verified with > the latest versions of Quartus and ISE. Yes. > 2. Intial value support for arrays should be included > (all types are initialized). Verdict is still out > if the ivs for arrays should be "synthesizable". Yes. In summary: I think initial values should be written, regardless of what synthesis does with it, because of the exact match in simulation. > 3. Unresolved, should there be a method to disable > ivs. The current proposed method is to use None. As a fallback method, I think it would be wise to be able to disable initial value writing by a control parameter to toVerilog/toVHDL. A separate control for plain signals and arrays probably. But this would be purely because some synthesis tools may not support the syntax. I don't see a value in adding support for None to intbv, as discussed before. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Jan D. <ja...@ja...> - 2012-05-22 13:20:18
|
On 05/05/2012 05:20 PM, Norbo wrote: > another point is that i think it is a good thing to have all the variables > by default not to be initialized > with values in the converted code. Initialisation should only occour if > you really want to describe (pre-init RAM) > or ROM. > because for example in VHDL all the std_logic signals are set at startup > of a vhdl simulation to the value 'U' (stands for uninitialized) if there > is no other initial value given. After the reset all values should have > changed from this > 'U' to something usefull. This allows you to see imidiatly if you have > messed up or missed something in the reset code. No, you don't see it immediately. You have to fire up a simulation, and then be lucky that the problem is not masked by logical operations. For something like this, I think the only good way is a formal check. What I always use is a simple check of flip-flop types inferred by synthesis. Works like a charm, no simulation needed, and you catch everything in one pass. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Norbo <Nor...@gm...> - 2012-05-21 11:29:19
|
> * Adding support for None in the intbv (also setting None as the default
> value?)
> * Creating initial values in Verilog/VHDL (when not None)
> * Changing the verilog continuous assignment to the behavioral statement
> in the verilog conversion
> * Work through the implementation changes needed, because of the None in
> the intbv (boundchecks, etc ..)
I started to try to implement these points.
the real issues started where i came to the :
* Work through the implementation changes needed, because of the None in
the intbv (boundchecks, etc ..
the issue arises when the intbv has a value of None in the myhdl
implementation, and something like this is done:
sig1=Signal(intbv(None)[8:))
sig2=Signal(intbv(None)[8:))
@always(clk.posedge)
def aritmetic():
square.next=sig1*sig1+sig2*sig2
i first changed all __add__ and __mult__ operater of the intbv to return
None as a value if one of the operands
is None. But as the two multiplications are done first the last plus
operation has two None values (None+None) which
doesnt works. So i returned for every operation a new intbv(None). Anyway
there seem to be some operators where intbv() are
returned and other operaters there is just the value returned (in the
orginal code -> has this any special reson?).
But there was an other case:
mem=[Signal(intbv(0)[8:]) for i in range(200)]
@always(clk.posedge)
def mem_read():
our.next=mem[addr]
if here the addr._val is None then it also crashes.
So my short just to try workaround was to subclass list and accept the
None as a index
class listx(list):
def __getitem__(self, key):
if key==None:
bits=super(listx, self).__getitem__(0)._nrbits
return intbv(None)[bits:]
return super(listx, self).__getitem__(key)
then the implementation would have to look like this:
mem=listx([Signal(intbv(0)[8:]) for i in range(200)])
@always(clk.posedge)
def mem_read():
our.next=mem[addr]
then the issue with the bool arised because if you write code like this:
sig=Signal(bool(None))
because bool(None) evaluates to false the _val of the Signal gets false an
not None
So i tried with a bool definition like the following:
def boolx(val=None):
if val in (0, 1):
return bool(val)
else:
return None
Then i changed all Signal operators (__add__, __sub__, etc..) that they
return None if one of the operaters is None
which brings the same problem with the plus to the signal as i had in the
intbv() which is that two None values can't be added or multiplyed or etc.
like in the intbv.
then i realized that it probably would just be better to make the Signal
as a base class and derive every other type from it, wheter it is (intbv,
bool"x" or modbv, enum, etc.). This probably doesnt made sense once when
only the intbv existed?
or is it done the way it is done because of performance reason?
greetings
Norbo
|
|
From: Jan D. <ja...@ja...> - 2012-05-21 16:56:32
|
On 05/21/2012 01:28 PM, Norbo wrote: > then i realized that it probably would just be better to make the Signal > as a base class and derive every other type from it, wheter it is (intbv, > bool"x" or modbv, enum, etc.). This probably doesnt made sense once when > only the intbv existed? > or is it done the way it is done because of performance reason? I'm just jumping in on this thread, but if that is the conclusion there is something fundamentally wrong. intbv is just a hardware friendly datatype. Signal is the type we need to do racefree communication. These types should be complementary - they can be used together (because you want to be able to do racefree communication with any datatype) or separate (because the datatype are useful for plain variables also.) -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Christopher F. <chr...@gm...> - 2012-05-21 12:07:23
|
On 5/21/2012 6:28 AM, Norbo wrote:
>> * Adding support for None in the intbv (also setting None as the default
>> value?)
>> * Creating initial values in Verilog/VHDL (when not None)
>> * Changing the verilog continuous assignment to the behavioral statement
>> in the verilog conversion
>> * Work through the implementation changes needed, because of the None in
>> the intbv (boundchecks, etc ..)
>
> I started to try to implement these points.
> the real issues started where i came to the :
> * Work through the implementation changes needed, because of the None in
> the intbv (boundchecks, etc ..
> the issue arises when the intbv has a value of None in the myhdl
> implementation, and something like this is done:
>
> sig1=Signal(intbv(None)[8:))
> sig2=Signal(intbv(None)[8:))
>
> @always(clk.posedge)
> def aritmetic():
> square.next=sig1*sig1+sig2*sig2
I am not sure of the answer right now but what is the correct course?
To propagate the "None" or to raise and exception?
>
> i first changed all __add__ and __mult__ operater of the intbv to return
> None as a value if one of the operands
> is None. But as the two multiplications are done first the last plus
> operation has two None values (None+None) which
> doesnt works. So i returned for every operation a new intbv(None). Anyway
> there seem to be some operators where intbv() are
> returned and other operaters there is just the value returned (in the
> orginal code -> has this any special reson?).
This has been discussed briefly in the past. IIRC it is for
performance? I might be plausible to to return intbv type for all
operations (I have prototyped this in the past, again IIRC it didn't
break anything). But I think we would want very good reason to modify
before doing so.
>
> But there was an other case:
>
> mem=[Signal(intbv(0)[8:]) for i in range(200)]
>
> @always(clk.posedge)
> def mem_read():
> our.next=mem[addr]
>
> if here the addr._val is None then it also crashes.
> So my short just to try workaround was to subclass list and accept the
> None as a index
>
> class listx(list):
> def __getitem__(self, key):
> if key==None:
> bits=super(listx, self).__getitem__(0)._nrbits
> return intbv(None)[bits:]
> return super(listx, self).__getitem__(key)
>
> then the implementation would have to look like this:
>
> mem=listx([Signal(intbv(0)[8:]) for i in range(200)])
>
> @always(clk.posedge)
> def mem_read():
> our.next=mem[addr]
>
> then the issue with the bool arised because if you write code like this:
>
> sig=Signal(bool(None))
>
> because bool(None) evaluates to false the _val of the Signal gets false an
> not None
> So i tried with a bool definition like the following:
>
I think that might be an ok behavior. I know it doesn't match the other
non-initialized but the bool not having a non-initialize is probably
acceptable.
> def boolx(val=None):
> if val in (0, 1):
> return bool(val)
> else:
> return None
>
> Then i changed all Signal operators (__add__, __sub__, etc..) that they
> return None if one of the operaters is None
> which brings the same problem with the plus to the signal as i had in the
> intbv() which is that two None values can't be added or multiplyed or etc.
> like in the intbv.
>
> then i realized that it probably would just be better to make the Signal
> as a base class and derive every other type from it, wheter it is (intbv,
> bool"x" or modbv, enum, etc.). This probably doesnt made sense once when
> only the intbv existed?
> or is it done the way it is done because of performance reason?
>
Hmmm, I am not sure about that. In some cases, mainly modeling, I want
to use intbv directly and do not want it to be a Signal. Example, I
don't want to have to call the "update" explicitly or implicitly to have
the get the value.
As I write this, I think the rules should be :
1. intbv can have a type None but not the other
Python built-in types: bool, int, long, etc.
(I realize only bool is convertible).
2. If an intbv with a value of None is used an
exception should be raised.
The main use of the "None" was to control if initial values were written
to the lower (v)HDLs. Which I think is fair. But MyHDL currently does
not have this concept in conversion or modeling. That is, you can't
have an unknown value. I think we preserve this by raising an
exception. The rules is changed slightly, currently you cannot have a
type with an unknown value and proposed you can't use a type with an
unknown (a.k.a None).
And there is the limitation that the Python built-in types will always
be initialized. Only the intbv can not be initialized. I believe the
only arguable reason for not initializing so far is for large arrays
(memories). Or did I quickly forget?
Regards,
Chris
|
|
From: Jan D. <ja...@ja...> - 2012-05-21 17:00:18
|
On 05/21/2012 02:06 PM, Christopher Felton wrote: > As I write this, I think the rules should be : > > 1. intbv can have a type None but not the other > Python built-in types: bool, int, long, etc. > (I realize only bool is convertible). Can you tell me in one sentence why intbv would need this, unlike the other types? It used to be a like that, and then I kicked it out because of too many issues with operators, and lack of a use case. None is used in TristateSignal to represent high-impedance. I don't see another useful use case. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Christopher F. <chr...@gm...> - 2012-05-21 17:24:52
|
On 5/21/2012 11:58 AM, Jan Decaluwe wrote: > On 05/21/2012 02:06 PM, Christopher Felton wrote: > >> As I write this, I think the rules should be : >> >> 1. intbv can have a type None but not the other >> Python built-in types: bool, int, long, etc. >> (I realize only bool is convertible). > > Can you tell me in one sentence why intbv would need this, > unlike the other types? To control initial value support, because intbv can be used to model memories and the initialization of large internal memories might be inefficient and/or unwanted. This is all in the context of initial value support and extended to pre-init RAM (which is possible in an FPGA). > > It used to be a like that, and then I kicked it out because > of too many issues with operators, and lack of a use case. > > None is used in TristateSignal to represent high-impedance. > I don't see another useful use case. > What we have been discussing is the API to disable initial value support if it was added. Would it be via additional arguments, special value (i.e. None), or a separate type (NoInitSignal?)? Regards, Chris |
|
From: Norbo <Nor...@gm...> - 2012-05-22 20:42:04
|
Am 22.05.2012, 15:16 Uhr, schrieb Jan Decaluwe <ja...@ja...>: > On 05/05/2012 05:20 PM, Norbo wrote: > >> another point is that i think it is a good thing to have all the >> variables >> by default not to be initialized >> with values in the converted code. Initialisation should only occour if >> you really want to describe (pre-init RAM) >> or ROM. >> because for example in VHDL all the std_logic signals are set at startup >> of a vhdl simulation to the value 'U' (stands for uninitialized) if >> there >> is no other initial value given. After the reset all values should have >> changed from this >> 'U' to something usefull. This allows you to see imidiatly if you have >> messed up or missed something in the reset code. > > No, you don't see it immediately. You have to fire up a simulation, > and then be lucky that the problem is not masked by logical > operations. obviously there is no way around the simulation at least for setting the reset for some time to low and then to high. What you forget is that the reset is asynchron, so the normal flip-flop operation is "blocked" and no logical masking or whatsoever will occour. You dont even have to apply a clock signal to see it. > For something like this, I think the only good way is a formal > check. What I always use is a simple check of flip-flop types > inferred by synthesis. Works like a charm, no simulation needed, > and you catch everything in one pass. Yeah, you can do that but, i personally dont like two wait till the end of a e.g: "hour" long synthesis to just discover that something is wrong with reset values and than synthesis all over again. greetings Norbo |
|
From: Jan D. <ja...@ja...> - 2012-05-22 21:28:25
|
On 05/22/2012 10:41 PM, Norbo wrote: > Am 22.05.2012, 15:16 Uhr, schrieb Jan Decaluwe<ja...@ja...>: > >> On 05/05/2012 05:20 PM, Norbo wrote: >> >>> another point is that i think it is a good thing to have all the >>> variables >>> by default not to be initialized >>> with values in the converted code. Initialisation should only occour if >>> you really want to describe (pre-init RAM) >>> or ROM. >>> because for example in VHDL all the std_logic signals are set at startup >>> of a vhdl simulation to the value 'U' (stands for uninitialized) if >>> there >>> is no other initial value given. After the reset all values should have >>> changed from this >>> 'U' to something usefull. This allows you to see imidiatly if you have >>> messed up or missed something in the reset code. >> >> No, you don't see it immediately. You have to fire up a simulation, >> and then be lucky that the problem is not masked by logical >> operations. > > obviously there is no way around the simulation at least for setting the > reset for some time > to low and then to high. > What you forget is that the reset is asynchron, so the normal flip-flop > operation is "blocked" and no logical > masking or whatsoever will occour. You dont even have to apply a clock > signal to see it. What I mean is that you have to look for unitialized values specifically, on every signal, after a dedicated reset sequence. Other simulations may not reveal any issue, even if there are unitialized values at the start. But things may still go wrong at the gate level because RTL and gate level are only loosely related on this point. >> For something like this, I think the only good way is a formal >> check. What I always use is a simple check of flip-flop types >> inferred by synthesis. Works like a charm, no simulation needed, >> and you catch everything in one pass. > > Yeah, you can do that but, i personally dont like two wait till the end of > a e.g: "hour" long synthesis to > just discover that something is wrong with reset values and than synthesis > all over again. You must be doing million gate synthesis runs then :-) No need for full synthesis of course. The analysis phase of a tool like Design Compiler gives you a full list with all registers and their characteristics within seconds. To me it's part of debugging and fixing synthesis warnings to get the design clean for synthesis. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Norbo <Nor...@gm...> - 2012-05-24 16:27:59
|
Am 22.05.2012, 23:28 Uhr, schrieb Jan Decaluwe <ja...@ja...>: > On 05/22/2012 10:41 PM, Norbo wrote: >> Am 22.05.2012, 15:16 Uhr, schrieb Jan Decaluwe<ja...@ja...>: >> >>> On 05/05/2012 05:20 PM, Norbo wrote: >>> >>>> another point is that i think it is a good thing to have all the >>>> variables >>>> by default not to be initialized >>>> with values in the converted code. Initialisation should only occour >>>> if >>>> you really want to describe (pre-init RAM) >>>> or ROM. >>>> because for example in VHDL all the std_logic signals are set at >>>> startup >>>> of a vhdl simulation to the value 'U' (stands for uninitialized) if >>>> there >>>> is no other initial value given. After the reset all values should >>>> have >>>> changed from this >>>> 'U' to something usefull. This allows you to see imidiatly if you have >>>> messed up or missed something in the reset code. >>> >>> No, you don't see it immediately. You have to fire up a simulation, >>> and then be lucky that the problem is not masked by logical >>> operations. >> >> obviously there is no way around the simulation at least for setting the >> reset for some time >> to low and then to high. >> What you forget is that the reset is asynchron, so the normal flip-flop >> operation is "blocked" and no logical >> masking or whatsoever will occour. You dont even have to apply a clock >> signal to see it. > > What I mean is that you have to look for unitialized values > specifically, on every signal, after a dedicated reset sequence In myhdl it would be quit easy to iterate through the complete signallist. Ok but there would still be a problem with the Registers that dont have a reset. To make it a 100% coverage thing , the only rule to obey is, don't use Register without reset. > Other simulations may not reveal any issue, even if there are > unitialized values at the start. For example in a plane vhdl simulation. (This is bassically also my number one reason why the initial values from my point of view should not be written to just every signal because then it wouldn't be possible to just look at the 'U' signals, or in other words you have to look at every signal because you cant tell wheater the value comes from the initial or from the reset) What i bassically do is: open the waveformviewer, recursivly add all signals, set the marker at the point of interesst, scroll down, watch out for uninitialized values with 'U' (mostly red), if there is a 'U' signal, check if its not from a Register without a reset -> 100 % resetvalue set coverage > But things may still go wrong > at the gate level because RTL and gate level are only loosely > related on this point. Thats just a reason more, to somehow be able to verify it at least at the RTL level. > I have also given considerable thought on the value of > 'X' in digital design. A full explanation is very extensive, > but my conclusion is that 'X' has no place in RTL design, > and its value at the gate level is doubtful at best. I completly agree with the 'X' but i am not so sure about the 'U' But i came to understand that the 'U' concept, kind of involves the 'X' concept and that the 'X' concept is not compatible with the intbv() integer concept, especially when it comes to operaters like "&" or "|". So in the end i kind of have to thank you for stopping me on continue implementing on something which is not reasonable feasible the way i thought. greetings Norbo |
|
From: Jan D. <ja...@ja...> - 2012-05-24 19:24:12
|
On 05/24/2012 06:27 PM, Norbo wrote: > I completly agree with the 'X' but i am not so sure about the 'U' Ok, but note that Verilog has only X, and MyHDL has to cater for both :-) In general, this type of problem is a real issue: we have to support both HDLs at the back end, including their pecularities and restrictions, and furthermore we poor open source guys have take into account the restrictions of commercial tools! > But i came to understand that the 'U' concept, kind of involves the 'X' > concept > and that the 'X' concept is not compatible with the intbv() integer > concept, especially when > it comes to operaters like "&" or "|". > > So in the end i kind of have to thank you for stopping me on continue > implementing on something which is not reasonable feasible the way i > thought. Well, I think you were finding out that you know where you start but you don't were you will end - I went through the experience before. Note that I haven't claimed that there is no issue - there is. I also don't want to say categorically that "None" has no role to play - I have used it for tristate representation. I only said that supporting None in intbv is not a good idea. In a situation like this, I think we should try to think out of the box and innovate. Not try to mimic what exists, because it's all broken in some way, but come up with a better solution. I have some ideas but I need to think a bit longer first. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Norbo <Nor...@gm...> - 2012-04-21 15:22:46
|
> As you are aware the use cases supported by MyHDL are RAM and ROM and > examples for each and descriptions can be found here: > > http://www.myhdl.org/doc/0.7/manual/conversion_examples.html#ram-inference I am actually not particular happy with this example because it is asynchron. The following statment from [page14 , http://www.altera.com/literature/hb/qts/qts_qii51007.pdf] kind of nails it, and from my point of view it is not only true for altera devices. """Altera recommends using synchronous memory blocks for Altera designs. Because memory blocks in the newest devices from Altera are synchronous, RAM designs that are targeted towards architectures that contain these dedicated memory blocks must be synchronous to be mapped directly into the device architecture. For these devices, asynchronous memory logic is implemented in regular logic cells. Synchronous memory offers several advantages over asynchronous memory, including higher frequencies and thus higher memory bandwidth, increased reliability, and less standby power.""" > In the past discussions the Altera recommended guidelines for RAM and > ROM instantiation has been referenced. > http://www.altera.com/literature/hb/qts/qts_qii51007.pdf. > > From my experience tool specific pragmas or init files are used to > pre-init RAMS in the FPGA vendor tools. The guidelines for "specifying > initial memory contents at power-up" is described start at section > 11-32, which seem to suggest the same (.mif file). But it does go on to > describe a method for initializing, using an initial block in Verilog > and a function in VHDL. To get to an actual synthesizable approach it > appears the initial values would not be enough? The initial values for the array signal are enough for a synthesizable approach. The Function with is used in the VHDL code is just another way which can be used to give the signals in the array there initial values in a more procedural way (for vhdl). If you have the procedure wich gives the values in python, you can write the initial values in vhdl to the array directly. The "specifying initial memory contents at power-up" > One of the reasons why initial values has not been implemented (it is on > the todo list, > http://www.myhdl.org/doku.php/dev:tasks#initial_values_suppot) is that > it was observed that Quartus did not support initial value support in > Verilog. There would be a mis-match between the Verilog conversion and > VHDL conversion. I just can say that i use quartus v11.1 and i dont see this limitation there. But this is probably not satisfactorily if someone uses a older version. There is this another open task: http://www.myhdl.org/doku.php/dev:tasks # More general support of indexed constants If the array of signals is initialized with values (also in the vhdl an verilig code) you can then use it also as a indexed "constant" value in a more general way, this signal can be used everyvere where like a normal signal. if you never write to this signal it is just like a constant. greetings Norbo |
|
From: Christopher F. <chr...@gm...> - 2012-04-24 03:31:18
|
<snip> >> To get to an actual synthesizable approach it >> appears the initial values would not be enough? > > The initial values for the array signal are enough for a synthesizable > approach. > The Function with is used in the VHDL code is just another way which can > be used to give the > signals in the array there initial values in a more procedural way (for > vhdl). If you have the procedure > wich gives the values in python, you can write the initial values in vhdl > to the array directly. > The "specifying initial memory contents at power-up" > Is this true for Verilog and VHDL? And is it true across multiple vendor tools? IMO the actual creation of the pre-init RAM is less important, unless widely advertised, than wide support of pre-init. Reworded, adding the init support even if it doesn't support pre-init RAM in the vendor synthesis is ok, IMO. > >> One of the reasons why initial values has not been implemented (it is on >> the todo list, >> http://www.myhdl.org/doku.php/dev:tasks#initial_values_suppot) is that >> it was observed that Quartus did not support initial value support in >> Verilog. There would be a mis-match between the Verilog conversion and >> VHDL conversion. > > I just can say that i use quartus v11.1 and i dont see this limitation > there. > But this is probably not satisfactorily if someone uses a older version. I think moving forward that is ok, not to support older Quartus, I don't recall any objections in the past. But to clarify, you do not see initial value errors with Verilog in Quartus? > > There is this another open task: > http://www.myhdl.org/doku.php/dev:tasks # More general support of indexed > constants > > If the array of signals is initialized with values (also in the vhdl an > verilig code) > you can then use it also as a indexed "constant" value > in a more general way, this signal can be used everyvere where like a > normal signal. > if you never write to this signal it is just like a constant. > > > greetings > Norbo > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 |
|
From: Norbo <Nor...@gm...> - 2012-04-25 13:30:41
|
>> The initial values for the array signal are enough for a synthesizable >> approach. >> The Function with is used in the VHDL code is just another way which can >> be used to give the >> signals in the array there initial values in a more procedural way (for >> vhdl). If you have the procedure >> wich gives the values in python, you can write the initial values in >> vhdl >> to the array directly. > Is this true for Verilog and VHDL? And is it true across multiple > vendor tools? IMO the actual creation of the pre-init RAM is less > important, unless widely advertised, than wide support of pre-init. > Reworded, adding the init support even if it doesn't support pre-init > RAM in the vendor synthesis is ok, IMO. ...... ...... > But to clarify, you do not see initial value errors with Verilog in > Quartus? I looked at it more closely now, and here is what i found : Bassicaly a signal array with initial value can be used, meaningfull in the following scenarios: 1. reading it from a combinatorical process -> vhdl synthesis works & verilog syntesis works (but signal array must be defined as "reg") 2. reading it synchron (clocked) -> vhdl synthesis works & verilog syntesis works (but signal array must be defined as "reg") 3. reading it synchron (clocked) and writing it synchron -> vhdl synthesis works & verilog synthesis works (signal array is allready defined as "reg") 4. reading it synchron (clocked) and writing it in a combinatorical process -> vhdl synthesis works & verilog synthesis doesnt work !!! (because signal cant be defined as reg when you write to in a combinatorical process. So if you write to just one signal in the array the whole array needs to be defined as wire and you cant use the initial statment for that signal array, so you cant initialize all the other signals which are not written in a combinatorical process. it normally makes sense that if you have a inital value in a signal that you are not allowed to overwrite it immidiatly with an combinatorical assignment. But the problem is that if you just use one signal of the array to write to it in a combinatorical process, you "lose" the hole array. Addition: "if there is a asynchron reset in a clocked process where you assign on of the array signals a reset value, then the verilog synthesis works with the initialized array" 5. reading and writing in a combinatorical process same problem in verilog -> you cant have the signal array be defined as "wire" and use the init block statment in verilog. Or in other words: If the signal array is defined as "reg" you cannot write to it in a combinatorical process. So a relative simple addition would be to find out wheter a signal is driven in a combinatorical process (@always_comb) or not, to decide wheter the initial values are written for the signal array. So that in Case 4. and 5. no initial values are written. This would mean some of vhdl's liberty is lost but acceptable since thes are very rare cases. Is this possible to decide wheter it is driven in (@always_comb ) or not? The more complex one would probably be to find out which signal in the array are driven in a combinatorical process, and then seperate these signals from the array so that these signals can be defined as "wire" and the other remaining can be defined as "reg". Then a warning during conversion can be writen which says: "Warning: You are overiting initial values in a combinatorical process (initial value is usless in this case)" -> ;) Sorry i didn't recognized this since i wasn't encountering this case. greeting Norbo |
|
From: Christopher F. <chr...@gm...> - 2012-04-26 03:49:24
|
On 4/25/12 8:30 AM, Norbo wrote: > >>> The initial values for the array signal are enough for a synthesizable >>> approach. >>> The Function with is used in the VHDL code is just another way which can >>> be used to give the >>> signals in the array there initial values in a more procedural way (for >>> vhdl). If you have the procedure >>> wich gives the values in python, you can write the initial values in >>> vhdl >>> to the array directly. > >> Is this true for Verilog and VHDL? And is it true across multiple >> vendor tools? IMO the actual creation of the pre-init RAM is less >> important, unless widely advertised, than wide support of pre-init. >> Reworded, adding the init support even if it doesn't support pre-init >> RAM in the vendor synthesis is ok, IMO. > ...... > ...... >> But to clarify, you do not see initial value errors with Verilog in >> Quartus? > > I looked at it more closely now, and here is what i found : > Bassicaly a signal array with initial value can be used, meaningfull in > the following scenarios: > > 1. reading it from a combinatorical process > -> vhdl synthesis works& verilog syntesis works (but signal array > must be defined as "reg") > > 2. reading it synchron (clocked) > -> vhdl synthesis works& verilog syntesis works (but signal array must > be defined as "reg") > > 3. reading it synchron (clocked) and writing it synchron > -> vhdl synthesis works& verilog synthesis works (signal array is > allready defined as "reg") > > 4. reading it synchron (clocked) and writing it in a combinatorical process > -> vhdl synthesis works& verilog synthesis doesnt work !!! (because > signal cant be defined as reg when you write to in a combinatorical > process. So if you write to just one signal in the array the whole array > needs to be defined as wire and you cant use the > initial statment for that signal array, so you cant initialize all the > other signals which are not written in a combinatorical process. > it normally makes sense that if you have a inital value in a signal that > you are not allowed to overwrite it immidiatly with an combinatorical > assignment. > But the problem is that if you just use one signal of the array to write > to it in a combinatorical process, you "lose" the hole array. > > Addition: "if there is a asynchron reset in a clocked process where you > assign on of the array signals a reset value, then the verilog synthesis > works with the initialized array" This is an alternative to the initial block initial values (pre-init RAM)? > > 5. reading and writing in a combinatorical process > same problem in verilog -> you cant have the signal array be defined as > "wire" and use the init block statment in verilog. > Or in other words: If the signal array is defined as "reg" you cannot > write to it in a combinatorical process. > In the above can you clarify between what synthesizes and what creates RAM/ROM as expected. As we discovered with Quartus, it will not use a BRAM for a ROM when an always_comb is used to describe a ROM, the ROM needs to be clocked. But this does not seem to be the case for the Xilinx tools. One case is that is synthesizes and no BRAM used the other is synthesizes and BRAM used. We might want to create a wiki page with a table and summarize these results. The question would be where on the wiki, as a simple project page, a RAM/ROM cookbook page, or an FAQ page? Regards, Chris |
×
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