adding FPGA grounds

Hi Gerhard,

On 14/10/2020 12:38, Gerhard Hoffmann wrote:
..
> Mentioning XC3020 should give a hint about the time frame.
> We had stacks of Compaq-286s then for concurrent runs of apr,
> in the hope that there was a usable routing solution the next morning.
..

Sorry to hijack this thread, I am curious if you have ever flown an 
XC3020. I also worked in the space industry about 30 years ago and was 
told that we couldn't use the XC3020 as it was latchup sensitive. Hence 
I had to continue using the Actel 1020 and 1280 which were very 
expensive and put a low of pressure on the engineers not to make a 
mistake. One oops and you have to burn a new device. This was long 
before the Qpro series.


> Scrubbing does not make the FPGA radiation proof. Important logic
> must be triple module redundant.
> 
> Since I was not given the Xilinx TMR tool (ITAR..) I wrote a
> VHDL library with tmr_slv, tmr_signed etc that looks much like the
> normal standard_logic_vector etc and hides most of the redundancy.
> I prefer my own library now.  :-)

I did the same although a bit simper, I build TMR FF's in Viewlogic and 
used those for the logic. This was before I learned about VHDL.

> 
> 
> Yes, scrubbing can have unexpected side effects. For example, you
> may not use these 2*8 bit CLB RAMs because they are physically
> in the configuration RAM.
> 
> Unfortunately, the Picoblaze uses these for its registers.
> Our software people did not like it that their programs
> crashed every few minutes.
> 
> I have rewritten the Picoblaze to use ordinary flipflops for its
> registers. The performance and area drawback was acceptable.

I decided to write an 8086 in VHDL a few years later with the same idea, 
make an SEU/SET tolerant softcore. We already used an 80186 for our main 
OBC like many other satellites in those days. However, some brilliant 
ESTEC engineer came along who wrote a far more capable Sparc processor 
in about a quoter of the time it took me to write the 8086...

Regards,
Hans.
www.ht-lab.com



> 
> Cheers, Gerhard

On Wednesday, October 14, 2020 at 7:38:41 AM UTC-4, Gerhard Hoffmann wrote:
> Am 14.10.20 um 05:43 schrieb Rick C:
> > On Tuesday, October 13, 2020 at 1:14:31 PM UTC-4, Gerhard Hoffmann wrot=
e:
> >> Am 12.10.20 um 18:57 schrieb Rick C:
> >>> On Monday, October 12, 2020 at 12:52:19 PM UTC-4, Jim Lewis wrote:
> >>>> How do you know these pins are not some sort of manufacturing test o=
utput pins?
> >>>>
> >>>> On a networking chip I used (years ago), a couple of the pins that w=
ere
> >>>> documented  as power and ground pins were actually mode configuratio=
n pins.
> >>>
> >>> He is talking about wiring unused I/O pins that he can specify as gro=
unds or power by assigning a '0' or '1' respectively.  They are not the sam=
e as a solid connection to the chip ground or power, but every bit helps.  =
At high frequency the pin inductance is probably higher impedance than the =
resistance of the internal MOSFET, so the I/O grounds are probably a lot be=
tter than nothing.  But this is also needed on the I/O power supply as well=
 as ground.
> >>>
> >>
> >> It may be possible to improve ground bounce slightly, but the
> >> on-chip ground connections may be connected only group-wise,
> >=20
> > Sorry, not sure what you mean by "group wise".  Grounds are connected t=
o ground, typically a ground plane.  What is "group wise"?
>=20
> groups might be a GTX transceiver , a tile of CLBs, a hard SDRAM
> interface.. WE cannot know that, but it could make sense.
> We can just bet or try it.

Sorry, I'm simply not following the thought here.  The FPGAs I use don't or=
ganize CLBs in tiles.  But more importantly, what does this have to do with=
 grounds?  I don't recall the source of this info, but grounds are not orga=
nized by groups, rather there is a global connectivity for the ground.  If =
grounds were connected to local logic/IOs specifically, they would be much =
less effective when the loading was not even.=20


> >> so that the drivers for SDRAM buses etc do not force ground bounce
> >> on the GND of the low level core signals.
> >=20
> > Why do you emphasize the ground an ignore the power?  The problem comes=
 from the threshold of an input being impacted.  The threshold is based on =
the differential voltage of the power and ground.  So is it not correct tha=
t the power rail will also impact the input threshold?
>=20
> Because JL wants to add GND connections. It's in the
> title of the thread.

JL *SAYS* he wants to add ground connections, but his actual goal is to red=
uce the jitter on a signal traversing the chip.  He thinks this means deali=
ng with ground bounce, but in reality it means dealing with power bounce as=
 well. =20

Interesting that he is focusing on mitigating the impedance to ground while=
 not giving so much attention to the other factors that cause bounce, the s=
witching outputs.  He did mention something about slowing output drives, bu=
t even more important is to stagger output switching times.  If you have 16=
 outputs switching at once and you reduce the drive 2x the bounce reduces b=
y 2x.  Stagger the 16 outputs so none switch at the same nanosecond and you=
 reduce the bounce by up to 16x.=20


> And input thresholds do not depend on VDD in the first or second order.
> That is determined by active circuitry in the chip and is set by
> configuration data.
> Remember you can choose 3V3-LVCMOS or 2V5 or 1.8V logic, or whatever.

