From: alann@accom.com (Alan Nishioka) Newsgroups: comp.arch.fpga Subject: Re: Size of configuration bitstream for xcv50 (xilinx) Date: 18 Oct 2002 09:42:09 -0700 Organization: http://groups.google.com/ Lines: 31 Message-ID: References: <2a1195bc.0210171814.1ad98bc6@posting.google.com> NNTP-Posting-Host: 209.1.249.229 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1034959329 9442 127.0.0.1 (18 Oct 2002 16:42:09 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 18 Oct 2002 16:42:09 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22217 1. The .bit file has a header. http://www.fpga-faq.com/FAQ_Pages/0026_Tell_me_about_bit_files.htm 2. The .bit file data is a series of frames that is interpreted by the FPGA. Depending on contents of the FPGA, the exact number of frames can vary. 3. The .bit file compresses like binary data (about 50%). For example, I have several .bit files concatenated together for 7530508 bytes. Using gzip -9, this compresses to 4072712 bytes. Alan Nishioka alann@accom.com meghnaag7@hotmail.com (Meg) wrote in message news:<2a1195bc.0210171814.1ad98bc6@posting.google.com>... > hi > i am new to FPGAs. i want to run compression algorithms on virtex > xcv50 configuration file. i have consulted the xilinx app. notes as > well as other few websites. The xilinx website says the configuration > bits needed are 559,200bits (= 69,900 bytes) but at > fpgaconfigurator.com, it is mentioned tht 559,232 bits are needed. The > bit file generated by Xilinx tools has the size 69,967 bytes which is > 67 bytes more than specified by xilinx. I am really confused about > what's going on ?? > > moeover from what i understand, xcv50 needs 15,876 32-bit words for > CLBs, 780*2 for ram and 39 words for issuing commands. The sum of all > these is less than the number of configuration bits required > (559,232), So, how exactly is this figure calculated ?? > > Meghna ###### From: ldoolitt@recycle.lbl.gov (Larry Doolittle) Newsgroups: comp.arch.fpga Subject: Re: Size of configuration bitstream for xcv50 (xilinx) Date: Fri, 18 Oct 2002 16:53:04 +0000 (UTC) Organization: LBNL News Server Lines: 12 Message-ID: References: <2a1195bc.0210171814.1ad98bc6@posting.google.com> NNTP-Posting-Host: recycle.lbl.gov X-Trace: overload.lbl.gov 1034959984 13398 131.243.169.124 (18 Oct 2002 16:53:04 GMT) X-Complaints-To: "newsmaster@lbl.gov" NNTP-Posting-Date: Fri, 18 Oct 2002 16:53:04 +0000 (UTC) X-Newsreader: slrn (0.9.4.3 UNIX) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!news.lbl.gov!ldoolitt Xref: chonsp.franklin.ch comp.arch.fpga:22220 On 18 Oct 2002 09:42:09 -0700, Alan Nishioka wrote: > >3. The .bit file compresses like binary data (about 50%). For example, I > have several .bit files concatenated together for 7530508 bytes. Using > gzip -9, this compresses to 4072712 bytes. That very much depends on how much of the chip's logic is in use. Unused bits are set to zero, which compress really well. ;-) I find the gzip-compressed file size and the slice utilization track pretty closely. - Larry ###### Reply-To: "Steve Casselman" From: "Steve Casselman" Newsgroups: comp.arch.fpga References: <2a1195bc.0210171814.1ad98bc6@posting.google.com> Subject: Re: Size of configuration bitstream for xcv50 (xilinx) Lines: 12 Organization: Virtual Computer Corporation X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: NNTP-Posting-Host: 64.164.175.85 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr21.news.prodigy.com 1034977440 ST000 64.164.175.85 (Fri, 18 Oct 2002 17:44:00 EDT) NNTP-Posting-Date: Fri, 18 Oct 2002 17:44:00 EDT X-UserInfo1: OXYYR\OGQJT_SVH]^JKBOW@@YJ_ZTB\MV@BL\QMIWIWTEPIB_NVUAH_[BL[\IRKIANGGJBFNJF_DOLSCENSY^U@FRFUEXR@KFXYDBPWBCDQJA@X_DCBHXR[C@\EOKCJLED_SZ@RMWYXYWE_P@\\GOIW^@SYFFSWHFIXMADO@^[ADPRPETLBJ]RDGENSKQQZN Date: Fri, 18 Oct 2002 21:44:00 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!news-out.cwix.com!newsfeed.cwix.com!prodigy.com!prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr21.news.prodigy.com.POSTED!2ac7f5fa!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22224 > Unused bits are set to zero, which compress really well. ;-) This is not ture. If you go into the fpga editor and create a blank part you will see lots of ones and zeros. What is ture is that the if a lot of the chip is not used there is a repeating pattern that is the same for each unused tile and so a low utillization design gives better compression results. For example if you just have one input and one output and one wire inbetween in a V1000 it compress about 100x.. Steve ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Size of configuration bitstream for xcv50 (xilinx) Date: 19 Oct 2002 16:13:42 +0200 Organization: My own Private Self Lines: 53 Message-ID: <6uk7ke34a1.fsf@chonsp.franklin.ch> References: <2a1195bc.0210171814.1ad98bc6@posting.google.com> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 1035036822 642 10.0.3.2 (19 Oct 2002 14:13:42 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 19 Oct 2002 14:13:42 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:22226 "Steve Casselman" writes: > > Unused bits are set to zero, which compress really well. ;-) > > This is not ture. If you go into the fpga editor and create a blank part you > will see lots of ones and zeros. neil@chonsp 16:09:11 ~> vd -er 0/0 null300.bit Col: 0, Row: 0 CLB: 0 1 2 3 4 frame 012345678901234567890123456789012345678901234567 addr .------------------------------------------------ 0|110111110001100011111011110111110001100011111011 1|100001000101011010000001100000010110111000100001 2|111111111111111110000000000000011111111111111111 3|111111111111111100100000000001001111111111111111 4|000000000100001000000000000000000010100000000000 5|000000000000000000000000000000000000000000000000 6|000000000000000000000000000000000000000000000000 7|000000000000000000000000000000000000000000000000 8|000000000000000000000000000000000000000000000000 9|000000000000000000000000000000000000000000000000 10|000000000000000000000000000000000000000000000000 11|000000000000000000000000000000000000000000000000 12|000000000000000000000000000000000000000000000000 13|000000000000000000000000000000000000000000000000 14|111111111111111111111111111111111111111111111111 15|100011100011100011100011100011100011100011100011 16|111111111111111111111111111111111111111111111111 17|111111111111111111111111111111111111111111111111 bit addr > What is ture is that the if a lot of the > chip is not used there is a repeating pattern that is the same for each > unused tile and so a low utillization design gives better compression > results. For example if you just have one input and one output and one wire > inbetween in a V1000 it compress about 100x.. Empty XCV300: -r--r--r-- 1 neil franklin 219047 Sep 27 2001 null300.bit -r--r--r-- 1 neil franklin 3794 Sep 27 2001 null300.bit.gz About 1/4 full XCV300: -rw-r--r-- 1 neil franklin 219047 Oct 16 00:34 pdp10.bit -rw-r--r-- 1 neil franklin 21241 Oct 16 00:34 pdp10.bit.gz -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - hardware runs the world, software controls the hardware code generates the software, have you coded today? ###### Reply-To: "Steve Casselman" From: "Steve Casselman" Newsgroups: comp.arch.fpga References: <2a1195bc.0210171814.1ad98bc6@posting.google.com> <6uk7ke34a1.fsf@chonsp.franklin.ch> Subject: Re: Size of configuration bitstream for xcv50 (xilinx) Lines: 69 Organization: Virtual Computer Corporation X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: NNTP-Posting-Host: 64.168.191.102 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr21.news.prodigy.com 1035185952 ST000 64.168.191.102 (Mon, 21 Oct 2002 03:39:12 EDT) NNTP-Posting-Date: Mon, 21 Oct 2002 03:39:12 EDT X-UserInfo1: [[PGG_SEPRR[RRP[OBCD^VX@WB]^PCPDLXUNNH\KMAVNDQUBLNTC@AWZWDXZXQ[K\FFSKCVM@F_N_DOBWVWG__LG@VVOIPLIGX\\BU_B@\P\PFX\B[APHTWAHDCKJF^NHD[YJAZMCY_CWG[SX\Y]^KC\HSZRWSWKGAY_PC[BQ[BXAS\F\\@DMTLFZFUE@\VL Date: Mon, 21 Oct 2002 07:39:12 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.stueberl.de!cox.net!rip!news.webusenet.com!prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr21.news.prodigy.com.POSTED!2ac7f5fa!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22249 There are 8 frames in the beginning that only have the main clock buffers and the DLLs in the frames the middle portion is 0's. Most of the frames in the V1 devices have lots of ones and zeros. If you look at a bit file in a binary editor you'll see this. I just ran my software for the V2 and those devices do have 0's for a blank configuration. Also they have all the configuration bits for a look up table in the same frame. Steve "Neil Franklin" wrote in message news:6uk7ke34a1.fsf@chonsp.franklin.ch... > "Steve Casselman" writes: > > > > Unused bits are set to zero, which compress really well. ;-) > > > > This is not ture. If you go into the fpga editor and create a blank part you > > will see lots of ones and zeros. > > neil@chonsp 16:09:11 ~> vd -er 0/0 null300.bit > Col: 0, Row: 0 CLB: > 0 1 2 3 4 frame > 012345678901234567890123456789012345678901234567 addr > .------------------------------------------------ > 0|110111110001100011111011110111110001100011111011 > 1|100001000101011010000001100000010110111000100001 > 2|111111111111111110000000000000011111111111111111 > 3|111111111111111100100000000001001111111111111111 > 4|000000000100001000000000000000000010100000000000 > 5|000000000000000000000000000000000000000000000000 > 6|000000000000000000000000000000000000000000000000 > 7|000000000000000000000000000000000000000000000000 > 8|000000000000000000000000000000000000000000000000 > 9|000000000000000000000000000000000000000000000000 > 10|000000000000000000000000000000000000000000000000 > 11|000000000000000000000000000000000000000000000000 > 12|000000000000000000000000000000000000000000000000 > 13|000000000000000000000000000000000000000000000000 > 14|111111111111111111111111111111111111111111111111 > 15|100011100011100011100011100011100011100011100011 > 16|111111111111111111111111111111111111111111111111 > 17|111111111111111111111111111111111111111111111111 > bit addr > > > > What is ture is that the if a lot of the > > chip is not used there is a repeating pattern that is the same for each > > unused tile and so a low utillization design gives better compression > > results. For example if you just have one input and one output and one wire > > inbetween in a V1000 it compress about 100x.. > > Empty XCV300: > -r--r--r-- 1 neil franklin 219047 Sep 27 2001 null300.bit > -r--r--r-- 1 neil franklin 3794 Sep 27 2001 null300.bit.gz > > About 1/4 full XCV300: > -rw-r--r-- 1 neil franklin 219047 Oct 16 00:34 pdp10.bit > -rw-r--r-- 1 neil franklin 21241 Oct 16 00:34 pdp10.bit.gz > > > -- > Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ > Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer > - hardware runs the world, software controls the hardware > code generates the software, have you coded today? ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Size of configuration bitstream for xcv50 (xilinx) Date: 21 Oct 2002 22:05:18 +0200 Organization: My own Private Self Lines: 79 Message-ID: <6uvg3vwoap.fsf@chonsp.franklin.ch> References: <2a1195bc.0210171814.1ad98bc6@posting.google.com> <6uk7ke34a1.fsf@chonsp.franklin.ch> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 1035230718 1656 10.0.3.2 (21 Oct 2002 20:05:18 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 21 Oct 2002 20:05:18 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:22284 "Steve Casselman" writes: > There are 8 frames in the beginning that only have the main clock buffers > and the DLLs in the frames the middle portion is 0's. Those 8 frames are only GCLKs in the "top" and "bottom" rows (same positions as the north/south IOBs are relative to CLBs), no DLLs. The DLLs are in the same "top" and "bottom" sections of the BRAM control frames (27 per BRAM column). That is why there are 4 DLLs, 2 each per BRAM column. The "top" and "bottom of the 2*64 BRAM data frames seem to be empty, dito those of the 2*54 west/east IOB frames. Also the "middle" (same position as CLBs) of the GCLK frames has some stuff in the 8th frame: 1st to 7th frame (on XCV300, null300.bit) are all like this (slight variation): 00 0000220 12 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000320 00 00 00 00 00 00 00 00 00 40 04 80 00 00 00 00 0000340 00 00 00 but the 8th frame has "middle" stuff: ff 12 00 0a 00 0001340 02 80 00 a0 00 28 00 0a 00 02 80 00 a0 00 28 00 0001360 0a 00 02 80 00 a0 00 28 00 0a 00 02 80 00 a0 00 0001400 28 00 0a 00 02 80 00 a0 00 28 00 0a 00 02 80 00 0001420 a0 00 28 00 0a 00 02 80 00 a0 00 28 00 0a 00 02 0001440 80 00 a0 00 28 3f c4 00 00 00 00 00 00 00 00 only then comes the first CLB frame: c0 0001460 07 fc 00 ff 00 3f c0 0f f0 03 fc 00 ff 00 3f c0 0001500 0f f0 03 fc 00 ff 00 3f c0 0f f0 03 fc 00 ff 00 0001520 3f c0 0f f0 03 fc 00 ff 00 3f c0 0f f0 03 fc 00 0001540 ff 00 3f c0 0f f0 03 fc 00 ff 00 3f c0 0f f0 03 0001560 fc 00 ff 00 3f c0 0f f0 03 f0 00 f0 00 00 00 00 0001600 00 00 00 > the V1 devices have lots of ones and zeros. Yes. and in an funny "banded" pattern. > If you look at a bit file in a > binary editor you'll see this. I use "od". That is what the above are cut&paste from. Sorry, "vd" does not yet list non CLB stuff, so no nice formatted output from it here. That is in the next milestone of its development. > I just ran my software for the V2 and those > devices do have 0's for a blank configuration. Interesting. So LUTs are not stored inverted? Or do they default them to output-ones in the null files? > Also they have all the > configuration bits for a look up table in the same frame. Vertical LUTs? Sensible. Was one of the weaknesses in V1, slow on read-out. Hmmm. I knew they have an 80(vert)x22(hor) format. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - hardware runs the world, software controls the hardware code generates the software, have you coded today?