Thread: [myhdl-list] Signal has multiple drivers - Solution ?
Brought to you by:
jandecaluwe
From: Sadique S. <sa...@in...> - 2011-06-16 10:15:56
|
Hi, I am absolutely new to HDL (just started 3 weeks ago!). I started with some reading on VHDL but fell in love with MyHDL. I have been trying to do some basic simulations where i use a simple RAM. I basically copied it from the documentation. http://www.myhdl.org/doc/0.6/manual/conversion_examples.html#ram-inference Now in my simulation i use the addr signal in more than one location to read from the ram. While simulating, everything works as expected. But when i try conversion to VHDL it complains : Signal has multiple drivers: addr A bit of googling on this issue tells me that I should either set the signal to "tristate" while i am not using it or use a "resolution function." A quick search in MyHDL documentation tells me that tristate thing is not a very nice thing to do. Can some one tell me how this is usually handled ? Can I get an example on how to define and use a "resolution function". Thanks a lot Sadique |
From: Ben <ben...@gm...> - 2011-06-16 11:17:52
|
On Thu, Jun 16, 2011 at 11:57, Sadique Sheik <sa...@in...> wrote: > Hi, > > I am absolutely new to HDL (just started 3 weeks ago!). > > I started with some reading on VHDL but fell in love with MyHDL. > I have been trying to do some basic simulations where i use a simple > RAM. I basically copied it from the documentation. > http://www.myhdl.org/doc/0.6/manual/conversion_examples.html#ram-inference > > Now in my simulation i use the addr signal in more than one location to > read from the ram. While simulating, everything works as expected. But > when i try conversion to VHDL it complains : > > Signal has multiple drivers: addr > What he means there, is that in your current design, multiple source can set the value of the `addr` signal. While this may go well in your simulation process (for instance, because you care that only one source at a time tries to set it), the convertor cannot make sure that it will always work and for this reason ask you to reduce the number of soures to 1. > A bit of googling on this issue tells me that I should either set the > signal to "tristate" while i am not using it or use a "resolution > function." > > A quick search in MyHDL documentation tells me that tristate thing is > not a very nice thing to do. Can some one tell me how this is usually > handled ? > > Can I get an example on how to define and use a "resolution function". A resolution function, sometimes also called `arbiter`, will care about setting the value of the `addr` signal. Thus he will be the only one writing to this signal. The input of this module will consists of all the whished `addr` values from all the modules trying to set it, *and* a synchronisation mechanism that will instruct the arbiter who tries to set the `addr` value. Those might go from very simple to quite elaborated, depending on your design. The easiest sample of such an arbiter is a multiplexer: def mux2(addr1, addr2, sel, addr): @always_comb: def muxLogic(): addr.next = addr1 if sel == 1: addr.next = addr2 return muxLogic But as said, such module can become really complicated. In the case of your RAM, a common seen practice is to have two `raddr` (read address) input in you module and two associated `dout` (data output) allowing two simultaneous read to happen from different modules. Hope this helps. Regards Benoît. |
From: Sadique S. <sa...@in...> - 2011-06-16 12:46:17
|
Hi Benoit, Thanks for the quick reply. It was very informative. I still have a few quick queries though. > > The easiest sample of such an arbiter is a multiplexer: > > def mux2(addr1, addr2, sel, addr): > @always_comb: > def muxLogic(): > addr.next = addr1 > if sel == 1: > addr.next = addr2 > return muxLogic The multiplexer doesn't seem to solve the problem, atleast the way i see it. It seems that now instead of using the 'addr' signal i will endup driving the 'sel' signal by multiple components/locations. In the case of only two components, its alright because you can use one of the components as a master and the other as a slave that relies on the other component to set the correct select signal. Did i get that right ? Or did i miss something very crucial .. > In the case of your RAM, a common seen practice is to have two `raddr` > (read address) input in you module and two associated `dout` (data > output) allowing two simultaneous read to happen from different > modules. This sounds good to me. I am going to go ahead and use it for my simulations. Although, I wonder how things are gona work if there are multiple (more than 2) components, wont that just increase the number of ports ? May be i should do some proper literature reading and get my basics right.. |
From: Christopher F. <chr...@gm...> - 2011-06-16 12:56:32
|
On 6/16/2011 7:46 AM, Sadique Sheik wrote: > Hi Benoit, > > Thanks for the quick reply. It was very informative. > > I still have a few quick queries though. >> >> The easiest sample of such an arbiter is a multiplexer: >> >> def mux2(addr1, addr2, sel, addr): >> @always_comb: >> def muxLogic(): >> addr.next = addr1 >> if sel == 1: >> addr.next = addr2 >> return muxLogic > > The multiplexer doesn't seem to solve the problem, atleast the way i see > it. It seems that now instead of using the 'addr' signal i will endup > driving the 'sel' signal by multiple components/locations. > The multiplexer solves the specific problem of multiple drivers. It might not solve the *design* issue. Per the description thus far, you only have one communication channel to the RAM. You need to decide how this resource (RAM addr and data) are shared. What are the "rules" for sharing. As Benoit suggested, you might need some sort of arbitration (you can look at the wishbone documentations, or other on-chip buses for some examples). A Dual-Port RAM might be appropriate in your case, if you have a separate writer and reader. In general, once you determine the rules for sharing, the implementation can be a mux, a bunch of ORs (or ANDs). As you read, tri-states are usually avoided for on-chip bus sharing. Chris |