fpga design problems....???

hi sir..im doing a project in elliptic curve cryptography using vhdl in xilinx ise and modelsim....my program is correctly simulated in modelsim..but when i try to simulate using virtex or xilinx...error msg comes as

"Too many bonded comps of type "IOB" found to fit this device.
ERROR:Map:115 - The design is too large to fit the device. "

what should i do nw???..i use totally 1215 pins in my program but nt any device is found to suit this...???

1215? As far as I know, Xilinx has no devices with that kind of pin count. And if it had - it would be golden price-wise. You definitely have to redesign your interface.

but sir...ecc deals with 160,190,256 bits...when i put up in vhdl the count increases...

It doesn't matter how much bits you process. It's a matter of how you receive and transmit them. You can transmit 8 bits in one cycle over 8 pins; or in 2 cycles over 4 pins; or in 8 cycles over 1 pin. All modern interfaces are serial, and for a good reason.

sir..im nt using any actual interface nw...i hv written a program in vhdl for dual field multiplier tht should be used in ecc using cary save adder...i need to sysnthesis using xilinx ise tool..upto map n routing stage(implementation n generate programming file) in software only.....these r the first few lines..

library ieee;
use ieee.std_logic_1164.all;

entity nilu_dual_mult is
port(abo,ab1,ab2,ab3,ab4,ab5,ab6,ab7,ab8,ab9,ab10,ab11,ab12,
ab13,ab14,ab15,ab16,ab17,ab18,ab19,ab20,ab21,ab22,ab23,
ab24,ab25,ab26,ab27,ab28,ab29,ab30,ab31:in bit_vector(32 downto 1);
primeout1,primeout2: out bit_vector(64 downto 1);
binaryoutut bit_vector(63 downto 1));
end nilu_dual_mult;
architecture nilu_dual_mult_arch of nilu_dual_mult is

component nilu_CSA
generic(ip1MAX,ip2MAx,ip3MAx:integer:=32;opMAX:integer:=34);
port(ip1:in bit_vector(ip1Max downto 1);
ip2:in bit_vector(ip2Max downto 1);
ip3:in bit_vector(ip3Max downto 1);
op1,op2ut bit_vector(opMax downto 1));
end component;
signal t1,t2,t3,t4,t5,t6,t7,t8,t9,t10,t11,t12,t13,t14,t15,t16,t17,t18,t19,t20:bit_vector(34 downto 1);
signal t21,t22,t23,t24,t25,t26,t27,t28,t29,t30,t31,t32,t35,t36,t37,t38,t41,t42:bit_vector(40 downto 1);
signal t33,t34:bit_vector(36 downto 1);
signal t39,t40,t45,t46,t51,t52:bit_vector(58 downto 1);
signal t43,t44:bit_vector(49 downto 1);
signal t49,t50:bit_vector(45 downto 1);
signal t47,t48,t53,t54,t55,t56,t57,t58,t59,t60:bit_vector(63 downto 1);

signal t61,t62:bit_vector(64 downto 1);

signal zero:bit_vector(40 downto 1):=(others=>'0');


but mapping stage gets failed...why???

I understand you. Map fails because the selected FPGA doesn't have enogh resources (I/O pins). You can't get past translation stage before you fix this. You could try creating a wrapper around your module, that would use less pins.

thk u sir..n hw to create wrapper...??

