Problems with ALTASMI_PARALLEL megafunction

Altera_Forum · ‎11-02-2011

Hi,

I'm trying to use ALTASMI_PARALLEL in a Cyclone design with an EPCS1. The problem is that all the code which drives this megafunction, and the megafunction itself, gets optimised away during compilation.

I am doing something slightly unusual in that I am only storing one byte in the EPCS1; the code in the Cyclone then reads this byte when it comes out of reset and uses it to initialise a signal. 0xFF = '1', anything else = '0'. The addr[] and datain[] ports are therefore hard-coded to 0x018000 and 0x00 respectively; my code asserts the read, write and sector_erase inputs to read, clear and set the flag respectively.

Is it possible to use the ALTASMI_PARALLEL function in this way, or is it the stuck values at datain[] and addr[] causing the code to be optimised away?

I have never used this megafunction before so not sure of its limitations.

Using QuartusII Web Edition V9.1. The VHDL port mapping for the megafunction is:


    asmi : asmi_altasmi_parallel_6h12 port map(
        addr          => x"018000",
        busy          => asmi_busy,
        clkin         => asmi_clkin,
        data_valid    => asmi_data_valid,
        datain        => x"00",
        dataout       => asmi_dataout,
        illegal_erase => open,
        illegal_write => open,
        rden          => '0',
        read          => asmi_read,
        sector_erase  => asmi_sector_erase,
        wren          => '1',
        write         => asmi_write
        );

TIA

R.

Altera_Forum · ‎11-02-2011

Found it!

If I change the mapping rden => '0' to rden => '1' the registers are all preserved. The documentation is a bit confusing, the online help in the MegaWizard Plugin Manager says that rden should be held high to continue reading sequential addresses, but app note AN379 figure 2 implies that the read operation will terminate immediately if rden is driven low.

It's nearly working, doesn't meet timing at the moment when driven with the main 32MHz clock used elsewhere in the design. It looks like I need to divide this clock in half and use it as asmi_clk_in, then re-sync all the signals coming to / from the ASMI function.

Altera_Forum · ‎10-04-2016

I have a similar problem, but I don't read at all. I only use the component to write to the configuration memory.

I have tried to set rden=1 (which feels strange when you don't want to read), but the component is optimized away anyway.

Is there any specific operation I need to perform to get it to stay in my design?

I tried to forward some of the address lines to a debug pin or use signal tap, in this case the component stays and work, but I don't want this code in my final product.

Thanks / Joakim

Altera_Forum · ‎10-04-2016

--- Quote Start ---

I have a similar problem, but I don't read at all. I only use the component to write to the configuration memory.

I have tried to set rden=1 (which feels strange when you don't want to read), but the component is optimized away anyway.

Is there any specific operation I need to perform to get it to stay in my design?

I tried to forward some of the address lines to a debug pin or use signal tap, in this case the component stays and work, but I don't want this code in my final product.

Thanks / Joakim

--- Quote End ---

If your application code never reads the EEPROM then I'm assuming the data you are writing is new configuration bitstream, for use when the device is reconfigured, i.e. a sort of bootloader?

In that case I would try adding a synthesis keep or preserve attribute to the signals mapped to the ASMI instance.

For a bootloader, especially one to be used by the end customer, I would always read back and verify the EEPROM data anyway.

Regards

Rhydian.

Altera_Forum · ‎10-04-2016

Thanks Rhydian,

The attribute preserve led me to another attribute that seemed to be more suitable, prune.

But I could not get it to work, I ended up connecting one of the address lines to an unused pin.

I still think it's strange that Quartus does not know that altasmi_parallel is connected to some pins internally and should not be optimized away. So if someone have a good answer in the future I would really appreciate if you could put a note in here to let us know.

/ Joakim