async. SRAM control signal generation

Hello,

I've been busy lately, trying to understand how to interface asynchronous SRAMs
(like IDT 71V016, CY7C10xx or other 16-bit wide and fast parts in TSOP-II)

I have found some descriptions of multicycle methods, using FSMs, but this does
not fit my target because my circuits already run at "nominal speed" (8 to 15ns
cycles, depending on the SRAM chip). So I attempt to find how SRAM reads and
writes can be done in one cycle, with a FPGA that can't (or shouldn't) go faster.
(Yes I use Actel's ProASIC and I'm fine).

I have found (through the examination of timing diagrams in several datasheets)
that I can design a stateless async SRAM interface with this behaviour :

Read :
  on clock's rising edge :
     latch the address bus's value,
     Output Enable = 1, WriteEnable = 1,
     and keep data bus floating
  after 1/3 of clock cycle :
     Output Enable = 0
  on next clock rising edge :
     latch the data bus input.

Write :
   on clock rising edge :
     latch addres bus, OE=1, WriteEnable=1,
     keep data bus floating
   after 1/3 of clock cycle :
      WriteEnable = 0
   after 1/2 clock cycle (falling edge)
      latch data output and drive the output buffer

It's fine for me because it can be done by
correctly wiring latches to the proper control/data/clock signals
and it should work. Now comes the big question :

How would I generate the 1/3 clock cycle signal ?

* I don't want to use a 3x clock because the design already
fast and even though the PLL can output 350MHz, I'm not sure
that the logic and routing will follow (so making a 3-state FSM
is eventually possible but not realistic, too uncertain).
A dual-edged FSM with 1,5x clock would be another improbable chimera...

* I have seen that the PLL can generate a 5ns (max) delayed clock
based on the main clock, so it's fine for 15ns-rated SRAMs
(I could set the delay to 2,6ns for 8ns parts)
but what happens if 20ns or slower SRAMs are to be used ?
(I have 70ns chips for example, but I don't want to make
a FSM just for a few slow parts)
Also, I would like to keep/reserve PLL outputs for other purposes.

* In all the datasheets I have found, it is implicitly
necessary to have this 1/3 delay :
   - if shorter, there is a driver conflict on the data bus
      if the precendent cycle was a read
       (data remain present up to about 1/3 of the next clock cycle)
   - if longer, the data setup time is not respected and reliability suffers.

Any idea ?
And are my assumption valid ?
(for those who have already designed this kind of circuitry)

yg
-- 
http://ygdes.com / http://yasep.org

On Jun 10, 2:01=A0pm, whygee <why...@yg.yg> wrote:
> Hello,
>
> I've been busy lately, trying to understand how to interface asynchronous=
 SRAMs
> (like IDT 71V016, CY7C10xx or other 16-bit wide and fast parts in TSOP-II=
)
>
> I have found some descriptions of multicycle methods, using FSMs, but thi=
s does
> not fit my target because my circuits already run at "nominal speed" (8 t=
o 15ns
> cycles, depending on the SRAM chip). So I attempt to find how SRAM reads =
and
> writes can be done in one cycle, with a FPGA that can't (or shouldn't) go=
 faster.
> (Yes I use Actel's ProASIC and I'm fine).
>
> I have found (through the examination of timing diagrams in several datas=
heets)
> that I can design a stateless async SRAM interface with this behaviour :
>
> Read :
> =A0 on clock's rising edge :
> =A0 =A0 =A0latch the address bus's value,
> =A0 =A0 =A0Output Enable =3D 1, WriteEnable =3D 1,
> =A0 =A0 =A0and keep data bus floating
> =A0 after 1/3 of clock cycle :
> =A0 =A0 =A0Output Enable =3D 0
> =A0 on next clock rising edge :
> =A0 =A0 =A0latch the data bus input.
>
> Write :
> =A0 =A0on clock rising edge :
> =A0 =A0 =A0latch addres bus, OE=3D1, WriteEnable=3D1,
> =A0 =A0 =A0keep data bus floating
> =A0 =A0after 1/3 of clock cycle :
> =A0 =A0 =A0 WriteEnable =3D 0
> =A0 =A0after 1/2 clock cycle (falling edge)
> =A0 =A0 =A0 latch data output and drive the output buffer
>
> It's fine for me because it can be done by
> correctly wiring latches to the proper control/data/clock signals
> and it should work. Now comes the big question :
>
> How would I generate the 1/3 clock cycle signal ?
>
> * I don't want to use a 3x clock because the design already
> fast and even though the PLL can output 350MHz, I'm not sure
> that the logic and routing will follow (so making a 3-state FSM
> is eventually possible but not realistic, too uncertain).
> A dual-edged FSM with 1,5x clock would be another improbable chimera...
>
> * I have seen that the PLL can generate a 5ns (max) delayed clock
> based on the main clock, so it's fine for 15ns-rated SRAMs
> (I could set the delay to 2,6ns for 8ns parts)
> but what happens if 20ns or slower SRAMs are to be used ?
> (I have 70ns chips for example, but I don't want to make
> a FSM just for a few slow parts)
> Also, I would like to keep/reserve PLL outputs for other purposes.
>
> * In all the datasheets I have found, it is implicitly
> necessary to have this 1/3 delay :
> =A0 =A0- if shorter, there is a driver conflict on the data bus
> =A0 =A0 =A0 if the precendent cycle was a read
> =A0 =A0 =A0 =A0(data remain present up to about 1/3 of the next clock cyc=
le)
> =A0 =A0- if longer, the data setup time is not respected and reliability =
suffers.
>
> Any idea ?
> And are my assumption valid ?
> (for those who have already designed this kind of circuitry)
>
> yg
> --http://ygdes.com/http://yasep.org

