Intel® FPGA University Program
University Program Material, Education Boards, and Laboratory Exercises
1174 Discussions

Size of the my digital system into the EPCS16

Altera_Forum
Honored Contributor II
1,068 Views

I am using a DE2 board with a 16 Mbits in its serial config device. How do I know if my design fits into the serial configuration device? I found that RPD file is always of a same size no matter how many modules I remove, so i guess it is not related to the size of the design.

0 Kudos
9 Replies
Altera_Forum
Honored Contributor II
357 Views

Yes, it's the case when not enabling configuration bitstream compression in device options. EP2C35 configuration always fits an EPCS16, see manual. However, compression can reduce programming time and free memory space for other purposes.

0 Kudos
Altera_Forum
Honored Contributor II
357 Views

Thanks for the reply. But how do I figure out if my design fits in an EPCS16? For example, is it possible that a design never fits into the EPCS16?

0 Kudos
Altera_Forum
Honored Contributor II
357 Views

See table 13–3. cyclone ii raw binary file (.rbf) sizes in Cyclone II device manual.

0 Kudos
Altera_Forum
Honored Contributor II
357 Views

The size of the uncompressed configuration data is fixed for a given FPGA. So a 2C35 will always require the exact same number of configurations bits and it can be found in the documentation as a previous poster pointed out.  

 

However, compression can be enabled on the bitstream and will compress the data by 35-55%. This compressed file size can vary by design. You can use 0.65 * (rbf size) as an upper limit to the size of the compressed file. 

 

Uncompression is performed by the FPGA on the fly as it receives the compressed bitstream so this can reduce the config time in addition to saving space in the EPCS device.
0 Kudos
Altera_Forum
Honored Contributor II
357 Views

So, for an uncompressed configuration data, is there any correlation btwn the no of LEs used in my design and the actual footprint of my design on the configuration data? (I.e, if the compilation summary says I am using 10% of LEs, is it that only 10% of the configuration data is my actual design?) 

 

Thanks for the replies, I am gaining better understanding of the FPGA.
0 Kudos
Altera_Forum
Honored Contributor II
357 Views

 

--- Quote Start ---  

So, for an uncompressed configuration data, is there any correlation btwn the no of LEs used in my design and the actual footprint of my design on the configuration data? 

--- Quote End ---  

You have reported yourself, that the size of uncompressed configuration data is constant, so what else you're asking for? The size of compressed configuration data depends on the LE utilization, but there's no exact relation.
0 Kudos
Altera_Forum
Honored Contributor II
357 Views

 

--- Quote Start ---  

The size of compressed configuration data depends on the LE utilization, but there's no exact relation 

--- Quote End ---  

Thanks. That is what I wanted to confirm.
0 Kudos
Altera_Forum
Honored Contributor II
357 Views

 

--- Quote Start ---  

So, for an uncompressed configuration data, is there any correlation btwn the no of LEs used in my design and the actual footprint of my design on the configuration data? (I.e, if the compilation summary says I am using 10% of LEs, is it that only 10% of the configuration data is my actual design?) 

--- Quote End ---  

 

 

I don't think this is what you're asking, but just want to make sure it's clear: For uncompressed config data, there is no correlation between# of LEs and the size of the config data. It is always fixed and would be the same whether using 10% of LEs or 98% of LEs.  

 

I think what you are asking is if 10% of the config data describes your 10% utilized design and the other 90% does not. I suppose this may be roughly true, but I wouldn't think of it that way. If your design makes use of 10% of the LEs, then the config data MUST tell those LEs how to configure themselves. However, the config data MUST ALSO tell the other 90% LEs how to configure themselves as well. Same goes for I/O. For example, unused I/O need to be told if they should tri-state themselves or if they should become ground pins. 

 

Hope that helps.
0 Kudos
Altera_Forum
Honored Contributor II
357 Views

Got it! Thanks.

0 Kudos
Reply