cyclone 3 and odd pin behavior

[Altera_Forum]

Using EP3C40F324I7N andEPCS16 in 'jic' setup. 'appears' only one pin, outputting a clock, D7, when programmed by the EPCS16, outputs a 'high' instead of a clock. (as apposed to low for un-assigned pins). but when I load 'sof' file directly, pin outputs the expected clock. Programming the EPCS16 appears to go fine, including verify. any ideas :confused:

[Altera_Forum]

How are your MSEL pins strapped? Are they configured for AS (Active Serial) configuration? You won't get a clock out of the FPGA's DCLK pin (to drive the EPCS) unless they are configured correctly. 

 In that device pin D7 is a general purpose I/O pin. You're not expecting it to be DCLK, are you?  Regards, Alex

[Altera_Forum]

--- Quote Start ---  How are your MSEL pins strapped? Are they configured for AS (Active Serial) configuration? You won't get a clock out of the FPGA's DCLK pin (to drive the EPCS) unless they are configured correctly.  In that device pin D7 is a general purpose I/O pin. You're not expecting it to be DCLK, are you?  Regards, Alex  --- Quote End ---    Left out, the rest of the chip appears to work. getting expected results from other outputs.

[Altera_Forum]

Then I must question whether the .sof you are using to generate the .jic is the same file as you are using when programming directly. 

 Assuming it is - are you happy that you are testing the device in the same way when programming in each way? Is there logic in the device to gate the clock under certain conditions? Is it being gated when programmed from EPCS and not when programmed directly - i.e. is this happening by design?  Regards, Alex

[Altera_Forum]

--- Quote Start ---  Then I must question whether the .sof you are using to generate the .jic is the same file as you are using when programming directly.  Assuming it is - are you happy that you are testing the device in the same way when programming in each way? Is there logic in the device to gate the clock under certain conditions? Is it being gated when programmed from EPCS and not when programmed directly - i.e. is this happening by design?  Regards, Alex  --- Quote End ---    there are a couple of dual port rams in the fpga. the outside logic that feeds data to the fpga and into the ram, uses this clock. so, for this side of the fpga, i don't know if fpga's logic is working. On the other side, there is a processor interface and other statemachines/counters doing varies things; This all appears to be working. there is an init file that loads '0xFF' into the rams and all data comming out of the rams is '0xFF'. there was logic for gating the clock, (shut off if external reset active), but that was removed. The clock in, that is driving the statemachines/counters that are working, is now connected directly to this output pin.  I have a ticket in asking if the 'cof' file is setup correctly, but no reply for a week now. this is not my first 'jic' project, (at least 10 Cyclone(1234s)), but is first using the EPSC16.  Since a can't get an answer, i'm going to try, first changing the offending pin to reserve input or drill out the via feeding that pin and then patch in a clock from another source.

[Altera_Forum]

so i tried changing the pin to reserve input. It still shows high output, but haven't test it to see if it is actually 'pulled' high, but, if i load 'sof' file, it drops to zero.

[Altera_Forum]

You've confused me now....:confused: 

  --- Quote Start ---  drill out the via feeding that pin and then patch in a clock from another source  --- Quote End ---   I thought we were discussing an FPGA pin (D7) configured as an output?  Configuring a pin as an input (providing there is no other load/drive on the net it's attached to) may well result in it going high thanks to internal pull-ups. In the FPGA's non-configured state it may well also appear high for the same reason.  If it drops to zero when you configure it with a .sof image, then either a) you've specified in your design for it to drive low; or b) you've not assigned a function to that pin but told Quartus to reserve all unused pins: 'As output driving ground', as specified in the project's Device and Pin Options.  Is this all moving away from your original issue?  Regards, Alex

[Altera_Forum]

"... but haven't test(ed) it..."  

 but then, when booting from ecps16, the pin is 'high' and when load directly with 'sof' file, it goes 'low'. still wrong....