if you as ram is specified as 15ns type
then do not hope it attaches to soc system with 15ns cycle time

Antti

On Jun 10, 1:29=A0pm, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Jun 10, 2:01=A0pm, whygee <why...@yg.yg> wrote:
>
>
>
>
>
> > Hello,
>
> > I've been busy lately, trying to understand how to interface asynchrono=
us SRAMs
> > (like IDT 71V016, CY7C10xx or other 16-bit wide and fast parts in TSOP-=
II)
>
> > I have found some descriptions of multicycle methods, using FSMs, but t=
his does
> > not fit my target because my circuits already run at "nominal speed" (8=
 to 15ns
> > cycles, depending on the SRAM chip). So I attempt to find how SRAM read=
s and
> > writes can be done in one cycle, with a FPGA that can't (or shouldn't) =
go faster.
> > (Yes I use Actel's ProASIC and I'm fine).
>
> > I have found (through the examination of timing diagrams in several dat=
asheets)
> > that I can design a stateless async SRAM interface with this behaviour =
:
>
> > Read :
> > =A0 on clock's rising edge :
> > =A0 =A0 =A0latch the address bus's value,
> > =A0 =A0 =A0Output Enable =3D 1, WriteEnable =3D 1,
> > =A0 =A0 =A0and keep data bus floating
> > =A0 after 1/3 of clock cycle :
> > =A0 =A0 =A0Output Enable =3D 0
> > =A0 on next clock rising edge :
> > =A0 =A0 =A0latch the data bus input.
>
> > Write :
> > =A0 =A0on clock rising edge :
> > =A0 =A0 =A0latch addres bus, OE=3D1, WriteEnable=3D1,
> > =A0 =A0 =A0keep data bus floating
> > =A0 =A0after 1/3 of clock cycle :
> > =A0 =A0 =A0 WriteEnable =3D 0
> > =A0 =A0after 1/2 clock cycle (falling edge)
> > =A0 =A0 =A0 latch data output and drive the output buffer
>
> > It's fine for me because it can be done by
> > correctly wiring latches to the proper control/data/clock signals
> > and it should work. Now comes the big question :
>
> > How would I generate the 1/3 clock cycle signal ?
>
> > * I don't want to use a 3x clock because the design already
> > fast and even though the PLL can output 350MHz, I'm not sure
> > that the logic and routing will follow (so making a 3-state FSM
> > is eventually possible but not realistic, too uncertain).
> > A dual-edged FSM with 1,5x clock would be another improbable chimera...
>
> > * I have seen that the PLL can generate a 5ns (max) delayed clock
> > based on the main clock, so it's fine for 15ns-rated SRAMs
> > (I could set the delay to 2,6ns for 8ns parts)
> > but what happens if 20ns or slower SRAMs are to be used ?
> > (I have 70ns chips for example, but I don't want to make
> > a FSM just for a few slow parts)
> > Also, I would like to keep/reserve PLL outputs for other purposes.
>
> > * In all the datasheets I have found, it is implicitly
> > necessary to have this 1/3 delay :
> > =A0 =A0- if shorter, there is a driver conflict on the data bus
> > =A0 =A0 =A0 if the precendent cycle was a read
> > =A0 =A0 =A0 =A0(data remain present up to about 1/3 of the next clock c=
ycle)
> > =A0 =A0- if longer, the data setup time is not respected and reliabilit=
y suffers.
>
> > Any idea ?
> > And are my assumption valid ?
> > (for those who have already designed this kind of circuitry)
>
> > yg
> > --http://ygdes.com/http://yasep.org
>
> if you as ram is specified as 15ns type
> then do not hope it attaches to soc system with 15ns cycle time
>
> Antti- Hide quoted text -
>
> - Show quoted text -

