myhdl-list Mailing List for MyHDL (Page 183)
Brought to you by:
jandecaluwe
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(14) |
Nov
(4) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(1) |
Feb
(10) |
Mar
(19) |
Apr
(14) |
May
(1) |
Jun
(4) |
Jul
(10) |
Aug
|
Sep
(2) |
Oct
(7) |
Nov
(17) |
Dec
(12) |
2005 |
Jan
(6) |
Feb
(10) |
Mar
(17) |
Apr
(10) |
May
(9) |
Jun
(5) |
Jul
(26) |
Aug
(34) |
Sep
(10) |
Oct
(38) |
Nov
(71) |
Dec
(74) |
2006 |
Jan
(20) |
Feb
(20) |
Mar
(7) |
Apr
(2) |
May
(13) |
Jun
|
Jul
|
Aug
(4) |
Sep
(37) |
Oct
(43) |
Nov
(30) |
Dec
(33) |
2007 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(30) |
Jun
(9) |
Jul
(1) |
Aug
|
Sep
(8) |
Oct
(13) |
Nov
|
Dec
(4) |
2008 |
Jan
(13) |
Feb
(46) |
Mar
(25) |
Apr
(7) |
May
(20) |
Jun
(73) |
Jul
(38) |
Aug
(47) |
Sep
(24) |
Oct
(18) |
Nov
(9) |
Dec
(36) |
2009 |
Jan
(31) |
Feb
(24) |
Mar
(73) |
Apr
(13) |
May
(47) |
Jun
(28) |
Jul
(36) |
Aug
(2) |
Sep
(5) |
Oct
(8) |
Nov
(16) |
Dec
(29) |
2010 |
Jan
(34) |
Feb
(18) |
Mar
(18) |
Apr
(5) |
May
|
Jun
(24) |
Jul
(53) |
Aug
(3) |
Sep
(18) |
Oct
(33) |
Nov
(19) |
Dec
(15) |
2011 |
Jan
(9) |
Feb
(4) |
Mar
(39) |
Apr
(213) |
May
(86) |
Jun
(46) |
Jul
(22) |
Aug
(11) |
Sep
(78) |
Oct
(59) |
Nov
(38) |
Dec
(24) |
2012 |
Jan
(9) |
Feb
(22) |
Mar
(89) |
Apr
(55) |
May
(222) |
Jun
(86) |
Jul
(57) |
Aug
(32) |
Sep
(49) |
Oct
(69) |
Nov
(12) |
Dec
(35) |
2013 |
Jan
(67) |
Feb
(39) |
Mar
(18) |
Apr
(42) |
May
(79) |
Jun
(1) |
Jul
(19) |
Aug
(18) |
Sep
(54) |
Oct
(79) |
Nov
(9) |
Dec
(26) |
2014 |
Jan
(30) |
Feb
(44) |
Mar
(26) |
Apr
(11) |
May
(39) |
Jun
(1) |
Jul
(89) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
(20) |
Dec
(27) |
2015 |
Jan
(107) |
Feb
(106) |
Mar
(130) |
Apr
(90) |
May
(147) |
Jun
(28) |
Jul
(53) |
Aug
(16) |
Sep
(23) |
Oct
(7) |
Nov
|
Dec
(16) |
2016 |
Jan
(86) |
Feb
(41) |
Mar
(38) |
Apr
(31) |
May
(37) |
Jun
(11) |
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
(1) |
Nov
(5) |
Dec
(3) |
2017 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
2018 |
Jan
(1) |
Feb
(1) |
Mar
(7) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(3) |
Dec
|
2020 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(12) |
Dec
(11) |
2022 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2023 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2024 |
Jan
(1) |
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jan D. <ja...@ja...> - 2005-09-05 09:35:18
|
Tom Dillon wrote: > Jan Decaluwe wrote: >> >> Back to our original issue: if as user wants set >> the instance name to another value than the default, >> the usage model would be: >> >> toVerilog.name = "myInstanceName" >> inst = toVerilog(func, *args, **kwargs) >> >> I'm inclined to implement it like that - so hurry >> with feedback if you want to stop me :-) > This would work, although it seems like logically a class is better for > that. I wouldn't think to set an attribute to a function, even though > python supports it. I am OK with it though, would get used to it, and > probably learn and use that feature of python in other circumstances. Perhaps we have a misunderstanding? In the code above, toVerilog actually is an instance of a ToVerilogConvertor class. So you do get all the goodies of classes, instances, and attributes. However, the class would support the special __call__ attribute, which means you can call toVerilog as if it were a function. When I think of it further, I think this way to do it provides the right balance between backward compatibility and additional power required to customize toVerilog's behavior. > Let me throw in a couple more ideas: > > a 2nd function, > > inst = toVerilogNamed(func,name,*args,**kwargs) > > or just changing toVerilog to that format, throwing backward > compatibility to the wind. You could allow "" or None to use the default > as it is now. If find neither proposal attractive. It is very well possible that we will want to support additonal options than "name" in the future. The proposals above don't address that. Moreover, I believe that default usage should really be as simple as going from: inst = func(*args, **kwargs) to: inst = toVerilog(func, *args, **kwargs) without having to explain about additional capabilities. For many users and in many cases, this usage will be enough. It is appropriate that the more sophisticated user needs to learn a little more (e.g. that toVerilog is actually in instance). Jan -- Jan Decaluwe - Resources bvba - http://jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium Using Python as a hardware description language: http://jandecaluwe.com/Tools/MyHDL/Overview.html |
From: Tom D. <td...@di...> - 2005-09-02 20:34:13
|
Jan Decaluwe wrote: > Ok - so we need another way to parametrize toVerilog's behavior. > Note that until now I have been able to avoid "options" to > the convertor, but at some point that may become unavoidable. > So we need a general way support options, and "name" would > be the first supported option. > > One could think of using function attributes, e.g. > toVerilog.name = "topname" > However, with normal functions, this has a similar problem, > as they have non-hidden attributes that we don't want to > touch, e.g. func_name. > > What we would do is to create a ToVerilogConvertor class, > that defines the supported option names as attributes. > It would have a __call__ interface and toVerilog would > become an instance of that class, so that its behavior > would remain as it is now (except for the difference in > instance name inference, as discussed earlier.) > > An advantage would be that the supported attributes > can be managed attributes (properties) so that we can > do any type of checking on them. Another advantage > (in the future) is that a user could create other > convertor instances with the options set to other > values, e.g. toVerilogForXilinx. > > Back to our original issue: if as user wants set > the instance name to another value than the default, > the usage model would be: > > toVerilog.name = "myInstanceName" > inst = toVerilog(func, *args, **kwargs) > > I'm inclined to implement it like that - so hurry > with feedback if you want to stop me :-) This would work, although it seems like logically a class is better for that. I wouldn't think to set an attribute to a function, even though python supports it. I am OK with it though, would get used to it, and probably learn and use that feature of python in other circumstances. Let me throw in a couple more ideas: a 2nd function, inst = toVerilogNamed(func,name,*args,**kwargs) or just changing toVerilog to that format, throwing backward compatibility to the wind. You could allow "" or None to use the default as it is now. Tom |
From: Jan D. <ja...@ja...> - 2005-09-02 19:47:51
|
Tom Dillon wrote: > Jan Decaluwe wrote: > >> >> I propose to drop the current instance name inference mechanism. >> Instead, I would use func.func_name as the default name. >> (This is the name that appears in the def statement). >> Technically, this is more correct, as the Verilog file >> doesn't contain an instance, but a module. >> >> Additionally, a named parameter "name" would be introduced >> in toVerilog, that can be used to override the default name >> in any desired way. > > > That would work great, if you don't like the default name you can > substitute in what you want. > > Can you do this in python? > def toVerilog(func,name=None, *args,**kwargs) > > It seems like > > toVerilog(add,"addTopName",x,a,b,clk) > > Could get name and *args confused? Maybe I'm confused... No, you're right, it can't work like that. I thought of using a keyword argument "name" but that would end up in **kwargs, and we want to use that for named association with ports. Ok - so we need another way to parametrize toVerilog's behavior. Note that until now I have been able to avoid "options" to the convertor, but at some point that may become unavoidable. So we need a general way support options, and "name" would be the first supported option. One could think of using function attributes, e.g. toVerilog.name = "topname" However, with normal functions, this has a similar problem, as they have non-hidden attributes that we don't want to touch, e.g. func_name. What we would do is to create a ToVerilogConvertor class, that defines the supported option names as attributes. It would have a __call__ interface and toVerilog would become an instance of that class, so that its behavior would remain as it is now (except for the difference in instance name inference, as discussed earlier.) An advantage would be that the supported attributes can be managed attributes (properties) so that we can do any type of checking on them. Another advantage (in the future) is that a user could create other convertor instances with the options set to other values, e.g. toVerilogForXilinx. Back to our original issue: if as user wants set the instance name to another value than the default, the usage model would be: toVerilog.name = "myInstanceName" inst = toVerilog(func, *args, **kwargs) I'm inclined to implement it like that - so hurry with feedback if you want to stop me :-) Jan -- Jan Decaluwe - Resources bvba - http://jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium Using Python as a hardware description language: http://jandecaluwe.com/Tools/MyHDL/Overview.html |
From: Tom D. <td...@di...> - 2005-09-01 21:07:31
|
Jan Decaluwe wrote: > > I propose to drop the current instance name inference mechanism. > Instead, I would use func.func_name as the default name. > (This is the name that appears in the def statement). > Technically, this is more correct, as the Verilog file > doesn't contain an instance, but a module. > > Additionally, a named parameter "name" would be introduced > in toVerilog, that can be used to override the default name > in any desired way. That would work great, if you don't like the default name you can substitute in what you want. Can you do this in python? def toVerilog(func,name=None, *args,**kwargs) It seems like toVerilog(add,"addTopName",x,a,b,clk) Could get name and *args confused? Maybe I'm confused... > > [For completeness: the current implementation also infers > the name if it is subscripted, e.g. inst[0]. But this > is probably an exotic feature that nobody uses and > therefore would not be missed.] You could still use name="inst[%s]"%i or something like that to take care of that. BTW, I never did figure out in Python how to make a dynamic variable name. I gave up and hacked my local copy of MyHDL to pass a sting to toVerilog with the name. Tom |
From: Tom D. <td...@di...> - 2005-09-01 20:51:20
|
I agree with you dislike for tri-states. I like the fact that a None signal causes a problem that you have to fix=20 before your simulation works. If we are talking about I/O tri-states, then it can easily be solved=20 with an HDL wrapper and bringing out of the MyHDL code the date_o,=20 data_i and data_oe signals. Tom Jan Decaluwe wrote: > Jos=E9 Pedro Matos wrote: > >> hello to all. >> >> Is any solution for the tristate question been resolved? > > > Bom dia, tudo bem? :-) > > Not much has been done - I still hate tristates as much as then :-) > However, in the development version, I have started to support None as > as a value for an intbv slice, by removing the bound checks if > the value is None. This was done to support things like: > > intbv()[8:] > > in list of signal definitions (for memory inference in toVerilog). > >> >> The first example that i make in verilog and in vhdl is to put a value >> in the data bus when READ_Z and ChipSelect_Z go down and then put the >> bus in high impedance when the chip is not selected. I see it work fin= e. >> I'm happy. >> >> I tried to generate the same hdl in myhdl. Not happy. >> >> I would like to use myhdl, because python is on my self-learning path, >> because for what i've read i believe in xp programming and i see lot o= f >> good things comming from python people. >> >> Can someone help me? >> I could try hack the code. Has someone done that? > > > Hacking the code is fine, a discussion on how things should work, > in full detail, even better :-) > >> Why there is no CVS for this project? > > > (Note: I do use CVS locally to manage the source code.) > > To main reasons why there is not yet a public CVS repository: > > 1. In my judgement, it was not the most urgent functionality > for the project, considering the stage it is in. > 2. I hoped that by the time a public repo would be useful, there > would be a better alternative to CVS available, perhaps a > distributed version control system. > > Best regards, > > Jan > |
From: Jan D. <ja...@ja...> - 2005-09-01 20:40:39
|
José Pedro Matos wrote: > hello to all. > > Is any solution for the tristate question been resolved? Bom dia, tudo bem? :-) Not much has been done - I still hate tristates as much as then :-) However, in the development version, I have started to support None as as a value for an intbv slice, by removing the bound checks if the value is None. This was done to support things like: intbv()[8:] in list of signal definitions (for memory inference in toVerilog). > > The first example that i make in verilog and in vhdl is to put a value > in the data bus when READ_Z and ChipSelect_Z go down and then put the > bus in high impedance when the chip is not selected. I see it work fine. > I'm happy. > > I tried to generate the same hdl in myhdl. Not happy. > > I would like to use myhdl, because python is on my self-learning path, > because for what i've read i believe in xp programming and i see lot of > good things comming from python people. > > Can someone help me? > I could try hack the code. Has someone done that? Hacking the code is fine, a discussion on how things should work, in full detail, even better :-) > Why there is no CVS for this project? (Note: I do use CVS locally to manage the source code.) To main reasons why there is not yet a public CVS repository: 1. In my judgement, it was not the most urgent functionality for the project, considering the stage it is in. 2. I hoped that by the time a public repo would be useful, there would be a better alternative to CVS available, perhaps a distributed version control system. Best regards, Jan -- Jan Decaluwe - Resources bvba - http://jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium Using Python as a hardware description language: http://jandecaluwe.com/Tools/MyHDL/Overview.html |
From: Jan D. <ja...@ja...> - 2005-09-01 20:18:50
|
Tom Dillon wrote: > I was trying to develop a class to handle the details of synthesizing a > MyHDL function. This was all fine except for one thing that I am stuck on. > > To use toVerilog, you do: > > topName = toVerilog(func,*args,**kwargs) > > I could not get this to work with a dynamic topName. I tried the > following and some other attempts as well. > > exec('%s = toVerilog(func,*args,**kwargs)'%(name) > > func, is the name of the MyHDL function to use, *args, **kwargs are the > signal and parameter connections to that function. name is a string > representation of what the top level name should be. > > I don't think this is a python limitation, either my error or because > of how toVerilog figures out the top level name. > > Any ideas? Yes - it's ugly and it is caused by my exagerated attempts to make things "easier" for a user :-) My goal was to encourage the user to simulate the converted design (because good simulation catches more errors than the convertor does.) That's why toVerilog returns an instance, and why I wanted to use the instance name when naming the converted Verilog files. So, in: topName = toVerilog(func,*args,**kwargs) I need to find the string "topName". If you think about it, you'll understand why this gets ugly. toVerilog does crazy things: it gets its own frame info, finds the source file, gets to the line of its own call, and parses that to get the instance name ... And of course, this all fails when the scheme above is not followed (e.g. when not using the returned instance value, or with dynamic naming). So I apologize :-) and propose to change this to something less "clever". Now, an issue to consider is that this would introduce some backward incompability. So, to all those interested: please review the following proposal carefully and provide feedback. I propose to drop the current instance name inference mechanism. Instead, I would use func.func_name as the default name. (This is the name that appears in the def statement). Technically, this is more correct, as the Verilog file doesn't contain an instance, but a module. Additionally, a named parameter "name" would be introduced in toVerilog, that can be used to override the default name in any desired way. For consistency, a similar thing should be done with traceSignals. This solution would be more general with much simpler code. However, as I said, existing code would need to be modified as the Verilog files will have different names than before (by default). [For completeness: the current implementation also infers the name if it is subscripted, e.g. inst[0]. But this is probably an exotic feature that nobody uses and therefore would not be missed.] Feedback welcome. Jan -- Jan Decaluwe - Resources bvba - http://jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium Using Python as a hardware description language: http://jandecaluwe.com/Tools/MyHDL/Overview.html |
From: P. M. <jos...@pt...> - 2005-08-31 14:31:08
|
################################################################# # brouter.py EXAMPLE code ################################################################# from __future__ import generators from myhdl import Signal, Simulation, delay, traceSignals, intbv, toVerilog def brouter( clk, clk2m, mclk, cs_z, liu_thz, rd_z, dados, teste, rs232_tx, rs232_rx, addr): """ brouter um exemplo simples em myhdl input clk; CLK_CPU input clk2m; CLK_2048MHz output mclk; CLK_LIU_MCLK input cs_z; CS_FPGA_Z output liu_thz; LIU_TH_Z input rd_z; RD_Z inout [7:0] dados; DADOS output teste; pino de test output rs232_rx; RX uC porta serie 2 input rs232_tx; TX uC porta serie 2 input [19:0] addr; ADDR """ # teste.next = clk.val # mclk.next = clk2m.val # liu_thz.next = intbv(0)[1:] # rs232_rx.next = rs232_tx.val def brouterProcess(): while 1: yield cs_z, rd_z if (cs_z == 0) and (rd_z == 0): dados.next = intbv(0xA5)[8:] else: dados.next = intbv(None)[8:] #high impedance assign return brouterProcess() clk= Signal(bool(0)) clk2m= Signal(bool(1)) mclk = Signal(bool(0)) cs_z = Signal(bool(1)) liu_thz = Signal(bool(1)) rd_z = Signal(bool(1)) dados = Signal(intbv(0)[8:]) teste = Signal(bool(0)) rs232_tx = Signal(bool(1)) rs232_rx = Signal(bool(0)) addr = Signal(intbv(0)[20:]) dados.next = intbv(val=None,_nrbits=8) dados.next = intbv(None)[8:] if dados.val._nrbits == 0: print "len: 0\n" else: print "len: %d \n" % (dados.val._nrbits) br_inst= toVerilog(brouter, clk, clk2m, mclk, cs_z, liu_thz, rd_z, dados, teste, rs232_tx, rs232_rx, addr) ################################################################# # GENERATED CODE ################################################################# module br_inst ( clk, clk2m, mclk, cs_z, liu_thz, rd_z, dados, teste, rs232_tx, rs232_rx, addr ); input clk; input clk2m; input mclk; input cs_z; input liu_thz; input rd_z; output [7:0] dados; reg [7:0] dados; input teste; input rs232_tx; input rs232_rx; input [19:0] addr; always @(cs_z or rd_z) begin: _MYHDL1_BLOCK if (((cs_z == 0) && (rd_z == 0))) begin dados <= 8'ha5; end else begin dados <= 8'hZ; end end endmodule ############################ CUT ME ############################# # _intbv.py.patch ############################ CUT ME ############################# jmatos - ~/work/hdl/myhdl-0.4.1/myhdl $ diff -u --new-file _intbv.py /usr/lib/python2.3/site-packages/myhdl/_intbv.py --- _intbv.py 2004-12-29 13:37:59.000000000 +0000 +++ /usr/lib/python2.3/site-packages/myhdl/_intbv.py 2005-08-31 13:54:36.000000000 +0000 @@ -71,14 +71,13 @@ min = property(_get_min, None) def _checkBounds(self): - if self._max is not None: - if self._val >= self._max: - raise ValueError("intbv value %s >= maximum %s" % - (self._val, self._max)) - if self._min is not None: - if self._val < self._min: - raise ValueError("intbv value %s < minimum %s" % - (self._val, self._min)) + if self._val is not None: + if self._max is not None: + if self._val >= self._max: + raise ValueError("intbv value %s >= maximum %s" % (self._val, self._max)) + if self._min is not None: + if self._val < self._min: + raise ValueError("intbv value %s < minimum %s" % (self._val, self._min)) # hash @@ -113,7 +112,10 @@ def __getitem__(self, key): if isinstance(key, int): i = key - res = intbv((self._val >> i) & 0x1, _nrbits=1) + if self._val is None: + res= intbv(None,_nrbits=1) + else: + res = intbv((self._val >> i) & 0x1, _nrbits=1) return res elif isinstance(key, slice): i, j = key.start, key.stop @@ -127,7 +129,10 @@ if i <= j: raise ValueError, "intbv[i:j] requires i > j\n" \ " i, j == %s, %s" % (i, j) - res = intbv((self._val & (1L << i)-1) >> j, _nrbits=i-j) + if self._val is None: + res= intbv(None,_nrbits=i-j) + else: + res = intbv((self._val & (1L << i)-1) >> j, _nrbits=i-j) return res else: raise TypeError("intbv item/slice indices should be integers") ############ CUT ME ############################################### ############ CUT ME ############################################### # _convert.py.patch ############ CUT ME ############################################### jmatos - ~/work/hdl/myhdl-0.4.1/myhdl $ diff -u _toVerilog/_convert.py /usr/lib/python2.3/site-packages/myhdl/_toVerilog/_convert.py --- _toVerilog/_convert.py 2004-12-24 13:35:02.000000000 +0000 +++ /usr/lib/python2.3/site-packages/myhdl/_toVerilog/_convert.py 2005-08-31 13:58:31.000000000 +0000 @@ -654,7 +654,10 @@ node.expr.node.obj is intbv: c = self.getVal(node) self.write("%s'h" % c._nrbits) - self.write("%x" % c._val) + if c._val is not None: + self.write("%x" % c._val) + else: + self.write("Z") return self.visit(node.expr) self.write("[") ############ CUT ME ############################################### |
From: P. M. <jos...@pt...> - 2005-08-31 11:28:37
|
hello to all. Is any solution for the tristate question been resolved? The first example that i make in verilog and in vhdl is to put a value in the data bus when READ_Z and ChipSelect_Z go down and then put the bus in high impedance when the chip is not selected. I see it work fine. I'm happy. I tried to generate the same hdl in myhdl. Not happy. I would like to use myhdl, because python is on my self-learning path, because for what i've read i believe in xp programming and i see lot of good things comming from python people. Can someone help me? I could try hack the code. Has someone done that?=20 Why there is no CVS for this project? -- Jos=E9 Pedro Matos |
From: Jan D. <ja...@ja...> - 2005-08-25 09:25:01
|
--- Günter Dannoritzer <dan...@we...> wrote: > Hi, > > I started using the logging module of python to > print out debugging > information instead of just using print functions. > The nice feature > about this is that the logging information can be > left in the code and > just disabled by setting the level to what level > should print out > accordingly. > > However, it seems like toVerilog does not like > logging entries, as it > canceled on them with an Assertion Error. This is > maybe not only a > logging problem as there are many other python > modules that could be > included in code. Off course there is the question > how much sense it > makes to include modules in a part of code that is > meant for being > translated by toVerilog anyway. Currently, what you can do is include code to be ignored in an if __debug__ statement. This was included in 0.4.1 but the manual was not updated with that release. Browse the RFE section on SourceForge for (closed) issues. Jan > > I was just wondering whether it would be beneficial > to have some type of > ignore function that allows to specify modules that > should be ignored by > toVerilog? So for example if I do a: > > import logging > > > I can do > > myhdl.ignore(logging) > > > and toVerilog will ignore any statements of the > type: > > logging.debug(...) > > > Regards, > > Guenter > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software > Conference & EXPO > September 19-22, 2005 * San Francisco, CA * > Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects > & Teams * Testing & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
From: Jan D. <ja...@ja...> - 2005-08-25 09:10:33
|
--- Tom Dillon <td...@di...> wrote: > Jan, > > This version works very well. All list of signals > troubles are fixed. > > The only trouble I'm having is with dual port ROMs. > I am checking to see > how to fix that. I don't think the dual case > statement is the answer. What is the Verilog coding style to infer this, if any? I see the issue: expansion into a case removes info and makes it hard to infer that this can be "shared" resource. The Verilog code would have to keep the info about the original list in some way. Using a function perhaps?` Jan > > Thanks for the new features, they are very useful. > > Tom > > > > > Jan Decaluwe wrote: > > > Hi all: > > > > Attached you find a snapshot of the myhdl > development tree. The > > goal is to implement ROM inference from toVerilog > output. This > > snapshot is for testing purposes. > > > > Release notes > > ============= > > > > The requirements to infer ROMs from toVerilog > output were discussed > > recently. See the discussions elsewhere in the > mailing list for > > more background. > > > > A tuple of ints is conceptually viewed as a ROM, > and indexing it > > is viewed as accessing the ROM. If such indexing > is the RHS of > > an assignment, that assignment is mapped to a case > statement > > in Verilog, with a case item per address. This is > done because > > certain synthesis tools know how to map such code > into a ROM. > > > > The tuple of ints can be defined at the same > places where signals > > can be defined, that is, outside generators. > (Note: > > everything outside a generator is "elaborated" by > the Python > > intepreter.) > > > > This snapshot also changes the rules for mapping > lists of signals > > to memories in the Verilog output. Only lists of > "anonymous" signals > > (signals that don't have a name at any > hierarchical level) are > > mapped to memories. This preserves both the older > functionality > > and the new functionality for RAM inference. > > > > Note: in the near future, I won't use the mailing > list for snapshots, > > but the MyHDL web site once it has been > "wikified". > > > > Installation > > ============ > > > > This snapshot should be installed as a replacement > of the myhdl > > subdirectory in the installation directory. > > > > Regards, > > > > Jan > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software > Conference & EXPO > September 19-22, 2005 * San Francisco, CA * > Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects > & Teams * Testing & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
From: <dan...@we...> - 2005-08-23 09:57:01
|
Hi, I started using the logging module of python to print out debugging information instead of just using print functions. The nice feature about this is that the logging information can be left in the code and just disabled by setting the level to what level should print out accordingly. However, it seems like toVerilog does not like logging entries, as it canceled on them with an Assertion Error. This is maybe not only a logging problem as there are many other python modules that could be included in code. Off course there is the question how much sense it makes to include modules in a part of code that is meant for being translated by toVerilog anyway. I was just wondering whether it would be beneficial to have some type of ignore function that allows to specify modules that should be ignored by toVerilog? So for example if I do a: import logging I can do myhdl.ignore(logging) and toVerilog will ignore any statements of the type: logging.debug(...) Regards, Guenter |
From: Tom D. <td...@di...> - 2005-08-22 18:22:08
|
I was trying to develop a class to handle the details of synthesizing a MyHDL function. This was all fine except for one thing that I am stuck on. To use toVerilog, you do: topName = toVerilog(func,*args,**kwargs) I could not get this to work with a dynamic topName. I tried the following and some other attempts as well. exec('%s = toVerilog(func,*args,**kwargs)'%(name) func, is the name of the MyHDL function to use, *args, **kwargs are the signal and parameter connections to that function. name is a string representation of what the top level name should be. I don't think this is a python limitation, either my error or because of how toVerilog figures out the top level name. Any ideas? Thanks, Tom |
From: Tom D. <td...@di...> - 2005-08-22 17:53:48
|
Jan, This version works very well. All list of signals troubles are fixed. The only trouble I'm having is with dual port ROMs. I am checking to see how to fix that. I don't think the dual case statement is the answer. Thanks for the new features, they are very useful. Tom Jan Decaluwe wrote: > Hi all: > > Attached you find a snapshot of the myhdl development tree. The > goal is to implement ROM inference from toVerilog output. This > snapshot is for testing purposes. > > Release notes > ============= > > The requirements to infer ROMs from toVerilog output were discussed > recently. See the discussions elsewhere in the mailing list for > more background. > > A tuple of ints is conceptually viewed as a ROM, and indexing it > is viewed as accessing the ROM. If such indexing is the RHS of > an assignment, that assignment is mapped to a case statement > in Verilog, with a case item per address. This is done because > certain synthesis tools know how to map such code into a ROM. > > The tuple of ints can be defined at the same places where signals > can be defined, that is, outside generators. (Note: > everything outside a generator is "elaborated" by the Python > intepreter.) > > This snapshot also changes the rules for mapping lists of signals > to memories in the Verilog output. Only lists of "anonymous" signals > (signals that don't have a name at any hierarchical level) are > mapped to memories. This preserves both the older functionality > and the new functionality for RAM inference. > > Note: in the near future, I won't use the mailing list for snapshots, > but the MyHDL web site once it has been "wikified". > > Installation > ============ > > This snapshot should be installed as a replacement of the myhdl > subdirectory in the installation directory. > > Regards, > > Jan > |
From: Jan D. <ja...@ja...> - 2005-08-19 16:02:05
|
Hi all: Attached you find a snapshot of the myhdl development tree. The goal is to implement ROM inference from toVerilog output. This snapshot is for testing purposes. Release notes ============= The requirements to infer ROMs from toVerilog output were discussed recently. See the discussions elsewhere in the mailing list for more background. A tuple of ints is conceptually viewed as a ROM, and indexing it is viewed as accessing the ROM. If such indexing is the RHS of an assignment, that assignment is mapped to a case statement in Verilog, with a case item per address. This is done because certain synthesis tools know how to map such code into a ROM. The tuple of ints can be defined at the same places where signals can be defined, that is, outside generators. (Note: everything outside a generator is "elaborated" by the Python intepreter.) This snapshot also changes the rules for mapping lists of signals to memories in the Verilog output. Only lists of "anonymous" signals (signals that don't have a name at any hierarchical level) are mapped to memories. This preserves both the older functionality and the new functionality for RAM inference. Note: in the near future, I won't use the mailing list for snapshots, but the MyHDL web site once it has been "wikified". Installation ============ This snapshot should be installed as a replacement of the myhdl subdirectory in the installation directory. Regards, Jan -- Jan Decaluwe - Resources bvba - http://jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium Using Python as a hardware description language: http://jandecaluwe.com/Tools/MyHDL/Overview.html |
From: Tom D. <td...@di...> - 2005-08-19 15:21:39
|
Jan Decaluwe wrote: > Tom Dillon wrote: > > > No, I mean that the tuple will not be mapped to something in Verilog. > All constants from the tuple will be directly put at the appropriate > place in the Verilog case statement, like so: > > # in MyHDL: theTuple = (72, 35, 9, 109 ...) > > // Verilog output > .... > always @(posedge clk) begin: RL > // ROM > case (addr) > 0: dout <= 72; > 1: dout <= 35; > 2: dout <= 9; > 3: dout <= 194; > ... > > Is that OK? Yes. > > Ok, I'll make the last one the default. I'll include the synthesis > pragma's for now - I don't see how they can hurt and perhaps other > tools need them. Sounds, good. I will run it through all the tools we have to test it. > >> I would love to give it a try. Also if it includes the list of >> signals fix from the previous posting that would be very useful. > > > Yes, I'll prepare a snapshot with that fix and the ROM support. Great. Tom |
From: Jan D. <ja...@ja...> - 2005-08-19 14:57:44
|
Tom Dillon wrote: >> >> Now for the details: >> >> It's not necessary to use an additional memL object - the code could >> just simply refer to the defining list dataL instead. That list would >> not be present in Verilog - all constants would be directly present >> in the code. I assume that's Ok for the synthesis tools? > > > This sounds like a great idea. > > When you say directly present in the code, you mean in the MyHDL source, > correct? No, I mean that the tuple will not be mapped to something in Verilog. All constants from the tuple will be directly put at the appropriate place in the Verilog case statement, like so: # in MyHDL: theTuple = (72, 35, 9, 109 ...) // Verilog output .... always @(posedge clk) begin: RL // ROM case (addr) 0: dout <= 72; 1: dout <= 35; 2: dout <= 9; 3: dout <= 194; ... Is that OK? >> About the case statement: should it have synthesis attributes like >> parallel_case, full_case? Should there be a default fallback or >> not? > > > The cases are mutually exclusive since a unique address selects each > one. I have have never put attribute on them and they get inferred fine. > > You should only have enough cases as the length of the tuple, since if > your address is bigger synthesis will figure out you don't use them all > optimize the rom. This is important since not all roms end up in built > in memories, sometimes in combinatorial logic or registers. > > So I would either use the default for the last one, or leave it out. > Leaving it out will probably produce a synthesis warning. Ok, I'll make the last one the default. I'll include the synthesis pragma's for now - I don't see how they can hurt and perhaps other tools need them. > I would love to give it a try. Also if it includes the list of signals fix from the previous posting that would be very useful. Yes, I'll prepare a snapshot with that fix and the ROM support. Jan -- Jan Decaluwe - Resources bvba - http://jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium Using Python as a hardware description language: http://jandecaluwe.com/Tools/MyHDL/Overview.html |
From: Tom D. <td...@di...> - 2005-08-19 14:22:49
|
Jan Decaluwe wrote: > > I like this. It is a feature where conversion can have an additional > productivity advantage, as as lists/tuples of constants are easier > to create and maintain in Python than in Verilog. Yes, we now build roms from a python script for just that reason. > > Now for the details: > > It's not necessary to use an additional memL object - the code could > just simply refer to the defining list dataL instead. That list would > not be present in Verilog - all constants would be directly present > in the code. I assume that's Ok for the synthesis tools? This sounds like a great idea. When you say directly present in the code, you mean in the MyHDL source, correct? In Verilog you would need the case statement addressed by the index and outputting the value from the rom on a wire that would connect to where it was needed. > > There's no need for these constants to be intbv's - plain int's > are just fine and easier. I think ints would be OK for the right side of the assignment in Verilog since it can figure out the width from the left. > > So in short: a tuple of ints used in an assignment in the way you > described, would be expanded into an equivalent case statement. > > About the case statement: should it have synthesis attributes like > parallel_case, full_case? Should there be a default fallback or > not? The cases are mutually exclusive since a unique address selects each one. I have have never put attribute on them and they get inferred fine. You should only have enough cases as the length of the tuple, since if your address is bigger synthesis will figure out you don't use them all optimize the rom. This is important since not all roms end up in built in memories, sometimes in combinatorial logic or registers. So I would either use the default for the last one, or leave it out. Leaving it out will probably produce a synthesis warning. > > All the above will come without additional effort. The high-level > assignment will be mapped to a case statement, and all context > that surrounds it will be there as usual. Dual port roms as well? That is great. > > I have an initial implementation ready along the lines above and > I could generate a new snapshot. If there is feedback, send it > quickly because next week I have another assignment. I would love to give it a try. Also if it includes the list of signals fix from the previous posting that would be very useful. Tom |
From: Jan D. <ja...@ja...> - 2005-08-19 10:47:44
|
Tom Dillon wrote: > ROMs are also needed and easy to infer in synthesis. It would be very > good if the following would produce a case statement in Verilog: > > def rom(dout,addr,clk=None,dataL=None) : > """ > rom : rom module > > Inputs: > addr : input address > clk : clock for synchronous roms, == None for async > Outputs: > dout : output port, width determines width of rom > Params: > dataL : list of values for rom, length is depth of rom > """ > > memL = [intbv(data,min=dout._min,max=dout._max) for data in dataL] > while 1: > yield posedge(clk) > dout.next = memL[int(addr)] > > > You would need to be able to figure out that the values in memL never > get modified after it is defined. > > The important thing here, is the memL define and the dout.next > assignment need to get mapped to a case statement: > > always @(posedge clk) > case(addr) : > 0 : dout <= dataL[0] ; > 1 : dout <= dataL[1] ; > . > . I like this. It is a feature where conversion can have an additional productivity advantage, as as lists/tuples of constants are easier to create and maintain in Python than in Verilog. Now for the details: It's not necessary to use an additional memL object - the code could just simply refer to the defining list dataL instead. That list would not be present in Verilog - all constants would be directly present in the code. I assume that's Ok for the synthesis tools? There's no need for these constants to be intbv's - plain int's are just fine and easier. To make sure that a list of constants cannot be modified outside the scope of toVerilog, I propose to use a tuple instead. Note that a tuple cannot be modified after creation, which maps nicely to the concept of a Rom. No doubt this may cause some initial confusion with users who use lists for everything, but I think it's worthwhile to document and explain this. Note that a tuple can easily be created from a list: t = tuple(AnyList) So in short: a tuple of ints used in an assignment in the way you described, would be expanded into an equivalent case statement. About the case statement: should it have synthesis attributes like parallel_case, full_case? Should there be a default fallback or not? > Now you may also want some control around this, or possibly asynchronous > so only the list needs to become the case statement, that case statement > may end up inside come control statements. Possibly a clock enable. > > This is very helpful. There are also dual port ROMs, so you would need > two case statements on the same list, with a separate address into the > list. All the above will come without additional effort. The high-level assignment will be mapped to a case statement, and all context that surrounds it will be there as usual. I have an initial implementation ready along the lines above and I could generate a new snapshot. If there is feedback, send it quickly because next week I have another assignment. Jan -- Jan Decaluwe - Resources bvba - http://jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium Using Python as a hardware description language: http://jandecaluwe.com/Tools/MyHDL/Overview.html |
From: Jan D. <ja...@ja...> - 2005-08-18 19:18:49
|
Tom Dillon wrote: > Jan, > > Thanks for the update. So far it is making memories properly including > true dual port rams with separate always blocks. I will run some more > cases over the next few days. > > One problem, it looks like all lists of signals are being mapped to > memory structures in Verilog, even true lists of signals as described in > 3.1.2 of the manual. Yes. I figured this would be a feature :-) > This won't synthesize properly and causes some > cosimulation problem, specifically slicing of one of the signals. Well spotted. I agree that this will cause problems. > Is it possible for you to distinguish between a list for memory and a > true list of signals? Yes. The difference is that a list intended for a memory will only contain "anonymous" signals. They can only be accessed through list indexing. In the other type of usage (as described in the manual) the signals in the list will have a regular signal name at other levels of the hierarchy. In this case, as the output Verilog code is flat, the convertor has to choose which name to keep and declare: the "memory" name, or the signal names. In the code snapshot, the "memory" name is kept when it is higher in the hierarchy. But this has problems as you point out. So instead, the signal names should always be used when available. For conversion purposes, such a list name cannot be referenced inside a generator - this will result in an error. I have already modified the code an checked it in. My test suite continues to run unchanged, but now again signals are used in the output of test_RandomScrambler.py. The code will be included in a future snapshot with additional features - but you can thus assume that it will work as desired. Regards, Jan -- Jan Decaluwe - Resources bvba - http://jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium Using Python as a hardware description language: http://jandecaluwe.com/Tools/MyHDL/Overview.html |
From: Jan D. <ja...@ja...> - 2005-08-18 18:23:01
|
Tom Dillon wrote: > Jan, > > Thanks for the update. So far it is making memories properly including > true dual port rams with separate always blocks. I will run some more > cases over the next few days. > > One problem, it looks like all lists of signals are being mapped to > memory structures in Verilog, even true lists of signals as described in > 3.1.2 of the manual. Yes. I figured this would be a feature :-) > This won't synthesize properly and causes some > cosimulation problem, specifically slicing of one of the signals. Well spotted. I agree that this will cause problems. > Is it possible for you to distinguish between a list for memory and a > true list of signals? Yes. The difference is that a list intended for a memory will only contain "anonymous" signals. They can only be accessed through list indexing. In the other type of usage (as described in the manual) the signals in the list will have a regular signal name at other levels of the hierarchy. In this case, as the output Verilog code is flat, the convertor has to choose which name to keep and declare: the "memory" name, or the signal names. In the code snapshot, the "memory" name is kept when it is higher in the hierarchy. But this has problems as you point out. So instead, the signal names should always be used when available. For conversion purposes, such a list name cannot be referenced inside a generator - this will result in an error. I have already modified the code an checked it in. My test suite continues to run unchanged, but now again signals are used in the output of test_RandomScrambler.py. The code will be included in a future snapshot with additional features - but you can thus assume that it will work as desired. Regards, Jan -- Jan Decaluwe - Resources bvba - http://jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium Using Python as a hardware description language: http://jandecaluwe.com/Tools/MyHDL/Overview.html |
From: <dan...@we...> - 2005-08-16 09:34:09
|
Hi, with the latest version of toVerilog I was able to implement a Dual-Port RAM with synchronous read (read through) with Xilinx ISE, using XST for synthesis. According to the XST manual there are certain Verilog templates, if they are recognized by XST it will implement them in block ram. For example, for the Dual-Port RAM with synchronous read the Verilog code should look like this: ---------------------------------------------------------------------- module raminfr (clk, we, a, dpra, di, spo, dpo); input clk; input we; input [4:0] a; input [4:0] dpra; input [3:0] di; output [3:0] spo; output [3:0] dpo; reg [3:0] ram [31:0]; reg [4:0] read_a; reg [4:0] read_dpra; always @(posedge clk) begin if (we) ram[a] <= di; read_a <= a; read_dpra <= dpra; end assign spo = ram[read_a]; assign dpo = ram[read_dpra]; endmodule ---------------------------------------------------------------------- I did the following implementation with MyHDL: ---------------------------------------------------------------------- def dp_ram_py(clk, we, addr, di, spo, dp_addr, dpo, d_width=8, a_width=2): memL = [Signal(intbv(0)[d_width:]) for i in range(2**a_width)] read_addr = Signal(intbv(0)[a_width:]) read_dp_addr = Signal(intbv(0)[a_width:]) def write(clk, we, addr, di, d_width=8, a_width=2): while 1: yield posedge(clk) if we: memL[int(addr)].next = di read_addr.next = addr read_dp_addr.next = dp_addr def read(read_addr, spo, read_dp_addr, dpo): def assign(): spo.next = memL[int(read_addr)] dpo.next = memL[int(read_dp_addr)] return always_comb(assign) rd = read(read_addr, spo, read_dp_addr, dpo) wr = write(clk, we, addr, di, d_width=8, a_width=2) return rd,wr ---------------------------------------------------------------------- turning that into Verilog code with toVerilog and implementing it with ISE, synthesis reported this: ========================================================================= * HDL Synthesis * ========================================================================= Synthesizing Unit <dp_ram>. Related source file is ../../rtl/verilog/dp_ram.v. Found 4x8-bit dual-port block RAM for signal <memL>. ----------------------------------------------------------------------- | mode | write-first | | | dual mode | write-first | | | aspect ratio | 4-word x 8-bit | | | clock | connected to signal <clk> | rise | | dual clock | connected to signal <clk> | rise | | write enable | connected to signal <we> | high | | address | connected to signal <addr> | | | dual address | connected to signal <dp_addr> | | | data in | connected to signal <di> | | | data out | connected to signal <spo> | | | dual data out | connected to signal <dpo> | | | ram_style | Auto | | ----------------------------------------------------------------------- Summary: inferred 1 RAM(s). Unit <dp_ram> synthesized. Cheers, Guenter |
From: Tom D. <td...@di...> - 2005-08-12 05:31:23
|
Jan, Thanks for the update. So far it is making memories properly including true dual port rams with separate always blocks. I will run some more cases over the next few days. One problem, it looks like all lists of signals are being mapped to memory structures in Verilog, even true lists of signals as described in 3.1.2 of the manual. This won't synthesize properly and causes some cosimulation problem, specifically slicing of one of the signals. Is it possible for you to distinguish between a list for memory and a true list of signals? Tom Jan Decaluwe wrote: > Hi all: > > Attached you find a snapshot of the myhdl development tree. The > goal is to implement RAM inference from toVerilog output. > > The purpose of this snapshot release is to get feedback from early > users that are willing to test this. As the implemented features are > especially useful in combination with the capabilities of external > tools, their feedback is essential. > > Release notes > ============= > > The requirements to infer RAM from toVerilog output were discussed > recently. Two features were implemented: > > 1. Support for lists of signals > ------------------------------- > Lists of Signals are now supported alongside Signals in the > hierarchy. They are mapped to Verilog memories. > > 2. Support to generate Verilog assign statements > ------------------------------------------------ > always_comb blocks that are simple enough are converted to a series of > assign statements, instead of a combinatorial always block. Note that > you do need to use always_comb for this feature; an explicit > combinatorial generator is not sufficient. > > Installation > ============ > > Several files have undergone changes; therefore the snapshot consists > of a complete myhdl package directory. This should be installed as a > replacement of the myhdl directory in the installed directory. > > This snapshot therefore contains several other (undocumented) features > and improvements outside the specific goal outlined above. Testers > should be aware of that and be careful, so that they can easily go > back if required. That being said, all the regression tests run fine, > of course. > > Implementation notes > ==================== > (Only for those who want to know more implementation details.) > > 1. Support for lists of signals > ------------------------------- > As always, I tried to make the implementation as general as > possible. Lists of Signals are now handled as a first-class object in > the hierarchy, alongside Signals. The Signal elements have the same > restrictions as ordinary Signals, and additional restrictions among > them. For example, they should all have the same type and bit width. > > In Python, it is easy to create lists that share elements. This can > obviously lead to problems in Verilog conversion. An attempt was made > to do meaningful things. Several error conditions were added and > checked to implement meaningful restrictions. But it is possible that > more will need to be done. > > I was pleasantly surprized to see that the existing > test_RandomScrambler.py test continues to run unmodified, but uses > memories in the Verilog output now. The usage of Lists of Signals in > that example is more sophisticated than for a single RAM inference, > showing that we may have an additional powerful feature now. > > 2. Support to generate Verilog assign statements > ------------------------------------------------ > A simple always_comb block is converted to Verilog assign > statements. It was reported that Xilinx tools need this to recognize > RAM templates. > > One criterium for "simpleness" is that the block only contains signal > assignments. However, this is not enough: for example, multiple > assignments to the same signal are perfectly valid code, but don't > qualify as simple. > > An additional point was that the signals driven by Verilog assignments > should be declared as wires. > > Regards, > > Jan > |
From: Jan D. <ja...@ja...> - 2005-08-09 23:17:03
|
-- Jan Decaluwe - Resources bvba - http://jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium Using Python as a hardware description language: http://jandecaluwe.com/Tools/MyHDL/Overview.html |
From: Jan D. <ja...@ja...> - 2005-08-09 19:05:48
|
Hi all: Attached you find a snapshot of the myhdl development tree. The goal is to implement RAM inference from toVerilog output. The purpose of this snapshot release is to get feedback from early users that are willing to test this. As the implemented features are especially useful in combination with the capabilities of external tools, their feedback is essential. Release notes ============= The requirements to infer RAM from toVerilog output were discussed recently. Two features were implemented: 1. Support for lists of signals ------------------------------- Lists of Signals are now supported alongside Signals in the hierarchy. They are mapped to Verilog memories. 2. Support to generate Verilog assign statements ------------------------------------------------ always_comb blocks that are simple enough are converted to a series of assign statements, instead of a combinatorial always block. Note that you do need to use always_comb for this feature; an explicit combinatorial generator is not sufficient. Installation ============ Several files have undergone changes; therefore the snapshot consists of a complete myhdl package directory. This should be installed as a replacement of the myhdl directory in the installed directory. This snapshot therefore contains several other (undocumented) features and improvements outside the specific goal outlined above. Testers should be aware of that and be careful, so that they can easily go back if required. That being said, all the regression tests run fine, of course. Implementation notes ==================== (Only for those who want to know more implementation details.) 1. Support for lists of signals ------------------------------- As always, I tried to make the implementation as general as possible. Lists of Signals are now handled as a first-class object in the hierarchy, alongside Signals. The Signal elements have the same restrictions as ordinary Signals, and additional restrictions among them. For example, they should all have the same type and bit width. In Python, it is easy to create lists that share elements. This can obviously lead to problems in Verilog conversion. An attempt was made to do meaningful things. Several error conditions were added and checked to implement meaningful restrictions. But it is possible that more will need to be done. I was pleasantly surprized to see that the existing test_RandomScrambler.py test continues to run unmodified, but uses memories in the Verilog output now. The usage of Lists of Signals in that example is more sophisticated than for a single RAM inference, showing that we may have an additional powerful feature now. 2. Support to generate Verilog assign statements ------------------------------------------------ A simple always_comb block is converted to Verilog assign statements. It was reported that Xilinx tools need this to recognize RAM templates. One criterium for "simpleness" is that the block only contains signal assignments. However, this is not enough: for example, multiple assignments to the same signal are perfectly valid code, but don't qualify as simple. An additional point was that the signals driven by Verilog assignments should be declared as wires. Regards, Jan -- Jan Decaluwe - Resources bvba - http://jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium Using Python as a hardware description language: http://jandecaluwe.com/Tools/MyHDL/Overview.html |