FPGA to SRAM port interface

> No, you want the continuous clock that
> generated ALE. In a synchronous system,
> ALE is an input, not a clock.

Mike, I don't have access to this clock.

Luiz Carlos.

> I just don't like your logic of testing ALE inside the
> clocked section -- when the clock itself depends on
> ALE. This is really questionable, get that out of the
> picture and things will get simpler.

Hi Dave,

Yes, that's the point. I also don't like it, but if possible and safe,
it would be the easier way.
Can it be made in a safe way? This is what I'm trying to learn!

Luiz Carlos.

oen_br schrieb:

> Not really.
> The FPGA, besides other functions, connects 4 DSPs, a shared external
> SRAM and a PCI controller, everybody talking to everybody.

In this case, a SYNCHRONOUS bus is strongly suggested. AFAIK many DSPs 
output the bus clock along with all other signals.

> I thought this kind of problem was very common (combinatorial clocks
> using it's source signals as clock enables)!

This is bad bad hack an shounld be avoided as much as possible. Maybe 
sometimes even more ;-)

Regards
Falk

> In this case, a SYNCHRONOUS bus is strongly suggested. AFAIK many DSPs
> output the bus clock along with all other signals.

Yes, but not the parallel port of ADSP-21363!

> This is bad bad hack an shounld be avoided as much as possible. Maybe
> sometimes even more ;-)

I would like to have the DSP peripheral clock, but I have to work with
what is available.

Luiz Carlos.

oen_br wrote:
>> No, you want the continuous clock that
>> generated ALE. In a synchronous system,
>> ALE is an input, not a clock.
> 
> Mike, I don't have access to this clock.

In that case, I would use a PLL or add an oscillator
to resynchronize everything to one clock.

        -- Mike Treseler

oen_br wrote:
> > No, you want the continuous clock that
> > generated ALE. In a synchronous system,
> > ALE is an input, not a clock.
>
> Mike, I don't have access to this clock.
>
> Luiz Carlos.

Few years ago I had this asynchronous interface running at ~25Mhz, not
sure for 60Mhz.  You may try to load the address asynchronous.  No
reason why it doesn't work if you take care setup/hold time

process(ALE, WRITE#)
  if (ALE = '1') then
    addr <= dtadd;
  elsif  rising_edge(WRITE#)   then
    addr <= addr + 1;
  end if;
end process;

Marlboro wrote:
> oen_br wrote:
> 
>>>No, you want the continuous clock that
>>>generated ALE. In a synchronous system,
>>>ALE is an input, not a clock.
>>
>>Mike, I don't have access to this clock.
>>
>>Luiz Carlos.
> 
> 
> Few years ago I had this asynchronous interface running at ~25Mhz, not
> sure for 60Mhz.  You may try to load the address asynchronous.  No
> reason why it doesn't work if you take care setup/hold time
> 
> process(ALE, WRITE#)
>   if (ALE = '1') then
>     addr <= dtadd;
>   elsif  rising_edge(WRITE#)   then
>     addr <= addr + 1;
>   end if;
> end process;
> 

For the love of god, would the original poster please
post a follow up on what finally makes the thing
work? Too many people post questions, get answers,
then vanish.

Note the WRITE# isn't enough, there's also the READ#.
But this code seems perfect, if it works.

-Dave


-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

David,

I don't have the hardware yet, so, I'm just doing simulations. It will
take more 3 to 4 months for the prototype board, but I'm trying to
catch early designs faults. (Actually I'm doing everything, hardware,
software and pre-layout, and a lot of times I have to stop and do other
things!)
At simulations, it worked (using auxiliary signals as that LOAD_ADDR),
but I want a robust, clear and as simple as possible design. So I asked
for some guide lines/ideias.
I'll share the results when I have them.

Luiz Carlos

> process(ALE, WRITE#)
>   if (ALE = '1') then
>     addr <= dtadd;
>   elsif  rising_edge(WRITE#)   then
>     addr <= addr + 1;
>   end if;
> end process;

Marlboro,

This means that the CLB storage must have flip-flop and latch behavior
at the same time, and I think it's not possible. When it's a flip-flop
you can have preset/clear input, but it is preset or clear. Well,
looking at the datasheet I found that "rev" input, I need to read more
about it.

Luiz Carlos

oen_br wrote:
> > process(ALE, WRITE#)
> >   if (ALE = '1') then
> >     addr <= dtadd;
> >   elsif  rising_edge(WRITE#)   then
> >     addr <= addr + 1;
> >   end if;
> > end process;
>
> Marlboro,
>
> This means that the CLB storage must have flip-flop and latch behavior
> at the same time, and I think it's not possible. When it's a flip-flop
> you can have preset/clear input, but it is preset or clear. Well,
> looking at the datasheet I found that "rev" input, I need to read more
> about it.
>
> Luiz Carlos

Good point, I guess the synthesizer  will "decode" the combine logic of
dtadd & ALE and feed outputs to async R/P of the flipflops...

For example R(0) = ALE and not(dtadd(0)),  P(0) = ALE and dtadd(0)...