Paying attention to the r/w line and that it can be raised at the end
of a cycle not just after 70% of the cycle, and realizing this is the
main issue for meeting the cycle time constraints. Keeping /OE low for
read and write (as r/w overides the output buffer, check the specs).
Raising r/w early is no problem as data the same, lowering it early
maybe is what you need? The drive shorting rail to rail would be a
power loss issue so maybe delay the data output of the processor
slighly... the rising edge will be countered by the addressing delay.

The timing may be very possible if you do interleave every write with
a read, but as I said the timing will be tight.

Antti.Lukats@googlemail.com wrote:
> if you as ram is specified as 15ns type
> then do not hope it attaches to soc system with 15ns cycle time
of course, the pin and trace capacitance as
well as the setup&hold of the other pins must be taken into account.

anyway, the available access times are close enough to the cycle times
of the pipelines so I modified my design to make it completely "synchronous".
It is less troublesome...

> Antti
yg
-- 
http://ygdes.com / http://yasep.org

On Jun 10, 4:01=A0am, whygee <why...@yg.yg> wrote:
> Hello,
>
> I've been busy lately, trying to understand how to interface asynchronous=
 SRAMs
> (like IDT 71V016, CY7C10xx or other 16-bit wide and fast parts in TSOP-II=
)
>
> I have found some descriptions of multicycle methods, using FSMs, but thi=
s does
> not fit my target because my circuits already run at "nominal speed" (8 t=
o 15ns
> cycles, depending on the SRAM chip). So I attempt to find how SRAM reads =
and
> writes can be done in one cycle, with a FPGA that can't (or shouldn't) go=
 faster.
> (Yes I use Actel's ProASIC and I'm fine).
>
> I have found (through the examination of timing diagrams in several datas=
heets)
> that I can design a stateless async SRAM interface with this behaviour :
>
> Read :
> =A0 on clock's rising edge :
> =A0 =A0 =A0latch the address bus's value,
> =A0 =A0 =A0Output Enable =3D 1, WriteEnable =3D 1,
> =A0 =A0 =A0and keep data bus floating
> =A0 after 1/3 of clock cycle :
> =A0 =A0 =A0Output Enable =3D 0
> =A0 on next clock rising edge :
> =A0 =A0 =A0latch the data bus input.
>
> Write :
> =A0 =A0on clock rising edge :
> =A0 =A0 =A0latch addres bus, OE=3D1, WriteEnable=3D1,
> =A0 =A0 =A0keep data bus floating
> =A0 =A0after 1/3 of clock cycle :
> =A0 =A0 =A0 WriteEnable =3D 0
> =A0 =A0after 1/2 clock cycle (falling edge)
> =A0 =A0 =A0 latch data output and drive the output buffer
>
> It's fine for me because it can be done by
> correctly wiring latches to the proper control/data/clock signals
> and it should work. Now comes the big question :
>
> How would I generate the 1/3 clock cycle signal ?
>
> * I don't want to use a 3x clock because the design already
> fast and even though the PLL can output 350MHz, I'm not sure
> that the logic and routing will follow (so making a 3-state FSM
> is eventually possible but not realistic, too uncertain).
> A dual-edged FSM with 1,5x clock would be another improbable chimera...
>
> * I have seen that the PLL can generate a 5ns (max) delayed clock
> based on the main clock, so it's fine for 15ns-rated SRAMs
> (I could set the delay to 2,6ns for 8ns parts)
> but what happens if 20ns or slower SRAMs are to be used ?
> (I have 70ns chips for example, but I don't want to make
> a FSM just for a few slow parts)
> Also, I would like to keep/reserve PLL outputs for other purposes.
>
> * In all the datasheets I have found, it is implicitly
> necessary to have this 1/3 delay :
> =A0 =A0- if shorter, there is a driver conflict on the data bus
> =A0 =A0 =A0 if the precendent cycle was a read
> =A0 =A0 =A0 =A0(data remain present up to about 1/3 of the next clock cyc=
le)
> =A0 =A0- if longer, the data setup time is not respected and reliability =
suffers.
>
> Any idea ?
> And are my assumption valid ?
> (for those who have already designed this kind of circuitry)
>
> yg
> --http://ygdes.com/http://yasep.org

