Hi all,When I create a new tristate slave component for the NIOS/SOPC builder and the component is implemented using some custom logic in VHDL code, the SOPC builder adds a new data bus for the component. Checked the is_shared setting in the PTF file and is set to value is_shared = "1". This same thing happends for every tristate slave component I add to the system. Question is, Is there any way for avoiding these extra data buses from appearing? From my point of view, this buses have sense only if the external chips are not intended for being connected to the same FPGA data bus pins, which is not my case. Thanks a lot in advance.
Hi VlorenzoThere seems to be a bug in the SOPC builder. To work around this problem, you will have to manually edit the ptf file and set the "is_shared" value to is_shared = "0" for the tristate bus and regenerate the SOPC system. This should solve your problem. Regards, Kel
Hi, Kelvin,Thanks for your comment. Tried changing the is_shared's value to "0", but the extra data buses were still appearing. Looking at the LAN91C111 SOPC builder info, found that it has two more settings : Uses_Tri_State_Data_Bus = "1"; and Tri_State_Data_Bus = "--unknown--"; Are these settings somehow related with this data buses issue? Has anyone check it?
VLorenzo,did you attend not to modify the .ptf file while SOPC Builder is open otherwise it is restored to its original content when generating? The failure you described was in Quartus 4.2 / NIOS 1.1 and appeared with Avalons read and write signals . With Version 5.0 this is solved. Mike
Being out of work for several days, so...Hi, Kelvin, Mike, I have manually edited the PTF file (making sure that neither SOPCBuilder nor QuartusII were running) and changed the component's PORT data attribute is_shared to "0"; same results as with value "1", an extra data bus appeared. In the settings for the tri-state bus master I found no is_shared attribute to play with. Where is the "tristate bus" located, Kelvin? Thanks in advance.
Hi,In the case of a tristate bus, you have both options: simply mapping the avalon signals to ports for being connected to the external fpga chip, or including an HDL file (or files) for including hardware into the system. Some chips have a very simple interface and need nothing else but simple connections to the corresponding avalon bus signals, but some others have a rather than simple interface and require special timing and signals which are not a simple combinational logic from the avalon bus signals, which is our case.
1. tristate-Data_bus and address_bus should be directly ported out to external device2. the signals of above components could be added LOGIC in FPGA before being ported out ot external device