Additional Hardware Module with Xilinx MicroBlaze Processor

Hey all,

I have a Xilinx Spartan-3E starter board, and I'm implementing a MicroBlaze processor on the FPGA. I would also like to use the LCD which is on board, and I have already developed a hardware module that takes care of initialization and printing to the LCD. The interface is shown below:

entity LCD_top is Port ( clk : in STD_LOGIC; reset : in STD_LOGIC;

din : in STD_LOGIC_VECTOR (7 downto 0); din_ready : in STD_LOGIC; busy : out STD_LOGIC;

LCD_D : out STD_LOGIC_VECTOR (11 downto 8); LCD_E : out STD_LOGIC; LCD_RS : out STD_LOGIC; LCD_RW : out STD_LOGIC

); end LCD_top;

I really would like to instantiate this module along with the processor core. My question is this - how would I go about interfacing this with the MicroBlaze processor internal to the FPGA? What I would like to do is define a GPIO port on the processor to connect to the din, din_ready and busy lines of the LCD module, but I keep getting the following error:

ERROR:MDT - INST:LCD_data_status_10Bit PORT:GPIO_IO CONNECTOR:LCD_data_status_10Bit_GPIO_IO - C:\EDK_Test_LCD \system.mhs line 150 - connection is not connected to an external port! MPD subproperties IOB_STATE=BUF|REG or THREE_STATE=TRUE require that the port be connected directly to an external port.

Is there any way to work around this? I realize I could just connect the LCD to the GPIO directly and write software drivers, but I'm trying to avoid that because I already have the hardware module in place and working smoothly. It will also be nice to have this separate module so that it does the work of printing to the LCD, and the processor itself can stay busy with other more important jobs.

Also, is there an easier way to add another hardware module without manually editing the generated VHDL files for the core? I'm not sure if you can do that within Platform Studio.

Any advice would be much appreciated, thanks!

Ray

Reply to
Ray D.
Loading thread data ...

e

The "IOB_STATE=3DBUF|REG" part of the error message means that the GPIO core is instantiating IOB primitives in its code instead of letting Platgen infer them. That means that this core will not be happy unless those ports are made external and go to FPGA pins.

I would suggest creating a simple OPB interface to your core. The OPB bus is simple, and creating a slave interface to what you show above would not be hard.

The OPB is documented in $EDK/third_party/doc/OpbBus.pdf. That might be part of the IBM CoreConnect Bus Functional Model tool kit. If it is, you just register for the tool kit on the Xilinx web site to get access to it.

For you second question, did you package your LCD code as an EDK Pcore? If you do that, you can add the core through the GUI.

Regards,

John McCaskill

formatting link

Reply to
John McCaskill

The problem is that EDK basically wants all EDK blocks in its design, and assumes that anything you want to do can be done with EDK blocks, such as GPIO.

I agree with John that you probably want an OPB bus interface to the LCD device; the question is the easiest way to create one.

The OPB bus looks complex, if you take all the optional features into account. John's view is that it isn't, but if you need DMA or other special features it may get tricky. Using DMA, I have seen bugs in the Xilinx-supplied cores (in the EDK 7.1 era) which either shows it's complex, or suggests you roll your own in place of the vendor cores!

If you don't want to delve straight into OPB, look at the "OPB IPIF" module which is a starting point for your own OPB core. What I did with this was to add whatever I/O signals I wanted (e.g. to talk to your LCD interface) to the IPIF top level, and simply connect them up to the IPIF interface internally, in the section indicated for user logic.

I did it this way because the EDK project was a small bolt-on to a large project. It would be more straightforward to instantiate the LCD controller in the IPIF user logic area; and thus wrap it as an EDK block.

I'm not recommending this as a better option than rolling your own OPB core, but it's an alternative worth looking at; possibly simpler for a first EDK project.

- Brian

Reply to
Brian Drummond

Hi,

Depending a little on how your busy signals work, you might just hook up your module to the FSL interface on MicroBlaze. Your busy signal needs be high when it can't accept a new word even when there is no attempt to write to the module. MicroBlaze will also just do one cycle write so your module needs to accept a new word in one clock cycle when busy is low.

Connect: din(7 downto 0) -> FSL0_M_Data(24 to 31) din_ready -> FSL0_M_Write busy -> FSL0_M_Full

You need to enable FSL Interfaces to MicroBlaze with the parameter C_FSL_LINKS (set it to 1) You can write to the fsl interface with the function putfslx, you can read more about this function in the document "OS and Libraries Document Collection".

Göran

Reply to
Göran Bilski

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.