LOL!  They do not specify exact voltages for any of these I/O types.  They =
switching voltage is almost universally specified as a function of Vcc.  Th=
e different thresholds selected vary mostly by the varying Vcc spec for the=
 different modes.  It's not like they have voltage sources compared to the =
input with differential amps.=20

Larkin has already shown the propagation delay varies wildly with Vcc, now =
he is just trying to find the sources of this variation, one of which is gr=
ound/power bounce because of the change in threshold for the incoming signa=
l. =20

Ask him, he's always happy to discuss his designs in great detail.=20


> And for powerup, VDD rise time and monotonous rise is usually specified.
>=20
> >> But driving unused outputs to GND cannot be bad since your logic
> >> might require it and there can be no bus fight.
> >=20
> > I'm not clear why you are mentioning "bus fights".
> >=20
> >=20
> >> Long time ago, I had a bus fight between an XC3020 and a 74AS244.
> >> The AS244 said low, the xc3020 said high. Saying low is the easier
> >> part, but the XC3020 won hands down.
> >> That consumed a lot of current.  :-)
> >>
> >> Early FPGAs could do that with their on-chip tri-state buses
> >> on their own, just by feeding them corrupt configuration data.
> >=20
> > My understanding is that all FPGAs have protections against accepting i=
nvalid configurations.  I may be mistaken.  It's just that I am pretty sure=
 this was resolved so long ago that I no longer even give it a thought.
>=20
> Mentioning XC3020 should give a hint about the time frame.
> We had stacks of Compaq-286s then for concurrent runs of apr,
> in the hope that there was a usable routing solution the next morning.

You are talking about a device that has not seen a design win in over 20 ye=
ars.  Yes, I've forgotten nearly everything I knew about them other than th=
ey followed the XC2000 series and preceded the XC4000 series.  No, I don't =
consider such devices when discussing FPGAs any more than I consider my '63=
 Chevy II when discussing automobiles. =20


> >> I had to study Virtex power up in quite detail when I implemented
> >> configuration memory scrubbing for some space-bound Virtexes that
> >> may encounter radiation and get bit flips in configuration ram.
> >=20
> > Yes, that is a different matter.  I worked with a guy from NASA for a w=
hile who was radiation testing FPGAs and he explained how they would reload=
 the configuration periodically to deal with soft errors.  What he never ex=
plained was how the circuit functioned while the FPGA was being reloaded.
> >=20
> >=20
> >> Mitigation consists of re-loading the configuration ram from
> >> non-volatile memory every few minutes and doing the user land
> >> logic   triple module redundant. Refresh must be done before the
> >> errors pile up so badly that the redundancy fails.
> >=20
> > So how do you deal with the loss of the FPGA functionality while being =
reconfigured?
> >=20
> >=20
> >> FPGA configuration is a well defined synchronous process controlled
> >> by the configuration clock. Scrubbing is done just like a power up,
> >> but the process is aborted 1 clock before the global reset etc is
> >> executed.
> >=20
> > So is the FPGA never stopped?  The devices I've worked with start confi=
guration by resetting the entire configuration RAM.  It was explained to me=
 that was what was happening that set the minimum configuration time, one f=
ull cycle through the process.  As long as the configuration pin was held a=
sserted, the process would continue.  When you released the signal it would=
 complete the cycle it was on, then accept a new bit stream.  I think Xilin=
x used the INIT pin for the flag that it was ready to be configured which c=
ould be paralleled between multiple devices.
>=20
> The Virtex is never stopped. The user-land circuit continues to run
> while the configuration ram contents is rejuvenated in dual port style.

I was not aware this was possible.  I thought that when the configuration p=
in is asserted the global set/reset was activated.=20


> That takes a known number of CCLKs from the activation of the program
> command pin. A few CCLKs later, chip re-initialization would start:
> global reset etc.
> That must not happen, so the configuration clock must be stopped
> in time until after the next program command a few minutes later.

Ok.  That's the easy to understand part.  I'm unclear about initiating conf=
iguration while the chip is running.  I'm not aware of any dual buffering o=
f the configuration memory.  So while the chip is being loaded any LUTs use=
d as memory or any block RAMs would be clobbered.  I guess they can not be =
used. =20


> Scrubbing does not make the FPGA radiation proof. Important logic
> must be triple module redundant.
>=20
> Since I was not given the Xilinx TMR tool (ITAR..) I wrote a
> VHDL library with tmr_slv, tmr_signed etc that looks much like the
> normal standard_logic_vector etc and hides most of the redundancy.
> I prefer my own library now.  :-)
>=20
>=20
> Yes, scrubbing can have unexpected side effects. For example, you
> may not use these 2*8 bit CLB RAMs because they are physically
> in the configuration RAM.
>=20
> Unfortunately, the Picoblaze uses these for its registers.
> Our software people did not like it that their programs
> crashed every few minutes.
>=20
> I have rewritten the Picoblaze to use ordinary flipflops for its
> registers. The performance and area drawback was acceptable.

Yeah, the picoblaze is not written in RTL, it is instantiated LUTs and regi=
sters, the way XC2000 designs were done.  Fine if you only want to use it. =
 Not so fine if you want to modify it.  They do get consistent performance =
with it.=20

--=20

  Rick C.

  -+- Get 1,000 miles of free Supercharging
  -+- Tesla referral code - https://ts.la/richard11209