FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 01-15-2004, 10:11 PM
Steve T Shannon
Guest
 
Posts: n/a
Default Spartan-IIE as an ASYNC RAM?

Hello! I'm trying to interface a Spartan-IIE to one of analog device's
new ADSP-21262 DSPs. The problem is that my application requires
high-bandwidth communication with the DSP, and the DSP's parallel
interface expects an _asynchronous_ ram. That's right, it has
edge-triggering ALE, RE, and WE lines that are expected to interface
to standard static SRAM.

I have been trying to come up with a solution to talking to the FPGA,
to no avail. The ALE signal is asserted for only 10 ns, thus
oversampling the pins is going to be really difficult (and that's
ignoring all the potential metastability issues!) Has anyone ever made
an interface like this work? I know on the spartan-series, internal
flip-flops can only be gated by the internal clock nets, which can
only be sourced by one of the 4 clock pins.

Any help would be appreciated!

Thanks,

Steve
Reply With Quote
  #2 (permalink)  
Old 01-16-2004, 01:38 AM
Allan Herriman
Guest
 
Posts: n/a
Default Re: Spartan-IIE as an ASYNC RAM?

On 15 Jan 2004 13:11:49 -0800, [email protected] (Steve T
Shannon) wrote:

>Hello! I'm trying to interface a Spartan-IIE to one of analog device's
>new ADSP-21262 DSPs. The problem is that my application requires
>high-bandwidth communication with the DSP, and the DSP's parallel
>interface expects an _asynchronous_ ram. That's right, it has
>edge-triggering ALE, RE, and WE lines that are expected to interface
>to standard static SRAM.
>
>I have been trying to come up with a solution to talking to the FPGA,
>to no avail. The ALE signal is asserted for only 10 ns, thus
>oversampling the pins is going to be really difficult (and that's
>ignoring all the potential metastability issues!) Has anyone ever made
>an interface like this work? I know on the spartan-series, internal
>flip-flops can only be gated by the internal clock nets, which can
>only be sourced by one of the 4 clock pins.


ALE, RE, etc. are actually timed from a clock inside the DSP. Can you
access the processor core clock? If so, you can pass that to the FPGA
and have a fully synchronous interface, assuming your FPGA can handle
the speed (200MHz).

Ummm, I can't see a CCLK out pin on the datasheet, but you do control
CLKIN (which gets multiplied by a PLL inside the DSP to form CCLK).
You might be able to do something with that (like using an external
PLL to form your own CCLK).

It might be simpler to treat the signals as asynchronous. Can
Spartan-IIE do DDR? If so, you only need a clock a little over 50MHz
to sample the 10ns ALE strobe.

Regards,
Allan.
Reply With Quote
  #3 (permalink)  
Old 01-16-2004, 05:59 AM
Ralph Malph
Guest
 
Posts: n/a
Default Re: Spartan-IIE as an ASYNC RAM?

Allan Herriman wrote:
>
> On 15 Jan 2004 13:11:49 -0800, [email protected] (Steve T
> Shannon) wrote:
>
> >Hello! I'm trying to interface a Spartan-IIE to one of analog device's
> >new ADSP-21262 DSPs. The problem is that my application requires
> >high-bandwidth communication with the DSP, and the DSP's parallel
> >interface expects an _asynchronous_ ram. That's right, it has
> >edge-triggering ALE, RE, and WE lines that are expected to interface
> >to standard static SRAM.
> >
> >I have been trying to come up with a solution to talking to the FPGA,
> >to no avail. The ALE signal is asserted for only 10 ns, thus
> >oversampling the pins is going to be really difficult (and that's
> >ignoring all the potential metastability issues!) Has anyone ever made
> >an interface like this work? I know on the spartan-series, internal
> >flip-flops can only be gated by the internal clock nets, which can
> >only be sourced by one of the 4 clock pins.

