[Milkymist-devel] Draft 1 schematics
Adam Wang
adam at sharism.cc
Thu Jan 28 02:23:23 PST 2010
Hi
> The FPGA will also be powered from the 2.5V source (for VCCAUX); setting it to
> 2.6V reduces the VCCAUX margins to +25mV -225mV, which seems pretty tight.
> An alternative is to power VCCAUX with 3.3V (Spartan-6s allow two voltages and
> they are selected via a configuration option) but this increases the
> dissipation on the 3.3V regulator.
Correct.
> I chose this DRAM part because it was easily available at DigiKey and
> backwards compatible with the others - not necessarily to run it with PC3200
> timings. We can use a slower and cheaper part during production. It is
> unlikely that we reach 200MHz on Spartan-6, the maximum target frequency I'm
> thinking about is 166MHz (PC2700 timings). I think the easiest option is to
> forget completely about PC3200 timings and set the power to 2.5V.
Ok. So from official web, the DDR400 SDRAM shown will easily let user
thought the timing can be reached 200MHz without checking Spartan-6
firstly. So the target freq. is clear now.
> For your information, the system is currently working on development boards
> using PC1600 (100MHz) timings so there is no need for super-high speed DRAM.
sounds good.
> What would you recommend as current limiting devices? Polyswitch?
Polyswitch is designed to protect against overcurrent. It became more
easier everywhere. You can check [1] or [2]. Placing two PPTCs
connected into individual usb-a connector.
>> 3, Can add 33 ohm on SDA & SCLK?
> Is this only for protection in case of signal contention?
yes, my original thought only.
> For this purpose, we can set the drive strength of the FPGA I/O to 2mA (there
> are no other devices on this I2C bus) which is even more efficient than the 33
> ohm resistors which would limit the current to 10mA and requires no extra
> part. Of course, this assumes that the FPGA does not get misconfigured with a
> higher drive strength.
If can let resistor value to be zero and traced to connectors as
option if one wants to add extra device via I2C later. This could
exempt from misconfiguration also make I2C extendable potentially.
Some hackers may like.
Adam
[1] http://www.ce-mag.com/archive/2000/mayjune/hapan.html
[2] http://www.electronicsweb.com/article.mvc/Meeting-USB-Overcurrent-Protection-Requiremen-0001?VNETCOOKIE=NO
More information about the Devel
mailing list