Multiple components driving a single bus

B

Benjamin Couillard

Guest
Hi, I've got a question for you guys.

Let's say I've got 2 blocks that can drive one bus (but there could be
more).

Block1 : Block
generic map (Address => x"000")
port map (CLK => CLK,
ADDR => ADDR,
BUS_STB => BUS_STB,
RD_WR_N => RD_WR_N,
DATA_OUT => BUS_DATA,
....);


Block2 : Block
generic map (Address => x"004")
port map (CLK => CLK,
ADDR => ADDR,
BUS_STB => BUS_STB,
RD_WR_N => RD_WR_N,
DATA_OUT => BUS_DATA,
......);

Let's say that when the address is not 0, DATA_OUT of block1 will be
high-Z and when the addres is not 4 Data_out of block 2 will be high-
Z. Will ISE synthesis engine be smart enough to realize there is no
bus contention? Basically, will ISE infer muxes from that code? I
realize that I could use a switch case, however I want a more scalable
solution where I don't need to have an ugly 200-line switch case.

I looked a Jonathan Bromley's solution too, it's very clever and it
looks like a good solution, however I'd like to know your opinion on
this method first. The reason, why I like the solution above is that
the address is specified when we instantiate the block.

Best regards.
 
On Tue, 21 Apr 2009 18:27:42 -0700 (PDT), Benjamin Couillard
<benjamin.couillard@gmail.com> wrote:

Hi, I've got a question for you guys.

Let's say I've got 2 blocks that can drive one bus (but there could be
more).

Block1 : Block
generic map (Address => x"000")
port map (CLK => CLK,
ADDR => ADDR,
BUS_STB => BUS_STB,
RD_WR_N => RD_WR_N,
DATA_OUT => BUS_DATA,
....);


Block2 : Block
generic map (Address => x"004")
port map (CLK => CLK,
....
Let's say that when the address is not 0, DATA_OUT of block1 will be
high-Z and when the addres is not 4 Data_out of block 2 will be high-
Z. Will ISE synthesis engine be smart enough to realize there is no
bus contention? Basically, will ISE infer muxes from that code?
Click to expand...
Look in the synthesis report for warnings that tri-states have been replaced by
muxes.

Any time I've tried it, it has worked - but XST will complain about it.

This ssumes ADDR is internal. If ADDR goes off chip, the synth tool can't
analyse the outside world. It may be smart enough to infer MUXes internally and
tristates on the I/O pins but I haven't verified that.

- Brian
 
On Tue, 21 Apr 2009 18:27:42 -0700 (PDT), Benjamin Couillard wrote:

[...]
Let's say that when the address is not 0, DATA_OUT of block1 will be
high-Z and when the addres is not 4 Data_out of block 2 will be high-
Z. Will ISE synthesis engine be smart enough to realize there is no
bus contention? Basically, will ISE infer muxes from that code?
Click to expand...
This is the readback-decode problem that has caused me much pain
in the past.

There was quite an interesting related discussion here back in
January, in the thread "Unassigned register decode", in which
I posted a sketch of one possible way to attack it - without
writing tri-states and then expecting the tool to convert
them to muxes.

But I agree with you and Brian that the tristate=>mux solution
usually works pretty well.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On 23 avr, 04:53, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
On Tue, 21 Apr 2009 18:27:42 -0700 (PDT), Benjamin Couillard wrote:

[...]

Let's say that when the address is not 0, DATA_OUT of block1  will be
high-Z and when the addres is not 4 Data_out of block 2 will be high-
Z. Will ISE synthesis engine be smart enough to realize there is no
bus contention? Basically, will ISE infer muxes from that code?

This is the readback-decode problem that has caused me much pain
in the past.

There was quite an interesting related discussion here back in
January, in the thread "Unassigned register decode", in which
I posted a sketch of one possible way to attack it - without
writing tri-states and then expecting the tool to convert
them to muxes.

But I agree with you and Brian that the tristate=>mux solution
usually works pretty well.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Click to expand...
I tried my method, and it doesn't seem to scale well. ISE seems to
synthesize just fine even though there are address conflicts (I put
those conflicts on purpose)

.. I think I'm gonna use your method Jonathan, it seems to scale
reasonably well and it avoids the mess of having one huge process
implementing all the registers (I have about 50 register so far, but
the number could easily double).
 
On Thu, 23 Apr 2009 11:40:23 -0700 (PDT), Benjamin Couillard
<benjamin.couillard@gmail.com> wrote:

On 23 avr, 04:53, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:
On Tue, 21 Apr 2009 18:27:42 -0700 (PDT), Benjamin Couillard wrote:

[...]

Let's say that when the address is not 0, DATA_OUT of block1  will be
high-Z and when the addres is not 4 Data_out of block 2 will be high-
Z. Will ISE synthesis engine be smart enough to realize there is no
bus contention? Basically, will ISE infer muxes from that code?

But I agree with you and Brian that the tristate=>mux solution
usually works pretty well.

I tried my method, and it doesn't seem to scale well. ISE seems to
synthesize just fine even though there are address conflicts (I put
those conflicts on purpose)
Click to expand...
This is a fair comment; the muxes start to slow down given enough registers (30
maybe 50 seem no problem in V5, maybe half that in S3. My answer was simply to
pipeline pages of about 16-30 registers! (A second cycle muxes between the
pages)
However I believe Jonathan's method will scale rather better...

- Brian
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top