CYCLONE II FPGA configuration verification

[bedsah]

I am designing a board that I will use cyclone II EP2C35 FPGA. The configuration is as shown in the photo. what I want to do is to program both FPGA and epcsq16 with jtag.

Is there something wrong with my schematic?
as far as I learned, MSEL PINS SHOULD NOT GO TO GND TO PROGRAM EPCSQ with jtag. IS THIS TRUE?

[ak6dn]

Looks ok to me, very similar to a board I have that uses the EP2C20 device with an EPCS4 config device.

It uses normal (slower) AS active serial mode, so both MSEL1 and MSEL0 are wired to GND.

JTAG wiring is connected to the FPGA only; programming the config device EPCS4 is done thru JTAG using the SFL module instantiated in the code as shown below.

When the board is first powered on with a blank config device and an unconfigured FPGA, only the FPGA is in the JTAG chain.
I then load a .sof ram image into the FPGA that has the SFL module in it, and rescan the JTAG chain.
This will then allow the config EPCS4 to now appear in the JTAG chain (so two devices are present, the FPGA and the EPCS4).

At this point I can then program the EPCS4 with a .jic file that has the FPGA program image.

Here is the .cdf (chain descriptor file) I use to do the programming with the Altera Programmer:

JedecChain;
	FileRevision(JESD32A);
	DefaultMfr(6E);

	P ActionCode(Cfg)
		Device PartName(EP2C20F484)
                   Path("") File("PDP8.sof")
                   MfrSpec(OpMask(1) SEC_Device(EPCS4)
                   Child_OpMask(1 3) SFLPath("PDP8.jic"));

ChainEnd;

AlteraBegin;
	ChainType(JTAG);
AlteraEnd;

Altera SFL serial flash loader instantiated in FPGA top level verilog module:

    // Altera Serial Flash Loader module

    // Allows external JTAG access to the serial config eeprom for programming

    sfl	sfl
	( .asdo_in		(1'b0),		// not used
	  .dclk_in		(1'b0),		// not used
	  .ncso_in		(1'b0),		// not used
	  .noe_in		(1'b0),		// always enabled
	  .asmi_access_granted	(1'b1),		// external JTAG access always
	  .asmi_access_request	(),		// not used
	  .data0_out		()		// not used
	  );

Also you do know you have to use Quartus 13.0sp1 or 13.1 for development (still downloadable) as those are the last versions that support the CycloneII series.

Which begs the question why are you designing a NEW board with the CycloneII series? It is basically EOL and obsolete at this point.

[bedsah]

Hi

Thank you very much for your reply. The most important reason for designing a new card with the Cyclone II series is the cost. Since it is our undergraduate graduation project, we have to choose the one that is suitable in terms of cost. Cyclone II is the only cheap option that I can use for my design in the country I live in.

Apart from Intel EPCS/EPCQ, is there a different configuration device you can recommend that is compatible with Cyclone II?

[ak6dn · Accepted solution]

Ok, understood, this is not a product per se intended for volume production, but rather a one off project.

Re: the configuration device, there are a number of devices compatible with the EPCS series. Read this thread:

https://community.intel.com/t5/Programmable-Devices/EPCS-Discontinuation-looking-for-replacement/td-p/250468

[Fakhrul]

Hi bedsah,

I hope ak6dn's reply above has addressed your question. I wish to follow up with you about this case. Do you have any updates? 

Otherwise, this thread will be idling and marked as inactive, thus it will be transitioned to community support because there is no update received from you in a while.

Regards,

Fakhrul

[Fakhrul]

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.