Is there any way you can have "bursty" accesses, ie, a bunch of reads
in a row?  In
that case, there is no chance of bus contention once the burst
starts.  All you need
to do is change the address and a bit later you can latch the new
data.

Writes are trickier since you will need to set/clr the sram enable
signal, but again
if you can group writes together, you can avoid data bus contention.

John Providenza

Antti wrote :
>> if you as ram is specified as 15ns type
>> then do not hope it attaches to soc system with 15ns cycle time
>> Antti

Now I remember that this is possible,
but only when consecutive reads are performed.
Beware of the propagation delays, but it's
not impossible to get cyle time =3D access time.
However, when writes are done, this does not hold
anymore. Ok, I stop here :-)

My only "real world example" for the study is the
"FoxVHDL" (superseeded by the "Colibri") board
of ACME Systems ( http://colibri.acmesystems.it/ )
It has two 12ns SRAMs with a 64MHz clock,
so there is 3,625ns of margin.
I've been unable to understand how/why the
memory interface of the VGA framebuffer works, though.

Now that I look at this number (I thought that
it was only 3ns, rather than almost 4), it appears
that the memory cycle could be split into 4 even
sub-cycles, requiring only a local 2x clock increase.
I like this idea :-)
With 8ns parts, that would enable 90MHz (roughly)
pipeline frequencies (with good layout and decoupling and...).
And with 15ns parts, that makes a nice, round 50MHz frequency.
This fits well with my stock of 25MHz oscillators and 15ns SRAMs.

Does it sound right to others ?

Jacko wrote:
> Paying attention to the r/w line and that it can be raised at the end
> of a cycle not just after 70% of the cycle, and realizing this is the
> main issue for meeting the cycle time constraints.
I realized it yesterday, right, but my working hypothesis
was to lower it at 30% and raising at 100%,
so the data bus has less chance (or duration) of contention.
SRAMs seem to take more time than I expected
to release the data bus. And when writing to the SRAM,
the data setup is long (70% of the access time) and the hold time
is often 0, this privileges the "late WE/ raise" rather than your version=
=2E
What do you think ?

> Keeping /OE low for
> read and write (as r/w overides the output buffer, check the specs).
I've seen that too, even though it is not often clearly mentioned.
It surprised me... But I stick to the safe side and only lower /OE
when needed to avoid contentions.

> Raising r/w early is no problem as data the same, lowering it early
> maybe is what you need?
maybe but I didn't want to play too much with the specs

> The drive shorting rail to rail would be a
> power loss issue so maybe delay the data output of the processor
> slighly...
"power matters" (to paraphrase one FPGA vendor ;-P)
currently, I'm just trying to apply what I know for years (at last),
but that I couldn't test before. Later, I'll probably have
power constraints and I don't want to redesign and retest
memory controllers. So I take contention seriously.

> the rising edge will be countered by the addressing delay.
can you elaborate ?

> The timing may be very possible if you do interleave every write with
> a read, but as I said the timing will be tight.
I can't count on such systematic interleave.
This access pattern is rare, and not often found in CPUs
or graphic framebuffers, for example.

It sounds that if I add 33% of margin to the SRAM access time,
things fall in place and I can just use a PLL to generate
a 2x frequency, or a 90=B0 out of phase control signal.
When the input clock changes, the phase will not change,
contrary with a fixed delay approach.
I'll recheck all the timings and datasheets...

--=20
http://ygdes.com / http://yasep.org

Hi,

john wrote:
> Is there any way you can have "bursty" accesses, ie, a bunch of reads in a row?
In the present case, well, no :-/
It's for microcontroller applications,
one FPGA, one SRAM chip and some electronic interfaces
(that kind of thing, then each system is customised
for a specific target).
The usage pattern would be an average of 2 or 3 reads
(may be more, may be less) and 1 write.

For higher performance, I can use synchronous SRAMs
that have 4-word bursts, from 66MHz to 250MHz...
but it takes more room, it is a bit harder to route
and consumes more power...
SSRAM looks more adapted (and in fact, it is indeed designed)
as L2 cache, where reads and writes are bursted.
I'll see this later.

