EEVblog Electronics Community Forum

Nice work. Is there a way to use it with VHDL under Quartus?

Thanks for sharing, Please make a reop on github too

Nice work. Is there a way to use it with VHDL under Quartus?

I don't use Quartus, but otherwise, the answer is usually, yes. Brian's controller is written in SystemVerilog, so first you need to check whether this is properly supported by the Quartus version you're using. If it's recent enough, I guess it is.

Mixing HDLs is usually no problem. You'll just need to define a component interface for the controller in VHDL following the SV interface.

I just bought a Deca Max 10 (arrived today, my birthday... Perfect timing and plan to use this code with it, but with VHDL. I'll probably use the latest Quartus unless something requires an older version.

Question to Brian: you were talking about testing this controller on a Lattice ECP5 IIRC. Did you get to do this? If so, how did that turn out, and how many LUTs does it take?

I just need to find a ECP5 board with at least 1 DDR3 ram chip.

The code was designed to be ported to old and new FPGAs alike, however, the capture read data method I used to be compatible across all basic FPGA limits the DDR3 controller to around 500MHz / 1gtps.  Higher than that and it would be recommended to change the read data sampling to using the DQS strobe input as a clock instead of as a latch-enable.

The DDR3 controller alone, 1 read, 1 write port, running a 16bit DDR3 512mb ram chip in Quartus uses:
3480 logic cells in the HDMI out ellipse demo.
512 LUT-Only LCs,
1806 Registers-Only LCs
1166 LUT/Registers LCs

The 3480 number may be inflated since it is connected to the Multiport module, and that one eats a crap-load of registers as it it has independent caches on each port and it's a huge cross-bar matrix.
In the Ellipse demo, it eats another ~3k logic cells.

Ah yes... I don't have one either. The one I have only has SDRAM. And right now, prices have inflated quite a bit, so ECP5 boards with DDR3 are not quite cheap...

Design you own? It won't be cheap either - at least initially - but it will surely be a lot of fun And if you team up with others, it will help to spread the NRE around, as well as speed up the process.

You can always use a trial version of their DDR3 controller to verify the hardware. I would also use it to confirm that the pinout will work.

I tend to agree with BrianHG here. One thing to debug at a time...

Like I said, using a trial version of controller solves the hardware checkout problem. I use this method all the time, albeit with Xilinx devices.

Now I suppose if you're familiar with routing DDR3 stuff, going directly for a custom board should not be a problem. But I'm not. (Now I guess possibly the design could be shared, and someone else could do the routing...)

Or you can do the routing yourself and ask someone to check it once completed, and/or perhaps ask some questions in case DDR3 layout rules are not sufficiently clear. Otherwise it's going to be a classic chicken-and-egg problem when you won't attempt a DDR3 design because you have no experience, but you can't gain experience without actually doing it.

There is nothing particularly difficult about it, especially if you go for a relatively simple design - like a single DDR3 memory device, no ADDR/CTRL termination, and low'ish (as far as DDR3 standard goes) frequency. It's just a handful of rules you've got to follow, and that's pretty much it.

Asmi, I feel exactly that about using DDR 3. Do you have a list of layout rules and a description about how DDR3 ? I surely understand SRAM memories and more or less get dynamic memories, but I have no idea what other complications exists for synchronous memories.

DDR3 memory interface consists of a bunch of traces, which are divided into several groups: a single group typically called "Address/control" (or "Command/address/control") which, as the name suggests, consists of address lines (A0-A15, depending on module's capacity), bank address lines (BA0-BA2), and command lines (CKE, RAS, CAS, WE, CS, ODT); and then one or more of "byte lanes" (also called "DQ group"), each one consisting of 8 DQ (data) lines, associated DQS and DQS# lines, and a data mask DM. Attached is a good image from iMX6 datasheet showing example rules for length matching in case of a single x16 DDR3 memory device.

0. Remember that the length matching is about signal length (sometimes also called electrical length) a.k.a. propagation delay, not necessarily physical length! This is important to keep in mind in case you route traces within a group on different layers - signals on outer layers travel faster than on internal ones. Also remember that a portion of via height that the signal is going along also needs to be included - it's typically called via z-length. Not all eCAD tools take this into account, so you have to be on a lookout for these things.
1. The clock line needs to be at least as long as address/control lines are. I typically match it as part of the group, but it can be a bit longer.
2. Traces within address/control lines need to be matched to ±10 ps.
3. All byte lanes has to be no longer than address/command traces.
4. All signals within a single byte lane need to be matched to ±10ps.
5. There is no requirement to match traces of different byte lanes.
6. Traces within differential pair (CK/CK#, DQSn/DQSn#) needs to be matched to ±2ps.

As far as impedance goes, depending on a frequency and a specific controller it can be 50 Ohm or as low as 40 Ohm (the latter is a Xilinx requirement for 7 series FPGAs for DDR3 frequencies above 666 MHz, 50 Ohm is good enough for speeds below that).

If you intend to use several memory devices in your interface, things get more complicated because with DDR3 there are two possible topologies for address/control lines - a balanced tree (like DDR2 and below), and a fly-by (new for DDR3). Technically all DDR3 controllers are supposed to support fly-by topology (which is easier to route), but in reality there are some which don't support it.

Finally, it might be required to implement a termination for address/control lines (DQ, DQS and DM lines don't need one because memory devices have dynamic on-die termination controlled by ODT input). Whether it's required or not can be determined by SI simulations, but typically you can get away without it for a single component which is close to the controller. For multi-chip interfaces you will more likely than not need to implement it.

New release:
**********************************
Beta Release V0.95, August 4, 2021.
**********************************

Has now been uploaded at the top of this thread:
https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/
Changes are written there and the history is in the README file.
Please make sure you are downloading the _V0.95 as I kept the earlier revisions available for download as well.


Utilization report DDR3 controller inside the HDMI out ellipse demo:

Old V0.9.
3480  logic cells in the HDMI out ellipse demo,
512    LUT-Only LCs,
1806  Registers-Only LCs,
1166  LUT/Registers LCs.

New V0.95.
3100  logic cells in the HDMI out ellipse demo,
478    LUT-Only LCs,
1826  Registers-Only LCs,
796    LUT/Registers LCs.

New V0.95 True Stand-alone DDR3_PHY_SEQ.sv DDR3 controller with 128bit read and write port.
2082  logic cells,
515    LUT-Only LCs,
984    Registers-Only LCs,
583    LUT/Registers LCs.

Update:  Just cleaned up the main BrianHG_DDR3_PHY_SEQ.sv controller and sequencer.

All FMAX limitations and cross clock domain problems have been cleaned out.  Easily achieved proper 350MHz controller and 400MHz with only a few cross-clock domain signals not making the cut @ TC85 degrees by less the 0.070ns, yet it runs clean.  (The signals being some of the OEs for the write data, however, my codes is programmed to turn on the OE 1 clock cycle early, and turn it off 1 clock cycle late meaning an error here will not occur.  The core and all data + IO paths clear the timing analysis fine above 400MHz.)  The logic cell and LUT count has also shrunk.  The change in code has generated what appears as a minor occasional 1 DDR_CK clock delay occasionally when bursting after the first BL8, however, what is going on is if a read or write burst begins on an odd DDR_CK phase compared to it's half-clock interface clock, or the tRCD, tCAS happens to be an odd number, an alignment to the phase of the burst size of 8 may realign to the even matched phase after the first BL8 burst.  The old full speed V0.9 controller stacked a few additional commands in advance and would retain the 'ODD' alignments generating an unbroken consecutive burst making the appearance of a tighter ram controller by packing everything back-to-back.  After the release of version 1.0, I will see if there is a cheap method of packing the commands in this way once again without having to move the timers back to the full speed DDR_CK clock rate.

The one issue remaining is the multi-port handler 'BrianHG_DDR3_COMMANDER.sv'.  It's current FMAX has trouble passing 130MHz if it is configured with 2x128 bit read, 2x128bit write ports, all smart options enabled @ TC85 degrees.  I'm thinking of a way to get this one to compile robustly above 150MHz without any big compromise so you may at least use it with ram running at 300MHz and half rate.  Right now, it can work fine at 75MHz, or even at 100MHz with the ram at 400MHz.  (This means no timing violations at any temperature.  The 130MHz builds always work error free at 150MHz, but this is not what we want.)  If I cannot come up with a solution, I will leave it as it is and create a secondary FAST multi-port handler 'BrianHG_DDR3_COMMANDER_fast.sv' which will be a strict 2 read, 2 write port device targeting a 200MHz FMAX allowing half-rate support with 400MHz ram.  This multiport will be designed to be chain-able where you can use 3 of them to give you 4 read, 4 write ports, or 7 of them for 8 read, 8 write ports.

Note that the Altera's Cyclone & MAX FPGA fabrics are really slow and low power, my current code would probably be at least 50% faster on other vendor's FPGAs, or even Altera's Arria/Stratix FPGAs.  Achieving a full consistent 400MHz core builds without the paid version of Quartus for manually placing cells, even though that portion is truly only software serializers & IO port controller is still difficult as it still has to be controlled by a 200MHz section and bridge the 2 clock domains in both directions.

Have you thought about hosting the code on GitHub? I bet a lot of people would find your work very helpful, and that would be an easy and free way to distribute it more widely than on this forum. In any case, amazing work!

We'll see in a few days after I release v1.00.
I never used GitHub before and would probably need to venture around first.

                                  
    400MHz/800MTPS, Zero timing violations with 85C model   
                                  



V1.00 coming...
Just cleaning up and increasing the clearance by a bit more...

Slowest fabric -8 build using the device 10M50DAF484C8GES set to 300MHz.



Note that the DECA eval board uses the fastest -6 Max10 fabric.
Note that Altera doesn't support DDR3 on -8 Max10/Cyclone V FPGA as the DDR buffer transceivers max out at 550MTPS instead of the required 600MTPS.  Though, my source code has the 'DDR_TRICK_MTPS_CAP' parameter function to allow you to get around this (used to break Quartus' 600MTPS limiter on my 800MTPS builds), otherwise, you could not do a full compile.  (The fitter and timing analyzer still performs the rest of their function properly recognizing the requested true 300MHz core frequency.)

Yes, you can now have a DDR3 controller on any slowest -8 Cyclone III / IV / V / Max10.

That's really impressive for Cyclone devices. 

LOL, Cyclone III/IV has the fastest fabric in the series and can outperform Max10 & Cyclone V.  IE, it should compile with better FMAX than what I have accomplished here, though it's only about 10% faster.

It's been hell.
I've started our around 2 months ago with something which only occasionally worked after each build, even when under clocking the DDR3 at 250MHz.

Then, the 300MHz got a little more stable, but 350MHz was a fluke and I got to see 400MHz initialize once as well as a 450MHz fluke with horrible FMAX report and no other code in the FPGA like the graphics geometry engine and video output.  Once I begun with the 1080p output, it took a few weeks to stabilize the 300MHz, but adding the ellipse geometry unit killed that.  500Mhz was a fable dream.

Finally, 300MHz was stable and 350 not too reliable while 400 was dead until last week.  Some concentration and fine tuning, now 400MHz is a breeze and 300MHz is a given.  Even 500MHz surprisingly worked first shot, though, right now, 450MHz has a weird addressing bug, but it's not with the DDR3 controller, but in the extended 16 read/write channel multiport front end.

I'm almost done with some final tests and tweaks, I should have a rev 1.00 out in a day where it's only limiting factor is the top FMAX speed of the 16 channel multi-port module.  It looks like the best solution here will be to make an alternate fast strip-down version with 2 read, 2 write port designed for speed and pyramid style stacking support so you can have as many ports as you like, though ports deep in the pyramid will have an extended sequential pipe delay.  Stack it the way you like and you can have at least 1 read & write port right next to the DDR ram controller with a single pipe stage.

Latest version of the project tested and working fine on the DECA at 500MHz!!!!! 

https://youtu.be/a1k106CNylI

Tried the 500MHz version in my DECA10 and it worked flawlessy. Looking formward for the 1.0 release. I plan to make a VHDL wrapper for it. Congratulations!

Ok, Cyclone III and Cyclone IV compiles and reached a true 400MHz FMAX.

But for some FN reason, Cyclone V's PLL isn't compatible with Cyclone III/IV/10 LP/Max 10/Arria II.

Yes, there is a different PLL megafunction dedicated just for the Cyclone V.  If I use the normal 'altpll', it wont support phase stepping on a Cyclone V.  So, I need to use Cyclone V's 'altera_pll' function which uses a shit load of strings to define it's settings and yet still has the same identical phase step tuning function as the 'altpll' other than it has many more clock outputs.  Something which I might not be able to handle with my current parameters auto-pll generator system.

Altera drives me nuts.  Max 10 will simulate and compile correctly using the old 'altddio_bidir', but will not output anything unless you use the new 'altera_gpio_lite'.  Cyclone V needs the new PLL, and at least wont compile, but uses the old 'altddio_bidir', but the Max 10 uses the old PLL but new IO scheme...

Once I get the Cyclone V pll working and test the FMAX, I'll upload V1.00.

V1.00 update.

Ok, I got a Cyclone-V-6 to run at 300MHz, just barely with advanced smart banking feature in the multiport module disabled.  (The stand alone DDR3_PHY ram controller can still run at 400/200MHz and it's smart bank management is always enabled.  It's been designed to run at speed on the most pathetically slow FPGA s ever...)

I'll stick V1.00 here, document the updates and upload 1.00.

My DDR3 PHY stand-alone controller can do over 300MHz easy on the C-V -6, it's just the multiport hub which has a devastating FMAX of 50% speed.  I'm also going to upload it to Intel's support with the C-IV-6 versions and ask why there is such a huge speed difference.

Setting up it's PLL was a nightmare with built in system bugs, parameters as fancy non-standard string types & the compiler simplifying out some crucial clocks which I needed to invent multiple work arounds.

V1.00 coming tonight...

So, reporting back somewhat later than I expected, I have the bouncing ellipses running on the screen at 1080p, and it's FREAKING AWESOME 

Regarding the blue eye-destroyers, LEDs 3 through 7 are lit

BrianHD_DDR3 V1.00 system FPGA utilization reports:

300MHz_PHY_only.png - DDR3 controller with 1 read & write port to an 8 bit device build.


300MHz-8_ellipse.png - DDR3 controller random ellipse project with 4 ports, 128 bit access, 300MHz Max10-8.


300MHz_ellipse.png - DDR3 controller random ellipse project with 4 ports, 128 bit access, 300MHz Max10-6.


400MHz_ellipse.png - DDR3 controller random ellipse project with 4 ports, 128 bit access, 400MHz Max10-6.


450MHz_ellipse.png - DDR3 controller random ellipse project with 4 ports, 128 bit access, 450MHz Max10-6.


500MHz_ellipse.png - DDR3 controller random ellipse project with 4 ports, 128 bit access, 500MHz Max10-6.



I've included a few builds.  You will notice that the LC/LUT increases with frequency.  This is most likely the compiler adding duplicate parallel logic cells to improve FMAX timing.


I highlighted the 'BrianHG_PHY_SEQ' module which tells you the full LC/LUT count is you were to build a stand-alone 1 read/write port DDR3 controller.

The COMMANDER module is the multiport handler configured with 2 read and 2 write ports in the ellipse demo.

OMG, learning how to use Github with it's esoteric project generation and file entry is not treating me well.  I'm wondering if it is worth the hassle.

On github just create a new empty repository (in the menu on the top right of the web page). Hit the green CODE button and copy the ssh URL you find there there.

In your local git repo type "git remote add github <url>" then "git push github"

If you don't already have a local git repo then that's the first step. cd into your project directory and type "git init" and then "git add FOO" where FOO is a file or directory or whitespace separated list of files or directories. Repeat for everything you want sent to github i.e. source code and config files, not output files. Then type "git commit -m 'Initial commit'". And then follow the instructions above to deal with github.

If you don't already have a local git repo then that's the first step. cd into your project directory and type "git init" and then "git add FOO" where FOO is a file or directory or whitespace separated list of files or directories. Repeat for everything you want sent to github i.e. source code and config files, not output files. Then type "git commit -m 'Initial commit'". And then follow the instructions above to deal with github.

What do you mean by ', not output files.'?

For example, my Quartus projects do have some binary files and may include a hex file.

Also, when I copy and paste ASCII files/show readme files, why does all my carriage returns disappear?

Quote from: brucehoult on August 29, 2021, 02:48:14 am

If you don't already have a local git repo then that's the first step. cd into your project directory and type "git init" and then "git add FOO" where FOO is a file or directory or whitespace separated list of files or directories. Repeat for everything you want sent to github i.e. source code and config files, not output files. Then type "git commit -m 'Initial commit'". And then follow the instructions above to deal with github.

What do you mean by ', not output files.'?

You don't include output files in a SOURCE CODE control system because they are not source code. The outputs of compilation or synthesis and routing, or whatever it is your project does (I'm talking in general terms here) change every time you run the build process. AND anyone who checks out the project will generate them themselves, from the source files.

If you want to put bitstreams or something somewhere so that people don't have to run synthesis themselves, that's a binary release, which is a different thing. Github has a different place to put releases (or you can put them on any web or ft server etc).

For example, my Quartus projects do have some binary files and may include a hex file.

If those are inputs to the process then that is fine.

Also, when I copy and paste ASCII files/show readme files, why does all my carriage returns disappear?

What do you mean "copy and paste"?

Whatever you put into git comes back out absolutely byte identical to what you put in. There is no line ending translation. Git handles binary files just fine, and in fact treats text as binary e.g. diffs are by bytes not lines.

Ok, nice.  I went to Google tutorials on the tool.  Fine.  But still, just even the setup for TortoiseGit is super esoteric.  It's like I'm going back to the 90's with systems setups designed for insiders only.  A putty setup enviroment and public/private key generation + paste and copy URL address from my web browser display status of my generated repository into TortoiseGit.  Seriously, it's 2021.  Could you imagine having to go through this trouble to securely purchase anything on Amazon?

Still, it looks like I'm going to end up using TortoiseGit.

This is a typical example of what happens when you let developers design a user interface. Even after using it for many years professionally, I still stumble upon it every once in a while.

Finally!!!!  (Damn javascript bug finally bypassed...)

My GitHub repository release:
https://github.com/BrianHGinc/BrianHG-DDR3-Controller

Brian play with Gowin too, they are the cheapest,  also they promised to spin out a new chip this year with 12Gb SERDES and internal DDR4 Memory!

If anyone has seen some cheap or free Lattice ECP5 LFE5U-25/45/85F boards with at least 1 16 bit DDR3 ram chip and preferably and HDMI output, please link them here...

Free?

There are very few boards with an ECP5. You have the Lattice dev boards, but they all come with an LFE5UM AFAIR.
Then there is the ULX3S, but no DDR3, just SDRAM. Also boards I mentioned earlier (which are repurposed boards from Colorlight) that you can find on Aliexpress. I have a couple. They are fine. HDMI connector, but no DDR3, only SDRAM...

One such board is the OrangeCrab, ECP5-25F, 1Gbit DDR3, no HDMI connector though, and limited IOs: https://1bitsquared.com/products/orangecrab

I don't know of anything else on the market at the moment.

I am not interested in the LFE5UM as those require a Lattice Diamond License and the goal of my DDR3 controller is to offer a free solution for the most affordable Lattice components.

Zero idea about Lattice licensing, but the TrellisBoard has a LFE5UM5G-85F and is usable with the Yosys opensource toolchain, including the DDR3 SDRAM. So is the ECPIX5, which (unlike the TrellisBoard) is commercially manufactured.

The FOSS toolchain might not be able to reach the performance of the Lattice toolchain, but might be an interesting option to try nonetheless.

Just adding a quick note about Yosys here, as this post finally decided me to take the plunge.

So, using the latest GHDL, Yosys, Prjtrellis and Nextpnr from git (warning: Yosys/Prjtrellis/Nextpnr take a fair amount of time to build from source), I was able to generate a .bit file from VHDL source files (+.lpf constraint file). The only modification I had to do was on the .lpf file, as nextpnr doesn't support port groups yet (which kind of bites, but that's not a dealbreaker). But all in all, it was smoother than I feared.

What I can say at this point is that Fmax is higher than what I get with Lattice Diamond for the design I tried, but I didn't dig enough to figure out if nextpnr is just being more optimistic, or if it indeed yields faster logic. This was a relatively simple design too, so that may not be as good for larger designs. Another point is that it all runs much faster than the commercial tools (but again, this is probably due, at least partly, to the fact that optimization is less aggressive.)

As I said, I don't know if SV support in Yosys is enough for Brian's work, but it could be worth a shot. With recent versions of GHDL and the combo with Yosys, VHDL support has become pretty good. So now, I'm curious to try this with larger designs.

It's interesting. But beyond performance, there are other issues to consider. AFAIK, BrianHG uses SystemVerilog for his developments, and currently, Yosys only supports a subset of SV. I would expect a number of problems trying to compile his code with Yosys. Nonetheless, you can have a look there to check what could possibly be a problem, although they mention supported features - not the ones that aren't, and there are probably many - so I guess it'll be hard to tell before actually trying: https://github.com/YosysHQ/yosys

My SystemVerilog coding relies on 2 dimensional arrays for IO ports and 'genvar/generate/if' to render repetitious instances of a single module, each one pointing to incremented dimension in one of my 2D arrays.

Also, I use the attribute ' (*preserve*) logic [ x:x ] var_name [ 0:x ] ; ' to force the compiler to not simplify out that particular register bundle, force it to use logic cells to aid in speed optimization.

I also use parameters and localparams, with string support and have a number of 'task' in a few places.

If it can handle these plus 'if (x=y) $stop', 'if (x=y) $error' and '$display ("msg")' or '$warning ("msg")' during compile time, my code should work.

If 'yosys' can handle this much, then the rest of my code operates down at a simplistic regular 'Verilog' level and it should work.  (IE: I went to SystemVerilog exclusively for the 2D interconnected IO ports capability.)  The dumber the compiler, the better FMAX you can expect from my coding style.  (IE: Cranking up Altera's Quartus 'speed' optimizations to the max actually slows down my designs, optimize for Area and my FMAX usually goes through the roof...)

The problem is how many Lattice users use 'yosys' and with a fresh Win7 install and nothing else, can I get it running, or, do I require other utils and need to build it on my system?

LOL, the ~150 stock of Arrow Deca boards for the last 6 months have just all sold out in 2 days.

Well, I guess we'll now get to see if they were just selling off old stock to get rid, hence the low price, or if more will become available...

Ok, I thought some may want to know about DDR pin planning in Quartus.

I've attached 2 screenshots of Quartus' pin planner, 1 for Cyclone_IV and 1 for Max_10.

You will see that I have chosen x8 devices even though we are suing an x16 DDR3 ram chip.  I have done this since the x16 DDR3 actually has 2 groups of DQS basically making it 2 x8 devices.

Here is the Max_10 device:


As for the Cyclone_IV (included Cyclone III), you will notice that there exists the DQS, but not a DQS_n.  My DDR3 ram controller will still work, however, it requires you connect the DDR3's DQS_n to the adjacent DQS IO within the same x8 bank.  Preferably a emulated differential pair as long as it is within the same IO bank, even if it isn't highlighted as being part of the same x8 group.  (Quartus' reported polarity of this differential pair doesn't matter.  So long as the DQS pin is connected to the DQS on the DDR3 and the differential pair gets connected to DQS# on the DDR3 even if Quartus' pin planner says that the x8 DQS pin is the negative part of the differential pair.)


The data mask pins also need to be placed inside the same associated x8 group.

Remember to check the data sheets as some older Cyclones have higher IO performance on the top and bottom rows compared to the left and right sides.  You want to use the higher speed performance IOs.

The CK and CK_n pins should be a differential pair close to the center of everything if you are using more than 1 DDR3 ram chip, otherwise, either end or center will do.

Note that the MAX_10 devices as well as Cyclone_V do have a dedicated CK and CK_n pin for DDR3.  You will need to use these for your DDR3 CK/CK_n if you want full compatibility with Altera's DDR3 controller.

Download Arrow DECA's schematics to get a complete example of the DDR3 wiring.

Amazing work and thanks for sharing Brian!

I hope in the near future I will have the time and courage to finally start toying more seriously with the FPGAs and DDR3 will definitely come into play then.  Now back to my flat reconstruction and electronics lab rebuild.

@Wiljan, one mistake:

just do everything in the  'BrianHG_display_Wmem' with the knowledge that you will start and stop every 4 pixels on the x axis for 32bit color.

My mistake, I forgot that you have the 'write mask' capability which will allow pixel precision writes down to 8 bit pixels while still using my multiport in 128bit mode to retain full sequential burst speed.  It's only the question of 128bit/4 pixel horizontal alignment.  There are ways to solve this as well at the CMD_CLK stage with a 4 position 224 bit to 128 bit shift register.

It is better to try to do any cropping and computation in the CMD_CLK domain while the sampler input to the dual port line buffer memory should have absolute minimal logic.

@BrianHG

I been trying over the weekend to make some simple tweaks just to see I actually get something into the FPGA over HDMI

I did remove the RS232 debug part

Changed the GPIO's to only input

Control signals from the HDMI board goes to LED

To be sure freq are not a problem I a 800x600@60 HDMI input (instead of 1920x1080@60)
I can messure the  PIXCLK, H,V, on the LED with a Scope so I for sure have some input the board

(no FIFO yet )

I tried to than just write to the DDR

• based on the PIXCLK and expected to see some garbage on the output... none, just the internal test signals.

I tried to write fixed 128bit  FF's to the DDR  based on the CMD_Clk still no garbage on the output just test signals

I have removed the Scroll and have fixed 0x0000, 0x0000 to be sure I do see top let (0,0) on the output

I tried to reduce the DDR to only use 1 read port .... then the test signal goes Red so I must must miss to change some signals so I back on 2xR and 2xW

So to be honest I have to say I'm bit stocked right now and could use some inspiration, are there any chance you could make the skeleton to feed in the external HDMI?

I will post some images how I have connected the hardware if other could be interested to have external HDMI input to the DECA board

Thank you
Wiljan

So to be honest I have to say I'm bit stocked right now and could use some inspiration, are there any chance you could make the skeleton to feed in the external HDMI?

Take a look at the 'BrianHG_DDR3_DECA_Show_1080p' project.  That project just displays ram at 1920x1080.
Like I said, I made this stuff for everyone to figure out.

It's not too difficult.  You will make it.  Begin with just getting 1 picture onscreen.  Just take a look at my module which writes draws graphics.  It's only if you have multiple 1080p signals simultaneously, writing 32bit pixels will be too slow at the 100MHz bus.  This is why I mentioned writing 128bits at a time which means writing 32bit pixels are at 4x speed.

Note that my ellipse drawing engine has an X/Y coordinate to address generator which is a little complex.  You do not need to go this far.  You only need a reset X&Y position, and add the Y coordinate by a fixed amount once every HS.  The address counter adds for every pixel written to create the X axis.

To begin, try a 720p or 480p source image to sample and copy my 32bit pixel write mode in the ellipse drawing engine.

It's fine to post results / examples and things you created with my DDR3 controller here.

If you are looking for in-depth help on coding techniques for sampling video, make a separate new thread as this thread should stick with my DDR3 controller issues or results/success stories.


BTW, with a Cyclone III of similar size to the DECA's MAX10 and DDR2, I did make a complete 2 video in, 1 video out scaler with PIP, each window crop-able and zoom in and out with test patterns, bi-linear filtering and picture enhancement and color processing, controlled through ethernet.  Though, the DDR2 bus width was a 128bit wide ram module, not a single 16bit wide chip.  I guess at 500MHz with 16bit color instead or 32bit color, you could achieve the same with the DECA board.

Some progress, even I'm out of time at the moment
1 x 800x600@60 is feed in

 There are some small error here and there but at least image on the output 

Wow, a 90 degree rotate.
The nasty non-sequential access preventing clean long bursts must be a killer unless you have worked around that.  I know a number of dedicated ways to work around this and get full performance, but they are advanced techniques.  For a first timer, even with small errors, that is still a great start.

Is that real-time?
Double buffered?

Wow, a 90 degree rotate.

Is that real-time?
Double buffered?

No double buffer, I write directly to 2 x 32bit ports where I have swapped the x1, y1 on the rotate one.
Real time, maybe... had no time to test with moving video yet, will not be home until next week

Hi Brian I'm back and I have made some changes.

SignalTap is very useful, thank you for mentioned it 

Tested with mowing video and the Rotate was now where real time ... right now I'm not interested in Rotate but 2 straight inputs
But for sure I would like to scale and rotate later

I have removed the flat cable and added in single wires (same length) so fit GPIO's
I have 2 HDMI inputs running 1920x1080@60 non sync in parallel from 2 BrighSign players

I place the 2 inputs side by side on the 4K buffer and can scroll to see the Left / Right transition and it pretty OK
I had some PSU issues and have spitted to more PSU's to avoid interference

I do have some noise here and there in the picture ... you can see in the black hole on the video
Not sure why, but I suspect the "wires" and potential wrong terminations

I would like to write to the DDR as 128 bit instead of 32 bit to lower the traffic to the DDR

Attached is the Quartus project

Link for video

Played half the day with your DDR3 controller on a DECA board and just wanted to say thank you for that absolutely brilliant piece of work!

What does it mean by 500MHz DDR_CK, Half Rate 250MHz Multiport ?

I wonder if I could achieve a 'Full-rate' controller at 300MHz.  Having a user 300MHz reading/writing 32bits data can generate perfect ~98% DDR3 data bus saturation consecutive bursts with a 16bit ram, good for 300MHz 32 bit cpus.

What do you exactly mean by Half-rate means my controller will accept a new command once every second DDR_CK clock. ?

Yes.

Half-rate means 2 things.  When the DDR3 is being run at 400MHz, (a) the processor which accepts user commands and (b) spits out DDR3 commands is running at 200MHz.  This part of my controller has always operated at half-rate.  The controller provides a busy signal if there are mandatory command delays required by the DDR3 and it's input buffer memory has exceeded it's stack.  Only my user multiport interface has been running in quarter-rate mode due to it's multiplexer complexity which I am currently enhancing performance there.

I only have a tiny pin driving command timer running at the DDR3 400MHz which receives the stream of generated commands from the above 200MHz controller called 'BrianHG_DDR3_CMD_SEQUENCER.sv', simulated by the 'BrianHG_DDR3_CMD_SEQUENCER_tb.sv'.

Quote

When the DDR3 is being run at 400MHz, (a) the processor which accepts user commands and (b) spits out DDR3 commands is running at 200MHz.  This part of my controller has always operated at half-rate.

However the problem with using half-rate on the commands will result in DDR3 manufacturer timing violations.  For example, given that your DRAM is accepting an incoming 400MHz ck signal, but the DDR3 commands is arriving to the DRAM at a rate of only 200MHz.  This will cause issue such as tMRD violation where the DRAM is getting 2 consecutive MRS commands.

Please correct me if wrong.

No.  I have a command output section running at the full 400MHz.  That section has a 2 word fifo which takes in the stream of commands generated at 200MHz by the 'BrianHG_DDR3_CMD_SEQUENCER.sv' processor and outputs 1 DDR_CK wide commands at 400MHz.  Before sending out each received command in that 2 word 200MHz in, 400MHz out FIFO, it uses a look-up table to see how many clock cycles since any previously sent commands to know when it may be permitted the insert the next new command.

I pipe enqueue multiple user request commands.  There are situations where a new bank may be activated while a previous write was just sent and a current burst is taking place.  This activate command is allowed immediately after the previous write command.  Without the 2 word FIFO, I will always have a 'NOP' between that write and activate since I can only generate 200 million commands a second.  This allows stuffing commands where permitted on either immediate or odd DDR_CK clock cycles.  Enlarging that fifo to say 4 words would allow for typically the most compact command sequences possible being sent to the DDR3.  With a simple 1 word latch, commands will typically be spaced out on at least every 2nd DDR_CK.  For my design, the type of FIFO I need, FWFT type with acknowledge, has difficulty routing the acknowledge tied to 7 individual DDR3 command timers operating at 400MHz on Altera Cyclone devices.  My 400MHz side doesn't care about the commands it receives, only that each DDR3 command has a different set amount of time for each other possible new command coming in and it is not allowed to violate those minimum delay clock cycles depending on the next command to be sent.

You could say because of my mid FIFO, if it were a bit larger like 4 words enqueue, I have designed a hybrid half-rate controller with a full-rate controller's performance.  But with 2 words, I'm sort of stuck half way in-between where some situations are taken advantage of while others arent.  One thing I cannot fix it the 'skew' or delay between receiving a user command and the length of pipe time it takes to get that command out to the DDR3 as my 'command sequencer' section is a 3-5 clock pipe running at 200 MHz.  (I have optimization parameters which can combine pipe stages at the cost of FMAX or FPGA size.)

I pipe enqueue multiple user request commands.  There are situations where a new bank may be activated while a previous write was just sent and a current burst is taking place.  This activate command is allowed immediately after the previous write command.  Without the 2 word FIFO, I will always have a 'NOP' between that write and activate since I can only generate 200 million commands a second.  This allows stuffing commands where permitted on either immediate or odd DDR_CK clock cycles.

Could ACTIVATE command for a new bank be issued to DRAM when a write burst for other bank is still ongoing ?
A check on ACTIVATE timing does not suggest so though.

Besides, why odd DDR_CK clock cycles when 2 words depth FIFO is used ?

Enlarging that fifo to say 4 words would allow for typically the most compact command sequences possible being sent to the DDR3.  With a simple 1 word latch, commands will typically be spaced out on at least every 2nd DDR_CK.

Why 4 words depth FIFO does not have the every 2nd DDR_CK concern ?

You could say because of my mid FIFO, if it were a bit larger like 4 words enqueue, I have designed a hybrid half-rate controller with a full-rate controller's performance.  But with 2 words, I'm sort of stuck half way in-between where some situations are taken advantage of while others arent.

I am confused with which other situations are not taken advantage of ?

You could say because of my mid FIFO, if it were a bit larger like 4 words enqueue, I have designed a hybrid half-rate controller with a full-rate controller's performance.  But with 2 words, I'm sort of stuck half way in-between where some situations are taken advantage of while others arent.

Which other situations are not taken advantage of ?


I understand that you are using synchronous FIFO in the above case of in-between commands. 
However, what about synchronizing asynchronous incoming multi-bits DQ signals from DRAM into FPGA ?
I suppose you would need an asynchronous FIFO ?

You could say because of my mid FIFO, if it were a bit larger like 4 words enqueue, I have designed a hybrid half-I understand that you are using synchronous FIFO in the above case of in-between commands. 
However, what about synchronizing asynchronous incoming multi-bits DQ signals from DRAM into FPGA ?
I suppose you would need an asynchronous FIFO ?

Actually, for the DDR DQ, in my 400MHz command out section, I decode the instructions being sent out to detect when a read or write command is being sent.  That r/w decode will schedule my read data and write data FIFO serializers to send or capture / receive DDR data at the right time.  It is the job of my controller to make sure the write data is ready for the write by the time the write data needs to be sent.  For the read, well, if you miss it when the acknowledge / read data ready comes in, you missed it.

Next I will make my own sync generator and replace the DECA example junk.
Fix a bug where only the current display mode of 1080p@32bit color functions properly.
And remove the 1-line dualport buffer for a minimal sized dual-port ram.

Quote

I pipe enqueue multiple user request commands.  There are situations where a new bank may be activated while a previous write was just sent and a current burst is taking place.  This activate command is allowed immediately after the previous write command. 

Could the same bank interleave mechanism happen for write operations ?
And if yes, then I suppose there is no need for such pipe enqueue stuff ?

Quote

every-time you switch between a read burst and write burst, there are a few dead 0 access clock cycles as the DDR3 needs time to transition from input to output.

Why few dead 0 access clock cycles ?

#1, Yes.  Opening and closing banks are separate of read and write data into any bank's activated row.  You may mess around with all other banks while you still are reading / writing on a different bank, or, at least give enough time for an ACT to become ready.
#2, Read the god damn DDR3 data sheet!  They have example illustrations on switching between read and write called read-to-write and write-to-read operations.  There are mandatory empty cycles as the DQ buffers and DQS switch direction and the DDR3 ram chip row amplifiers change drive current into the memory cap arrays.

Quote

During an unbroken burst, you send a command every 4 clocks to maintain optimum efficiency.  This means with a full rate controller, you can stuff 3 new commands in-between.  With a half-rate controller, your controller can only be fast enough to add 1 command in-between. 

I think the number of in-between commands shall not be limited by whether it is full-rate or half-rate controller.
Since it would only be using simple if-else clocked logic (inside fast clock domain, maybe 500MHz in your case), your controller should be able to achieve such goal without suffering from STA setup timing violation.

Please correct me if wrong.

  Ok, I have given you plenty enough already, just read my previous posts as the answer lies within.
Please stop asking for guidelines for altering your DDR3 controller here on my thread with my finished DDR3 controller.

    This thread is for those who have issues or need help implementing 'MY' controller in their designs, and, for those who wish to share their success stories & examples implementations using my DDR3 controller system.

Not sure why, but Nockieboy also had some occasional missing pixels during block fills in his 8-bit GPU thread using my DDR3 V1.00.  If it is actually the same problem, when we updated to V1.50 on the 8-bit GPU thread, all empty pixel fills disappeared.  (Improved multiport design...)  Note that with 1.50, if you need to be backwards compatible to the old separate read and write ports, just hard wire the write enable on 2 separate ports and you will achieve the same function.  And, don't forget to ASSIGN '0' to all the unused inputs as shown in my new simplified block diagram.

Thank you for letting me know, that similar issues has been observed.

The project I was working on was to determinate if a video clip played across 2 HDMI output on the same PC card actually was in sync.

The HDMI output it was processed through several video processors as 2 individual signal and ended up on a a huge LED wall (20m wide x 3 m height) working in 5 zones (processors).

So when I saw your DDR3 /  HDMI output and I already did have the 2 HDMI input board where I have used a scope to measure the 2 x V-Sync which was perfect in Sync, I got the idea to make the  HDMI splitter showing half of HDMI A and half of HDMI B on the same HDMI output.

Due to it was not perfect working in time, We ended up using 2 x Bacho multi-format converter HDMI to SDI (you can convert across all frame-rates / resolution) so it doe have a full frame of memory inside ,,, also here we saw the sync issue on fast horizontal moving content, we desired to record the 2x SDI on some broadcast recorders and try to analyze frame by frame, at the time we also added in external gen-lock for the 2 Barcho units... and the problem was gone.
This confirmed the video out of the PC was perfect in sync 

So right now the there are no need for the setup anymore. however I would like for my own exercise try the 1.5 when I get some time over Christmas.

If there still are noise I will also try to "loop" HDMI input to HDMI output via the FPGA to see if the noise goes away

But I'm aware that the wiring I  have are no good for a reliable solution, I did even think if it would be work to make a PCB shield fitting the DECA board with 2 HDMI input , on the other hand you can buy cheap 4x 2k input to 1x4k output splitt units and some of them have quite many features

Quote

This confirmed the video out of the PC was perfect in sync 

This depends on videocard type, drivers and settings/selected video modes, it is not guaranteed.

Absolutely .. it's a AMD dual head, and it was here all the discussion started if the problem was on the PC side or on the Wall side (I was in charge for the PC side) and a 3. party on the Wall side

I have a big interest in video processing, been working with broadcast for 30+ years 

Wanted to get serious with the BrianHG_DDR3_CONTROLLER after just playing (impressed  ) with it. Tried to replace a UniPHY DDR3 controller in one of my existing designs with it today, but failed miserably.

I'm a VHDL guy and it seems interfacing SystemVerilog designs with VHDL isn't really fully supported in Quartus. I implemented a VHDL component representing the BrianHG_DDR3_CONTROLLER_top module on the VHDL side that has the SystemVerilog parameters as VHDL generics but wasn't successful. It appears that it is not possible to map SystemVerilog parameters of any other types than plain integers or bit vectors.
E.g I was expecting that it should be possible to map a SystemVerilog bit parameter (as BHG_OPTIMIZE_SPEED) into a VHDL BIT generic, but all I get is
Error (10258): Verilog HDL error at BrianHG_DDR3_CONTROLLER_top.sv(116): unsupported type for Verilog parameter BHG_OPTIMIZE_SPEED
Tried to use an integer generic in the VHDL component instead. This was accepted on the VHDL side, but then failed on the SystemVerilog side as an invalid type.

Apparently, it is not possible to pass the SystemVerilog parameters as VHDL generics, so one either needs to do the parametrization on the SystemVerilog side or modify the interface.

Anybody more successful than myself in interfacing to VHDL?

@mfro, one thing you can try is to Quartus to 'generate' a verilog instantiation template file for my project.  The new .v generated by quartus re-write the parameters in the older style calling my SystemVerilog module.  Maybe it will be easier to call that new .v from VHDL instead of my direct SystemVerilog.

Though, once you see how Quartus rewrote the parameters, maybe that will give you a clue on how to directly feed my module in VHDL.

Also, do not forget the reverse route.  Just make my wire my top design to the FPGA as I have in the examples, and within that, initiate the rest of your VHDL project inside the FPGA top.sv with all the CDM_xxx and other FPGA IO ports wired to your VHDL instantiation in the top.sv.

@mfro, one thing you can try is to Quartus to 'generate' a verilog instantiation template file for my project.  The new .v generated by quartus re-write the parameters in the older style calling my SystemVerilog module.  Maybe it will be easier to call that new .v from VHDL instead of my direct SystemVerilog.

Doing a generate VHDL instantiation creates this file on one of my new projects: GPU_DECA_DDR3_top.cmp

-- Copyright (C) 2020  Intel Corporation. All rights reserved.
-- Your use of Intel Corporation's design tools, logic functions
-- and other software and tools, and any partner logic
-- functions, and any output files from any of the foregoing
-- (including device programming or simulation files), and any
-- associated documentation or information are expressly subject
-- to the terms and conditions of the Intel Program License
-- Subscription Agreement, the Intel Quartus Prime License Agreement,
-- the Intel FPGA IP License Agreement, or other applicable license
-- agreement, including, without limitation, that your use is for
-- the sole purpose of programming logic devices manufactured by
-- Intel and sold by Intel or its authorized distributors.  Please
-- refer to the applicable agreement for further details, at
-- https://fpgasoftware.intel.com/eula.


-- Generated by Quartus Prime Version 20.1 (Build Build 720 11/11/2020)
-- Created on Sun Jan 09 12:32:21 2022

COMPONENT GPU_DECA_DDR3_top
GENERIC ( GPU_MEM : INTEGER := 524288; ENDIAN : STRING := "Little"; PDI_LAYERS : STD_LOGIC_VECTOR(3 DOWNTO 0) := b"0001"; SDI_LAYERS : STD_LOGIC_VECTOR(3 DOWNTO 0) := b"0100";
ENABLE_TILE_MODE : STRING := "A(1,0,0,0,0,0,0,0)"; SKIP_TILE_DELAY : std_logic := '0'; ENABLE_PALETTE : STRING := "A(1,1,1,1,1,1,1,1)"; SKIP_PALETTE_DELAY : std_logic := '0';
HWREG_BASE_ADDRESS : INTEGER := 256; HWREG_BASE_ADDR_LSWAP : INTEGER := 240; PAL_BASE_ADDR : INTEGER := 4096; TILE_BYTES : INTEGER := 65536;
TILE_BASE_ADDR : INTEGER := 16384; FPGA_VENDOR : STRING := "Altera"; FPGA_FAMILY : STRING := "MAX 10"; BHG_OPTIMIZE_SPEED : std_logic := '1';
BHG_EXTRA_SPEED : std_logic := '1'; CLK_KHZ_IN : INTEGER := 50000; CLK_IN_MULT : INTEGER := 24; CLK_IN_DIV : INTEGER := 4;
DDR_TRICK_MTPS_CAP : INTEGER := 600; INTERFACE_SPEED : STRING := "Half"; DDR3_CK_MHZ : INTEGER := 300; DDR3_SPEED_GRADE : STRING := "-15E";
DDR3_SIZE_GB : INTEGER := 4; DDR3_WIDTH_DQ : INTEGER := 16; DDR3_NUM_CHIPS : INTEGER := 1; DDR3_NUM_CK : INTEGER := 1;
DDR3_WIDTH_ADDR : INTEGER := 15; DDR3_WIDTH_BANK : INTEGER := 3; DDR3_WIDTH_CAS : INTEGER := 10; DDR3_WIDTH_DM : INTEGER := 2;
DDR3_WIDTH_DQS : INTEGER := 2; DDR3_RWDQ_BITS : INTEGER := 128; DDR3_ODT_RTT : INTEGER := 40; DDR3_RZQ : INTEGER := 40;
DDR3_TEMP : INTEGER := 85; DDR3_WDQ_PHASE : INTEGER := 270; DDR3_RDQ_PHASE : INTEGER := 0; DDR3_MAX_REF_QUEUE : STD_LOGIC_VECTOR(3 DOWNTO 0) := b"1000";
IDLE_TIME_uSx10 : STD_LOGIC_VECTOR(6 DOWNTO 0) := b"0001010"; SKIP_PUP_TIMER : std_logic := '0'; BANK_ROW_ORDER : STRING := "ROW_BANK_COL"; PORT_ADDR_SIZE : INTEGER := 30;
PORT_TOTAL : INTEGER := 5; PORT_MLAYER_WIDTH : STRING := "A(2,2,2,2)"; PORT_VECTOR_SIZE : INTEGER := 16; READ_ID_SIZE : INTEGER := 4;
DDR3_VECTOR_SIZE : INTEGER := 5; PORT_CACHE_BITS : INTEGER := 128; CACHE_ADDR_WIDTH : INTEGER := 4; BYTE_INDEX_BITS : INTEGER := 11;
PORT_TOGGLE_INPUT : STRING := "A(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)"; PORT_R_DATA_WIDTH : STRING := "A(000001000,000001000,000010000,000010000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000)"; PORT_W_DATA_WIDTH : STRING := "A(000001000,000001000,000010000,000010000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000,010000000)"; PORT_PRIORITY : STRING := "A(11,10,00,00,10,00,00,00,00,00,00,00,00,00,00,00)";
PORT_READ_STACK : STRING := "A(16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16)"; PORT_W_CACHE_TOUT : STRING := "A(100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000)"; PORT_CACHE_SMART : STRING := "A(1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)"; PORT_DREG_READ : STRING := "A(1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)";
PORT_MAX_BURST : STRING := "A(100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000,100000000)"; SMART_BANK : std_logic := '0' );
PORT
(
ADC_CLK_10 : IN STD_LOGIC;
MAX10_CLK1_50 : IN STD_LOGIC;
MAX10_CLK2_50 : IN STD_LOGIC;
KEY : IN STD_LOGIC_VECTOR(1 DOWNTO 0);
LED : OUT STD_LOGIC_VECTOR(7 DOWNTO 0);
CAP_SENSE_I2C_SCL : INOUT STD_LOGIC;
CAP_SENSE_I2C_SDA : INOUT STD_LOGIC;
AUDIO_BCLK : INOUT STD_LOGIC;
AUDIO_DIN_MFP1 : OUT STD_LOGIC;
AUDIO_DOUT_MFP2 : IN STD_LOGIC;
AUDIO_GPIO_MFP5 : INOUT STD_LOGIC;
AUDIO_MCLK : OUT STD_LOGIC;
AUDIO_MISO_MFP4 : IN STD_LOGIC;
AUDIO_RESET_n : INOUT STD_LOGIC;
AUDIO_SCL_SS_n : OUT STD_LOGIC;
AUDIO_SCLK_MFP3 : OUT STD_LOGIC;
AUDIO_SDA_MOSI : INOUT STD_LOGIC;
AUDIO_SPI_SELECT : OUT STD_LOGIC;
AUDIO_WCLK : INOUT STD_LOGIC;
FLASH_DATA : INOUT STD_LOGIC_VECTOR(3 DOWNTO 0);
FLASH_DCLK : OUT STD_LOGIC;
FLASH_NCSO : OUT STD_LOGIC;
FLASH_RESET_n : OUT STD_LOGIC;
G_SENSOR_CS_n : OUT STD_LOGIC;
G_SENSOR_INT1 : IN STD_LOGIC;
G_SENSOR_INT2 : IN STD_LOGIC;
G_SENSOR_SCLK : INOUT STD_LOGIC;
G_SENSOR_SDI : INOUT STD_LOGIC;
G_SENSOR_SDO : INOUT STD_LOGIC;
HDMI_I2C_SCL : INOUT STD_LOGIC;
HDMI_I2C_SDA : INOUT STD_LOGIC;
HDMI_I2S : INOUT STD_LOGIC_VECTOR(3 DOWNTO 0);
HDMI_LRCLK : INOUT STD_LOGIC;
HDMI_MCLK : INOUT STD_LOGIC;
HDMI_SCLK : INOUT STD_LOGIC;
HDMI_TX_CLK : OUT STD_LOGIC;
HDMI_TX_D : OUT STD_LOGIC_VECTOR(23 DOWNTO 0);
HDMI_TX_DE : OUT STD_LOGIC;
HDMI_TX_HS : OUT STD_LOGIC;
HDMI_TX_INT : IN STD_LOGIC;
HDMI_TX_VS : OUT STD_LOGIC;
LIGHT_I2C_SCL : OUT STD_LOGIC;
LIGHT_I2C_SDA : INOUT STD_LOGIC;
LIGHT_INT : INOUT STD_LOGIC;
MIPI_CORE_EN : OUT STD_LOGIC;
MIPI_I2C_SCL : OUT STD_LOGIC;
MIPI_I2C_SDA : INOUT STD_LOGIC;
MIPI_LP_MC_n : IN STD_LOGIC;
MIPI_LP_MC_p : IN STD_LOGIC;
MIPI_LP_MD_n : IN STD_LOGIC_VECTOR(3 DOWNTO 0);
MIPI_LP_MD_p : IN STD_LOGIC_VECTOR(3 DOWNTO 0);
MIPI_MC_p : IN STD_LOGIC;
MIPI_MCLK : OUT STD_LOGIC;
MIPI_MD_p : IN STD_LOGIC_VECTOR(3 DOWNTO 0);
MIPI_RESET_n : OUT STD_LOGIC;
MIPI_WP : OUT STD_LOGIC;
NET_COL : IN STD_LOGIC;
NET_CRS : IN STD_LOGIC;
NET_MDC : OUT STD_LOGIC;
NET_MDIO : INOUT STD_LOGIC;
NET_PCF_EN : OUT STD_LOGIC;
NET_RESET_n : OUT STD_LOGIC;
NET_RX_CLK : IN STD_LOGIC;
NET_RX_DV : IN STD_LOGIC;
NET_RX_ER : IN STD_LOGIC;
NET_RXD : IN STD_LOGIC_VECTOR(3 DOWNTO 0);
NET_TX_CLK : IN STD_LOGIC;
NET_TX_EN : OUT STD_LOGIC;
NET_TXD : OUT STD_LOGIC_VECTOR(3 DOWNTO 0);
PMONITOR_ALERT : IN STD_LOGIC;
PMONITOR_I2C_SCL : OUT STD_LOGIC;
PMONITOR_I2C_SDA : INOUT STD_LOGIC;
RH_TEMP_DRDY_n : IN STD_LOGIC;
RH_TEMP_I2C_SCL : OUT STD_LOGIC;
RH_TEMP_I2C_SDA : INOUT STD_LOGIC;
SD_CLK : OUT STD_LOGIC;
SD_CMD : INOUT STD_LOGIC;
SD_CMD_DIR : OUT STD_LOGIC;
SD_D0_DIR : OUT STD_LOGIC;
SD_D123_DIR : INOUT STD_LOGIC;
SD_DAT : INOUT STD_LOGIC_VECTOR(3 DOWNTO 0);
SD_FB_CLK : IN STD_LOGIC;
SD_SEL : OUT STD_LOGIC;
SW : IN STD_LOGIC_VECTOR(1 DOWNTO 0);
TEMP_CS_n : OUT STD_LOGIC;
TEMP_SC : OUT STD_LOGIC;
TEMP_SIO : INOUT STD_LOGIC;
USB_CLKIN : IN STD_LOGIC;
USB_CS : OUT STD_LOGIC;
USB_DATA : INOUT STD_LOGIC_VECTOR(7 DOWNTO 0);
USB_DIR : IN STD_LOGIC;
USB_FAULT_n : IN STD_LOGIC;
USB_NXT : IN STD_LOGIC;
USB_RESET_n : OUT STD_LOGIC;
USB_STP : OUT STD_LOGIC;
BBB_PWR_BUT : IN STD_LOGIC;
BBB_SYS_RESET_n : IN STD_LOGIC;
GPIO0_D : INOUT STD_LOGIC_VECTOR(43 DOWNTO 0);
GPIO1_D : INOUT STD_LOGIC_VECTOR(22 DOWNTO 0);
DDR3_RESET_n : OUT STD_LOGIC;
DDR3_CK_p : OUT STD_LOGIC_VECTOR(DDR3_NUM_CK-1 DOWNTO 0);
DDR3_CK_n : OUT STD_LOGIC_VECTOR(DDR3_NUM_CK-1 DOWNTO 0);
DDR3_CKE : OUT STD_LOGIC;
DDR3_CS_n : OUT STD_LOGIC;
DDR3_RAS_n : OUT STD_LOGIC;
DDR3_CAS_n : OUT STD_LOGIC;
DDR3_WE_n : OUT STD_LOGIC;
DDR3_ODT : OUT STD_LOGIC;
DDR3_A : OUT STD_LOGIC_VECTOR(DDR3_WIDTH_ADDR-1 DOWNTO 0);
DDR3_BA : OUT STD_LOGIC_VECTOR(DDR3_WIDTH_BANK-1 DOWNTO 0);
DDR3_DM : OUT STD_LOGIC_VECTOR(DDR3_WIDTH_DM-1 DOWNTO 0);
DDR3_DQ : INOUT STD_LOGIC_VECTOR(DDR3_WIDTH_DQ-1 DOWNTO 0);
DDR3_DQS_p : INOUT STD_LOGIC_VECTOR(DDR3_WIDTH_DQS-1 DOWNTO 0);
DDR3_DQS_n : INOUT STD_LOGIC_VECTOR(DDR3_WIDTH_DQS-1 DOWNTO 0)
);
END COMPONENT;

It looks like Quartus knows about using the 'STD_LOGIC_VECTOR(0 DOWNTO 0) := ...
If fact, I'm assuming Quartus just made a VHDL compliant code to call my project...

In fact, they have it even simpler at:  BHG_EXTRA_SPEED : std_logic := '1';