Just my humble opinion (I'm not an FPGA designer): having parallel interface of such width is not a good design practice, IMHO. It will potentially lead to problems with routing, placing and achieving desired timings.

---------- Post added at 16:39 ---------- Previous post was at 16:37 ----------

As for the wrapper: I usually use RAM from/to which I load/store relatively short words (like 8 or 16 bits) . But to do that you need to design your module so that it can take input data in small portions over several cycles.

sir thks for ur opinion...but i hv exactly followed d architecture n datapath given in d ieee paper

A Highly Efficient Cipher Processor for Dual-Field
Elliptic Curve Cryptography by
Jyu-Yuan Lai, Student Member, IEEE, and Chih-Tsun Huang, Senior Member, IEEE

they hv achieved it in cmos n virtex 2 pro...but hw..???

---------- Post added at 20:26 ---------- Previous post was at 20:15 ----------

thk u for ur valuable time n suggestions...sir..

In Altera Quartus there is an alternative to a wrapper.
You can define "virtual pins", and then you can have more pins than the physical device.
This only solves the compilation problem. You still need a wrapper if you want to download the design into a device.

With virtual pins you can compile a sub-block as a Quartus top-level entity, even if it has "too many" pins. This is good for large designs when you don't want to compile the whole design every time.

I don't know if Xilinx has the same possibility.

std_match said:

In Altera Quartus there is an alternative to a wrapper.
You can define "virtual pins", and then you can have more pins than the physical device.

I don't know if Xilinx has the same possibility.

Click to expand...

Never heard of it, probably it doesn't.

thks std_match sir...forgot to try in quartus....ll surely try n c..

nilusharief003 said:

i hv exactly followed d architecture n datapath given in d ieee paper

A Highly Efficient Cipher Processor for Dual-Field
Elliptic Curve Cryptography

Click to expand...

OK, probably there's something I don't undestand. But sure as hell they did use some kind of top-level interface in their project.

oh i c...anyways thks again..wish to somehw ***** it..

In addition to the problem of reducing the number of interface bits, I notice, that the design has neither a clock nor any control signals. This means, that the design has to perform the ECC algorithm fully parallel which seems effectively impossible. So I guess, it won't be synthesizable.

You can however try VHDL simulator, e.g. Modelsim.

in modelsim its working perfectly sir..
ll try by inseting clk n control signals..

Looks like there's nothing else I can advise for now. Good luck with your project!

std_match said:

In Altera Quartus there is an alternative to a wrapper.
You can define "virtual pins", and then you can have more pins than the physical device.
This only solves the compilation problem. You still need a wrapper if you want to download the design into a device.

With virtual pins you can compile a sub-block as a Quartus top-level entity, even if it has "too many" pins. This is good for large designs when you don't want to compile the whole design every time.

I don't know if Xilinx has the same possibility.

Click to expand...

sir can u explain in detail hw to assign virtual pins for 1024 pins tht i use...???

You use Tcl commands like this:

set_instance_assignment -name VIRTUAL_PIN ON -to my_pin

Read more in page 15-11 in volume 2 of the Quartus II Handbook:

https://www.altera.com/literature/hb/qts/qts_qii5v2.pdf

Here are a few lines from the chapter:

"Virtual Pins

Usually, when you compile a design in the Quartus II software, all I/O ports are mapped directly to pins on the targeted device. However, you may not want to map all I/O ports to the device pins; use the Virtual Pin assignment then.
A virtual pin is an I/O element that you do not intend to connect to the chip pins. You create a virtual pin by assigning the Virtual Pin logic option to an I/O element. When you compile a design with some I/O elements assigned as virtual pins, those I/O elements become mapped to a logic element and not to a pin during compilation, and are then implemented as a LUT. You might use virtual pin assignments when you compile a partial design, because not all the I/Os from a partial design may drive chip pins at the top level."

std_match said:

You use Tcl commands like this:

set_instance_assignment -name VIRTUAL_PIN ON -to my_pin

Read more in page 15-11 in volume 2 of the Quartus II Handbook:

https://www.altera.com/literature/hb/qts/qts_qii5v2.pdf

Here are a few lines from the chapter:

"Virtual Pins

Usually, when you compile a design in the Quartus II software, all I/O ports are mapped directly to pins on the targeted device. However, you may not want to map all I/O ports to the device pins; use the Virtual Pin assignment then.
A virtual pin is an I/O element that you do not intend to connect to the chip pins. You create a virtual pin by assigning the Virtual Pin logic option to an I/O element. When you compile a design with some I/O elements assigned as virtual pins, those I/O elements become mapped to a logic element and not to a pin during compilation, and are then implemented as a LUT. You might use virtual pin assignments when you compile a partial design, because not all the I/Os from a partial design may drive chip pins at the top level."

Click to expand...

thk u sir for ur promt reply......