Buffering Avalon tristate data bus

[Altera_Forum]

In order to implement a special access on tristate avalon bus, it is necessary to decouple parts of the data bus. I've done this by inserting a set of bidirectional tri-buffers. Their enables are driven by 'write' (in transmit direction) and 'read' (in receive direction). But this doesn't work, the firmware don't run. 

The whole data bus is 32-bit wide and so is the SRAM, where the firmware runs. This tri-state buffers are only inserted in the lower byte. Perhaps a message in analysis report gives a hint: 'Warning: TRI or OPNDRN buffers permanently enabled' followed by eight data bus nodes (locate in design file leads to FPGA-pins D7..D0). Is there a separate segment with its own tri buffers directly at the pin logic ? It doesn't matter if 'outputenable' is used instead of 'read' and 'outputenable_n' instead of 'write'. An analysis with SignalTap II shows that the lower eight bits are stuck on zero when first opcode will be fetched after reset.  Any ideas ?  Mike

[Altera_Forum]

Can you describe what is on the bus (is it just SRAM or are there other shared devices?) With a tristate bus with multiple slaves you have to make sure that only the selected device is talking on the bus (all others must be tri-stated), and also each bidirection device must have tri-states for the data path. 

 So I don't know which situation you are describing here (there are two possible places where your question applies to). If I had to guess I'd say you do not have enough masks on the tri-state enables.

[Altera_Forum]

Mike, 

 Just so you know, if you use the "avalon to tri-state bridge" the physical tri-state handling on the bidir bus is done for you automatically by SOPC Builder-generated logic, turnaround times and all... if you're doing some logic that doesn't use the bridge, then yes, you need to infer the tri-buffs. I would typically do this in (verilog as an example) like this:  data_to_outside_world = (avalon_oe & avalon_write) ? avalon_writedata : 32'hzzzzzzzz; avalon_readdata = data;  ...you would then need to ensure sufficient idle time for the bus to turn around. Avalon setup/hold time is useful for this.

[Altera_Forum]

Hi BadOmen, 

On my Avalon Tristate Bus there are several off-chip devices sharing Address, Data, RD and WR . But all of them have their own CS and every device only drives the bus while its CS is active. This works so far. One external device is a bank of DSPs producing lots of data via a 16-Bit-Interface readible in two adjacent byte accesses (on an add-on board with 8-bit data bus). Reading these two bytes is possible either in memory-mode with Avalons dynamic bus sizing, or in register mode with software overhead reading (Addr + 0) and (Addr + 4) plus combining both bytes to a halfword. In dynamic mode, a 16-Bit-read accross a 8-bit interface on a 32-bit data-bus results in four single read cycles. This will increment an address counter in the DSPs by four instead of two. So both variants offer a bad performance and / or a malfunction in the DSP-Interface (HPI8). My idea was, to use a 16-bit avalon register interface with some additional glue logic which accesses two bytes and exchanges halfwords with nios (waitrequest is needed). Reading is not the problem, because the DSPs doesn't drive D[15..8]. But when writing to DSPs all data-lines are in active state driven by avalon bus. This is where I thought on adding tri-state buffers to substitute D[7..0] in a second cycle with the data provided on D[15..8]. But meanwhile I've looked at the pin-logic in cyclone devices. There is no single bidirectional tri state line possible. Output to the pin is done via a tri-state buffer. Input from this pin is made behind this buffer, directly at the pin. So this results in two separate lines: one for input and one for output (via tri). A data signal, configured as 'inout' is already the pin itself! You cannot insert additional logic. Perhaps I need two interfaces: one for reading and one for writing. Important is the read path, which will be controlled by a DMA to get most possible performance, writing could be done in a slower mode.  Mike

[Altera_Forum]

If you seperate the buses like you suggest at the end I think you will see better timing as well. The situation you listed is describbed in the tristate documentation (but the fact that you know about this suggests you have already read this). 

 Hmmmmm I think if I draw out a block diagram I may be able to see a possible solution.

[Altera_Forum]

Hi BadOmen & Jesse, 

 My original idea was to create an avalon slave (not tristate) together with some logic and merge it into the tristate side of the bus. There is a simplified diagram showing the basics what I've tried to do: ... see diagram ... (http://www.ing-buero-ruettger.de/nios/databus.htm) But if you look at the cyclone IOE structure, there is no physical way to insert these buffers. As Jesse posted, it is part of the "avalon to tri-state bridge" to merge input- and output-lines into a single bidir signal which is part of the IO cell. My design has to be done in the inner part of the tristate bridge.  I think one possibility is to create an own avalon-to-tristate-bridge with a multiplexer and tri buffers, controlled by the appropriate CS signals.  Thanks all for your help.  Mike

[Altera_Forum]

that link has no image btw. 

 Also the idea at the end of your reply sounds like something I have done in the past (so it's doable).  Good-luck.