Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

AS configuration and IO pin reuse

I have (hopefully) one last question - this time regarding the EPCS programming device. I know that it can be programmed in-circuit via JTAG using SFL. I also know that the ASDO and nCE lines can be reused (which I have). The ASDO is also used to drive an LED, and the nCE line is used to bring in a button input. Theoretically, the odds of the LED and the button conspiring to produce anything approaching valid to the EPCS should be nil, but you never know.

I would assume that after configuration, DCLK stops - so inputs from the board shouldn't affect the configuration PROM. Is that correct? If not, is there a safe way to reuse the AS pins after configuration? (IOW, without risk of corrupting the configuration data) Also, does the EPCS do any kind of sanity checking on incoming data to prevent spurious corruption?

Also, regarding in-system programming via JTAG, can I assume that if I follow both the AS and JTAG example circuits in the handbook that SFL will work? I would really like to drop the AS connector on the board - but I don't want to drop it if I end up having problems with JTAG programming of the EPCS PROM.

Thanks,

-Seth

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Regarding AS pins reuse, I think the only safe way is to keep one of the three input pins to the AS memory in an inactive state. Otherwise you can't exclude inadvertent corruption of the image. Also, the connected load must not bring on signal integrity issues for the AS communication.

    Apart from this, indirect AS programming through works fine.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    --- Quote Start ---

    Regarding AS pins reuse, I think the only safe way is to keep one of the three input pins to the AS memory in an inactive state. Otherwise you can't exclude inadvertent corruption of the image. Also, the connected load must not bring on signal integrity issues for the AS communication.

    Apart from this, indirect AS programming through works fine.

    --- Quote End ---

    If I understand the handbook correctly, when using DCLK; the FPGA only issues enough clocks to configure itself, and then disables the clock, correct? If so, then should resolve the issue of corruption. No clock = no writes or reads.

    The user button could potentially cause errors - if it was pressed during indirect programming of the AS part. However, it seems like a simple enough solution - don't do that! That said, it may be a moot issue.

    I just noticed the requirement on QFP parts regarding quiet pins around DCLK. Fortunately, one of the pins is DATA0, which I hadn't reused. Unfortunately, the other pin I had used as a low-side driver for an LED. It's not a critical component, so I can lose it. However, I may delete the user button, which could potentially cause glitches in programming, with the LED, instead. I can always implement a button on the user I/O port.

    I wouldn't think an LED would alter the ASDO signal enough to corrupt data to the EPCS, would it? I would be sinking current through the LED - so it would light when the signal is driven low. I would think it would act a bit like a pull-up from the perspective of the EPCS. The caveat is that the LED is on the other side of the board. (about 2.5" away)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Yes, keeping DCLK inactive prevents inadvertent modifications to the AS memory, I think.

    The pin placement rules related to AS pins should only apply, if the AS interface is used for AS programming in user mode, which isn't the case in your application. Possibly Quartus doesn't consider this different usage of AS pins, if so, you can dare to disable the checks by assigning a toggle rate 0 to the signals regarded as conflicting, if the AS programming is performed by the default SFL image rather than a SFL instance in your code.

    I don't want to decide about your plans with ASDO in detail. I assume, there's a way, to make the load compatible.