Generally speaking the way FPGAs are designed if your data were stored in a RAM style memory and the processing done with a simple micro controller the only increase in processor size you should see should be your addressing width and related signals/modules (IE cache).
Controllers are generally designed to scale nicely with increasing memory spaces, after all, your intel processor might use 4, 8 or 16 GB of memory with the same architecture, so they are related but only as follows: To individually access 1500 elements requires log2(1500) =11 bits of addressing, 100 lines (7 bits). That said, the number of required bits less than doubles so this does not account for the described “explosion” so the problem likely lies in how the data was stored (IE non RAM like parrallel access / coding accident) - so on to methodology.
Two general ideas:
1) That FPGA are a generalist jack of all trades and not optimal in storing large data (the way DRAM is at least).
2) That coding RTL for FPGA is not like writing software for processors. You write RTL to utilize the FPGA features and shape those into the patterns you require (if possible), unfortunately what often happens is that if you write RTL that does not nicely map to the functionality of the FPGA nicely so the software will "help" you and find a way to do what you asked, or try and fail, and then often fail to communicate the nature of the result in a humanly comprehensible fashion. The software is always interpreting what you actually want, so you need to always be checking that those guesses were accurate (reading tool logs and reports).
It is very helpful if you can draw or conceptualize somehow your design in gates or preferably luts and flip flops. If you can do that you can probably get a rough idea how many resources you might expect it to use. If you can visualize the hardware and understand how your language (Verilog or VHDL) defines that hardware then you are more likely to write code that the tools will interpret correctly (But go through the resource reports like a hawk anyway). Obviously Rome was not built in a day and this takes practice.
So in line with the philosophy of "utilizing the hardware that exists" consider how your 1500 lines are stored in the FPGA. If they are stored as bits in 1500*(data width) flip flops you are going to burn through your resources.
the efficent memories in FPGAs have a rigid structure and this means that your controller might have a 1500 word memory space but that should only be accessible 1 address (sometimes 2 addresses) in a memory at a time because that is one of the ways you can efficiently implement it. When you constrain the problem this way the FPGA can, often with tool help (IE ip catalog, others), impliment an efficient memory (example BRAM). For larger data sets people generally use actual memories that are outside the FPGA on their board when necessary and practical.
This may not be the access pattern you desire but it is what generally scales for many cases. If you are for example trying to design a different access style for you data, example a CAM (content accessable memory) doing so on any platform is very expensive in terms of luts and gates relativly speaking.