Table 6-16 shows the 'Hard Memory Controller Width for CV ', in the F256 pin device, it is not bonded to the IOs.
You need the U484 or F484 device, or, M383 device to get the 400MHz.
So, we are stuck with 303MHz, 606mtps without any sort of overclocking the fabric.
Or the compiler allows a higher speed without timing violations.
Or we write our own and cheat a little to get the IO port's theoretical ~800Mhz DDR data IO rate, though, 400MHz logic to control the ram would need to be a simple sequencer.
Table 6-16 shows the 'Hard Memory Controller Width for CV ', in the F256 pin device, it is not bonded to the IOs.
You need the U484 or F484 device, or, M383 device to get the 400MHz.
So, we are stuck with 303MHz, 606mtps without any sort of overclocking the fabric.
Or the compiler allows a higher speed without timing violations.
Or we write our own and cheat a little to get the IO port's theoretical ~800Mhz DDR data IO rate, though, 400MHz logic to control the ram would need to be a simple sequencer.
See - Antel itself pushes you towards Xilinx! There you will have your 400 MHz DDR3, and 720p HDMI, and more
Yup, you need to pay 4$ more for the F484 version, and more PCB area...
But this is 'Intel' with their 'Complex' and overpriced self-induced superiority.
I think that 8/16-bit bus between the FT313 and the FPGA will be an issue for me, though - that's potentially a lot of IOs that I may not have, depending on how the DDR3 goes. The MAX3421 can do it over an SPI connection, so that keeps IO usage to an absolute minimum.Have you actually started putting together schematics for all these updates?
Most USB-capable SoCs these days connect to USB 2.0 PHY via ULPI bus, which is a parallel 8 bit bus, and implement EHCI inside the SoC itself. This is why I was surprised to learn that such chips even exist as a stand-alone devices. The more I read about it, the more I like it. Of course, if you want performance, that device won't quite cut it, but in many-many cases performance is not very critical, and 10-20 MBytes/s might be more than enough, especially if you also get simplicity of implementation. Come to think of it, even USB audio streaming would require much less bandwidth than that.
Question for Nockieboy, will you stick with Quartus Prime 18.1 for this project, or upgrade to Quartus Prime 20.3?
Table 6-16 shows the 'Hard Memory Controller Width for CV ', in the F256 pin device, it is not bonded to the IOs.
You need the U484 or F484 device, or, M383 device to get the 400MHz.
So, we are stuck with 303MHz, 606mtps without any sort of overclocking the fabric.
Or the compiler allows a higher speed without timing violations.
Or we write our own and cheat a little to get the IO port's theoretical ~800Mhz DDR data IO rate, though, 400MHz logic to control the ram would need to be a simple sequencer.
See - Antel itself pushes you towards Xilinx! There you will have your 400 MHz DDR3, and 720p HDMI, and moreYup, you need to pay 4$ more for the F484 version, and more PCB area...
I say they should have retired their entire 28nm garbage and only begin their lineup with the Arria FPGAs.
Or, drop the prices of their 28nm lineup by at least 50% and drop their Arria line's price by a good 50-70%. Then they will be a good competitive deal. But this is 'Intel' with their 'Complex' and overpriced self-induced superiority.
I agree - if I want performance (anything more than the USB 1 12MBytes/s) then I'll need an 8- or 16-bit interface to the USB Host chip, but for keyboard and mouse usage, I think an SPI interface will work just fine.
Just for comparison, the Hyperram would have achieved ~150 megabytes a second.
Just for comparison, the Hyperram would have achieved ~150 megabytes a second.Why 150? It's running at 200 MHz DDR, so theoretical maximum will be 400 Mbytes/s, and in practice my design achieved bandwidth quite close to the limit (though I used 166 MHz DDR devices because 200 MHz ones didn't exist yet at that time). The trick here to utilize LONG bursts...
We cannot do long bursts every time and you cannot terminate midway a long burst with Hyperram when you need to...
Intel's DDR3 controller specifies smart alternating banking with multiport priority & weight allocation with burst termination capabilities built in. Are you saying Nockieboy would have achieved all that with his home-made Hyperram controller?
We cannot do long bursts every time and you cannot terminate midway a long burst with Hyperram when you need to...What do you mean? Of course you can terminate burst whenever you need to. As long as you provide data, it will accept it. Same for reading - as long as you hold CS low and provide clocks, it will continue pumping out data.
Damn, a number of additional penalties & cycles galore just to get the thing started again, especially if you just want to hop somewhere else in the same page...
Just so we are clear, at 300MHz, you are still getting 1.2 giga-bytes a second with even a CV-8...
With overhead, ~1 giga-byte a second.
Do you need more?
Just for comparison, the Hyperram would have achieved ~150 megabytes a second.
1 VGA/480p 16bit color display MAGGIE layer eats around 54 megabytes a second.
1 16bit 720p@60hz, or 1080p@30hz MAGGIE layer eats around 150 megabytes a second.
(That's 4 16 bit 1080p layers easy with DDR3 at 300MHz, or 12 VGA 640x480 layers. These figures leaves excessive access time left for the accelerated geometry, audio, FPU, SD-hard-disk at a rate the Z80 cant even begin to cope with even if it were 100MHz. Not to mention if you use 1 layer less, or 1 or 2 of the counted layers is only 8 bit 256 colors. And all this still has 0 effect on the FPGA internal memory's layers which operate in parallel.)
I agree - if I want performance (anything more than the USB 1 12MBytes/s) then I'll need an 8- or 16-bit interface to the USB Host chip, but for keyboard and mouse usage, I think an SPI interface will work just fine.Well if you move to a larger package or to Artix, you will have enough IO pins for everything. I still think that FTDI chip is a better long-term option as it provides better path for new functionality down the road. And SRAM is much easier protocol than SPI.
Need to be careful about the LVDS output. If we want the 'TRUE' 740/840mbps, we need to choose dedicated LVDS TX pair channels and not the emulated ones which only achieve 640mbps.
Need to be careful about the LVDS output. If we want the 'TRUE' 740/840mbps, we need to choose dedicated LVDS TX pair channels and not the emulated ones which only achieve 640mbps.Missed this part - what the hell is "emulated" LVDS and how it differs from "True"? No such thing on 7 series, all diff pairs there are the same
We made a booboo on the chosen LVDS drivers for the HDMI board as 1 of the 4 pairs chosen was a RX pair instead of TX. So, Quartus is telling me that our limit is 640mbps for 1 pair and I thought it was a limit of the C4, not that the pair I chose was faster at RX instead of TX if we used the next adjacent pair.
The difference is in each IO bank, there are 16 IOs total, 4 pairs true TX differential pairs and 4 true RX pairs. Use these pairs as as pairs and you get 840mbps with 160ps output jitter on the TX. Use any other IO combinations as your transmitter or receiver and you get 640mbps with 160ps jitter. Use any IOs you like as an emulated differential receiver or transmitter pair, the jitter jumps to 360ps.
Which pairs are which is located in the pinout files I listed above, but, not in the schematics where we have just an ##p & ##n shown on the FPGA symbol.
We made a booboo on the chosen LVDS drivers for the HDMI board as 1 of the 4 pairs chosen was a RX pair instead of TX. So, Quartus is telling me that our limit is 640mbps for 1 pair and I thought it was a limit of the C4, not that the pair I chose was faster at RX instead of TX if we used the next adjacent pair.
We made a booboo on the chosen LVDS drivers for the HDMI board as 1 of the 4 pairs chosen was a RX pair instead of TX. So, Quartus is telling me that our limit is 640mbps for 1 pair and I thought it was a limit of the C4, not that the pair I chose was faster at RX instead of TX if we used the next adjacent pair.
Is this a booboo I need to (or it would benefit from being) correct before I submit the PCB design?
The difference is in each IO bank, there are 16 IOs total, 4 pairs true TX differential pairs and 4 true RX pairs. Use these pairs as as pairs and you get 840mbps with 160ps output jitter on the TX. Use any other IO combinations as your transmitter or receiver and you get 640mbps with 160ps jitter. Use any IOs you like as an emulated differential receiver or transmitter pair, the jitter jumps to 360ps.
Which pairs are which is located in the pinout files I listed above, but, not in the schematics where we have just an ##p & ##n shown on the FPGA symbol.
We made a booboo on the chosen LVDS drivers for the HDMI board as 1 of the 4 pairs chosen was a RX pair instead of TX. So, Quartus is telling me that our limit is 640mbps for 1 pair and I thought it was a limit of the C4, not that the pair I chose was faster at RX instead of TX if we used the next adjacent pair.Oh wow - didn't even know that is a thing. No such nonsense in 7 series. All 24 diff pairs in the IO bank (50 pins total per bank, 2 pins per bank are non-differential) are the same and can reach max datasheet speed (and even higher as experience shows).
Parts and PCBs are now on order.
While I'm waiting for the PCBs to be delivered, I guess I should head back and finish that HDL ellipse function.
While I'm waiting for the PCBs to be delivered, I guess I should head back and finish that HDL ellipse function.
While I'm waiting for the PCBs to be delivered, I guess I should head back and finish that HDL ellipse function.Since you guys seems to be dead set on Cyclone V, you can also start working on DDR3 interface schematics and layout