>
> ALE, RE, etc. are actually timed from a clock inside the DSP. Can you
> access the processor core clock? If so, you can pass that to the FPGA
> and have a fully synchronous interface, assuming your FPGA can handle
> the speed (200MHz).
>
> Ummm, I can't see a CCLK out pin on the datasheet, but you do control
> CLKIN (which gets multiplied by a PLL inside the DSP to form CCLK).
> You might be able to do something with that (like using an external
> PLL to form your own CCLK).
>
> It might be simpler to treat the signals as asynchronous. Can
> Spartan-IIE do DDR? If so, you only need a clock a little over 50MHz
> to sample the 10ns ALE strobe.


Trying to treat this as a synchronous interface would be very, very
difficult. I have tried to do this on a chip where I *had access* to
the CPU clock. But the relative timing was not spec'd. So the best I
could do was to use the edges of strobes to clock data and then resync
to the clock.

Although your ALE may be very short, you can use the trailing edge to
clock or gate the data into FFs. Then you should be able to retime the
strobes (and assert the RDY/WAIT or otherwise add wait states) to allow
your FPGA a couple of internal clock cycles to read the data. On
writes, of course, you can clock the data into a register and then into
the RAM at your leisure. And of course, don't forget the metastable
issues, even if your clock is synchronous, it is not phase aligned.
Reply With Quote
  #4 (permalink)  
Old 01-16-2004, 07:27 AM
Allan Herriman
Guest
 
Posts: n/a
Default Re: Spartan-IIE as an ASYNC RAM?

On Thu, 15 Jan 2004 23:59:35 -0500, Ralph Malph <[email protected]>
wrote:

>Allan Herriman wrote:
>>
>> On 15 Jan 2004 13:11:49 -0800, [email protected] (Steve T
>> Shannon) wrote:
>>
>> >Hello! I'm trying to interface a Spartan-IIE to one of analog device's
>> >new ADSP-21262 DSPs. The problem is that my application requires
>> >high-bandwidth communication with the DSP, and the DSP's parallel
>> >interface expects an _asynchronous_ ram. That's right, it has
>> >edge-triggering ALE, RE, and WE lines that are expected to interface
>> >to standard static SRAM.
>> >
>> >I have been trying to come up with a solution to talking to the FPGA,
>> >to no avail. The ALE signal is asserted for only 10 ns, thus
>> >oversampling the pins is going to be really difficult (and that's
>> >ignoring all the potential metastability issues!) Has anyone ever made
>> >an interface like this work? I know on the spartan-series, internal
>> >flip-flops can only be gated by the internal clock nets, which can
>> >only be sourced by one of the 4 clock pins.

>>
>> ALE, RE, etc. are actually timed from a clock inside the DSP. Can you
>> access the processor core clock? If so, you can pass that to the FPGA
>> and have a fully synchronous interface, assuming your FPGA can handle
>> the speed (200MHz).
>>
>> Ummm, I can't see a CCLK out pin on the datasheet, but you do control
>> CLKIN (which gets multiplied by a PLL inside the DSP to form CCLK).
>> You might be able to do something with that (like using an external
>> PLL to form your own CCLK).
>>
>> It might be simpler to treat the signals as asynchronous. Can
>> Spartan-IIE do DDR? If so, you only need a clock a little over 50MHz
>> to sample the 10ns ALE strobe.

>
>Trying to treat this as a synchronous interface would be very, very
>difficult. I have tried to do this on a chip where I *had access* to
>the CPU clock. But the relative timing was not spec'd. So the best I
>could do was to use the edges of strobes to clock data and then resync
>to the clock.


I've had a lot of success treating nominally asynchronous interfaces
as synchronous. But then, these were all low speed (<= 50MHz) with
timing specified in terms of the clock, except for one which I
measured (and took the attendant risk).

>Although your ALE may be very short, you can use the trailing edge to
>clock or gate the data into FFs. Then you should be able to retime the
>strobes (and assert the RDY/WAIT or otherwise add wait states) to allow
>your FPGA a couple of internal clock cycles to read the data.


I've done this too, and I agree that it's a better solution for the
OP.

Also,
- ALE doesn't need to be on a BUFG even though it is used as a clock
(since there is no skew issue).

