e:
utput pins?
ere
n pins.
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.
o ground, typically a ground plane. What is "group wise"?
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.
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?
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.
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.
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.
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.
Ask him, he's always happy to discuss his designs in great detail.
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.
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.
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.
reconfigured?
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.
I was not aware this was possible. I thought that when the configuration p in is asserted the global set/reset was activated.
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.
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.