Dont split Vccint and Vccbram unless you are doing suspend/low power shenanigans.
They're only split in terms of the net names, so I can ensure sufficient decoupling caps for the BRAM connections, but I'm going to get rid of the link/separate net name and just box off the BRAM decoupling caps on the schematic. I'll still know what to do with them on the PCB design.
Either you are going for a cost/space constrained design, and they are the same power rail with caps all sharing the work so need to be designed for the task.
or you are just copying the UG483 recommended design because there is no pressure on size/cost
Initially the VCCBRAM net didn't exist, I just ran VCCINT to the VCCBRAM inputs on the FPGA. However, whilst copying the UG483 recommended decoupling layout, I realised there are a few caps specifically for the VCCBRAM inputs, so I thought I'd just split the net via a 0R resistor so that I could see more clearly which caps were for VCCBRAM and which weren't by their net names instead of just by their annotation. There are other ways I could have done this that wouldn't be as clear on the PCB layout, like just 'boxing off' a few VCCINT caps on the decoupling schematic for the VCCBRAM connectors, but I went for this one knowing I'd be likely to change it in the future. Didn't think it would be that much of an issue to be honest.
![Confused :-//](https://www.eevblog.com/forum/Smileys/default/confused0024.gif)
I don't know if you read the TL;DR at the start of this thread, but I'm not a professional PCB designer or electronics engineer. I'm a hobbyist, at best. When I talk about pressure on size/cost, I'm talking about saving money on big things like chip choice, not worrying about saving a few thousandths of a dollar on a cap here and there. I'm literally going to be building (hopefully) one, maybe up to four (to use all the FPGAs I've bought) of these things. I'll be making the designs public, so I suppose there's that, but I'm not designing for mass production and so perhaps I'm not looking at this from the same angle you are with your career/expertise behind you.
Xilinx provide pretty good documentation, but you have to actually read it. Very few systems are going to push the power distribution up to or beyond their baseline example.
I am. I have UG470, UG471, UG472, UG473, UG474, UG475, UG482, UG483 and UG586 (amongst others) open in tabs on my browser. I'm trying to read them as I go and use them as references - I've already used their decoupling design, for example.
I thought I was pretty clear that I offered MPM3683-7 only for Vccint rail. MPM3833s should be fine for other rails.
Sorry; I either misunderstood, misread or outright forgot.
Okay, I've switched to DDR3 (instead of DDR3L) chips (these ones) and have increased the voltage from 1.35V to 1.5V for VCCDDR. I've dropped the DDR3 size down to 64MBx32.
All DDR3L chips can work in DDR3 mode (at 1.5 V). So no need to switch devices. I would plan for 4Gb parts - or even 8Gb ones for the layout, but you can always place smaller part - these devices are fully backwards compatible.
Okay, I'll stick with the
original choice then. I've really got to stop doing this late at night. I saw 'Vdd=Vddq=1.35V (1.283-1.45V)' and missed the bit underneath that said 'backward compatible to 1.5V'.
But before we can settle on connectors, we will need to figure out how many pins we will need and what's going to be a pinout. This is why I keep asking about listing everything that is to be connected. We will probably want to route out as many IO as we can, so maybe it will be better to just see which IOs are going to be available.
This is the downside to designing a core card that can fit onto any carrier board design - you don't really know what's going to be on the carrier board, so I guess we have to consider worst-case scenarios and try to route as many IOs as possible.
That aside, here's what I really need it to do - everything else is a bonus:
Core board:
2xDDR3 via 32-bit bus @ 400MHz.
JTAG programming port.
1 or 2 IO LEDs for testing the core board without a carrier board.
All power supplies except 5V, which will be provided by carrier board or external source if no carrier connected.
Carrier board (specific to my use-case) - nothing too demanding really other than HDMI:
HDMI TX capable of 1080p @ 60Hz or better.
Audio output via headphone/line out.
USB-A host PHY (CH559 or something similar - open to suggestions - serial/SPI/I2C interface to FPGA) for keyboard/mouse.
USB FPGA programmer.
5V power supply via USB or DC power connector.
80-pin interface to 5V host bus via level converters.
Various buttons/LEDs/RGB LEDs.
I'm going to need at least 60 I/Os for the carrier board for the host interface, then there's the HDMI, JTAG, audio codec, USB, generic IO lines.
Your schematic has a zero Ohm resistor dividing those lines. No need for that crap. Just do a schematic like I did in mine (see a pdf I linked few posts above), and include a table from Xilinx user guide which lists what caps and of what nominal will we need. See UG483, chapter 2, section PCB Decoupling Capacitors -> Recommended PCB Capacitors per Device. I typically use 0201 caps for 0.47 uF (as these need to be places inside of via field), 0402s for 4.7 uF, larger caps size is not very important as they can be placed anywhere, so I usually use whatever cap I happen to have - like 0805 or even 1210.
As I mentioned above, I'm using UG483 already. I've never used 0201 caps and am a little concerned a butterfly will flap in a garden twenty miles away and they'll all just disappear like a cloud of nanites.
![Shocked :o](https://www.eevblog.com/forum/Smileys/default/shocked.gif)
Might have to have some discussion around how you solder those things, as 0402 feels like my limit at the moment. And I need to get a microscope!
![Wink ;)](https://www.eevblog.com/forum/Smileys/default/wink.gif)
Ah okay, I didn't know how the Xilinx FPGA would be with just letting all the horses out of the gate at once. If it's not an issue, I'll scrub the sequencer then - thanks. ![Smiley :)](https://www.eevblog.com/forum/Smileys/default/smiley.gif)
Yeah, I never bothered with rail sequencing unless I had a system controller MCU for some other reason which I could just reuse for sequencing, and never had any problems with it.
Excellent. The sequencer is gone, like all those 0201s as a mosquito flies by.
![Wink ;)](https://www.eevblog.com/forum/Smileys/default/wink.gif)