bidirectional bus sanity check

[bmarchio]

I'm a lone Verilog-er at my present company and need a sanity check for
some busses that I've coded into a PLD.

My PLD interfaces with an ASIC and a processor. The PLD is supposed to
poll the ASIC every few hundred clocks and do some maintenance thereto.
The processor can also read and write to the ASIC when it needs to. I
think my arbitration is okay, but I feel shaky about my bidirectionals:

/*************************************/
// port declarations
inout [7:0] dataB_up; // data bus to/from processor
inout [7:0] dataB_asic; // data bus to/from asic

// internals
wire [7:0] data_up;
wire [7:0] data_asic;
reg [7:0] dout_asic; // to output to asic when I write

// logic
// n.b., read and write are active low
// "poll" is the signal that tells me that it's time to poll, or i'm in
// the middle of a poll read/write sequence.

assign data_up = dataB_up;
assign dataB_up = _rd ? 8'hzz : data_asic;

assign data_cirrus = dataB_asic;
assign dataB_cirrus = _wr ? 8'hzz : (poll ? dout_asic : data_up);
/**********************************/

Anybody see any issues? Many thanks -
Bmarchio

 

[Swapnajit Mittra]

From my understanding of your email, I am assuming you are
attempting to write synthesizable code. If that is the case, and

unless you are using some special PLD specific synthesizer,
there are several no-nos in your code, but I will mention just one
here: do not use inout ports in your design. You should use
inputs and outputs only. When you are using a bi-directional bus,
you should use input port for incoming data and output ports for
outgoing data and the output enable signal. There will be an IO
cell that converts the bi-directional bus on one side to your
input and output on the other side. It will let the input come in
or output to go out based on your output enable.

- Swapnajit.

--
SystemVerilog, DPI, Verilog PLI and all other good stuffs.
Project VeriPage: <URL: http://www.project-veripage.co­­m>
Get information on new articles:
<URL: http://www.project-veripage.co­­m/list/?p=subscribe&id=1>

 

[Dr Justice]

"Swapnajit Mittra" <mittra@juno.com> wrote in message
news:1120601511.151912.302110@g49g2000cwa.googlegroups.com...
[snip]

there are several no-nos in your code, but I will mention
just one here: do not use inout ports in your design.
You should use inputs and outputs only. When you are using
a bi-directional bus, you should use input port for incoming data
and output ports for outgoing data and the output enable signal.
[snip]

I have used this previously in CPLDs with great success,
and I find a lot of examples on their use. I'm going through
Google search results for this issue right now, and so far
nobody else is "no-no'ing" the use of inout and tristates.

I have tried both methods (separate r/w buses and bidir bus)
in a project I'm currently working on. They both work fine
in simulation, but I'd prefer to use the single bus.

Please, would you care to elaborate on exactly why
bidirectional buses with tristates should not be used
internally in FPGAs as opposed to at the IO-pad boundary?

Also, how would the synthesis results of the two methods
compare in general?

DJ
--

 

[Swapnajit Mittra]

Both methods will work fine in the simulation. There is no problem
there.

Also, I am not asking you not to use tri-state buffers, but just to
code
in such a way to restrict them outside of your RTL, because:

- from an ASIC type of methodology, tri-state buffers are best placed
near an IO pad. Often your fab will restrict the placement of IO cells
near
IO pads. Even if you are using a non-ASIC methodology, sticking to
least common denom will help you writing portable codes. (This is
equivalent of writing code that includes 'initial' which some FPGAs,
I am told, can now synthesize).

- IO cells are often hand instantiated according to the drive strength
requirements of your bi-di bus. Separating the structural Verilog
of IO cells from RTL is usually considered to be a good idea.

- perhaps it is simply a coding methodology preference, but involving
z's in my RTL code is something I would avoid.

Of course, if your synthesis tools can handle this and you know you
will have no timing issues or issues related to portability etc. later
on,
go ahead.

--
SystemVerilog, DPI, Verilog PLI and all other good stuffs.
Project VeriPage: <URL: http://www.project-veripage.co­­­m>
Get information on new articles:
<URL: http://www.project-veripage.co­­­m/list/?p=subscribe&id=1>

 

[Anton Erasmus]

On Wed, 6 Jul 2005 16:57:27 +0200, "Dr Justice" <sorry@no.spam.wanted>
wrote:

"Swapnajit Mittra" <mittra@juno.com> wrote in message
news:1120601511.151912.302110@g49g2000cwa.googlegroups.com...
[snip]
there are several no-nos in your code, but I will mention
just one here: do not use inout ports in your design.
You should use inputs and outputs only. When you are using
a bi-directional bus, you should use input port for incoming data
and output ports for outgoing data and the output enable signal.
[snip]

I have used this previously in CPLDs with great success,
and I find a lot of examples on their use. I'm going through
Google search results for this issue right now, and so far
nobody else is "no-no'ing" the use of inout and tristates.

I have tried both methods (separate r/w buses and bidir bus)
in a project I'm currently working on. They both work fine
in simulation, but I'd prefer to use the single bus.

Please, would you care to elaborate on exactly why
bidirectional buses with tristates should not be used
internally in FPGAs as opposed to at the IO-pad boundary?

Also, how would the synthesis results of the two methods
compare in general?

Based on advise from this group I changed my code from using internal
tri-state busses to seperate input / output busses. This made a huge
difference in the quality of the synthesized circuit. The number of
macrocells used, drop by over 30%, while the maximum speed of my
circuit went up 4 fold.


Regards
Anton Erasmus

 

[Dr Justice]

"Anton Erasmus" <nobody@spam.prevent.net> wrote in message
news:1120670808.29e77b146be744ce325a812bca8f4ffb@teranews...
[snip]

Also, how would the synthesis results of the two methods
compare in general?

Based on advise from this group I changed my code from using internal
tri-state busses to seperate input / output busses. This made a huge
difference in the quality of the synthesized circuit. The number of
macrocells used, drop by over 30%, while the maximum speed of my
circuit went up 4 fold.
[snip]

Now that's always useful Thanks!

The one thing I was expecting to hear about are
potential problems(?) with turnover between drivers.
Thinking about overlapping (in time) drivers.
And maybe something about routing resources.

Well, so it's back to a common write bus and mux'es
on the read bus then... I'll try to synthesize and compare
both varieties and learn more from that.

Thanks for the loan of your thread bmarchio,
hopefully we all benefitted.

DJ
--

 

[Swapnajit Mittra]

Hello Justice,

Yes, to learn from all these and be benefitted is the goal
for all of us and thanks for posing a contrarian viewpoint.
I will comment on one other thing that you wrote:

"... And maybe something about routing resources."

This is one of the main reasons for keeping the IO cells
close to the pads. By reducing routing and possibly the
routing amount from the nearest flop, you gain in routing delay
and hence I am not surprised to see the speed increase from
Erasmus.

Also, I forgot to mention another minor 'code legibility'
type of issue for separate input and output busses. When you
have a separate input and output busses, you know exactly,
the source of the signal (inside or outside) value that you
are reading or writing. This simplifies life.

--
SystemVerilog, DPI, Verilog PLI and all other good stuffs.
Project VeriPage: <URL: http://www.project-veripage.co­­­m>
Get information on new articles:
<URL: http://www.project-veripage.co­­­m/list/?p=subscribe&id=1>