Dev board with EMC

[lpcware]

Content originally posted in LPCWare by rowesca on Wed Mar 23 01:26:13 MST 2016
Hi,

Last week i asked a question to the suport but theu redirected me to here:

My problem is i have to read something from an FPGA very fast, like 60Mbps, SPI is gonna be tricky for this so i want to test if i can directly connect the external memory controller to a FPGA. But at first i want to test this, therefor i need a dev board. and there came my question.

i couldn't find a dev board with the external memory pins connected to headers, where i can connect a FPGA to it, does NXP have these? prefer with a LPC4300+ serie

Thanks!

[lpcware]

bump

[lpcware]

Content originally posted in LPCWare by rowesca on Fri Mar 25 04:47:30 MST 2016
Wouldn't dare to ask for a schematic, takes all the fun out of it haha! :)  thanks for very usefull tips! the jtag connection to MCU and clkout  to fpga are very smart tricks!

I planned on using Xilinx because of the free software and the little experience i already got with it. was planning on artix 7 family.  but will certainly take a look at MicroSemi, tbh i never heard of them before.

Cheers, Rowesca!

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Thu Mar 24 06:08:19 MST 2016
Some tips that may save you time and or grief.

1. We use Actel (now MicroSemi) devices. These can be 'flashed' with (fpga) code and are non-volatile.
    I.e. they retain the programming over power-cycles.
    We use the A3P-250 in a 208 QFP package. These contain internal ram blocks if that is of interest.

2. Rather than add a separate crystal to the BOM for the FPGA, I use (one of?) the ClkOut pins of the 1778
    to supply 50 Mhz (if I remember correctly) to the FPGA. Internally it uses PLL to get to 180 MHz.

3. Due to the flashing requirement, add a JTAG header for access to the FPGA JTAG pins.

4. The FPGA JTAG pins were also routed to otherwise unused GPIO pins on the 1778
    This means that we can send jedec files over the comms and re-program the FPGA via software in the CPU
    There is (actually 2) "C" code project on the ACtel site called "Direct-C" (registration required) which implements
    a STAPL player to actually program the FPGA from the jedec stapl file from your FPGA dev suite.

So we have two ways to (re) program the FPGA. Normally via an adapter and the JTAG port using Actel PC software
or via my 1778 software with a STAPL file over the comms. The latter is for corrective surgery to units already in the field where
physical access to the PCB is awkward or otherwise limited.

Please note that I work for a commercial company and therefore cannot share either schematics or code.
So just don't ask :)

Cheers, Mike.

[lpcware]

Content originally posted in LPCWare by rowesca on Thu Mar 24 03:53:41 MST 2016
First of all, i really appreciate your comment, this will be the first time working with the EMC and because i couldn't find a dev board where the emc pins are still free it is a bit risky to develop a board and only to find out it won't work.

Yeah i also read about those double read issues, I will take a look at the lpc1778, because i was thinking of not connecting the adress ports. But if it does double read cycles, it could mess up my sequence, where the FPGA increments the adress itself and the whole data will be out of order.

i was thinking of doing the configuration of the FPGA ( not the programming, internal config for my product ) by spi and than only do read cycles with the MCU so i could maximize my reading speed. besides some configs in the FPGA i wont have to send data from the MCU to the FPGA so that is why i wanted to not connect the adress ports, because the reading has a standard sequence.

Thanks, Rowesca

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Wed Mar 23 03:15:27 MST 2016
Hi Rowesca.

We use the LPC 1778 which also has the EMC peripheral.

I (the hardware guy) route the address and data and static RAM control signals from the CPU to the FPGA.

I then set the FPGA region as static RAM. The FPGA runs at 180 MHz internally via its PLL. The CPU runs at 120 MHz
so (for 1778) the EMC bus is at 60 MHz.

I don't do FPGA code, but it detects memory read and write (via CS, OE/WE etc) samples the address for
function required and data in for parameters or supplies data out to the CPU.

Other pins on the FPGA go to devices it controls.

This all works very well with no problems.

However, (I don't know but have read on these forums) the 43XX EMC (and also the 18XX which is the same EMC)
has an irritating problem in that it will (sometimes? always?) issue double read cycles even though the CPU only did
one read and buffering/burst is turned off. [Search the 18xx forum, but also applies to 43XX].
If your FPGA code can deal with extra read cycles appropriately, I would recommend the EMC approach.
It will be much faster the SPI/I2C in any case.

Cheers, Mike.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Mar 23 01:39:03 MST 2016
You could try looking at the LPC43xx development boards from Keil, Embedded Artists and Hitex. If none of those give you what you need, then I suspect that you may need to do your own board.

Regards,
LPCXpresso Support