From: Pontus on
In case a tristate bus is not driven, the synthesis tool must decide
what value the bus should have (synplify selected '0').
This is not a problem for the bus itself, but if you also have
multiple drivers on a net that is used to acknowledge a request, it
matters if you are using negative logic for the ack!

When porting a design from a device containing "true" tristate
nets to a device which didn't - and using an active low ack to the bus
you will have a problem. Either change to active high ack, or
implement the ack with a wide and-gate.

Yes I spent a few hours around this ...

-- Pontus

From: Manmohan on
On Apr 15, 7:14 am, Pontus <pontus.stenst...(a)gmail.com> wrote:
> In case a tristate bus is not driven, the synthesis tool must decide
> what value the bus should have (synplify selected '0').
> This is not a problem for the bus itself, but if you also have
> multiple drivers on a net that is used to acknowledge a request, it
> matters if you are using negative logic for the ack!
>
> When porting a design from a device containing "true" tristate
> nets to a device which didn't - and using an active low ack to the bus
> you will have a problem. Either change to active high ack, or
> implement the ack with a wide and-gate.
>
> Yes I spent a few hours around this ...
>
> -- Pontus



Welll what about implementing a pullup in the bidirectional bus for
all the non active drivers ?

any idea to implement that ?
From: Andy Peters on
On Apr 14, 1:24 am, Manmohan <mmm...(a)gmail.com> wrote:
> On Apr 14, 7:50 am, Andy Peters <goo...(a)latke.net> wrote:
>
>
>
> > On Apr 13, 4:43 pm, Manmohan <mmm...(a)gmail.com> wrote:
>
> > > Hi all,
>
> > > I would like to implement a router mesh (3x3) with bidirectional links
> > > within the FPGA . I am using a Virtex 4 board. Since there are  a lot
> > > of bidirectional buses in my design, I would like to know if it is
> > > possible to implement all the buses using tristate logic? when I
> > > snthesised only one single bidirectional bus, it was mapped to the
> > > IOBs and consumed around 15% of the 240 IOBs.
>
> > > I would like to know if there is any other way to implement a
> > > bidirectional bus that does not use the IOBs ?
>
> > No, internal tristates have vanished from Brand X FPGAs after the
> > XC4000 series.
>
> > I don't miss them. I don't see how they can possibly have any
> > advantage over distinct "going this way" and "going that way" buses.
>
> > -a
>
> Hi Thank you for the reply... But actually I am planning to implement
> a single set of 8 bit wide bus for both input and output direction....
> So , I need to have a bidirectional bus .... Is there any other way
> other than tristating to implement such a bus ?

Give up on the idea of using an internal tristate/bidirectional bus
and instead use two unidirectional buses, one for each direction.

-a

From: Pontus on
> Well what about implementing a pullup in the bidirectional bus for
> all the non active drivers ?
>
> any idea to implement that ?


As far as I remember we did instatiate a pullup from unisim (xilinx).
This worked for virtexE (which has internal tristate) but failed when
trying it with Virtex5 (which doesn't). With this I mean that [for V5]
the tri_to_mux conversion is OK if you expect an undriven signal to go
low. If you think that an undriven signal should be high you will be
surprised.
To be explicit, there was an internal bus that several entities could
drive. If an entity "felt adressed" it would provide data and ack.
We had (for whatever reason) chosen negative logic for the ack.
So when no entity felt adressed, no one drove the ack, and since
synplify then put the signal low, the bus ended up beeing ack:ed
all the time.

Try it yourself and tell us about your results.

-- Pontus
From: Gabor on
On Apr 15, 4:43 pm, Pontus <pontus.stenst...(a)gmail.com> wrote:
> > Well what about implementing a pullup in the bidirectional bus for
> > all the non active drivers ?
>
> > any idea to implement that ?
>
> As far as I remember we did instatiate a pullup from unisim (xilinx).
> This worked for virtexE (which has internal tristate) but failed when
> trying it with Virtex5 (which doesn't). With this I mean that [for V5]
> the tri_to_mux conversion is OK if you expect an undriven signal to go
> low. If you think that an undriven signal should be high you will be
> surprised.
> To be explicit, there was an internal bus that several entities could
> drive. If an entity "felt adressed" it would provide data and ack.
> We had (for whatever reason) chosen negative logic for the ack.
> So when no entity felt adressed, no one drove the ack, and since
> synplify then put the signal low, the bus ended up beeing ack:ed
> all the time.
>
> Try it yourself and tell us about your results.
>
> -- Pontus

This of course is a simulation mis-match and should be flagged
during synthesis. If the synthesizer ignores a pullup on a
net it should indicate that as a warning.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Read from the compact flash
Next: Clock Mux by software ...