- Even if ALE is reallllly narrow, it's still possible to get it into
your clock domain by stretching it. Connecting ALE to the clock of a
FF. Tie D high, so that Q goes high on the rising edge of ALE.
Asynchronously reset the FF once Q is sampled in the other clock
domain. It's ugly but it works.

E.g.

Your clock --o---------------------+
| |
| |
| |
| |
| |
.---. | .---. __ | .---.
'1'-------|D Q|---------|D Q|-----| | +-----|D Q|----+--
ALE----------|>C | +----|>C | |& |-+ +---|>C | |
+---|R | | | +-|__| | |o-+ |
| '---' '---' | '---' | |
| +-------------------+ |
| |
+-----------------------------------------------+

created by Andy´s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de

The and gate is needed to ensure that the output pulse is only one
clock wide. (Note that this could be turned into a synchronous reset
on the third flip flop, which removes the and gate delay from the
metastability resolution time of the second flip flop.)

For some reason, the Xilinx tools won't trace delays on async resets
by default. There's some magic incantation in the pcf that makes it
work though (I can't remember it right now).


I don't mean to claim that this is the only way you can do it -
there are many other equivalent circuits that would work just as well.

Regards,
Allan.
Reply With Quote
  #5 (permalink)  
Old 01-16-2004, 10:51 AM
Hal Murray
Guest
 
Posts: n/a
Default Re: Spartan-IIE as an ASYNC RAM?

>Hello! I'm trying to interface a Spartan-IIE to one of analog device's
>new ADSP-21262 DSPs. The problem is that my application requires
>high-bandwidth communication with the DSP, and the DSP's parallel
>interface expects an _asynchronous_ ram. That's right, it has
>edge-triggering ALE, RE, and WE lines that are expected to interface
>to standard static SRAM.


Have you tried asking Analog Devices? I expect you aren't the only
one interested in this problem. They might have a good solution.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

Reply With Quote
  #6 (permalink)  
Old 01-16-2004, 02:21 PM
Steve T Shannon
Guest
 
Posts: n/a
Default Re: Spartan-IIE as an ASYNC RAM?

Allan Herriman <[email protected]> wrote in message news:<[email protected]>. ..
> On Thu, 15 Jan 2004 23:59:35 -0500, Ralph Malph <[email protected]>
> wrote:
>
> >Allan Herriman wrote:
> >>
> >> On 15 Jan 2004 13:11:49 -0800, [email protected] (Steve T
> >> Shannon) wrote:
> >>
> >> >Hello! I'm trying to interface a Spartan-IIE to one of analog device's
> >> >new ADSP-21262 DSPs. The problem is that my application requires
> >> >high-bandwidth communication with the DSP, and the DSP's parallel
> >> >interface expects an _asynchronous_ ram. That's right, it has
> >> >edge-triggering ALE, RE, and WE lines that are expected to interface
> >> >to standard static SRAM.
> >> >
> >> >I have been trying to come up with a solution to talking to the FPGA,
> >> >to no avail. The ALE signal is asserted for only 10 ns, thus
> >> >oversampling the pins is going to be really difficult (and that's
> >> >ignoring all the potential metastability issues!) Has anyone ever made
> >> >an interface like this work? I know on the spartan-series, internal
> >> >flip-flops can only be gated by the internal clock nets, which can
> >> >only be sourced by one of the 4 clock pins.
> >>
> >> ALE, RE, etc. are actually timed from a clock inside the DSP. Can you
> >> access the processor core clock? If so, you can pass that to the FPGA
> >> and have a fully synchronous interface, assuming your FPGA can handle
> >> the speed (200MHz).
> >>
> >> Ummm, I can't see a CCLK out pin on the datasheet, but you do control
> >> CLKIN (which gets multiplied by a PLL inside the DSP to form CCLK).
> >> You might be able to do something with that (like using an external
> >> PLL to form your own CCLK).
> >>
> >> It might be simpler to treat the signals as asynchronous. Can
> >> Spartan-IIE do DDR? If so, you only need a clock a little over 50MHz
> >> to sample the 10ns ALE strobe.

> >
> >Trying to treat this as a synchronous interface would be very, very
> >difficult. I have tried to do this on a chip where I *had access* to
> >the CPU clock. But the relative timing was not spec'd. So the best I
> >could do was to use the edges of strobes to clock data and then resync
> >to the clock.

>
> I've had a lot of success treating nominally asynchronous interfaces
> as synchronous. But then, these were all low speed (<= 50MHz) with
> timing specified in terms of the clock, except for one which I
> measured (and took the attendant risk).
>
> >Although your ALE may be very short, you can use the trailing edge to
> >clock or gate the data into FFs. Then you should be able to retime the
> >strobes (and assert the RDY/WAIT or otherwise add wait states) to allow
> >your FPGA a couple of internal clock cycles to read the data.

>
> I've done this too, and I agree that it's a better solution for the
> OP.
>
> Also,
> - ALE doesn't need to be on a BUFG even though it is used as a clock
> (since there is no skew issue).
>
> - Even if ALE is reallllly narrow, it's still possible to get it into
> your clock domain by stretching it. Connecting ALE to the clock of a
> FF. Tie D high, so that Q goes high on the rising edge of ALE.
> Asynchronously reset the FF once Q is sampled in the other clock
> domain. It's ugly but it works.
>
> E.g.
>
> Your clock --o---------------------+
> | |
> | |
> | |
> | |
> | |
> .---. | .---. __ | .---.
> '1'-------|D Q|---------|D Q|-----| | +-----|D Q|----+--
> ALE----------|>C | +----|>C | |& |-+ +---|>C | |
> +---|R | | | +-|__| | |o-+ |
> | '---' '---' | '---' | |
> | +-------------------+ |
> | |
> +-----------------------------------------------+
>
> created by Andy´s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de
>
> The and gate is needed to ensure that the output pulse is only one
> clock wide. (Note that this could be turned into a synchronous reset
> on the third flip flop, which removes the and gate delay from the
> metastability resolution time of the second flip flop.)
>
> For some reason, the Xilinx tools won't trace delays on async resets
> by default. There's some magic incantation in the pcf that makes it
> work though (I can't remember it right now).
>
>
> I don't mean to claim that this is the only way you can do it -
> there are many other equivalent circuits that would work just as well.
>
> Regards,
> Allan.


Thanks for the advice! My concern isn't the BUFGs so much as it is the
IBUFGs, which seem to be the only way to get a clock-able signal into
the chip. I'm already using them all I think I'm going to settle on
decoding the ALE signal externally with a latch, and just having the
entire system be sampled. I've had to move up to the PQ208 Spartan-IIE
(from the TQ144) which is a bit more expensive, but still should work.
Now I just have to tackle the metastability issues. (oh no!)

Thanks again for the help,

Steve
Reply With Quote
  #7 (permalink)  
Old 01-16-2004, 04:54 PM
Allan Herriman
Guest
 
Posts: n/a
Default Re: Spartan-IIE as an ASYNC RAM?

On 16 Jan 2004 05:21:37 -0800, [email protected] (Steve T
Shannon) wrote:

>Thanks for the advice! My concern isn't the BUFGs so much as it is the
>IBUFGs, which seem to be the only way to get a clock-able signal into
>the chip. I'm already using them all I think I'm going to settle on
>decoding the ALE signal externally with a latch, and just having the
>entire system be sampled. I've had to move up to the PQ208 Spartan-IIE
>(from the TQ144) which is a bit more expensive, but still should work.
>Now I just have to tackle the metastability issues. (oh no!)


I don't think you need to use an IBUFG if you are not using a BUFG for
a clock, i.e. any old general purpose I/O pin will do. (But better to
make it one close to where it's need to reduce routing delays inside
the FPGA.)

Regards,
Allan.
Reply With Quote
  #8 (permalink)  
Old 01-16-2004, 06:47 PM
Ralph Malph
Guest
 
Posts: n/a
Default Re: Spartan-IIE as an ASYNC RAM?

Allan Herriman wrote:
>
> On Thu, 15 Jan 2004 23:59:35 -0500, Ralph Malph <[email protected]>
> wrote:
>
> >Trying to treat this as a synchronous interface would be very, very
> >difficult. I have tried to do this on a chip where I *had access* to
> >the CPU clock. But the relative timing was not spec'd. So the best I
> >could do was to use the edges of strobes to clock data and then resync
> >to the clock.

>
> I've had a lot of success treating nominally asynchronous interfaces
> as synchronous. But then, these were all low speed (<= 50MHz) with
> timing specified in terms of the clock, except for one which I
> measured (and took the attendant risk).


It can be done, but if the edges are spec'd relative to the clock, then
in essence this *is* a synchonous interface to async memory. If the
edges are *not* spec'd relative to the clock, then you are playing with
fire since the timing can vary from lot to lot and with temperature,
etc. It may work well, or it may fail on every hundredth board.

> >Although your ALE may be very short, you can use the trailing edge to
> >clock or gate the data into FFs. Then you should be able to retime the
> >strobes (and assert the RDY/WAIT or otherwise add wait states) to allow
> >your FPGA a couple of internal clock cycles to read the data.

>
> I've done this too, and I agree that it's a better solution for the
> OP.
>
> Also,
> - ALE doesn't need to be on a BUFG even though it is used as a clock
> (since there is no skew issue).
>
> - Even if ALE is reallllly narrow, it's still possible to get it into
> your clock domain by stretching it. Connecting ALE to the clock of a
> FF. Tie D high, so that Q goes high on the rising edge of ALE.
> Asynchronously reset the FF once Q is sampled in the other clock
> domain. It's ugly but it works.
>
> E.g.
>
> Your clock --o---------------------+
> | |
> | |
> | |
> | |
> | |
> .---. | .---. __ | .---.
> '1'-------|D Q|---------|D Q|-----| | +-----|D Q|----+--
> ALE----------|>C | +----|>C | |& |-+ +---|>C | |
> +---|R | | | +-|__| | |o-+ |
> | '---' '---' | '---' | |
> | +-------------------+ |
> | |
> +-----------------------------------------------+
>
> created by Andy´s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de
>
> The and gate is needed to ensure that the output pulse is only one
> clock wide. (Note that this could be turned into a synchronous reset
> on the third flip flop, which removes the and gate delay from the
> metastability resolution time of the second flip flop.)
>
> For some reason, the Xilinx tools won't trace delays on async resets
> by default. There's some magic incantation in the pcf that makes it
> work though (I can't remember it right now).
>
> I don't mean to claim that this is the only way you can do it -
> there are many other equivalent circuits that would work just as well.


I was once shown a circuit similar to yours above, that gets rid of the
async reset and replaces the and gate with an XOR.

___G1
+-----------| | Output1
| |XOR|---
+-----------------------------+--|___|
| | | Output2
| FF1 | | ___G2
| .---. | | +-----------| |
+--|D |- | | | |XOR|---
ALE | | FF2 | FF3 | | FF4 +-|___|
-----o|>C | .---. | .---. | | .---. |
| |o-----|D |--+--|D |-+--+--|D |--+
'---' | | | | | |
+--o|>C | +-o|>C | +-o|>C |
| | |o | | |o | | |
| '---' | '---' | '---'
| | | Clock
+----------+-----------+------------------

created by Andy´s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de

This circuit toggles the FFs each time the ALE clocks the first FF. No
reset is needed. FF2 and FF3 sync the edge to the new clock domain.
You can use G1 to output a one clock wide pulse if the gate does not
take too much time from the metastable settling. Or if you are running
a very fast clock, you can use FF4 and G2 to generate the one clock wide
pulse.

Thanks for the ASCII art reference. This is very useful.
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Questions about Async. FIFO [email protected] Verilog 0 01-17-2006 11:42 AM
Best Async FIFO Implementation Davy Verilog 10 11-11-2005 01:18 AM
Interpreting 1364.1-2002 5.2.2.1: Edge FF's with async jam load John Vickers Verilog 3 05-27-2004 01:36 PM
multiplier,CLK-insufficient RECOVERY time after async CLEAR ranbow FPGA 7 12-19-2003 09:30 PM


All times are GMT +1. The time now is 12:42 AM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved