LPC 2378: A/D bus connection with FPGA

Started by thefireprintproject March 26, 2007
Hey everybody,

We're about to design a development platform with the LPC 2378 and an
FPGA (Lattice XP). Our problem is that the 2378 seems to support only
an asynchronous bus, and we suppose that we will have problems with
the clock. Has something similar been done before, and are there any
application notes?

Regards,

fireprint

An Engineer's Guide to the LPC2100 Series

Hi,

> We're about to design a development platform with the LPC 2378 and an
> FPGA (Lattice XP). Our problem is that the 2378 seems to support only
> an asynchronous bus, and we suppose that we will have problems with
> the clock. Has something similar been done before, and are there any
> application notes?

I've not played with the 2378, but FPGAs I know.

To interface a clocked FPGA to an asynchronous interface is
fairly simple, but it depends on what you have available.

For example, does the 2378 output a bus clock in relation to
its asynchronous signals? Or does the data sheet show the bus timing
relative to its processor clock? If so, then so long as your
FPGA uses the same clock and meets the bus timing requirements,
then the 'asynchronous bus' can be treated as synchronous.

If you have no control over the clock relation, then simply
implement an asynchronous interface. If the FPGA uses a clock,
and the clock is a lot faster than the asynchronous control
signals, then you can synchronize the signals to the FPGA
clock domain and write to FPGA synchronous registers.
If the FPGA clock is on the same timescale as the async
waveforms, then you'll just have to create registers that
are clocked by the async signals, and then internally
synchronize control bits as needed, i.e., the register clock
is generated from the bus select/write-enable/address
control controls. Readback is simply, it uses just the
address, and the bus output-drivers are enabled if the
FPGA is selected for read.

For transferring blocks of data between the FPGA and the
2378, just use dual-ported RAM or a FIFO. The FPGA writes to
the RAM using its clock-domain, while the processor reads
it in its clock domain.

First thing I'd try to do is come up with a bus-functional-model
of the 2378 external bus, and then write VHDL and simulate
in ModelSim - thats all independent of the fact you want
to use Lattice FPGAs. The RAM/FIFO logic will likely be
specific to whatever FPGA you select.

Just a few ideas.
Dave
Heureka!!

Thank you very much for the quick reply.
We're gonna implement the asynchronous version, since
the 2378 does not output a bus clock.

Regards,
fireprint

--- In l..., David Hawkins wrote:
> Hi,
>
> > We're about to design a development platform with the LPC 2378 and an
> > FPGA (Lattice XP). Our problem is that the 2378 seems to support only
> > an asynchronous bus, and we suppose that we will have problems with
> > the clock. Has something similar been done before, and are there any
> > application notes?
>
> I've not played with the 2378, but FPGAs I know.
>
> To interface a clocked FPGA to an asynchronous interface is
> fairly simple, but it depends on what you have available.
>
> For example, does the 2378 output a bus clock in relation to
> its asynchronous signals? Or does the data sheet show the bus timing
> relative to its processor clock? If so, then so long as your
> FPGA uses the same clock and meets the bus timing requirements,
> then the 'asynchronous bus' can be treated as synchronous.
>
> If you have no control over the clock relation, then simply
> implement an asynchronous interface. If the FPGA uses a clock,
> and the clock is a lot faster than the asynchronous control
> signals, then you can synchronize the signals to the FPGA
> clock domain and write to FPGA synchronous registers.
> If the FPGA clock is on the same timescale as the async
> waveforms, then you'll just have to create registers that
> are clocked by the async signals, and then internally
> synchronize control bits as needed, i.e., the register clock
> is generated from the bus select/write-enable/address
> control controls. Readback is simply, it uses just the
> address, and the bus output-drivers are enabled if the
> FPGA is selected for read.
>
> For transferring blocks of data between the FPGA and the
> 2378, just use dual-ported RAM or a FIFO. The FPGA writes to
> the RAM using its clock-domain, while the processor reads
> it in its clock domain.
>
> First thing I'd try to do is come up with a bus-functional-model
> of the 2378 external bus, and then write VHDL and simulate
> in ModelSim - thats all independent of the fact you want
> to use Lattice FPGAs. The RAM/FIFO logic will likely be
> specific to whatever FPGA you select.
>
> Just a few ideas.
> Dave
>
Hi fireprint,

> Thank you very much for the quick reply.
> We're gonna implement the asynchronous version, since
> the 2378 does not output a bus clock.

Sounds good.

I took a quick look at the user manual and saw that
they didn't output their XCLK signal. I guess thats
the internal bus clock. So yep, I'd go for the async
interface. As to whether you use the control signals
as clock edges, or the FPGA clock to sync signals,
that'll depend on the FPGA clock rate.

Feel free to send me your VHDL file and testbench code,
I can fire up ModelSim and critique the code if you want.

Of course if you're stuck in the old-world of schematic
capture, then 'yer on yer own' ... hint hint ... work
in an HDL and life is good.

Check out opencores.org too. They may have something
over there you can copy as a reference design.

Cheers,
Dave
Hey Dave,

> I took a quick look at the user manual and saw that
> they didn't output their XCLK signal. I guess thats
> the internal bus clock. So yep, I'd go for the async
> interface. As to whether you use the control signals
> as clock edges, or the FPGA clock to sync signals,
> that'll depend on the FPGA clock rate.
>
> Feel free to send me your VHDL file and testbench code,
> I can fire up ModelSim and critique the code if you want.
>
> Of course if you're stuck in the old-world of schematic
> capture, then 'yer on yer own' ... hint hint ... work
> in an HDL and life is good.
>
> Check out opencores.org too. They may have something
> over there you can copy as a reference design.

Yeah, it took us a lot of nerves to accept that they don't
output the XCLK and that the X is not for eXternal... *lol*

Thank you a lot for your offer, but I actually do spend a
lot of time with ModelSim myself... :)
In my case, VHDL is for VHSIC, not Verilog. How about you?
What's your profession? (If I may ask?)

I took a quick look at opencores as well, cool! Thank you
for the hint. We're using a CORDIC for our current project
and we had the optimization of this part "outsourced".
(It's a student project, so work is cheap... *lol*)

Okay then... see you.

Cheers, Helga