1. Home
  2. Field-Programmable Gate Arrays
  3. Bus structures question (Spartan 3)

Bus structures question (Spartan 3)

hi,

currently I am working on a small hobby project with the Spartan 3 Starter Kit board from Xilinx. I use ISE WebPack 8.1i and Verilog as a language.

Now some questions have come up during this:

1) There is a need to implement bus structures, say a 16 bit bidirectional data bus which should connect several modules on the highest level of the project.

1a) Do i understand it right that although there is an "inout" statement for pins in verilog, this is of no use here, as it is working fully only for IO-Pins on the main level, which connect to physical pins of the FPGA itself ?

1b) Additionally there seems to be no possibility (at least for the Spartan 3 device) that several outputs from different modules drive a single bus line, even if care is taken for a proper assignment of 1'bz values.

So the consequence seems to be the following (my own thought): if one has modules

m1, m2, m3

and one is intending

m1(inout d), m2(inout d), m3(inout d)

one has in reality to do

m1(in din, out d1), m2(in din, out d2), m3(in din, out d2)

and declare a 4th module

bus_star(in sd1, in sd2, in sd3, out sdo)

and connect

sdx to dx (x from 1 to 3) din to sdo

The 4th module I called "bus_star" as it is internally realising a star shaped topology on the buses, wire-oring the products

(sdi and eni)

to give sdo. The signals eni here are enable signals, which dictate which of the modules mx is allowed to "talk out" over dx into the sdo and therefore into the din bus.

Is this correctly thought ? Or is there an easier way ?

1c) If the way in 1b) is correct, can the duplication of the buses (d1, d2, d3) - which are in reality maybe 32 bit wide - lead to practical problems in routing on the FPGA chip ? (Too many lines ?)

2) A second, totally unrelated question: Is there a verilog simulation module for the static RAMs on board of Spartan3 Starter Kit ? I intend to write a synchronous RAM-controller for these asynchronous RAMs and would like to test it before, possibly, damaging the RAMs with wrong code. (Or is this impossible ?)

Greetings

Jürgen

--
Jürgen Böhm                                            www.aviduratas.de
"At a time when so many scholars in the world are calculating, is it not
desirable that some, who can, dream ?"  R. Thom
Reply to
Jürgen Böhm
Loading thread data ...

Verilog supports inout ports.

Even through the Spartan3 has no internal tristates, you should still be able to use the tristate structures in your code (this is how the Xilinx PCI v3.0 core does it) using the 1'bz assignments when not driving from your module.

I changed most of my internal bus interfacing to the PCI core to be effectively your "bus_star" so I can have all the outputs going where they need when they only interface to the PCI core, not each other. This eliminated (conceptually, at least) any false paths from an internal module's output to an internal module's input. Any inter-module communication was directly connected and not part of my interface bus. I split the PCI into a dedicated input path and used their I/O path only for my output.

If you synthesize with tristate values, the synthesizer may implement your bus_star or the roughly equivalent "1 if idle, 0 if there's bus contention" like what the Spartan 2E's internal BUFTs implemented electrically.

Reply to
John_H

Hi Jürgen

The simplest way is to define the interface for each module as inout, and be careful of the 'z' statement. The tools will (usually, now)convert this to multiplexers internally.

Alternatively, you can define your own bus multiplexer (I've done this in the past) for the interconnect.

Cheers

PeteS

Reply to
PeteS

A big problem here is that you might have different behavior in simulation than in reality unless you take care.

For example, if you assign z to some signals that are used as control signals you might have some problems as seen in the following example:

if(controlsignal) begin Dosomething; end

Dosomething will not happen in simulation because z is not true. However, it will do something in reality because the signal will in reality be 1 in this situation due to the pullup you described. (I guess you could add pullups or pulldowns to the signals in the source code to avoid this in Verilog.)

But this still shows that you must be careful about this situation. My advice is to totally avoid tristates internally if you can avoid it.

/Andreas

Reply to
Andreas Ehliar

I wrote and use is0() and is1() vhdl functions that assert warnings if meta-values are encountered in the argument. They also interpret L and H as 0 and 1.

Andy

Andreas Ehliar wrote:

Reply to
Andy

This is one of the down sides of the Spartan 3. The way to solve this is to have a multiplexer at each device's input. This seems a bit cumbersome, but it actually works quite well and fast.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

Is it not on the contrary necessary to feed *different outputs* from the different devices into a multiplexer, which then drives a *single* input line for all devices ? Would not otherwise the notorious error message, saying that a single "wire" is driven by several different "out"s appear?

At least it was for this reason I conceived this "bus_star" topology (essentially a multiplexer of course) the way I outlined it in my original posting.

Greetings

Jürgen

--
Jürgen Böhm                                            www.aviduratas.de
"At a time when so many scholars in the world are calculating, is it not
desirable that some, who can, dream ?"  R. Thom
Reply to
Jürgen Böhm

If you define each module with inout (as if you had tristates internally), then the tools will infer the appropriate multiplexers for you (at least they will in XST).

Cheers

PeteS

Reply to
PeteS

Hi,

If you can live with latency, here is a noteworthy alternative: ring-bus.

m1 -> m2 -> m3 -> m1

When pipelined, a ring-bus allows higher operating frequencies and lower routing utilization. However, ring-bus interfaces do consume a few FFs and LUT and how much this may be depends on how simple/complex your implementation is.

In one of my own designs, I have used a pipelined 8bits ring-bus. Each hop consumed about 70 slices (32bits tap IO port) and the whole ring should have been able to run run at 170MHz on a V2P30-7 according to STA.

If you put together a similar bus with 16bits IO ports, you might be able to do someth> hi,

Reply to
Daniel S.

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.