Thread: [myhdl-list] Driving constants
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Sébastien B. <seb...@mi...> - 2011-09-03 10:42:08
|
Hi, I need to create instances that only drive their output to some constant level, e.g. the equivalent of: module foo(output bar); assign bar = 1'b1; endmodule I have tried doing: def ImplementControl(self): @always_comb def logic(): self.control.ack_o.next[0] = 1 return logic but MyHDL doesn't cope with the empty sensitivity list. Setting the value at signal creation (e.g. things like self.control.ack_o = Signal(intbv(1))) is not an option because it would become very messy with my object-oriented approach. Besides, I would find it surprising that describing something as basic as a constant driver is an intractable problem in MyHDL. Any solutions? Thanks, Sébastien |
|
From: Jan D. <ja...@ja...> - 2011-09-03 20:16:45
|
On 09/03/2011 12:39 PM, Sébastien Bourdeauducq wrote: > Hi, > > I need to create instances that only drive their output to some constant > level, e.g. the equivalent of: > > module foo(output bar); > assign bar = 1'b1; > endmodule > > I have tried doing: > def ImplementControl(self): > @always_comb > def logic(): > self.control.ack_o.next[0] = 1 > return logic > > but MyHDL doesn't cope with the empty sensitivity list. > > Setting the value at signal creation (e.g. things like > self.control.ack_o = Signal(intbv(1))) is not an option because it would > become very messy with my object-oriented approach. Besides, I would > find it surprising that describing something as basic as a constant > driver is an intractable problem in MyHDL. > > Any solutions? A signal that you don't drive in your code gives you a warning and the expected assign. To me, that is exactly what "constant" means. I don't see what's messy about it. Of course, one could use such a signal in an always_comb and assign it to another signal. Such an approach would be meaningful for parametrization (a signal which is sometimes a constant, in other cases driven in code). 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: Sébastien B. <seb...@mi...> - 2011-09-04 09:29:26
|
On 09/03/2011 10:16 PM, Jan Decaluwe wrote: > I don't see what's messy about it. Ok, then here is some more background: I have an abstract class FunctionalUnit which implements dataflow processing units. This abstract class creates handshaking signals (ack, strobe) common to all functional units which are used to control the flow of data. The method ImplementControl is overloaded by derived classes to implement the actual handshaking logic, and returns instances. Now, when some functional units need to drive handshaking signals constants, and if it is not possible to build "constant drivers" instances, it becomes messy. |
|
From: Jan D. <ja...@ja...> - 2011-09-05 08:02:14
|
On 09/04/2011 11:26 AM, Sébastien Bourdeauducq wrote: > On 09/03/2011 10:16 PM, Jan Decaluwe wrote: >> I don't see what's messy about it. > > Ok, then here is some more background: > > I have an abstract class FunctionalUnit which implements dataflow > processing units. This abstract class creates handshaking signals (ack, > strobe) common to all functional units which are used to control the > flow of data. > The method ImplementControl is overloaded by derived classes to > implement the actual handshaking logic, and returns instances. Now, when > some functional units need to drive handshaking signals constants, and > if it is not possible to build "constant drivers" instances, it becomes > messy. What would probably work is if such a method returns an empty list, explicitly indicating that it has no generators to contribute. -- 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: Sébastien B. <seb...@mi...> - 2011-09-05 08:52:00
|
On 09/05/2011 10:01 AM, Jan Decaluwe wrote: > What would probably work is if such a method returns > an empty list, explicitly indicating that it has no > generators to contribute. Then how will MyHDL get the constant values to use, if all it gets from the method is an empty list? What about making the generator yield a special object, which would mean "empty sensitivity list/only driving constants"? Then the @always_comb decorator can automatically use that special object when it detects an empty sensitivity list, which makes the whole thing transparent from the normal user's point of view. |
|
From: Jan D. <ja...@ja...> - 2011-09-06 12:27:04
|
On 09/05/2011 10:48 AM, Sébastien Bourdeauducq wrote: > On 09/05/2011 10:01 AM, Jan Decaluwe wrote: >> What would probably work is if such a method returns >> an empty list, explicitly indicating that it has no >> generators to contribute. > > Then how will MyHDL get the constant values to use, if all it gets from > the method is an empty list? From the initial value of the signals. -- 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: Sébastien B. <seb...@mi...> - 2011-09-06 12:30:56
|
On 09/06/2011 02:26 PM, Jan Decaluwe wrote: > On 09/05/2011 10:48 AM, Sébastien Bourdeauducq wrote: >> On 09/05/2011 10:01 AM, Jan Decaluwe wrote: >>> What would probably work is if such a method returns >>> an empty list, explicitly indicating that it has no >>> generators to contribute. >> >> Then how will MyHDL get the constant values to use, if all it gets from >> the method is an empty list? > > From the initial value of the signals. And how do I set it? The signals are created by the __init__ method of the parent class. I could of course add parameters to this __init__ method to define the initial value of the signals, but it's quite messy and inelegant. |
|
From: Sébastien B. <seb...@mi...> - 2011-09-06 13:42:58
|
On 09/06/2011 03:39 PM, Jan Decaluwe wrote: >> The signals are created by the __init__ method of the parent class. I >> could of course add parameters to this __init__ method to define the >> initial value of the signals, but it's quite messy and inelegant. > > No, just use overloading, it works for constructors also. Well, yes, but it's still inelegant. > I infer that some signals may have constant values that are > different depending on the subclass. Yes. How about my proposition of yielding a special object "empty sensitivity list/constant driver" in the generators? |
|
From: Jan D. <ja...@ja...> - 2011-09-06 14:21:47
|
On 09/06/2011 03:39 PM, Sébastien Bourdeauducq wrote: > On 09/06/2011 03:39 PM, Jan Decaluwe wrote: >>> The signals are created by the __init__ method of the parent class. I >>> could of course add parameters to this __init__ method to define the >>> initial value of the signals, but it's quite messy and inelegant. >> >> No, just use overloading, it works for constructors also. > > Well, yes, but it's still inelegant. Not in my opinion. I would want to define a constant at construction time, not through a driver. (In the first case events at time 0 are avoided, in the second case not necessarily.) In my view, Verilog' assign for this purpose is a workaround for the fact that Verilog didn't have initialization syntax originally. (The reason why I don't use initialization in conversion is because I fear some tools won't support it.) >> I infer that some signals may have constant values that are >> different depending on the subclass. > > Yes. > > How about my proposition of yielding a special object "empty sensitivity > list/constant driver" in the generators? You can use 'yield None' today, but it's not supported by conversion. Classes are neither, so perhaps you don't mind. -- 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...> - 2011-09-06 13:39:16
|
On 09/06/2011 02:27 PM, Sébastien Bourdeauducq wrote: > On 09/06/2011 02:26 PM, Jan Decaluwe wrote: >> On 09/05/2011 10:48 AM, Sébastien Bourdeauducq wrote: >>> On 09/05/2011 10:01 AM, Jan Decaluwe wrote: >>>> What would probably work is if such a method returns >>>> an empty list, explicitly indicating that it has no >>>> generators to contribute. >>> >>> Then how will MyHDL get the constant values to use, if all it gets from >>> the method is an empty list? >> >> From the initial value of the signals. > > And how do I set it? > > The signals are created by the __init__ method of the parent class. I > could of course add parameters to this __init__ method to define the > initial value of the signals, but it's quite messy and inelegant. No, just use overloading, it works for constructors also. I infer that some signals may have constant values that are different depending on the subclass. (I find that strange, because I would assume that the default initial value in a protocol is always the same. But I don't know your application of course.) In such a case, I would definitely want to set it right to the correct value at construction time. -- 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: Bob C. <Fl...@gm...> - 2011-10-18 22:09:19
|
Perhaps it is inappropriate to rewind the prior discussion, but here goes... On 09/04/2011 02:26 AM, Sébastien Bourdeauducq wrote: > Ok, then here is some more background: > > I have an abstract class FunctionalUnit which implements dataflow > processing units. This abstract class creates handshaking signals (ack, > strobe) common to all functional units which are used to control the > flow of data. > The method ImplementControl is overloaded by derived classes to > implement the actual handshaking logic, and returns instances. Now, when > some functional units need to drive handshaking signals constants, and > if it is not possible to build "constant drivers" instances, it becomes > messy. So, from my admittedly limited (and likely incorrect) perspective, here's what I think is going on: Let's say I have some 'dataflow 3-input NAND gates', where each of the three inputs sinks a data and strobe, and drives a return ack. When the 3rd input has been strobed, the output will fire (as well as generate the returning ack to the last input), sending its own data and strobe to the downstream dataflow element until the returning ack is seen. The problem, as I see it, is what if I need only a 2-input NAND gate at a particular point in the dataflow? And let's say I'd prefer to reuse my standard element rather than define a new 2-input element (though an optimizer may do it for me). To do this, I'd need to drive the unused input with a constant value, in this case a True or intvb(1) value. And the resulting ack would be ignored. Is that the gist of it? If so, can we reduce the above example to the application domain, and toss around some candidate solutions (and simulations) in MyHDL code? -BobC |
|
From: Jan L. <jan...@et...> - 2011-09-04 20:35:43
|
Could you just use a clock everywhere? Am 04.09.2011 um 11:26 schrieb Sébastien Bourdeauducq: > On 09/03/2011 10:16 PM, Jan Decaluwe wrote: >> I don't see what's messy about it. > > Ok, then here is some more background: > > I have an abstract class FunctionalUnit which implements dataflow > processing units. This abstract class creates handshaking signals > (ack, > strobe) common to all functional units which are used to control the > flow of data. > The method ImplementControl is overloaded by derived classes to > implement the actual handshaking logic, and returns instances. Now, > when > some functional units need to drive handshaking signals constants, and > if it is not possible to build "constant drivers" instances, it > becomes > messy. -- Jan Langer Professorship Circuit and System Design Chemnitz University of Technology, Reichenhainer Str. 70, 09126 Chemnitz Phone: +49 37209 688001, Fax: +49 371 531-833158, Mobile: +49 162 9847325 http://www.tu-chemnitz.de/etit/sse |
|
From: Sébastien B. <seb...@mi...> - 2011-09-04 21:40:59
|
On 09/04/2011 10:35 PM, Jan Langer wrote: > Could you just use a clock everywhere? Huh? How is that related? There is indeed a clock everywhere - the whole generated circuit is synchronous - but I still need (synchronous) strobe and acknowledgment signals to control the flow of data. This practice is very common in digital design, e.g. Wishbone and many other interconnect buses have similar systems. |
|
From: Jan L. <jan...@et...> - 2011-09-04 21:59:59
|
Am 04.09.2011 um 23:37 schrieb Sébastien Bourdeauducq: > On 09/04/2011 10:35 PM, Jan Langer wrote: >> Could you just use a clock everywhere? > > Huh? How is that related? > > There is indeed a clock everywhere - the whole generated circuit is > synchronous - but I still need (synchronous) strobe and acknowledgment > signals to control the flow of data. This practice is very common in > digital design, e.g. Wishbone and many other interconnect buses have > similar systems. As I understood, you need a always_comb block that just drives a constant. And since your sensitivity list is empty it does not work. So my idea was to put the clock edge into the sensitivity list and you get a clocked process that drives a constant, which in your case will get optimized away and behave as a normal constant. -- Jan Langer Professorship Circuit and System Design Chemnitz University of Technology, Reichenhainer Str. 70, 09126 Chemnitz Phone: +49 37209 688001, Fax: +49 371 531-833158, Mobile: +49 162 9847325 http://www.tu-chemnitz.de/etit/sse |
|
From: Sébastien B. <seb...@mi...> - 2011-09-04 22:43:44
|
On 09/04/2011 11:59 PM, Jan Langer wrote: > So my idea was to put the clock edge into the sensitivity list and you > get a clocked process that drives a constant, Ah, ok. :) > which in your case will get optimized away and behave as a normal constant. I'm afraid it won't. By default, FPGA registers are initialized at 0 immediately after configuration. So if I want to drive a constant 1, I will get instead a register that will drive 0 until the first clock cycle, after which it drives 1. |
|
From: Jan L. <jan...@et...> - 2011-09-04 22:50:00
|
Am 05.09.2011 um 00:40 schrieb Sébastien Bourdeauducq: > On 09/04/2011 11:59 PM, Jan Langer wrote: >> So my idea was to put the clock edge into the sensitivity list and >> you >> get a clocked process that drives a constant, > > Ah, ok. :) > >> which in your case will get optimized away and behave as a normal >> constant. > > I'm afraid it won't. By default, FPGA registers are initialized at 0 > immediately after configuration. So if I want to drive a constant 1, I > will get instead a register that will drive 0 until the first clock > cycle, after which it drives 1. Maybe you got a reset signal and can use that to set the initial value. Then the synthesis will get rid of the register. -- Jan Langer Professorship Circuit and System Design Chemnitz University of Technology, Reichenhainer Str. 70, 09126 Chemnitz Phone: +49 37209 688001, Fax: +49 371 531-833158, Mobile: +49 162 9847325 http://www.tu-chemnitz.de/etit/sse |
|
From: Sébastien B. <seb...@mi...> - 2011-09-05 08:46:13
|
On 09/05/2011 12:49 AM, Jan Langer wrote: > Maybe you got a reset signal and can use that to set the initial > value. Then the synthesis will get rid of the register. No, the initial value is set upon configuration, independently of the user's reset signal. There are only two ways to set this initial value: 1) "initial" block in Verilog or assignment at signal declaration in VHDL 2) with a parameter when you instantiate the register primitive |
×
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