> In that case, there is no chance of bus contention once the burst starts.  All you need
> to do is change the address and a bit later you can latch the new data.
> Writes are trickier since you will need to set/clr the sram enable signal, but again
> if you can group writes together, you can avoid data bus contention.
right but then, how does one manage the bus turnaround ?
it looks like a cycle or sub-cycle must be inserted,
which affects the rest of the system.

> John Providenza
yg

-- 
http://ygdes.com / http://yasep.org

On Jun 10, 2:01=A0pm, whygee <why...@yg.yg> wrote:
> Hello,
>
> I've been busy lately, trying to understand how to interface asynchronous=
 SRAMs
> (like IDT 71V016, CY7C10xx or other 16-bit wide and fast parts in TSOP-II=
)
>
> I have found some descriptions of multicycle methods, using FSMs, but thi=
s does
> not fit my target because my circuits already run at "nominal speed" (8 t=
o 15ns
> cycles, depending on the SRAM chip). So I attempt to find how SRAM reads =
and
> writes can be done in one cycle, with a FPGA that can't (or shouldn't) go=
 faster.
> (Yes I use Actel's ProASIC and I'm fine).
>
> I have found (through the examination of timing diagrams in several datas=
heets)
> that I can design a stateless async SRAM interface with this behaviour :
>
> Read :
> =A0 on clock's rising edge :
> =A0 =A0 =A0latch the address bus's value,
> =A0 =A0 =A0Output Enable =3D 1, WriteEnable =3D 1,
> =A0 =A0 =A0and keep data bus floating
> =A0 after 1/3 of clock cycle :
> =A0 =A0 =A0Output Enable =3D 0
> =A0 on next clock rising edge :
> =A0 =A0 =A0latch the data bus input.
>
> Write :
> =A0 =A0on clock rising edge :
> =A0 =A0 =A0latch addres bus, OE=3D1, WriteEnable=3D1,
> =A0 =A0 =A0keep data bus floating
> =A0 =A0after 1/3 of clock cycle :
> =A0 =A0 =A0 WriteEnable =3D 0
> =A0 =A0after 1/2 clock cycle (falling edge)
> =A0 =A0 =A0 latch data output and drive the output buffer
>
> It's fine for me because it can be done by
> correctly wiring latches to the proper control/data/clock signals
> and it should work. Now comes the big question :
>
> How would I generate the 1/3 clock cycle signal ?
>
> * I don't want to use a 3x clock because the design already
> fast and even though the PLL can output 350MHz, I'm not sure
> that the logic and routing will follow (so making a 3-state FSM
> is eventually possible but not realistic, too uncertain).
> A dual-edged FSM with 1,5x clock would be another improbable chimera...
>
> * I have seen that the PLL can generate a 5ns (max) delayed clock
> based on the main clock, so it's fine for 15ns-rated SRAMs
> (I could set the delay to 2,6ns for 8ns parts)
> but what happens if 20ns or slower SRAMs are to be used ?
> (I have 70ns chips for example, but I don't want to make
> a FSM just for a few slow parts)
> Also, I would like to keep/reserve PLL outputs for other purposes.
>
> * In all the datasheets I have found, it is implicitly
> necessary to have this 1/3 delay :
> =A0 =A0- if shorter, there is a driver conflict on the data bus
> =A0 =A0 =A0 if the precendent cycle was a read
> =A0 =A0 =A0 =A0(data remain present up to about 1/3 of the next clock cyc=
le)
> =A0 =A0- if longer, the data setup time is not respected and reliability =
suffers.
>
> Any idea ?
> And are my assumption valid ?
> (for those who have already designed this kind of circuitry)
>
> yg
> --http://ygdes.com/http://yasep.org

if you want todo something right, then add APB wrapper to your core
then you can integrate it into Actel Smartesign abd use CoreAPBSRAM

it maybe will not be the best in terms of performance but you (or
better
users of the yasep) will be able to use all the IP cores from the
actel
core offering as they all attach to APB bus

Antti

