Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 121900

Article: 121900
Subject: spartan-3e idcode
From: jonpry@gmail.com
Date: Sat, 14 Jul 2007 22:51:47 -0000
Links: << >>  << T >>  << A >>
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
Subject: Re: ESR Meter - design contest
From: PFC <lists@peufeu.com>
Date: Sun, 15 Jul 2007 01:19:19 +0200
Links: << >>  << T >>  << A >>

> 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
Subject: Re: ESR Meter - design contest
From: krw <krw@att.bizzzz>
Date: Sat, 14 Jul 2007 19:57:04 -0400
Links: << >>  << T >>  << A >>
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.

-- 
  Keith

Article: 121903
Subject: Re: ESR Meter - design contest
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sun, 15 Jul 2007 12:59:02 +1200
Links: << >>  << T >>  << A >>
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?)

-jg




Article: 121904
Subject: Re: ESR Meter - design contest
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sat, 14 Jul 2007 20:13:32 -0700
Links: << >>  << T >>  << A >>
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!

John



Article: 121905
Subject: Re: ESR Meter - design contest
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sun, 15 Jul 2007 16:17:33 +1200
Links: << >>  << T >>  << A >>
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 ]

-jg



Article: 121906
Subject: Re: ESR Meter - design contest
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sat, 14 Jul 2007 23:02:22 -0700
Links: << >>  << T >>  << A >>
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         1


Article: 121907
Subject: Re: Newbie's first FPGA board !
From: Ben Jackson <ben@ben.com>
Date: Sun, 15 Jul 2007 01:38:52 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: Chipscope 9.1: Any easy way to rename and regroup signals?
From: "Symon" <symon_brewer@hotmail.com>
Date: Sun, 15 Jul 2007 07:51:52 +0100
Links: << >>  << T >>  << A >>
"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
Subject: Re: ESR Meter - design contest
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sun, 15 Jul 2007 19:11:38 +1200
Links: << >>  << T >>  << A >>
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
Subject: Re: Interesting problems about high performance computing
From: "hitsx@hit.edu.cn" <hitsx@hit.edu.cn>
Date: Sun, 15 Jul 2007 01:05:39 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: ESR Meter - design contest
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 15 Jul 2007 09:32:38 GMT
Links: << >>  << T >>  << A >>
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.nl

Article: 121912
Subject: Re: ESR Meter - design contest
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 15 Jul 2007 10:06:07 GMT
Links: << >>  << T >>  << A >>
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.nl

Article: 121913
Subject: Re: ESR Meter - design contest
From: "Antonio Pasini" <removethis_antonio.pasini@alice.it>
Date: Sun, 15 Jul 2007 12:08:22 +0200
Links: << >>  << T >>  << A >>
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
Subject: QDR II SRAM Interface
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Sun, 15 Jul 2007 05:14:49 -0500
Links: << >>  << T >>  << A >>

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

Jon

Article: 121915
Subject: Re: spartan-3e idcode
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Sun, 15 Jul 2007 10:54:40 +0000 (UTC)
Links: << >>  << T >>  << A >>
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
Subject: Re: Newbie's first FPGA board !
From: PFC <lists@peufeu.com>
Date: Sun, 15 Jul 2007 13:02:31 +0200
Links: << >>  << T >>  << A >>


>>>> - 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
Subject: Re: How to create and map user library in command-line?
From: Pasacco <pasacco@gmail.com>
Date: Sun, 15 Jul 2007 04:30:46 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: How to create and map user library in command-line?
From: Sylvain Munaut <tnt-at-246tNt-dot-com@youknowwhattodo.com>
Date: Sun, 15 Jul 2007 15:20:16 +0200
Links: << >>  << T >>  << A >>
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.

   Sylvain

Article: 121919
Subject: Re: Microblaze and software interrupts?
From: Andreas Hofmann <ahnews@gmx.net>
Date: Sun, 15 Jul 2007 16:00:07 +0200
Links: << >>  << T >>  << A >>
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.

Andreas

Article: 121920
Subject: Re: spartan-3e idcode
From: Alan Nishioka <alan@nishioka.com>
Date: Sun, 15 Jul 2007 07:39:42 -0700
Links: << >>  << T >>  << A >>
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.com


Article: 121921
Subject: Re: spartan-3e idcode
From: austin <austin@xilinx.com>
Date: Sun, 15 Jul 2007 08:44:26 -0700
Links: << >>  << T >>  << A >>
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.

Austin


Article: 121922
Subject: Re: Newbie's first FPGA board !
From: John_H <newsgroup@johnhandwork.com>
Date: Sun, 15 Jul 2007 15:54:36 GMT
Links: << >>  << T >>  << A >>
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_H

Article: 121923
Subject: Re: QDR II SRAM Interface
From: austin <austin@xilinx.com>
Date: Sun, 15 Jul 2007 08:54:43 -0700
Links: << >>  << T >>  << A >>
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).

Austin

Article: 121924
Subject: Re: How to create and map user library in command-line?
From: Pasacco <pasacco@gmail.com>
Date: Sun, 15 Jul 2007 09:10:30 -0700
Links: << >>  << T >>  << A >>
".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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search