Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi all,
I've recently built a prototype board using a xilinx xc3s250e-
ft256. The idcode read back through jtag is not recognized and has a
different manufacturer, i believe it to be corrupt. The code is
0x000c1003. This is very much unlike the 0x0000000000 problems i
usually have. This happens using xilinx impact, digilent export, and a
custom program i wrote to try and debug this. I've looked at all the
signals on my scope and they seem to be in great shape. In my custom
software i have an idcode looping function and the chip returns this
number millions of times with out error. What could this possible be?
Thanks
Article: 121901> I just did some statistical analysis of a bunch of existing Spartan 3 > bit streams. If you treat them as bytes, and histogram the byte codes,= > there's some impressive stats, with code 0x00 of course dominant, then= > 0xFF, and the next 16 most common codes huge, tapering off pretty > hard. That makes sense, since LUT bits are usually zero, so simple > codes like 0x01...0x80 and simple 2-bit combos are most common. Block > ram is usually 0 in our designs, too. So a fixed dictionary should > work pretty well. > > So it looks like a byte stream would do, with byte codes that say > stuff like... > > 00000000 end of file > 001nnnnn make N zero bytes, N=3D1 to 31 > 010nnnnn make N 0xFF bytes, ditto Are you reinventing Huffman coding ? http://en.wikipedia.org/wiki/Huffman_coding If you have a CPU somewhere to do the decompression, check miniLZO. = Decompression is fast and the code is very small ! Plus, it's an open source library that works, and you don't have to cod= e = it. be lazy... http://www.oberhumer.com/opensource/lzo/Article: 121902
In article <ebhi93lfddpm3tr0h6cae41vq665337o82@4ax.com>, jjlarkin@highNOTlandTHIStechnologyPART.com says... > On Sat, 14 Jul 2007 14:17:53 -0400, krw <krw@att.bizzzz> wrote: > > >In article <670i93lg7f1m4jhrcu9l48hjosvoo0jcdv@4ax.com>, > >jjlarkin@highNOTlandTHIStechnologyPART.com says... > > > >> [1] statistical analysis of some FPGA configuration patterns, leading > >> up to a fast, small compression/decompression algorithm. We need to > >> fit an application program and 6 megabits of Xilinx config stuff into > >> a 4 mbit Eprom. > >> > >I think Xilinx has some stuff on their site regarding compressing > >FPGA patters. IIRC, they're quite compressible, easily (RLL or some > >such). > > I'm looking for something that will be fast and easy to decode at fpga > config time. Run-length is pretty simple. The reason this caught my eye was we were looking at doing some invention here. As it turned out there was no inventing to be done because the problem was so simple. > I just did some statistical analysis of a bunch of existing Spartan 3 > bit streams. If you treat them as bytes, and histogram the byte codes, > there's some impressive stats, with code 0x00 of course dominant, then > 0xFF, and the next 16 most common codes huge, tapering off pretty > hard. That makes sense, since LUT bits are usually zero, so simple > codes like 0x01...0x80 and simple 2-bit combos are most common. Block > ram is usually 0 in our designs, too. So a fixed dictionary should > work pretty well. I think you'll find that it's not only a byte of '00s' that's dominant, but *many* bytes. IIRC a '0' turns off a passgate and '1' on. There are *MANY* more off passgates than on. This, and the fact that many cells aren't used at all (even columns), makes run-length work out very nicely. > So it looks like a byte stream would do, with byte codes that say > stuff like... > > > 00000000 end of file > > 001nnnnn make N zero bytes, N=1 to 31 > > 010nnnnn make N 0xFF bytes, ditto > > 011nnnnn the following N bytes are raw, unencoded stuff > > 1nnnnnnn look up code N in dictionary, N = 1 to 127 > > where the dictionary is a list of the most common 96 single bytes > followed by the most common 32 byte pairs. Net compression in this > case is just about 1:1! > > Something like that. > > Now the question is, how much compression will this give? I suppose > I'll have to code it and see. I need less than 2:1 now, and that > shouldn't be hard. That should be a piece of cake. Again, look at the Xilinx app notes. I remember there being more information in there. Watch bad encoding though. Bad things happen to FPGAs with random bits set. -- KeithArticle: 121903
John Larkin wrote: > On Sat, 14 Jul 2007 14:17:53 -0400, krw <krw@att.bizzzz> wrote: > > >>In article <670i93lg7f1m4jhrcu9l48hjosvoo0jcdv@4ax.com>, >>jjlarkin@highNOTlandTHIStechnologyPART.com says... >> >> >>>[1] statistical analysis of some FPGA configuration patterns, leading >>>up to a fast, small compression/decompression algorithm. We need to >>>fit an application program and 6 megabits of Xilinx config stuff into >>>a 4 mbit Eprom. >>> >> >>I think Xilinx has some stuff on their site regarding compressing >>FPGA patters. IIRC, they're quite compressible, easily (RLL or some >>such). > > > I'm looking for something that will be fast and easy to decode at fpga > config time. > > I just did some statistical analysis of a bunch of existing Spartan 3 > bit streams. If you treat them as bytes, and histogram the byte codes, > there's some impressive stats, with code 0x00 of course dominant, then > 0xFF, and the next 16 most common codes huge, tapering off pretty > hard. That makes sense, since LUT bits are usually zero, so simple > codes like 0x01...0x80 and simple 2-bit combos are most common. Block > ram is usually 0 in our designs, too. So a fixed dictionary should > work pretty well. > > So it looks like a byte stream would do, with byte codes that say > stuff like... Depends on what you want to use to unpack this, and what from. Are the cells 8 bit multiples in size ? Run-Length coding can work well, and even an extremely simple form like (eg) a 12 bit RLC field of nnnnVVVVVVVV where nnnn loads a counter (can be non linear - ie mini-table) and repeats the VVVVVVVV pattern until the counter hits zero, then another frame is fetched from the SPI memory. That sort of coding can fit into a CPLD/Serial FLASH combo, which can give fast loading, and usefull compression. Dictionary based compression needs table storage, so is more suited to small uC. Config clock speed is likely to be lower. (if that matters?) -jgArticle: 121904
On Sun, 15 Jul 2007 12:59:02 +1200, Jim Granville <no.spam@designtools.maps.co.nz> wrote: >John Larkin wrote: > >> On Sat, 14 Jul 2007 14:17:53 -0400, krw <krw@att.bizzzz> wrote: >> >> >>>In article <670i93lg7f1m4jhrcu9l48hjosvoo0jcdv@4ax.com>, >>>jjlarkin@highNOTlandTHIStechnologyPART.com says... >>> >>> >>>>[1] statistical analysis of some FPGA configuration patterns, leading >>>>up to a fast, small compression/decompression algorithm. We need to >>>>fit an application program and 6 megabits of Xilinx config stuff into >>>>a 4 mbit Eprom. >>>> >>> >>>I think Xilinx has some stuff on their site regarding compressing >>>FPGA patters. IIRC, they're quite compressible, easily (RLL or some >>>such). >> >> >> I'm looking for something that will be fast and easy to decode at fpga >> config time. >> >> I just did some statistical analysis of a bunch of existing Spartan 3 >> bit streams. If you treat them as bytes, and histogram the byte codes, >> there's some impressive stats, with code 0x00 of course dominant, then >> 0xFF, and the next 16 most common codes huge, tapering off pretty >> hard. That makes sense, since LUT bits are usually zero, so simple >> codes like 0x01...0x80 and simple 2-bit combos are most common. Block >> ram is usually 0 in our designs, too. So a fixed dictionary should >> work pretty well. >> >> So it looks like a byte stream would do, with byte codes that say >> stuff like... > >Depends on what you want to use to unpack this, and what from. An PC will build a rom image from uP hex code (S28 files, from an assembler) and one to as many as 6 FPGA config files (.RBT files, from the Xilinx tools) We burn a rom and it gets plugged into the end-product. At startup time, the uP code runs and early-on it will unsquash the compressed FPGA configs and load the chips, usually by bit-banging a parallel port. This can take several seconds already, so I don't want to slow it down much more. >Are the cells 8 bit multiples in size ? The bit patterns in a Xilinx config file sure look like they are. > >Run-Length coding can work well, and even an extremely simple form >like (eg) a 12 bit RLC field of > >nnnnVVVVVVVV > >where nnnn loads a counter (can be non linear - ie mini-table) >and repeats the VVVVVVVV pattern until the counter hits zero, then >another frame is fetched from the SPI memory. That requires treating the squeezed data as a stream, which is a nuisance to unpack, and has a lot of overhead in the "random" regions of the config data. The data tends to be long runs of 0's and clumps of messy stuff. I'm thinking that a byte-oriented dictionary thing might be able to have roughly zero overhead in the data clusters, and be very efficient in coding the long runs of zeroes and the occasional 0xFFs. But if bytes do tend to repeat, there might be a way to express that and pack a little better. >That sort of coding can fit into a CPLD/Serial FLASH combo, which >can give fast loading, and usefull compression. > >Dictionary based compression needs table storage, so is more suited >to small uC. Config clock speed is likely to be lower. (if that matters?) This is a 68332 uP, and a fixed dictionary wouldn't be bad, just a couple of hundred bytes in rom maybe. My whole application program, tables and all, comes in under 10K bytes! JohnArticle: 121905
John Larkin wrote: > On Sun, 15 Jul 2007 12:59:02 +1200, Jim Granville > <no.spam@designtools.maps.co.nz> wrote: > > >>John Larkin wrote: >> >> >>>On Sat, 14 Jul 2007 14:17:53 -0400, krw <krw@att.bizzzz> wrote: >>> >>> >>> >>>>In article <670i93lg7f1m4jhrcu9l48hjosvoo0jcdv@4ax.com>, >>>>jjlarkin@highNOTlandTHIStechnologyPART.com says... >>>> >>>> >>>> >>>>>[1] statistical analysis of some FPGA configuration patterns, leading >>>>>up to a fast, small compression/decompression algorithm. We need to >>>>>fit an application program and 6 megabits of Xilinx config stuff into >>>>>a 4 mbit Eprom. >>>>> >>>> >>>>I think Xilinx has some stuff on their site regarding compressing >>>>FPGA patters. IIRC, they're quite compressible, easily (RLL or some >>>>such). >>> >>> >>>I'm looking for something that will be fast and easy to decode at fpga >>>config time. >>> >>>I just did some statistical analysis of a bunch of existing Spartan 3 >>>bit streams. If you treat them as bytes, and histogram the byte codes, >>>there's some impressive stats, with code 0x00 of course dominant, then >>>0xFF, and the next 16 most common codes huge, tapering off pretty >>>hard. That makes sense, since LUT bits are usually zero, so simple >>>codes like 0x01...0x80 and simple 2-bit combos are most common. Block >>>ram is usually 0 in our designs, too. So a fixed dictionary should >>>work pretty well. >>> >>>So it looks like a byte stream would do, with byte codes that say >>>stuff like... >> >>Depends on what you want to use to unpack this, and what from. > > > An PC will build a rom image from uP hex code (S28 files, from an > assembler) and one to as many as 6 FPGA config files (.RBT files, from > the Xilinx tools) We burn a rom and it gets plugged into the > end-product. At startup time, the uP code runs and early-on it will > unsquash the compressed FPGA configs and load the chips, usually by > bit-banging a parallel port. This can take several seconds already, so > I don't want to slow it down much more. > > >>Are the cells 8 bit multiples in size ? > > > The bit patterns in a Xilinx config file sure look like they are. > > >>Run-Length coding can work well, and even an extremely simple form >>like (eg) a 12 bit RLC field of >> >>nnnnVVVVVVVV >> >>where nnnn loads a counter (can be non linear - ie mini-table) >>and repeats the VVVVVVVV pattern until the counter hits zero, then >>another frame is fetched from the SPI memory. > > > That requires treating the squeezed data as a stream, which is a > nuisance to unpack, and has a lot of overhead in the "random" regions > of the config data. The data tends to be long runs of 0's and clumps > of messy stuff. I'm thinking that a byte-oriented dictionary thing > might be able to have roughly zero overhead in the data clusters, and > be very efficient in coding the long runs of zeroes and the occasional > 0xFFs. But if bytes do tend to repeat, there might be a way to express > that and pack a little better. > > >>That sort of coding can fit into a CPLD/Serial FLASH combo, which >>can give fast loading, and usefull compression. >> >>Dictionary based compression needs table storage, so is more suited >>to small uC. Config clock speed is likely to be lower. (if that matters?) > > > This is a 68332 uP, and a fixed dictionary wouldn't be bad, just a > couple of hundred bytes in rom maybe. My whole application program, > tables and all, comes in under 10K bytes! If you have a 68332 'going spare' for this, then your approach is prety spot on. You could check the streams to see if repeat-pattern was common enough to encode. - and you could define the count via a dictionary/table as well. [eg 5 bit index into 32 x 16 bit values ] -jgArticle: 121906
On Sun, 15 Jul 2007 16:17:33 +1200, Jim Granville <no.spam@designtools.maps.co.nz> wrote: >> >> This is a 68332 uP, and a fixed dictionary wouldn't be bad, just a >> couple of hundred bytes in rom maybe. My whole application program, >> tables and all, comes in under 10K bytes! > >If you have a 68332 'going spare' for this, then your approach is prety >spot on. You could check the streams to see if repeat-pattern was common >enough to encode. >- and you could define the count via a dictionary/table as well. >[eg 5 bit index into 32 x 16 bit values ] > >-jg > Here's a byte histogram of a typical Spartan 3 config file. Most of the config bits are zero. I read one Xilinx appnote about the rad hardness of sram-based FPGAs, and they got the upset rate calculation down by noting that most config bits actually don't matter! 80,413 NONZERO BYTES ============== SORTED ================= NNN Byte Hex Frequency 0 0 0 181,476 1 255 FF 5,809 2 1 1 5,390 3 128 80 3,991 4 4 4 3,867 5 8 8 3,815 6 16 10 3,785 7 32 20 3,653 8 2 2 3,364 9 48 30 3,282 10 64 40 3,139 11 12 C 1,941 12 3 3 1,587 13 192 C0 1,472 14 36 24 1,038 15 112 70 1,009 16 20 14 936 17 10 A 824 18 144 90 706 19 40 28 699 20 24 18 678 21 9 9 631 22 80 50 626 23 160 A0 602 24 5 5 573 25 96 60 571 26 6 6 558 27 14 E 558 28 56 38 503 29 18 12 498 30 176 B0 487 31 19 13 480 32 60 3C 461 33 28 1C 454 34 129 81 449 35 153 99 449 36 136 88 441 37 13 D 411 38 34 22 408 39 33 21 405 40 195 C3 399 41 68 44 389 42 224 E0 383 43 204 CC 381 44 44 2C 366 45 130 82 358 46 170 AA 354 47 72 48 351 48 7 7 345 49 132 84 345 50 17 11 324 51 52 34 312 52 140 8C 308 53 65 41 299 54 240 F0 294 55 200 C8 290 56 120 78 279 57 66 42 274 58 29 1D 271 59 131 83 267 60 139 8B 242 61 49 31 236 62 30 1E 218 63 254 FE 218 64 157 9D 217 65 58 3A 216 66 45 2D 212 67 196 C4 207 68 138 8A 194 69 199 C7 191 70 51 33 191 71 227 E3 188 72 74 4A 188 73 26 1A 182 74 168 A8 181 75 50 32 180 76 37 25 173 77 122 7A 173 78 152 98 173 79 187 BB 172 80 85 55 166 81 252 FC 164 82 184 B8 161 83 156 9C 152 84 165 A5 146 85 22 16 146 86 193 C1 144 87 238 EE 139 88 42 2A 139 89 148 94 139 90 104 68 137 91 76 4C 135 92 88 58 134 93 137 89 133 94 59 3B 132 95 92 5C 130 96 11 B 129 97 84 54 122 98 102 66 119 99 208 D0 118 100 124 7C 115 101 71 47 114 102 15 F 112 103 250 FA 108 104 35 23 106 105 62 3E 103 106 41 29 101 107 251 FB 98 108 25 19 96 109 188 BC 96 110 21 15 95 111 54 36 93 112 61 3D 92 113 207 CF 91 114 116 74 89 115 55 37 88 116 143 8F 88 117 57 39 86 118 126 7E 85 119 90 5A 83 120 236 EC 83 121 226 E2 80 122 100 64 80 123 211 D3 77 124 146 92 77 125 221 DD 76 126 241 F1 76 127 82 52 75 128 203 CB 72 129 145 91 72 130 243 F3 70 131 194 C2 69 132 81 51 66 133 142 8E 66 134 46 2E 63 135 180 B4 63 136 67 43 61 137 239 EF 60 138 27 1B 60 139 70 46 60 140 253 FD 59 141 97 61 59 142 154 9A 58 143 186 BA 57 144 197 C5 55 145 134 86 55 146 53 35 54 147 108 6C 54 148 69 45 53 149 191 BF 52 150 99 63 52 151 38 26 52 152 158 9E 52 153 98 62 52 154 172 AC 52 155 247 F7 50 156 179 B3 49 157 190 BE 48 158 113 71 47 159 248 F8 47 160 141 8D 46 161 175 AF 45 162 115 73 45 163 201 C9 45 164 225 E1 45 165 78 4E 45 166 114 72 44 167 162 A2 44 168 245 F5 43 169 189 BD 43 170 73 49 43 171 228 E4 43 172 135 87 42 173 133 85 42 174 216 D8 42 175 223 DF 41 176 202 CA 39 177 161 A1 38 178 87 57 37 179 185 B9 37 180 94 5E 36 181 23 17 34 182 31 1F 34 183 147 93 34 184 118 76 34 185 163 A3 33 186 77 4D 32 187 125 7D 32 188 174 AE 32 189 178 B2 32 190 86 56 31 191 106 6A 31 192 149 95 30 193 234 EA 30 194 198 C6 29 195 206 CE 29 196 242 F2 29 197 232 E8 28 198 164 A4 27 199 220 DC 27 200 244 F4 26 201 39 27 25 202 93 5D 24 203 177 B1 24 204 121 79 23 205 150 96 23 206 105 69 22 207 83 53 21 208 89 59 20 209 182 B6 20 210 110 6E 20 211 119 77 18 212 95 5F 18 213 63 3F 18 214 181 B5 17 215 117 75 16 216 212 D4 16 217 219 DB 15 218 101 65 15 219 230 E6 15 220 218 DA 15 221 43 2B 14 222 205 CD 14 223 209 D1 14 224 171 AB 13 225 75 4B 12 226 235 EB 11 227 169 A9 11 228 222 DE 11 229 79 4F 10 230 127 7F 10 231 123 7B 10 232 151 97 8 233 215 D7 8 234 47 2F 8 235 109 6D 8 236 173 AD 8 237 214 D6 8 238 166 A6 8 239 167 A7 7 240 213 D5 7 241 103 67 6 242 217 D9 6 243 233 E9 5 244 246 F6 5 245 111 6F 4 246 229 E5 4 247 210 D2 4 248 155 9B 3 249 91 5B 3 250 249 F9 3 251 231 E7 2 252 183 B7 2 253 159 9F 2 254 237 ED 1 255 107 6B 1Article: 121907
On 2007-07-14, PFC <lists@peufeu.com> wrote: > >>> - do I need to add resistors to the data lines ? >> >> You can always stuff them with 0R if you need to. If your design rules >> allow it, something like a CTS 742C083 series resistor array would be >> easy to fit in the layout. That package is basically 3 0603 resistors >> side by side in one 1206 package. > > I'll check this when I route. Isn't the FPGA drive strength option > suficient ? Maybe for the address lines, but the data lines are bidirectional. If you plan to run the SDRAM at 10MHz, I wouldn't give it a second thought. If you're aiming at >100MHz then you probably want to give yourself the option. I just pulled out an old SODIMM and it has 16 4x 10R arrays (64 lines total). -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 121908
"Patrick Dubois" <prdubois@gmail.com> wrote in message news:1184344666.626506.194870@m3g2000hsh.googlegroups.com... > On Jul 13, 11:36 am, "Symon" <symon_bre...@hotmail.com> wrote: > > Oh, I had misunderstood your problem. Yes the signals names will > revert to the ones in the cdc file... What is kept is things like > colors, buses you created, triggers... But not the names, sorry about > the confusion! I never ran into that problem because I don't change > the names of the signals. Yet one more simply feature that the > Chipscope GUI should have... > Hi Patrick, Thanks for your reply, I'm glad that we see the same behaviour. I thought I was missing out on something! > > If you really need that feature, you could try to modify the csptool > script to create a "custom cdc import" feature. That would be fairly > involved however because csptool can only parse .cpj files, not .cdc > ones. > > > Alternatively, you could try to modify the cdc file to only keep the > new signals, and then import this partial cdc file. If you're lucky it > will work... > > Patrick > Actually, this might not be too bad, the cdc file is pretty obvious, and it would be easy to remove the 'pathname' of the instance with a perl script. Even though it wouldn't keep renamed signals, at least I could reduce the length of the names to something more manageable. If I get around to bashing one out, I'll post it. Thanks again, Syms.Article: 121909
John Larkin wrote: > On Sun, 15 Jul 2007 16:17:33 +1200, Jim Granville > Here's a byte histogram of a typical Spartan 3 config file. Most of > the config bits are zero. I read one Xilinx appnote about the rad > hardness of sram-based FPGAs, and they got the upset rate calculation > down by noting that most config bits actually don't matter! On this one, that's appx 70% zeroes. Could be interesting to see the 'RunCount' values - maybe something like the 2 smallest, 2 highest, and 7 most common run lengths, in 11 more columns ? to help design the best algorithm. I also notice that a Single HI bit, is very common, so even if that does not repeat, a specific compression coverage for those would cover 38.5% of the non zero bytes ? -jg > 80,413 NONZERO BYTES > > > ============== SORTED ================= > > NNN Byte Hex Frequency > > 0 0 0 181,476 > 1 255 FF 5,809 > 2 1 1 5,390 > 3 128 80 3,991 > 4 4 4 3,867 > 5 8 8 3,815 > 6 16 10 3,785 > 7 32 20 3,653 > 8 2 2 3,364 > 9 48 30 3,282 > 10 64 40 3,139 > 11 12 C 1,941 > 12 3 3 1,587 > 13 192 C0 1,472 > 14 36 24 1,038 > 15 112 70 1,009 > 16 20 14 936 > 17 10 A 824 > 18 144 90 706 > 19 40 28 699 > 20 24 18 678 > 21 9 9 631 > 22 80 50 626 > 23 160 A0 602 > 24 5 5 573 > 25 96 60 571 > 26 6 6 558 > 27 14 E 558 > 28 56 38 503 > 29 18 12 498 > 30 176 B0 487 > 31 19 13 480 > 32 60 3C 461 > 33 28 1C 454 > 34 129 81 449 > 35 153 99 449 > 36 136 88 441 > 37 13 D 411 > 38 34 22 408 > 39 33 21 405 > 40 195 C3 399 > 41 68 44 389 > 42 224 E0 383 > 43 204 CC 381 > 44 44 2C 366 > 45 130 82 358 > 46 170 AA 354 > 47 72 48 351 > 48 7 7 345 > 49 132 84 345 > 50 17 11 324 > 51 52 34 312 > 52 140 8C 308 > 53 65 41 299 > 54 240 F0 294 > 55 200 C8 290 > 56 120 78 279 > 57 66 42 274 > 58 29 1D 271 > 59 131 83 267 > 60 139 8B 242 > 61 49 31 236 > 62 30 1E 218 > 63 254 FE 218 > 64 157 9D 217 > 65 58 3A 216 > 66 45 2D 212 > 67 196 C4 207 > 68 138 8A 194 > 69 199 C7 191 > 70 51 33 191 > 71 227 E3 188 > 72 74 4A 188 > 73 26 1A 182 > 74 168 A8 181 > 75 50 32 180 > 76 37 25 173 > 77 122 7A 173 > 78 152 98 173 > 79 187 BB 172 > 80 85 55 166 > 81 252 FC 164 > 82 184 B8 161 > 83 156 9C 152 > 84 165 A5 146 > 85 22 16 146 > 86 193 C1 144 > 87 238 EE 139 > 88 42 2A 139 > 89 148 94 139 > 90 104 68 137 > 91 76 4C 135 > 92 88 58 134 > 93 137 89 133 > 94 59 3B 132 > 95 92 5C 130 > 96 11 B 129 > 97 84 54 122 > 98 102 66 119 > 99 208 D0 118 > 100 124 7C 115 > 101 71 47 114 > 102 15 F 112 > 103 250 FA 108 > 104 35 23 106 > 105 62 3E 103 > 106 41 29 101 > 107 251 FB 98 > 108 25 19 96 > 109 188 BC 96 > 110 21 15 95 > 111 54 36 93 > 112 61 3D 92 > 113 207 CF 91 > 114 116 74 89 > 115 55 37 88 > 116 143 8F 88 > 117 57 39 86 > 118 126 7E 85 > 119 90 5A 83 > 120 236 EC 83 > 121 226 E2 80 > 122 100 64 80 > 123 211 D3 77 > 124 146 92 77 > 125 221 DD 76 > 126 241 F1 76 > 127 82 52 75 > 128 203 CB 72 > 129 145 91 72 > 130 243 F3 70 > 131 194 C2 69 > 132 81 51 66 > 133 142 8E 66 > 134 46 2E 63 > 135 180 B4 63 > 136 67 43 61 > 137 239 EF 60 > 138 27 1B 60 > 139 70 46 60 > 140 253 FD 59 > 141 97 61 59 > 142 154 9A 58 > 143 186 BA 57 > 144 197 C5 55 > 145 134 86 55 > 146 53 35 54 > 147 108 6C 54 > 148 69 45 53 > 149 191 BF 52 > 150 99 63 52 > 151 38 26 52 > 152 158 9E 52 > 153 98 62 52 > 154 172 AC 52 > 155 247 F7 50 > 156 179 B3 49 > 157 190 BE 48 > 158 113 71 47 > 159 248 F8 47 > 160 141 8D 46 > 161 175 AF 45 > 162 115 73 45 > 163 201 C9 45 > 164 225 E1 45 > 165 78 4E 45 > 166 114 72 44 > 167 162 A2 44 > 168 245 F5 43 > 169 189 BD 43 > 170 73 49 43 > 171 228 E4 43 > 172 135 87 42 > 173 133 85 42 > 174 216 D8 42 > 175 223 DF 41 > 176 202 CA 39 > 177 161 A1 38 > 178 87 57 37 > 179 185 B9 37 > 180 94 5E 36 > 181 23 17 34 > 182 31 1F 34 > 183 147 93 34 > 184 118 76 34 > 185 163 A3 33 > 186 77 4D 32 > 187 125 7D 32 > 188 174 AE 32 > 189 178 B2 32 > 190 86 56 31 > 191 106 6A 31 > 192 149 95 30 > 193 234 EA 30 > 194 198 C6 29 > 195 206 CE 29 > 196 242 F2 29 > 197 232 E8 28 > 198 164 A4 27 > 199 220 DC 27 > 200 244 F4 26 > 201 39 27 25 > 202 93 5D 24 > 203 177 B1 24 > 204 121 79 23 > 205 150 96 23 > 206 105 69 22 > 207 83 53 21 > 208 89 59 20 > 209 182 B6 20 > 210 110 6E 20 > 211 119 77 18 > 212 95 5F 18 > 213 63 3F 18 > 214 181 B5 17 > 215 117 75 16 > 216 212 D4 16 > 217 219 DB 15 > 218 101 65 15 > 219 230 E6 15 > 220 218 DA 15 > 221 43 2B 14 > 222 205 CD 14 > 223 209 D1 14 > 224 171 AB 13 > 225 75 4B 12 > 226 235 EB 11 > 227 169 A9 11 > 228 222 DE 11 > 229 79 4F 10 > 230 127 7F 10 > 231 123 7B 10 > 232 151 97 8 > 233 215 D7 8 > 234 47 2F 8 > 235 109 6D 8 > 236 173 AD 8 > 237 214 D6 8 > 238 166 A6 8 > 239 167 A7 7 > 240 213 D5 7 > 241 103 67 6 > 242 217 D9 6 > 243 233 E9 5 > 244 246 F6 5 > 245 111 6F 4 > 246 229 E5 4 > 247 210 D2 4 > 248 155 9B 3 > 249 91 5B 3 > 250 249 F9 3 > 251 231 E7 2 > 252 183 B7 2 > 253 159 9F 2 > 254 237 ED 1 > 255 107 6B 1 >Article: 121910
On Jul 10, 5:40 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > hi...@hit.edu.cn wrote: > > To be specific, my program is related to 3D image reconstruction. The > > input data is float point numbers in the form of 3D array. I represent > > it using symbol: g(x1,y1,z1), while the number of x1,y1,z1 are quite > > large. The output data is another 3D float point array. I represent it > > using symbol: F(x2,y2,z2), similarily the number of x2,y2,z2 are also > > quite large. > > The estimated memory usage is 2GB or so, while the calculations > > required is listed below: > > integer addition 2442 Giga operations per second > > float add 814 Giga operations per second > > float substrac 2424 Giga operations per second > > float muliply 1610 Giga operations per second > > float divide 809 Giga operations per second > > I want these calculations done in one minite, so we can divide the > > operations by 60. > > As a matter of fact, if the calculations could be done in 5 minites, > > it is OK for me. So for minimum requirment, divide the above numbers > > by 300(=60*5). > > As well as I know image reconstruction, you should be able > to do it in fixed point. It is commonly done in floating point > for software implementations, but it still might be better to > use fixed point for a hardware implementation. Also, > for multiply and divide it makes a big difference if it is > multiplied or divided by a constant or variable. > > You might prescale the floating point data in software before > sending it through the FPGA based hardware. I would probably > consider 24 bits intermediate data for a 16 bit result. > > Look for books or papers on systolic array implementations > of matrix operations. > > About how much can you spend on hardware? hundreds, thousands, > or millions of dollars? > > -- glen- Hide quoted text - > > - Show quoted text - Can you recommend some books about this field? The budget should be tens of thousands of dollars.Article: 121911
John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >On Sat, 14 Jul 2007 14:17:53 -0400, krw <krw@att.bizzzz> wrote: > >>In article <670i93lg7f1m4jhrcu9l48hjosvoo0jcdv@4ax.com>, >>jjlarkin@highNOTlandTHIStechnologyPART.com says... >> >>> [1] statistical analysis of some FPGA configuration patterns, leading >>> up to a fast, small compression/decompression algorithm. We need to >>> fit an application program and 6 megabits of Xilinx config stuff into >>> a 4 mbit Eprom. >>> >>I think Xilinx has some stuff on their site regarding compressing >>FPGA patters. IIRC, they're quite compressible, easily (RLL or some >>such). > >I'm looking for something that will be fast and easy to decode at fpga >config time. > >I just did some statistical analysis of a bunch of existing Spartan 3 >bit streams. If you treat them as bytes, and histogram the byte codes, >there's some impressive stats, with code 0x00 of course dominant, then >0xFF, and the next 16 most common codes huge, tapering off pretty >hard. That makes sense, since LUT bits are usually zero, so simple >codes like 0x01...0x80 and simple 2-bit combos are most common. Block >ram is usually 0 in our designs, too. So a fixed dictionary should >work pretty well. > >So it looks like a byte stream would do, with byte codes that say >stuff like... > > >00000000 end of file > >001nnnnn make N zero bytes, N=1 to 31 > >010nnnnn make N 0xFF bytes, ditto > >011nnnnn the following N bytes are raw, unencoded stuff > >1nnnnnnn look up code N in dictionary, N = 1 to 127 > >where the dictionary is a list of the most common 96 single bytes >followed by the most common 32 byte pairs. Net compression in this >case is just about 1:1! > >Something like that. > >Now the question is, how much compression will this give? I suppose >I'll have to code it and see. I need less than 2:1 now, and that >shouldn't be hard. Still working on this after 3 years? The following site looks promising if you can read German: http://www.sulimma.de/prak/ws0001/projekte/ralph/Projekt/index.htm -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 121912
Jim Granville <no.spam@designtools.maps.co.nz> wrote: >John Larkin wrote: > >> On Sun, 15 Jul 2007 16:17:33 +1200, Jim Granville >> Here's a byte histogram of a typical Spartan 3 config file. Most of >> the config bits are zero. I read one Xilinx appnote about the rad >> hardness of sram-based FPGAs, and they got the upset rate calculation >> down by noting that most config bits actually don't matter! > >On this one, that's appx 70% zeroes. >Could be interesting to see the 'RunCount' values - maybe something like >the 2 smallest, 2 highest, and 7 most common run lengths, in 11 more >columns ? to help design the best algorithm. > I also notice that a Single HI bit, is very common, so >even if that does not repeat, a specific compression coverage for those >would cover 38.5% of the non zero bytes ? Another optimisation may come from compressing the frame headers and deleting unused areas. Xilinx configuration data (which also includes commands BTW) is organised in frames with a CRC, preamble, location and postamble. There are appnotes on partial (re)configuration from Xilinx explaining these in more detail. The initialisation frames of blockrams may be omitted completely if they are not initialised which saves several kB. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 121913
Done something similar some time ago, to save some flash space for bitsream on a relatively small micro. Check this thread on this newsgroup: http://tinyurl.com/2xkt52 or search with google groups for "compressing Xilinx bitstreams, some test data". There are some measures from my real design, and a link to the source code. Please share your results with the group! "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> ha scritto nel messaggio news:6qdj93961u1thsslst6lj1smjeajem0hh8@4ax.com... > On Sun, 15 Jul 2007 16:17:33 +1200, Jim Granville > <no.spam@designtools.maps.co.nz> wrote: > > >>> >>> This is a 68332 uP, and a fixed dictionary wouldn't be bad, just a >>> couple of hundred bytes in rom maybe. My whole application program, >>> tables and all, comes in under 10K bytes! >> >>If you have a 68332 'going spare' for this, then your approach is prety >>spot on. You could check the streams to see if repeat-pattern was common >>enough to encode. >>- and you could define the count via a dictionary/table as well. >>[eg 5 bit index into 32 x 16 bit values ] >> >>-jg >> > > > Here's a byte histogram of a typical Spartan 3 config file. Most of > the config bits are zero. I read one Xilinx appnote about the rad > hardness of sram-based FPGAs, and they got the upset rate calculation > down by noting that most config bits actually don't matter!Article: 121914
Hi I am currently designing a circuit with a Virtex 4 FX FPGA and QDR II memory chip operating at 250MHz. I have a couple of questions :- 1) Can someone give me some advice regarding the decoupling capacitor requirements? I have had a look around the web but there seems to be a lack of info. 2) Can I get away with no termination? The longest track will be around 1.5". I have looked at a micron app note reagrding DDR2 and they state that for DDR2 around 2" is the max without termination. But as this is a different memory I am not sure if this would be valid. Cheers JonArticle: 121915
jonpry@gmail.com wrote: > Hi all, > I've recently built a prototype board using a xilinx xc3s250e- > ft256. The idcode read back through jtag is not recognized and has a > different manufacturer, i believe it to be corrupt. The code is > 0x000c1003. This is very much unlike the 0x0000000000 problems i > usually have. This happens using xilinx impact, digilent export, and a > custom program i wrote to try and debug this. I've looked at all the > signals on my scope and they seem to be in great shape. In my custom > software i have an idcode looping function and the chip returns this > number millions of times with out error. What could this possible be? Look with a scope if the 0x000c1003 is something real. Check for ringing on the sck line. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 121916
>>>> - do I need to add resistors to the data lines ? >>> >>> You can always stuff them with 0R if you need to. If your design rules >>> allow it, something like a CTS 742C083 series resistor array would be >>> easy to fit in the layout. That package is basically 3 0603 resistors >>> side by side in one 1206 package. >> >> I'll check this when I route. Isn't the FPGA drive strength option >> suficient ? > > Maybe for the address lines, but the data lines are bidirectional. > If you plan to run the SDRAM at 10MHz, I wouldn't give it a second > thought. If you're aiming at >100MHz then you probably want to give > yourself the option. > > I just pulled out an old SODIMM and it has 16 4x 10R arrays (64 lines > total). OK, I had forgotten that the SDRAM chip doesn't have a drive strength limit option... I'll use Xilinx mch_opb_sdram controller with XCL links to the CPU. The "mch" (multichannel) part isn't of any use to me but I tested this core versus the standard SDRAM core in a previous FPGA design and found this one to be much faster, and it plays well with the DMA controller's bursts. So the SDRAM will probably run around 50-70 MHz if I believe the core's datasheet, on SPartan-3E. I will locate the single 32-bit SDRAM chip below the FPGA, on the other side of the board (it's a PQFP 208) so trace length and skew will be minimal (about 1 cm). I may still have room for the resistor arrays, though. Since the FPGA limits its drive strength, I should place the resistors at the SDRAM pins, I think ? However, for the connector IO, I believe I can use the FPGA drive strength setting for signals sent by the FPGA, and place resistors (source-termination) at chips on the carrier board which will send data to the FPGA, right ? Thanks for the advice !Article: 121917
Thankyou for nice pointer. But it happened to me that I do need to separately "create and map libraries" in ISE. Probably Xilinx ISE does not have commands such as vlib, vmap, vcom (that Modelsim has). Thank you again for any comment.Article: 121918
Pasacco wrote: > Thankyou for nice pointer. > > But it happened to me that > I do need to separately "create and map libraries" in ISE. > > Probably Xilinx ISE does not have commands > such as vlib, vmap, vcom (that Modelsim has). > > Thank you again for any comment. > Have a look in the your_project_name.prj file. SylvainArticle: 121919
Hofjue schrieb: > On 9 Jul., 13:15, "Göran Bilski" <goran.bil...@xilinx.com> wrote: >> Each FSL port has one input connection (slave) and one output connection >> (master). >> So with 8 FSL ports, you can connect from one MicroBlaze to eight other >> MicroBlazes. >> >> This should be enough for your system. >> >> Göran Bilski > > Yes, that's right. But it doesn't work when MicroBlaze Nr. 3 should > communication with MicroBlaze Nr. 2 - or? In my opinion the only > solution in this configuration is to use a token ring communication. > But then it must be a cyclic communication and not an interrupt driven. Each MicroBlaze has 8 FSL-Ports. So if you have up to 9 MicroBlazes you can connect every MicroBlaze with every other. AndreasArticle: 121920
On Jul 14, 3:51 pm, jon...@gmail.com wrote: > I've recently built a prototype board using a xilinx xc3s250e- > ft256. The idcode read back through jtag is not recognized and has a > different manufacturer, i believe it to be corrupt. The code is > 0x000c1003. This is very much unlike the 0x0000000000 problems i > usually have. This happens using xilinx impact, digilent export, and a > custom program i wrote to try and debug this. I've looked at all the > signals on my scope and they seem to be in great shape. In my custom > software i have an idcode looping function and the chip returns this > number millions of times with out error. What could this possible be? I recently had a problem with my Spartan-3e design and my programming setup that has worked for years. Here is the thread: http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/b56a80c653060e70/ I finally got it to work by using a platform usb cable instead of a parallel III cable. I have not had the time to investigate why one works and the other doesn't. Alan Nishioka alan@nishioka.comArticle: 121921
All, The Parallel III cable was built before we had JTAG that had its Vcco lowered to 2.5V, and a whole slew of features added ... http://direct.xilinx.com/bvdocs/userguides/ug332.pdf Figure 9-1, has a good schematic of what is going on: input pins require series resistors, as they all use 2.5 V as their internal Vdd, output is optionally able to pullup (to Vccaux), see XAPP453. Also note Table 2-9 in the above referenced document, specifically what the TMSPIN does (enables, disables pullup to Vccaux internally). So, may an older parallel III cable work?: yes, but, you need to have the series resistors on input, and you need to address the TDO output, by either setting the TMSPIN to the right state, or providing an external pullup on TDO. The newer cables are 'smart' enough to figure out what to do, even though there may be settings that are enabling/disabling pullups. AustinArticle: 121922
Ben Jackson wrote: > On 2007-07-14, PFC <lists@peufeu.com> wrote: >>>> - do I need to add resistors to the data lines ? >>> You can always stuff them with 0R if you need to. If your design rules >>> allow it, something like a CTS 742C083 series resistor array would be >>> easy to fit in the layout. That package is basically 3 0603 resistors >>> side by side in one 1206 package. >> I'll check this when I route. Isn't the FPGA drive strength option >> suficient ? > > Maybe for the address lines, but the data lines are bidirectional. > If you plan to run the SDRAM at 10MHz, I wouldn't give it a second > thought. If you're aiming at >100MHz then you probably want to give > yourself the option. > > I just pulled out an old SODIMM and it has 16 4x 10R arrays (64 lines > total). For a point-to-point solution on a small board, I'd suggest the series resistors are overkill for data and address lines. If there were multiple loads, those resistors could be very handy. If the routing length was 6" or more, those resistors could be very handy. For even a 200 MHz SRAM interface placed very close to the FPGA, I had no qualms about point-to-point connections. For the signals that are *edge* critical, the resistor placeholder could be helpful to avoid some overshoot or troubles with monotonicity but I'd expect a smooth signal regardless if the transmission length is that short. __________________ One additional quick item - how are you hooking up the JTAG? If you're using the Xilinx programming adapter (I really prefer the Platform Cable USB) I'd suggest using the connector and pinout that plays nice with the ribbon cable connection. If this is board will have very few items produced, I'd also suggest using a memory that has a JTAG interface such that programming the Flash and reconfiguring the FPGA on the fly are both done with the same connect-in and forget-it interface. It may be a few dollars rather than 50 cents for a chip that gives you the flexibility, but I'd glagly take a $40 hit to avoid reconnecting those darned header signals over and over. A quick on-and-off connection with the 1mm spaced ribbon cable is so much easier than dealing with the flying leads and, perhaps, better for signal fidelity which can be an issue sometimes. - John_HArticle: 121923
Jon, some comments, below: > 1) Can someone give me some advice regarding the decoupling capacitor > requirements? I have had a look around the web but there seems to be a > lack of info. I am presuming you mean the QDR memory bypassing. I can't help you there. The FPGA bypassing is covered in: http://direct.xilinx.com/bvdocs/userguides/ug072.pdf > 2) Can I get away with no termination? The longest track will be around > 1.5". I have looked at a micron app note reagrding DDR2 and they state > that for DDR2 around 2" is the max without termination. But as this is a > different memory I am not sure if this would be valid. A number of customers do their SI simulations, and discover they are able to use LVCMOS 6 or 8 mA fast IO, and they meet all requirements (HSTL to LVCMOS, or SSTL to LVCMOS does work, but you need to simulate it, first. 1.5" might be OK, and then again, it might not). AustinArticle: 121924
".prj file" contains "library creation and mapping". Thank you for comment. I see following statements in the ".prj" file for one module. ------------------------------------------------------------------- -- Generated by GUI vhdl submodulelib "../../src/submdule_pkg.p.vhdl" vhdl submodulelib "../../src/submdule.e.vhdl" vhdl submodulelib "../../src/submdule_rtl.a.vhdl" ...... ------------------------------------------------------------------- Suddenly, I am confused. Let me ask question. ".prj file" does not look like a script. Suppose we have the ".prj file", In order to actually "create and map libraries", what is next step to proceed?
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z