SRAM on Cyclone Devices

Target Device: CYCLONE

My project allocates some RAM and initializes
it by an Intel Hex File. The Simulator correctly
shows the initialized data.

<CODE>

  lpm_ram_dq   ram
   (
      .address   (_addr),
      .q         (_dout),
      .data      (_di),
      .we        (_we),
      .inclock   (clk),
      .outclock  (!clk)
   );

   defparam ram.lpm_width   = 8;
   defparam ram.lpm_widthad = 11;
   defparam ram.lpm_file    = "-----.hex";
   defparam ram.lpm_indata  = "REGISTERED";
   defparam ram.lpm_outdata = "REGISTERED";

   defparam ram.lpm_address_control
     = "REGISTERED";

   defparam ram.lpm_hint    =
     "ENABLE_RUNTIME_MOD=YES, INSTANCE_NAME=AAAA";

</CODE>

I'm not sure the synthesizer/programmer initialize
the sram on the real device. I thought

1) i could check it out by using Quartus II
"In-System Memory Content Editor".

I also thought

2) that by inspecting the ram content i can check
whether my design is working as required.

But if i enable the ISMC Editor (the last defparam),
the compiler gives the following error:

"Insufficient resources available on RAM to use
In-System Memory Content Editor"

I guess that for "Device Family" reasons the compiler
ends up using altsyncram:

lpm_ram_dq:ram
__altram:sram
____altsyncram:ram_block

The error message doesn't say which are the
missing resources. I guess the ram needs to be
a dual port one. I use one port and the Editor
uses the other. If i disable ENABLE_RUNTIME_MOD
i get a single port. I thought the other port is left
unused, but now i'm not sure the chain:

lpm_ram_dq->altram->altsyncram

sets up for a dual port usage at all.

Even though i declare a single port, i thought
the synth adds the second one as soon as it
realizes the Runtime Mod is enabled. Altsyncram
has Dual Port, after all.

Or is the issue about something else?

"devices" <me@home> wrote in message
news:46e14f98$0$4784$4fafbaef@reader4.news.tin.it...
> Target Device: CYCLONE
>
> My project allocates some RAM and initializes
> it by an Intel Hex File. The Simulator correctly
> shows the initialized data.
>
> <CODE>
>
>   lpm_ram_dq   ram
>    (
>       .address   (_addr),
>       .q         (_dout),
>       .data      (_di),
>       .we        (_we),
>       .inclock   (clk),
>       .outclock  (!clk)
>    );
>
>    defparam ram.lpm_width   = 8;
>    defparam ram.lpm_widthad = 11;
>    defparam ram.lpm_file    = "-----.hex";
>    defparam ram.lpm_indata  = "REGISTERED";
>    defparam ram.lpm_outdata = "REGISTERED";
>
>    defparam ram.lpm_address_control
>      = "REGISTERED";
>
>    defparam ram.lpm_hint    =
>      "ENABLE_RUNTIME_MOD=YES, INSTANCE_NAME=AAAA";
>
> </CODE>
>
> I'm not sure the synthesizer/programmer initialize
> the sram on the real device. I thought
>
> 1) i could check it out by using Quartus II
> "In-System Memory Content Editor".
>
> I also thought
>
> 2) that by inspecting the ram content i can check
> whether my design is working as required.
>
> But if i enable the ISMC Editor (the last defparam),
> the compiler gives the following error:
>
> "Insufficient resources available on RAM to use
> In-System Memory Content Editor"
>
> I guess that for "Device Family" reasons the compiler
> ends up using altsyncram:
>
> lpm_ram_dq:ram
> __altram:sram
> ____altsyncram:ram_block
>
> The error message doesn't say which are the
> missing resources. I guess the ram needs to be
> a dual port one. I use one port and the Editor
> uses the other. If i disable ENABLE_RUNTIME_MOD
> i get a single port. I thought the other port is left
> unused, but now i'm not sure the chain:
>
> lpm_ram_dq->altram->altsyncram
>
> sets up for a dual port usage at all.
>
> Even though i declare a single port, i thought
> the synth adds the second one as soon as it
> realizes the Runtime Mod is enabled. Altsyncram
> has Dual Port, after all.
>
> Or is the issue about something else?
>
>

It was something else. I fixed the issue last night
and i've just tested the ram. Several lines above
the error there was another red line saying that
no clock was available. I gave up the "outclock"
and tied it to vcc, unregistering the output
(fortunately this posed no issue to the design).
The compiler was happy and started dancing
to the rhythm of the clock. I can clearly see
that the .hex file is correctly preloaded.