Using more than one core

Guest b3457m0d3

Recommended Posts

Guest b3457m0d3

i have a sharp (psp) lcd, and i found a core on opencores that simulates a driver board and all the dac functions, my question is, how can i get the avr8 core to talk to that core  so i can write a sketch to run the lcd from the arduino?  im willing to do the leg-work here, but can anyone point me in a good direction?

Link to comment
Share on other sites

Hey! This looks like a pretty fun and challenging project. :)

I'm taking a quick look at the source code to determine what we can do here. Here's what I like to do to quickly evaluate a core like this. Keep in mind that OpenCores is kind of like the Wild, Wild, West and things you find there are may or may not follow standards. So the first thing to do is see if it implements any kind of standard way to communicate with a soft processor, like the Wishbone bus. You can look at the Opencores project details to see if it does, in this case it does not. That's ok, the AVR8 has an experimental version that supports Wishbone but is still a work in progress.

So moving on and looking at the source code, you want to read any documentation or README files first. I don't see anything that jumps out so lets find the top level VHDL file first. In this case it is clearly labeled as design/llq057q3dc02_top.vhd.

If we open it up we see some nice comments and constants that give us hints about how this core works. Next lets look at the single most important thing when evaluating a new core, what interface does it present to the outside world? We look at the PORT section for this:

  -- Port Descriptions:
  --  --Clocks/Resets--
  --  RSTx                    -- System Reset
  --  CLK100_PAD              -- 100MHz Input Clock from On-board XTAL
  --  --LCD Control Signals--
  --  CLK_LCD                  -- 6.25MHz LCD Clock
  --  HSYNCx                  -- Horizontal Sync Strobe
  --  VSYNCx                  -- Vertical Sync Strobe
  --  ENAB                    -- Enable Signal for LCD's shift registers
  --  RL                      -- LCD Image Right/Left Orientation
  --  UD                      -- LCD Image Up/Down Orientation
  --  VQ                      -- VGA (640x480) or QVGA (320x240) mode
  --  --LCD Data Signals--
  --  R,G,B                    -- Red/Green/Blue Color Data
  PORT (

    -- <PORT_NAME> : <MODE> <DATA_TYPE>;

    CLK_100M_PAD : IN std_logic;
    VQ      : OUT std_logic;
    B      : OUT std_logic_vector(C_BIT_DEPTH/3-1 downto 0)

This tells us almost everything we need to know about how the AVR8 can communicate with this core. And it looks like this core was not designed to be driven by a soft processor or some external means. It is only outputting signals to drive the LCD display but it has no inputs to drive what it is displaying...

It looks like there is an included C program that will convert an image file into a COE file that gets loaded into BRAM (Block RAM) memory that is the FPGA's internal memory. This core then outputs the content of the BRAM memory space. So theoretically we should be able to use the AVR8 to modify the contents of the BRAM memory to control what the lq057 core is outputting. BRAM is dual ported in nature so we should be able to connect things so the AVR8 writes to memory and the lq057 core reads from that memory.

The problem becomes one of having enough BRAM memory available for both the AVR8 and the lq057 controller. The vanilla version of the AVR8 uses 10 BRAM blocks for 16K of program space and 1K of SRAM space (off the top of my head...). The Papilio One 250K has 12 BRAM blocks and the Papilio One 500K has 20 BRAM blocks. So we probably need to use the 500K to have any chance of having enough memory. It is going to be a case of balancing the BRAM memory available. The AVR8 can be modified to support less memory space which would free up more memory for the display core. Or it looks like the display core can be configured to use a lower color depth to use less memory.

From the top level file

--  One useful piece of info for this 320x240x18bpp screen is that the

--  largest amount of image data it can support with all color bits used

--  is 1,382,400 bits = 172,800 bytes.  The Virtex-II Pro has enough BRAM

--  space to support 306KB = 313,344 bytes.  So you could not possible

--  fill up the BRAM with a single image.

I would start out by getting the core to run by itself by using the C program to fill BRAM with an image. Then play around with the settings to see if the BRAM usage can fit in 10 BRAM blocks.

Now, another thing to keep in mind, we have new Papilio prototypes sitting on my desk that use the Spartan 6 LX and include SRAM memory. With the new boards there we are not facing the same memory constraints, so if we cannot get a satisfactory solution with the Papilio One we should be able to with the new boards.


Link to comment
Share on other sites

Guest b3457m0d3

Thanks for the input, i'm looking forward to learning more about vhdl, specifically for the purpose of recreating components to test with before buying anything, any advice for an up & comer?

Link to comment
Share on other sites

One idea that I think is really cool is to work out a development environment for classic arcade games like Pac-Man for the Papilio Arcade MegaWing. There are already several old school sound chips and graphics subsystems that are out there. If we manage to setup a development environment then we can start splicing together demo's that might use the Pac-man graphics and the C64 SID audio chip...

I've put some time into trying to recreate the development environment described by Scott Lawrence here. I keep getting black screens though, I emailed him once but did not hear anything back...

I might put some time into trying to debug the code with the MAME debug feature this weekend.


Link to comment
Share on other sites

  • 1 year later...
  • 3 months later...


This topic is now archived and is closed to further replies.