In for a penny, in for a pound... I'll be needing/wanting to implement these protection measures on the GPU card, so may as well test them out on the test card, too.
My MSO is only able to follow signals << 200Mhz. And that's my limit.
I hope the ram controller doesn't pause after every single read request. My old DDR2 ram controller scanned the next read or write req and if it was in the same current access column, it would fly the command through as just a new CAS would be asserted optimizing column access automatically.
I hope the ram controller doesn't pause after every single read request. My old DDR2 ram controller scanned the next read or write req and if it was in the same current access column, it would fly the command through as just a new CAS would be asserted optimizing column access automatically.As I understand, Xilinx controller has internal FIFOs for commands, read and write data (as it supports backpressure), but from what I read on it, it can hold rows open if it sees additional commands that refer to the same row. So it does some internal optimizations, but they are not visible outside and you get your responses in exact same order you've submitted your requests.
I foresee Nockieboy having to implement Z80 read cycle wait states in his Z80 bridge.
And I guess we will separate the ram instruction fetch from the ram data read into 2 separate channels with 1 burst cycle sized cache on each, or whatever size the ram controller can efficiently terminate a DDR3 burst. This way we wont throw out 8-16 sequential op-code instructuions or data bytes after a read of a new address cutting down repetitious access to the ram controller.
But like I said before, you guys will need to think about implementing a DMA controller. It's just not realistic to use such slow CPU to haul around megabytes of data. A single 32bit true-color image at 720p is about 3.5 MBytes, so just loading resources into memory will take forever unless you offload it to some sort of DMA engine.
If you design your layout for such part
the math-co FPU & sound system.
If you design your layout for such part
That's the point. I am not able to design such a PCB, neither to solder such a component, but I would buy a video-ram module if it existed.
That's the point. I am not able to design such a PCB, neither to solder such a component
the math-co FPU & sound system.
are you going to implement a floating point unit? with basic operations {+,-,*,/,%} or also trigonometric functions {sin,cos,tan,sinch,cosch,tanch,...}?
It will be half speed of the DDR3. That's still very good. But which FPGA? The only FPGA with a TQFP good pin-count is the CycloneIII at 240pin TQFP. All other Cyclones dropped the 240pin in favor of BGA. Only the 144 TQFP exists for all the new ones, though, the CycloneIII is basically identical if you aren't using any CPU hard core or high speed serdes, meaning compliant with this project.
You haven't been reading this thread, have you?
That's the point. I am not able to design such a PCB, neither to solder such a component
How do you know that? Have you actually tried?
So, How do I know that? Have I actually tried? Yes, I have already tried with BGAs with bad results, and to be honest, now I am thinking about the purchase an IR oven to fix it.
Besides, I tend to avoid Xilinx's IPs, I prefer to have my own HDL code, that's an other limit because you need time to design and test stuff.
Just a quick question before I send this PCB off for production - I had 3.3V pull-ups for the I2C lines from the FPGA (SCL_S and SDA_S) - I'm thinking these should be VCCIO pull-ups instead. Is that right?
If the FPGA is running its IO at 2.5V, then feeding 3.3V into the SDA and SCL lines is going to cause issues?
EDIT: Aaaaaalso, I found a wiring error on the header. I'd used the wrong pin for one half of one of the wired pairs.
Worst case, you will need to use some kapton tape to protect the connector and hot-air remove the SDRam chip to attempt 720p. Absolute worst case is if you need to do so just to get 480p working.
I think you f-ed up your connector. (It's head banging time again!)
Uhh that was a silly mistake with the header - I don't know if it was an issue with the type of header I'd used or what, but it was clearly wrong - well done for spotting that one.
Have updated the schematic and PCB with the other changes - should be up to date so far.