On Jun 13, 9:41=A0am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Jun 10, 2:01=A0pm, whygee <why...@yg.yg> wrote:
>
>
>
> > Hello,
>
> > I've been busy lately, trying to understand how to interface asynchrono=
us SRAMs
> > (like IDT 71V016, CY7C10xx or other 16-bit wide and fast parts in TSOP-=
II)
>
> > I have found some descriptions of multicycle methods, using FSMs, but t=
his does
> > not fit my target because my circuits already run at "nominal speed" (8=
 to 15ns
> > cycles, depending on the SRAM chip). So I attempt to find how SRAM read=
s and
> > writes can be done in one cycle, with a FPGA that can't (or shouldn't) =
go faster.
> > (Yes I use Actel's ProASIC and I'm fine).
>
> > I have found (through the examination of timing diagrams in several dat=
asheets)
> > that I can design a stateless async SRAM interface with this behaviour =
:
>
> > Read :
> > =A0 on clock's rising edge :
> > =A0 =A0 =A0latch the address bus's value,
> > =A0 =A0 =A0Output Enable =3D 1, WriteEnable =3D 1,
> > =A0 =A0 =A0and keep data bus floating
> > =A0 after 1/3 of clock cycle :
> > =A0 =A0 =A0Output Enable =3D 0
> > =A0 on next clock rising edge :
> > =A0 =A0 =A0latch the data bus input.
>
> > Write :
> > =A0 =A0on clock rising edge :
> > =A0 =A0 =A0latch addres bus, OE=3D1, WriteEnable=3D1,
> > =A0 =A0 =A0keep data bus floating
> > =A0 =A0after 1/3 of clock cycle :
> > =A0 =A0 =A0 WriteEnable =3D 0
> > =A0 =A0after 1/2 clock cycle (falling edge)
> > =A0 =A0 =A0 latch data output and drive the output buffer
>
> > It's fine for me because it can be done by
> > correctly wiring latches to the proper control/data/clock signals
> > and it should work. Now comes the big question :
>
> > How would I generate the 1/3 clock cycle signal ?
>
> > * I don't want to use a 3x clock because the design already
> > fast and even though the PLL can output 350MHz, I'm not sure
> > that the logic and routing will follow (so making a 3-state FSM
> > is eventually possible but not realistic, too uncertain).
> > A dual-edged FSM with 1,5x clock would be another improbable chimera...
>
> > * I have seen that the PLL can generate a 5ns (max) delayed clock
> > based on the main clock, so it's fine for 15ns-rated SRAMs
> > (I could set the delay to 2,6ns for 8ns parts)
> > but what happens if 20ns or slower SRAMs are to be used ?
> > (I have 70ns chips for example, but I don't want to make
> > a FSM just for a few slow parts)
> > Also, I would like to keep/reserve PLL outputs for other purposes.
>
> > * In all the datasheets I have found, it is implicitly
> > necessary to have this 1/3 delay :
> > =A0 =A0- if shorter, there is a driver conflict on the data bus
> > =A0 =A0 =A0 if the precendent cycle was a read
> > =A0 =A0 =A0 =A0(data remain present up to about 1/3 of the next clock c=
ycle)
> > =A0 =A0- if longer, the data setup time is not respected and reliabilit=
y suffers.
>
> > Any idea ?
> > And are my assumption valid ?
> > (for those who have already designed this kind of circuitry)
>
> > yg
> > --http://ygdes.com/http://yasep.org
>
> if you want todo something right, then add APB wrapper to your core
> then you can integrate it into Actel Smartesign abd use CoreAPBSRAM
>
> it maybe will not be the best in terms of performance but you (or
> better
> users of the yasep) will be able to use all the IP cores from the
> actel
> core offering as they all attach to APB bus
>
> Antti

eh taket that all back, i wrote before morning coffee

the APBSRAM core only uses internal rams, external
SRAM is supported by AHB controller only :(

Antti

Antti.Lukats@googlemail.com wrote:
> On Jun 13, 9:41 am, "Antti.Luk...@googlemail.com" wrote:
>> if you want todo something right, then add APB wrapper to your core
>> then you can integrate it into Actel Smartesign abd use CoreAPBSRAM
>> it maybe will not be the best in terms of performance but you (or
>> better users of the yasep) will be able to use all the IP cores from the
>> actel core offering as they all attach to APB bus
>>
>> Antti
> 
> eh taket that all back, i wrote before morning coffee
heh :-)
me... neeed... chocolate....

> the APBSRAM core only uses internal rams, external
> SRAM is supported by AHB controller only :(

In fact I never looked at the APB or AHB.
I remember some basics of the VCI, but in a microcontroller
where the core's timing is tied to the SRAM's,
performance also matters... At 64MHz, it's going to
give about 16 MIPS, add a "generic memory interface"
and it could drop to 10 or 5 MIPS : where's the point
of using 15ns SRAMs ? Yes, I know, I'm a speed freak :-/

anyway, thanks for mentioning the AxB things,

> Antti
yg

-- 
http://ygdes.com / http://yasep.org