--- 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.
Honored Contributor
