SOPC create 8bit ext tristate memory

[Altera_Forum]

Maybe a simple question but i haven't found the correct documentation how it is ment to be done with ths sopc builder. 

 Our Target has a couple of external 8bit devices. Each delivers an IRQ_n.  Now Nios is 32bit and a bus access, even a 8bit transfer could lead to 4 8bit transfers what is not what we want. so we use IORD_8DIRECT as the external devices have their own memory so the cache must not be used here.  My Question is the following :  I would like to replace the VHDL file we have that handles the datatransfer as is assumes an avalonconnection of 32bit and an external connection of 8bit. it is also fixed about amount of interrupt inputs and other stuff.  My first idea was to add a avalon tristate bridge and for each external 8bit device a custom sopc device.  At the end this should lead to SOPC schematic symbol where we have shared adress[19..0] and data[7..0] signal. it would be great if it could also lead to shared nRead and nWrite signals too but for each external device a seperate nchipselect and nirq.  The avalon tristate bridge is just a simple add ... fine.  Then i startet to build a new component with the sopc builder and this shares address and data but not read and write. This device is just a avalon_tristate_slave that is not base on a hdl. it's slave adressing is memory (i don't want the gap's) and the timing is set to that what the ext devices need.  Now does a 32-bit access lead to 4x 8-bit access ? Does a single 8-bit access lead to only 1 8-bit access ? or does nios always access 32-Bit ?  My problem is that some external devices are not 32-bit devices and a 8-bit access to such a device must not be an access to any other memory location of that device as adressed. imagine 8-data followed by 8-status bits and you try to read the data but nios reads the status too and troughs the value away but for the device the status has been accessed and it could be that the device drop's a bit (maybe int) as this bit has been read (what was not the intension of that access)  Does such a avalon_tristate_slave handle the 8-bit 32-bit access ? does it check for the byteenables ? and shift the adressbits ? Is the timing that is entered realy the timing (with waitstates) ?

[Altera_Forum]

The shared signal stuff seems to be solved. 

 Inside class.ptf i changed is_shared from 0 to 1 for nWr and nRd and now i have what i wanted ... but next step is how the access looks like. is a single 8bit access (char_ptr) also a single 8-bit access outside my fpga ....  The SOPC symbol looks as expected.

[Altera_Forum]

Here is some tips for you: ( in Quartus 5.0 , spoc 5.0 , component edit) 

 1.  if the external device is not "momery", please using "slave addressing=Registers(using native bus sizing) it write/read one by one ,not 4*8bytes.  2.  if using tristate bridge , choose "avalon tristate slave"  3.  then add signals properly   4.  it is default that address and data bus is shared if it is "avalon tristate slave". you can modify the ptf to share others signals what as you have done. (but I never tested it, it can also shared in quartus by gethering the signals by AND gate)

[Altera_Forum]

i must use memory instead of register, because some external devices are memory (NVRAM f.e.). And we cannot have the gaps we get with register mode. In fact we need to have to lowest 4 external bytes must be the first 32bit data in nios memory, and the next 4 external byte the next 32bit data ...  

 I have used the avalon tristate slave.  All signals are of interface type "avalon_tristate_slave_0" And the signal types are data 8 bidir write_n 1 input read_n 1 input irq_n 1 output address 20 input clk 1 input chipselect_n input  The interface is set to memory(dynamic bus sizing) with 0 minimum arbitration shares. The timing is as needed in nsec taken from the datasheets of the external devices.  So my concern is about memory dynamic bus sizing.  We had tried to implement this as we started with nios but failed.  I remember that we had to use register (nativ bis sizing) as this was the only chance that even with IORD_8DIRECT only a single byte access had been initiated.  My problem is that i have to design a tristate 8bit interface (like we use in those good old 8051 days) but the software must be able to use byte, halfword and word addressing mechanism and the 32, 16 or 8 bit access (read and write) must create 4, 2 or only 1 access to the external device depending on the nios access.  I hope that this tristate Bridge handles this correct.

[Altera_Forum]

Is it not possible to bolt on some external logic to filter CS/RD/WR based on those signals and the lower order address lines and byteselects?

[Altera_Forum]

That is exactly what the module did what i tried to replace by the tristate bridge. 

 If you have a 32-Bit connection to the avalon and a 8-Bit connection you must look at the byteenable signals which bit 0-7 8-15 16-23 24-31 are currently selected and out of this create the two missing addresslines to address to according bytes. 00 01 10 11.  Furthermore you have to create out of a 16 or 32 bit access 2 or 4 8-Bit access.  This and the generation of the missing address lines makes it a bit complicated. even more with timing (waitstates)  But i thought that such a tristate bridge does this and i do not have to bother about that anymore.  Maybe somebody from Altera or any other nios-expert can tell us right out of his head if this is what this bridge does or not.  A side note here... the tristate bridge has only 8-bit avalon-tristate-slaves.  I will try it with nios2_5.0.1 i have received from our sales office. today or on monday. i have to setup the ide for this purpose as well