Best way to handle multiple common data busses in Altera FPGA (and others)


I'm generating a new design using an Altera Cyclone FPGA. But I think this issue may be applicable to all FPGAs. I have 8 identical modules that each have an 11 bit status register. The CPU (in this case a NIOS embedded on the same device) needs to read these status registers.

The question is what is the best (size first, speed second) configuration for these inputs? Can I use a tristate type construction and save interconnects to the CPU. Does this really save any routine resources and at what expense. In this design I can live with long delays on reading the status registers.

Any input would be appreciated.

Thanks George

Reply to
Loading thread data ...


AFAIK the LE's on the Cyclone (and other FPGA's I've used) don't have a tristateable output - this is only available in the IOB's.

So when creating memory mapped registers I used a single write bus with address decodes generating clock enables for the latches, and multiple read buses (one per input register) going to a big MUX controlled by the address lines.

The ability to create apparent tri-states inside the design is an artifice, the sythesis will have to turn this into something similar to the above.

I think in answer to your question, you can use a tristate configuration to describe your design intent concisely, but the synthesis will convert this into a purley combinational function.

Hope a) I'm right and b) this helps.


Reply to
Gary Pace

Um, a mux?


Reply to
Andy Peters

I don't know anything about nios, but I expect it doesn't have 88 IO's, so consider doing nios read cycles for your registers at its standard width. Maybe drive 11 of the 16? bits for each address.

Whatever the nios data bus is, you will have to match. Consider avoiding on-chip tristates descriptions if you can. A big mux is much less trouble and probably what the hardware really does, in any case.

-- Mike Treseler

Reply to
Mike Treseler

If you can live with very long delays, consider one long shift register or eight 11-bit shift registers with an 8:1 mux. Status can be loaded into the shift registers in parallel and then shifted into the CPU. This is a little like JTAG boundary scan logic. It reduces global interconnect, but probably uses as much resources (though different kind, flip-flops vs. LUT's or TriState buffers) as the brute force parallel method.

Reply to
Gabor Szakacs

Well I entered a TriState mux 8 times into the design. I placed, routed and simulated with out large delays. But I did notice the LE (logic Elements) usage creeping up.

I like the serial shifting scheme. I can generate a SPI controller in the CPU so I only have to design the end that goes into each of the 8 status registers. The penality with this approach is that I might need 11 bit register to capture and shift the status values. Perhaps I could just make one counter (4 bit = 16 status inputs) for all status registers and an 11:1 mux for the data values. I like this a lot!!!

Thanks for the help. This group Rocks!! George

Reply to

To get the data into the processor the easiest method would be to use a PIO peripheral (included in the Nios kit). Someone mentioned that Nios doesn't have 88 can have as many as you want (as long as it fits)! However, for this application the most efficient way may be to create two PIO periherals that Nios directly addresses: an 11-bit intput to capture the data of a single logic module, and a 3-bit output that goes to a mux which connects your single 11-bit input PIO to the 8x11-bit status register values coming out of each module.

Outside of the Nios/SOPC Builder logic you would wire up the PIO output to a 8:3 mux, and you're in business...

Your software source would then look like this, to read each status register into an array of memory (C pseudocode):

unsigned short status[8];

for(i=0; i

Reply to
Jesse Kempa

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.