Reply by rickman June 24, 20152015-06-24
On 6/24/2015 11:04 AM, rickman wrote:
> On 6/23/2015 4:37 PM, TTman wrote: >> On 23/06/2015 19:50, ucy193@gmail.com wrote: >>> How to re/program thousands fpga at once in a short time? >>> >> What FPGA exactly ?? > > There are lots of details to this question. If they are all the same > FPGA with the exact same bitstream, they can be programmed in parallel, > although that will require one data return signal (TDO) for each of > them. Daisy chaining won't improve the programming time since each one > is done independently. > > If they all have different programming, but are the same device, then it > may be possible to have separate TDI and TDO signals yet program them in > parallel using the same TCK and TMS signals. > > My last thought is to question the need to program them all at the same > time. It is very unlikely that they are all available at exactly the > same time, so why wait on programming some before you program the > others. If there is a problem with manufacturing do you want to wait > until thousands are made before you test them and find the bug? > > I have a few hundred of my FPGA board made at the same time and at one > time I did all the testing. I would show up with my test setup as the > boards were coming out of cleaning and final inspection a couple dozen > at a time. I would program and test them about half as fast as they > could inspect them. I never found a need for a mass programming > fixture. I think it take about 30 seconds to program one Flash type, > small FPGA. Most of that is erase time.
Why don't you provide more info on your setup and ask this in the FPGA group? what flexibility do you have in what you are doing? What limitations do you have? Are you talking about RAM base devices that have to be reprogrammed every time they power up? -- Rick
Reply by June 24, 20152015-06-24
W dniu wtorek, 23 czerwca 2015 22:37:22 UTC+2 użytkownik TTman napisał:
> On 23/06/2015 19:50, ucy193@gmail.com wrote: > > How to re/program thousands fpga at once in a short time? > > > What FPGA exactly ?? > > --- > This email is free from viruses and malware because avast! Antivirus protection is active. > https://www.avast.com/antivirus
Fast reconfiguration diferent bitstreams, the biggestfpgas
Reply by rickman June 24, 20152015-06-24
On 6/23/2015 4:37 PM, TTman wrote:
> On 23/06/2015 19:50, ucy193@gmail.com wrote: >> How to re/program thousands fpga at once in a short time? >> > What FPGA exactly ??
There are lots of details to this question. If they are all the same FPGA with the exact same bitstream, they can be programmed in parallel, although that will require one data return signal (TDO) for each of them. Daisy chaining won't improve the programming time since each one is done independently. If they all have different programming, but are the same device, then it may be possible to have separate TDI and TDO signals yet program them in parallel using the same TCK and TMS signals. My last thought is to question the need to program them all at the same time. It is very unlikely that they are all available at exactly the same time, so why wait on programming some before you program the others. If there is a problem with manufacturing do you want to wait until thousands are made before you test them and find the bug? I have a few hundred of my FPGA board made at the same time and at one time I did all the testing. I would show up with my test setup as the boards were coming out of cleaning and final inspection a couple dozen at a time. I would program and test them about half as fast as they could inspect them. I never found a need for a mass programming fixture. I think it take about 30 seconds to program one Flash type, small FPGA. Most of that is erase time. -- Rick
Reply by rickman June 24, 20152015-06-24
On 6/24/2015 4:45 AM, Jan Panteltje wrote:
> On a sunny day (Wed, 24 Jun 2015 14:53:57 +0800) it happened Techman > <junkemail@bogus.com> wrote in > <v9CdnQj6v6KZyRfInZ2dnUU7-U2dnZ2d@westnet.com.au>: > >> On 24-Jun-15 1:05 PM, Jan Panteltje wrote: >>> On a sunny day (Tue, 23 Jun 2015 13:37:05 -0700 (PDT)) it happened whit3rd >>> <whit3rd@gmail.com> wrote in >>> <ea5b6d23-a608-40f9-a353-8cd533476bb5@googlegroups.com>: >>> >>>> Well, connector attach/detach time is a problem. >>>> Instead of a connector, use an IRDA receiver or transceiver, >>>> and you can send all the program commands from >>>> an IR LED searchlight, to as many powered boards >>>> as you can gather in the illuminated spot... >>>> >>>> The receiver, and the associated logic, are added cost; >>>> the program fixture and/or board connector for other program >>>> scheme, is a savings. >>> >>> Don't you want a verify? >>> >> >> Verification wasn't in the original spec. > > That is true. > > Few days ago when programming PICs, > I noticed that things would go a lot faster if I disabled verify. > But I resisted, as I would never know if something did not work if it was a coding error or > a programming error. > In the programmer code I wrote there is no option to switch verify off, > I resisted adding it.
I build a product with an FPGA in it and I find one in several hundred that do not program correctly, sometimes permanently so the chip has to be replaced. "Trust, but verify". -- Rick
Reply by N. Coesel June 24, 20152015-06-24
Techman schreef op 06/24/2015 om 08:53 AM:
> On 24-Jun-15 1:05 PM, Jan Panteltje wrote: >> On a sunny day (Tue, 23 Jun 2015 13:37:05 -0700 (PDT)) it happened >> whit3rd >> <whit3rd@gmail.com> wrote in >> <ea5b6d23-a608-40f9-a353-8cd533476bb5@googlegroups.com>: >> >>> Well, connector attach/detach time is a problem. >>> Instead of a connector, use an IRDA receiver or transceiver, >>> and you can send all the program commands from >>> an IR LED searchlight, to as many powered boards >>> as you can gather in the illuminated spot... >>> >>> The receiver, and the associated logic, are added cost; >>> the program fixture and/or board connector for other program >>> scheme, is a savings. >> >> Don't you want a verify? >> > > Verification wasn't in the original spec.
In mass programming I woudn't skip the verification step. Manually inspecting (root cause analyses + paperwork) one failed unit out of 10000 pays for the verification.
Reply by Jan Panteltje June 24, 20152015-06-24
On a sunny day (Wed, 24 Jun 2015 14:53:57 +0800) it happened Techman
<junkemail@bogus.com> wrote in
<v9CdnQj6v6KZyRfInZ2dnUU7-U2dnZ2d@westnet.com.au>:

>On 24-Jun-15 1:05 PM, Jan Panteltje wrote: >> On a sunny day (Tue, 23 Jun 2015 13:37:05 -0700 (PDT)) it happened whit3rd >> <whit3rd@gmail.com> wrote in >> <ea5b6d23-a608-40f9-a353-8cd533476bb5@googlegroups.com>: >> >>> Well, connector attach/detach time is a problem. >>> Instead of a connector, use an IRDA receiver or transceiver, >>> and you can send all the program commands from >>> an IR LED searchlight, to as many powered boards >>> as you can gather in the illuminated spot... >>> >>> The receiver, and the associated logic, are added cost; >>> the program fixture and/or board connector for other program >>> scheme, is a savings. >> >> Don't you want a verify? >> > >Verification wasn't in the original spec.
That is true. Few days ago when programming PICs, I noticed that things would go a lot faster if I disabled verify. But I resisted, as I would never know if something did not work if it was a coding error or a programming error. In the programmer code I wrote there is no option to switch verify off, I resisted adding it.
Reply by Techman June 24, 20152015-06-24
On 24-Jun-15 1:05 PM, Jan Panteltje wrote:
> On a sunny day (Tue, 23 Jun 2015 13:37:05 -0700 (PDT)) it happened whit3rd > <whit3rd@gmail.com> wrote in > <ea5b6d23-a608-40f9-a353-8cd533476bb5@googlegroups.com>: > >> Well, connector attach/detach time is a problem. >> Instead of a connector, use an IRDA receiver or transceiver, >> and you can send all the program commands from >> an IR LED searchlight, to as many powered boards >> as you can gather in the illuminated spot... >> >> The receiver, and the associated logic, are added cost; >> the program fixture and/or board connector for other program >> scheme, is a savings. > > Don't you want a verify? >
Verification wasn't in the original spec.
Reply by Jan Panteltje June 24, 20152015-06-24
On a sunny day (Tue, 23 Jun 2015 13:37:05 -0700 (PDT)) it happened whit3rd
<whit3rd@gmail.com> wrote in
<ea5b6d23-a608-40f9-a353-8cd533476bb5@googlegroups.com>:

>Well, connector attach/detach time is a problem. >Instead of a connector, use an IRDA receiver or transceiver, >and you can send all the program commands from >an IR LED searchlight, to as many powered boards >as you can gather in the illuminated spot... > >The receiver, and the associated logic, are added cost; >the program fixture and/or board connector for other program >scheme, is a savings.
Don't you want a verify?
Reply by whit3rd June 23, 20152015-06-23
Well, connector attach/detach time is a problem.
Instead of a connector, use an IRDA receiver or transceiver,
and you can send all the program commands from
an IR LED searchlight, to as many powered boards
as you can gather in the illuminated spot...

The receiver, and the associated logic,  are added cost;
the program fixture and/or board connector for other program
scheme, is a savings.
Reply by TTman June 23, 20152015-06-23
On 23/06/2015 19:50, ucy193@gmail.com wrote:
> How to re/program thousands fpga at once in a short time? >
What FPGA exactly ?? --- This email is free from viruses and malware because avast! Antivirus protection is active. https://www.avast.com/antivirus