Best way to handle multiple common data busses in Altera FPG

[George]

Hello:

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

 

[Gary Pace]

George,

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.

Gary

"George" <george.martin@att.net> wrote in message
news:e9d879fa.0405030651.523d875c@posting.google.com...

Hello:

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

 

[Andy Peters]

george.martin@att.net (George) wrote in message news:<e9d879fa.0405030651.523d875c@posting.google.com>...

Hello:

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.

Um, a mux?

-a

 

[Mike Treseler]

George wrote:

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?

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.

Can I use a tristate type
construction and save interconnects to the CPU.

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

 

[Gabor Szakacs]

george.martin@att.net (George) wrote in message news:<e9d879fa.0405030651.523d875c@posting.google.com>...

Hello:

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.

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.

Any input would be appreciated.

Thanks
George

 

[George]

gabor@alacron.com (Gabor Szakacs) wrote in message news:<8a436ba2.0405031357.39ec912b@posting.google.com>...

george.martin@att.net (George) wrote in message news:<e9d879fa.0405030651.523d875c@posting.google.com>...
Hello:

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.

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.

Any input would be appreciated.

Thanks
George

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

 

[Jesse Kempa]

george.martin@att.net (George) wrote in message news:<e9d879fa.0405030651.523d875c@posting.google.com>...

Hello:

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

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 IOs...it 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<8; i++)
{
*select_pio_data = i;
status = *status_pio_data;
}

It may be advisable to put a small delay statement in between the PIO
write (to mux select) and PIO read (to fetch data)... but that is
probably overkill.

Jesse Kempa
Altera Corp.
jkempa at altera dot com