FPGA VGA Controller for 8-bit computer

[nockieboy]

I'm trying to make a determined start on the DDR3. 

Please bare in mind that my electronics experience with RAM so far has been limited to 128KB & 512KB SRAM DIP and SOIC chips (these ones).  My knowledge and comfort zone extends to parallel 8-bit data, 16-bit address buses and no more additional complexity than RDn, WRn and CSn signals.  So when I say the DDR3 controller in Quartus looks complicated, and the DDR3 datasheet is gobbledegook, I really mean:    

The way I would approach this task is to do what I'm trying to do currently - do the schematic and board layout, worry about the HDL after.  I think the DDR3 itself is wired okay and has sufficient decoupling - it certainly follows other published designs - I just need to sort termination and some reference voltage pull-ups to some of the data lines, or something?

I'm trying to connect it up to the FPGA - you know, make progress in an area I think I can actually do something, but I've stopped here because it's likely I'm supposed to get the DDR3 controller up and running first, then let Quartus decide which pins the signals are going to be routed to.  Anyway, I've attached a PDF showing the current state of the DDR3 and the FPGA's current free pins.

So I'm looking at Banks 4A and 5B as potential candidates to connect the DDR3 to... is that right?  That would leave 4A for the DVI/HDMI output.  Or I could swap Bank 5A to 5B and use 5A for the DDR3?  I'm looking to place the DDR3 chip in the bottom-right corner of the FPGA on the board. Hopefully. 

[asmi]

Setting up a controller first is a right way to go because you can't just connect DDR3 chip to random FPGA pins and hope it will work. This applies to most high-speed interfaces, not just DDR3.

That said, I wish I could help you with setting it up, but I know nothing about Altera's IP, how it works and what kind of pinout restrictions does it have.

[BrianHG]

Ok, here is the complete GEOMETRY unit test-bench.  After all this work, I found some hidden errors in the blitter unit, so this post also includes a full update to the 'GPU_EP4CE10' project.  Please test and let me know if it works as a numerous minor 'invisible' glitches/bugs were uncovered and patched.

For the geometry test-bench, it is a stand-alone SystemVerolog project which you only need ModelSim running to run.  Just un-zip the 'GPU_GEOMETRY_Testbench_v1.0.zip', open ModelSim, select 'File - Change Directory...', then type in the transcript:
do setup.do    > sets up ModelSim
do run.do       > Re-compiles & runs the test-bench executing the default 'GEO_tb_command_list.txt'.

The results should be:
1.  A waveform with the Script_CMD and LINE# showing you all the generated waveforms.
2.  Three  .bmp pictures.
3.  A log file 'GEO_tb_command_results.txt' showing you the sent commands.

Geometry command list in the ascii .txt file:

Code: [Select]

******************************************************************************************************************
Commands: (*** No spaces allowed in any <FILE_NAME>)

[at]LOG_FILE  <FILE_NAME>            > Generates a results log file.         (No spaces allowed in file name).
[at]END_LOG_FILE                     > Forcefully closes/ends the log file.
[at]STOP                             > Stops the script processing/simulation.  Click on 'run -all' to continue script after the stop command.
[at]END                              > Ends the script processing/simulation. (You may now paint/set youw own manual controls in the waveform view and run -all)

[at]LOAD_GPU_RAM <file_name.bin>     > Reads a binary file, up to 1 megabyte, into the GEO pixel-writer memory. 
[at]SAVE_GPU_RAM <file_name.bin>     > Saves GEO pixel-writer 1 megabyte memory into a binary file.
[at]CLR_GPU_RAM                      > Clears the GPU memory

[at]CLR_BMP      <color_byte>        > Clears the test geometry_plotter bitmap memory to a set byte.  (This is not the pixel writer)

[at]SAVE_GEO_BMP   <FILE_NAME> <width> <height> <1=B&W>            > Saves a 256 color BMP picture of the geometry_plotter's output, NOT GPU Ram. Max 2048x2048.  <1=B&W> or 0 for dummy 256 color palette
[at]SAVE_PIXIE_BMP <FILE_NAME> <src/dest> <width> <height> <1=B&W> > Saves a 256 color BMP picture of the pixie-writer system GPU memory. SET_PAGET settings must be set & PIXIE must be enabled prior to draw commands.  <1=B&W> or 0 for dummy 256 color palette

[at]RESET                            > Sends a reset to the geometry unit.
[at]ENA_PIXIE <0/1>                  > Enables/disables pixel writer.  (Pixel writer is disabled by default)
[at]WAIT_IDLE <0/1>                  > Waits for the all processes to finish whatever they are currently doing before running next command. IE 1 command at a time.

[at]SEND_CMD <h0000-hFFFF>           > send a raw command, 16 bit hex value

[at]SET_XY  <x/y> <0..3> <decimal>                             > Sets 12 bit register X or Y with 12 bit decimal value 0-4095, basically calls SEND_CMD with the right value.
[at]SET_PAGET <src/dest> <base_address_hex> <width> <depth>    > Sets PAGET's (pixel address generator) source/dest   memory address, image width, color depth in bits/pixel = (1/2/4/8/16).
[at]SET_MAX_XY <x>   <y>                                       > Sets the maximum destination XY resolution.

[at]DRAW PIXEL <X>   <Y>   <c>                                          > Draws a dot at coordinates [XY], c=color(0..255)
[at]DRAW LINE  <aX>  <aY>  <bX>  <bY>  <c>                              > Draws a line from coordinates a[XY] to b[XY].
[at]DRAW BOX   <aX>  <aY>  <bX>  <bY>  <c>   <f>                        > Draws a box from top left a[XY] to bottom right b[XY] coordinates. f=fill(0/1)
[at]DRAW TRI   <aX>  <aY>  <bX>  <bY>  <cX>  <cY>  <c>   <f>            > Draws a triangle with coordinates [abc][XY].
[at]DRAW QUAD  <tlX> <tlY> <trX> <trY> <brX> <brY> <blX> <blY> <c> <f>  > Draws a quadrilateral, tl=Top Left, tr=Top Right, br=Bottom Right, bl=Bottom Left.
[at]DRAW ELLI  <Xc>  <Yc>  <Xr>  <Yr>  <c>   <q>   <f>                  > Draws an ellipse. Q=Quadrant.
                fill     = 0/1
                Quadrant = 0-3 to draw 1 of 4 quadrants.
                Quadrant = 4   to draw all 4 quadrants.

**** BLITTER must have PAGET (SRCE/DEST) set to function.

[at]BLIT TCOL  <transparent_color>         > [0.255]  Selects which color in the source image will be transparent when doing a paste when paste mask is enabled.
[at]BLIT SIZE  <px> <py> <width> <height>  > Sets the source image top left pixel position (px,py) and the copy (width,height) in pixels.
[at]BLIT ZOOM  <usX> <usY> <dsX> <dsY>     > Sets blitter zoom, us=upsample   float X/Y zooms up the SRCE image copy input   1.000000 to 4095.00000. (12 bit granularity)
                                                                ds=downsample float X/Y shrinks  the DEST image paste output 1.000000 to 0.000245.   (12 bit granularity)

[at]BLIT CONFIG  <ena>  <mask> <h-centp> <mirror> <v-centp> <flip> <r90>  <r45>

         ena       = blitter off/on             1 = blitter on when writing pixels.
                                                0 = blitter off when writing pixels.
         mask      = Transparancy mask enable.  1 = source transparent color pixels will not paste pixels onto destination, IE those colors are transparent.
                                                0 = Every pixel from the source will paste onto the destination.
         h-centp   = horizontal center paste.   1 = Offset the paste to the left by half of blit_width.
                                                0 = Use the paste coordinates as the beginning left.
         mirror    = Horizontal mirror paste.   1 = Mirror the output on the X axis.
                                                0 = Off.
         v-centp   = Vertical center paste.     1 = Offset the paste up by half of blit_height
                                                0 = Use the paste coordinates as the beginning top of the paste
         flip      = Vertical flip paste.       1 = Vertically flip the output on the Y axis.
                                                0 = Off
         r90       = Enable Rotate 90 degree.   1 = Swaps the X&Y coordinates on the paste.
         r45       = Enable Rotate 45 degree.   1 = Increments/decrements the X&Y coordinates on the paste in unison.


[at]VWAIT  <#of frames> <video line#>        > Pause geometry processor until the #frames and video line# has been reached.
           Frames = 1 thru 15, 0 = no wait
           line   = 0 thru 255               > (There is a hidden multiplier for line (1,2,4,8) to support video modes up to 2040 lines.  Not supported in this demo.)

*****************************************************************************************************************

After the 'do run.do', you may execute the other example command scripts by typing:

Code: [Select]

do test_8bitfont.do
do test_45deg.do              > Takes ~1 minute to simulate...
do test_art.do
do test_blitter.do
do test_blitter_hires.do      > Takes ~1 minute to simulate...
do test_vwait.do

The above 'do test_****.do' only change the 'TB_COMMAND_SCRIPT_FILE' parameter to a new source script filename, then a 'restart -f', then a 'run -all' to run the simulation.

If everything works OK, this will end any additions to the current Geometry unit.  The next version will be separated into 4 blocks, operate with 16bit X&Y coordinates with a 32/64 bit opcode while the pixel address generator and pixel writer will need upgrading to 32bit addressing, 32 bit color support and 256bit data bus for the ram.

[nockieboy]

Ok, here is the complete GEOMETRY unit test-bench.  After all this work, I found some hidden errors in the blitter unit, so this post also includes a full update to the 'GPU_EP4CE10' project.  Please test and let me know if it works as a numerous minor 'invisible' glitches/bugs were uncovered and patched.

Hidden errors? Anything interesting, or the kind that don't make any material difference to the output?  I've tested the new project on the hardware - works fine, can't detect any problems with my test software. 

Will test the geometry test bench as soon as I'm able.

[BrianHG]

Hidden errors like when you scale/zoom/enlarge the output, an extra line/pixel of graphics appear on the right and bottom of the output paste which is only 1 pixel wide while when you shrink the output, the first line and pixel along the top left is sometimes missing.  (What was going on is that the last line an pixel in the set width and height of the source bitmap wasn't being enlarged/zoomed, so it became only a single pixel thick even if you has the zoom set to 25x.)

There are also some issues with rotate 45 degrees and 90 de degrees simultaneously.  The 90 degrees moved the object onto a different quadrant, but, didn't actually turn it around, same issue with the mirror and flip.  Though, rotate 90 combined with a mirror & flip did work properly.

Also, the 45 had a jitter checkerboard in the output, always.  Right now, the checkerboard pattern is fixed so long as the paste scale is 1:1.  I cannot do much when simultaneously scaling and rotating at 45 degrees, so, your current solution is scale the source image, then do a 1:1 45 degree rotate.  This is something which needs a re-work of the blitter engine to fix properly, so I will not touch and doing it with 2 passes will need to be how it's done for now, or live with a speckle pattern along lines in the 45 degree pasted results.  Working without 'true color' is also a factor as I cannot smooth pixels unless the scale factor zoom enlarge settings always covers more than 4 pixels.

As for hidden errors, sometimes when writing pixels, depending on the next command, the GEO unit was sending a pile of write pixels of the last pixel in the drawing command.  Nothing you would see in the output as all the writes were correct, but, a waste of memory access.  Though, after drawing a line, writting 4 of the same pixels at 125MHz, I doubt your Z80 could ever be programmed to detect that...

[BrianHG]

I'm trying to make a determined start on the DDR3. 

Please bare in mind that my electronics experience with RAM so far has been limited to 128KB & 512KB SRAM DIP and SOIC chips (these ones).  My knowledge and comfort zone extends to parallel 8-bit data, 16-bit address buses and no more additional complexity than RDn, WRn and CSn signals.  So when I say the DDR3 controller in Quartus looks complicated, and the DDR3 datasheet is gobbledegook, I really mean:    

The way I would approach this task is to do what I'm trying to do currently - do the schematic and board layout, worry about the HDL after.  I think the DDR3 itself is wired okay and has sufficient decoupling - it certainly follows other published designs - I just need to sort termination and some reference voltage pull-ups to some of the data lines, or something?

I'm trying to connect it up to the FPGA - you know, make progress in an area I think I can actually do something, but I've stopped here because it's likely I'm supposed to get the DDR3 controller up and running first, then let Quartus decide which pins the signals are going to be routed to.  Anyway, I've attached a PDF showing the current state of the DDR3 and the FPGA's current free pins.

So I'm looking at Banks 4A and 5B as potential candidates to connect the DDR3 to... is that right?  That would leave 4A for the DVI/HDMI output.  Or I could swap Bank 5A to 5B and use 5A for the DDR3?  I'm looking to place the DDR3 chip in the bottom-right corner of the FPGA on the board. Hopefully. 

We have gone over this topic in this thread.
Wiring up Altera controller forces you to wire all the DDR3 IOs properly.
Remember, you need 2 IO banks for enough IO.

Preferably 2 IO banks sharing connection to 1 PLL.

1 of the IO banks needs a dedicated differential PLL output pins.

The DQS lines are also differential and need to be connected to Altera's  DQSp and DQSn IOs.  There a 2 of these differential DQS lines, LDQSn/p and UDQSn/p.

The IO bank which uses the LDQS needs to have it's DQ io pins tied to DQ7:0.

The IO bank which uses the UDQS needs to have it's DQ io pins tied to DQ15:8.

Begin with this.  All the other DDR3 controls are unidirectional (FPGA -> DDR3) running at half or quarter speed latched on the rising CLK signal, so you have more flexibility with these.

You may want to configure 3 IO banks at DDR3 IO voltage levels as the other DDR3 controls maybe easier to wire with extra IO on hand.  It is still a plus to make sure the third IO bank directly connects to the same PLL driving the DDR3 clk input.

The HDMI may be driven from the same IO bank running at the same IO voltage as the DDR3 ram.  It's only 8 output right at the edge of the FPGA.  Make sure those 8 are true differential LVDS outputs.  However, with our tests on the emulated differential output on the Cyclone IV board rated at 640mbps, we know we achieved that 1080mbps speed.  This translates into the potential of running the ram error free at 540MHz instead of down at the minimum guaranteed 303MHz, but, I wouldn't hold your breath.  There would be a trade-off of ram controller complexity VS raw throughput burst.  With video, raw throughput bursts it great, but with geometry drawing commands, complexity may gain an upper edge.  (This assumes we end up using a third party or our own opensource DDR3 controller.  Going to the 484 pin CV, you get access to the dedicated HardPHY pins to control the DDR3 which has the complexity & speed, but a much more expensive FPGA and a design which cannot be compiled on a third party vendor's FPGA.)  But with a Z80 feeding the geo unit, the raw throughput means many more MAGGIE layers on the DDR3, or 32 bit true color with a few layers while the geo will still run circles around the Z80.

[BrianHG]

Do not use port 5A.  Read my post here: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg3335836/#msg3335836

Go into the CV datasheet, look at the picture of the FPGA fabric layout and choose the IO banks where the DQs land on the highest FMAX in my linked post where 2 adjacent banks share a corner connection to a PLL with dedicated PLL output pins if you want the fastest possible DDR 3 controller.  Bank 5A will shove you right down to the minimum advertised limit listing from Intel of 303MHz.

Show me a snapshot of the datasheet's FPGA fabric.

[nockieboy]

Bank 5B is looking good as it's currently completely unused, and 7A can be freed up with a little clever routing or re-placement of the audio output.  Failing that, 4A and 3B.  Going to struggle to find a third adjacent bank.   I think the top-right corner is my preferred placement for the DDR, if the FPGA's IO will allow it.

Go into the CV datasheet, look at the picture of the FPGA fabric layout and choose the IO banks where the DQs land on the highest FMAX in my linked post where 2 adjacent banks share a corner connection to a PLL with dedicated PLL output pins if you want the fastest possible DDR 3 controller.  Bank 5A will shove you right down to the minimum advertised limit listing from Intel of 303MHz.

Show me a snapshot of the datasheet's FPGA fabric.

I can't find any reference to the FPGA fabric in the datasheet?  Or anywhere else for that matter - I remember seeing something like that in the Pin Planner in Quartus, but can't seem to find how to view it again. 

This is a real problem for me at the moment - I've got very little spare time to work on the project and I spend most of it trying to catch up with where I was at. 

I've attached latest PCB layout, schematic showing the FPGA's free pins and the Cyclone V bank diagram from the Quartus Pin Planner, in the vain hope that some of it will be useful.  I'm running low on useable free space on the PCB now.  I can move the signals coming in the right side of the FPGA (Z80 data and control signals) up or down as necessary to try to accommodate a SDRAM on the right side.  The bottom side still needs to accommodate U3 (enough for DVI output) and U11 (enough for a SPI).  There is potential for the PS/2 to be dropped completely if my USB interface works out (still in development currently).

[BrianHG]

Bank 5B is looking good as it's currently completely unused, and 7A can be freed up with a little clever routing or re-placement of the audio output.  Failing that, 4A and 3B.  Going to struggle to find a third adjacent bank.   I think the top-right corner is my preferred placement for the DDR, if the FPGA's IO will allow it.

Go into the CV datasheet, look at the picture of the FPGA fabric layout and choose the IO banks where the DQs land on the highest FMAX in my linked post where 2 adjacent banks share a corner connection to a PLL with dedicated PLL output pins if you want the fastest possible DDR 3 controller.  Bank 5A will shove you right down to the minimum advertised limit listing from Intel of 303MHz.

Show me a snapshot of the datasheet's FPGA fabric.

I can't find any reference to the FPGA fabric in the datasheet?  Or anywhere else for that matter - I remember seeing something like that in the Pin Planner in Quartus, but can't seem to find how to view it again. 

This is a real problem for me at the moment - I've got very little spare time to work on the project and I spend most of it trying to catch up with where I was at. 

I've attached latest PCB layout, schematic showing the FPGA's free pins and the Cyclone V bank diagram from the Quartus Pin Planner, in the vain hope that some of it will be useful.  I'm running low on useable free space on the PCB now.  I can move the signals coming in the right side of the FPGA (Z80 data and control signals) up or down as necessary to try to accommodate a SDRAM on the right side.  The bottom side still needs to accommodate U3 (enough for DVI output) and U11 (enough for a SPI).  There is potential for the PS/2 to be dropped completely if my USB interface works out (still in development currently).

Everything else shouldn't be wired.  The DDR3 gets absolute priority, then you can think about everything else.

Please check Cyclone V Device Handbook: Volume 1: Device Interfaces and Integration, page 216, Figure 6-8: PHYCLK Networks in Cyclone V E A2 and A4 Devices to show you the PLL connection to the banks.  You want to select IO banks which share a PLL and whose PLL has a dedicated outputs directly to one of the bank.  Make sure that your reference clock oscillator input is on a positive clock pin which goes to that PLL.  Page 206/207 shows the connections to the DQS groups and which shared DLL have direct connections.

[asmi]

I know it's a bit of off-topic, but have you considering buying DECA board mentioned in the thread nearby? https://www.eevblog.com/forum/fpga/arrow-deca-max-10-board-for-$37/
For the price, it's an absolute bargain, Among other things, it's got HDMI TX, microSD card socket, healthy 512 MBytes of DDR3 RAM, 100MBit Ethernet, USB 2.0 ULPI, audio codec, and it's got 69 digital GPIO pins on connectors, which should be more than enough to connect the rest of your system - I seem to recall you mentioned you need 63 FPGA IO pins. And, most importantly, it's got a rather large FPGA device with 50K LUTs.
I've ordered two even though I'm not really sure what I'm gonna do with them yet The reason I ordered two is to get the order over $50 for free shipping, as a single board with shipping charge was actually more expensive than two boards with free shipping
I suspect the stock won't last for long, so you might want to grab one (or two ) while you can.

[BrianHG]

I know it's a bit of off-topic, but have you considering buying DECA board mentioned in the thread nearby? https://www.eevblog.com/forum/fpga/arrow-deca-max-10-board-for-$37/
For the price, it's an absolute bargain, Among other things, it's got HDMI TX, microSD card socket, healthy 512 MBytes of DDR3 RAM, 100MBit Ethernet, USB 2.0 ULPI, audio codec, and it's got 69 digital GPIO pins on connectors, which should be more than enough to connect the rest of your system - I seem to recall you mentioned you need 63 FPGA IO pins. And, most importantly, it's got a rather large FPGA device with 50K LUTs.
I've ordered two even though I'm not really sure what I'm gonna do with them yet The reason I ordered two is to get the order over $50 for free shipping, as a single board with shipping charge was actually more expensive than two boards with free shipping
I suspect the stock won't last for long, so you might want to grab one (or two ) while you can.

Other than converting 3.3v to 5v for his Z80, I would say just place a Z80 inside the FPGA and be done with it.
He can test everything on those dev boards before considering making a dedicated GPU card for 5v Z80 and 68K series.

I would like to see the code avoid HW vendor specific calls so that any of the top vendor FPGA may be used.
It's too bad about the Lattice tools, the LFE5U45 is under 16$ at digikey and it is also a 45k gate beast with over 2 megabit ram inside for 16$us, (LFE5U85 - 85kgate 4megabit for 37$, LFE5U25, 9$)  a bit more IO than the CV and a certified minimum 312MHz for DDR3, slowest -6 version, 400MHz for -8.  Cyclone is reverse, -8=slow, -6=fastest.

I've found Modelsim to be quite useful and fast when developing HDL as it recompiles and can run my test scripts within a few seconds as seen with the entire GPU's geometry test above.  I wonder which sim tool Lattice provides with their 'Diamond' environment.

Funny, with Altera, you can install their ModelSim Lite all by itself without Quartus which is what I've been using the past few weeks to make my Geometry test bench and HDMI PLL configuration code.  It would be funny to work in Altera's Modelsim just to write code for Lattice Diamond.

[asmi]

Other than converting 3.3v to 5v for his Z80, I would say just place a Z80 inside the FPGA and be done with it.
He can test everything on those dev boards before considering making a dedicated GPU card for 5v Z80 and 68K series.

The most important part is that he can verify in hardware DDR3 interface on a known-good board. The user guide for the boards says it's wired for 300 MHz soft controller, which is what you guys are aiming for on CV board. Screwing up the wiring for DDR3 is the biggest risk I see for a full custom board. And as I understand, the fabric inside MAX10 is very similar to the one used in CIV-CV, so porting should not be a problem.

It's too bad about the Lattice tools, the LFE5U45 is under 16$ at digikey and it is also a 45k gate beast with over 2 megabit ram inside for 16$us, (LFE5U85 - 85kgate 4megabit for 37$, LFE5U25, 9$)  a bit more IO than the CV and a certified minimum 312MHz for DDR3, slowest -6 version, 400MHz for -8.  Cyclone is reverse, -8=slow, -6=fastest.

For Xilinx -1 is the slowest, -3 is the fastest. Some families (like Spartan-7) do not have -3 speed grade, they only have -1 and -2.

Funny, with Altera, you can install their ModelSim Lite all by itself without Quartus which is what I've been using the past few weeks to make my Geometry test bench and HDMI PLL configuration code.  It would be funny to work in Altera's Modelsim just to write code for Lattice Diamond.

I absolutely hated ModelSim that shipped with Quartus back in a day because it's artificially slowed down to entice you to upgrade into paid versions. It was a huge relief when I moved to Vivado with it's built-in simulator because it's fully-featured, not gimped down version of anything, and because how well it integrates into the IDE.

[BrianHG]

I absolutely hated ModelSim that shipped with Quartus back in a day because it's artificially slowed down to entice you to upgrade into paid versions. It was a huge relief when I moved to Vivado with it's built-in simulator because it's fully-featured, not gimped down version of anything, and because how well it integrates into the IDE.

Slowed down?  How so?  Re-compiles are almost instant.

In Xilinx, how long does it take to simulate my Geometry test-bench above running the:
GEO_tb_art.txt  script,  (Altera MS = 1 sec for 718,400 ns runtime)  (System Clk toggle rate = 100MHz)
And the
GEO_tb_45deg_zilog.txt script. (Altera MS no waveform = 25 sec for 13,851,400 ns runtime, all waveforms logged = 45sec.)

Includes the generation of the .bmp.

[asmi]

Slowed down?  How so?  Re-compiles are almost instant.

Here is official info: https://www.intel.ca/content/www/ca/en/software/programmable/quartus-prime/model-sim.html
Free version has 10K executable lines limit, paid version is 33% faster.

In Xilinx, how long does it take to simulate my Geometry test-bench above running the:
GEO_tb_art.txt  script,  (Altera MS = 1 sec for 718,400 ns runtime)  (System Clk toggle rate = 100MHz)
And the
GEO_tb_45deg_zilog.txt script. (Altera MS no waveform = 25 sec for 13,851,400 ns runtime, all waveforms logged = 45sec.)

Includes the generation of the .bmp.

No idea. I don't have time to port it to 7 series platform.

[BrianHG]

Slowed down?  How so?  Re-compiles are almost instant.

Here is official info: https://www.intel.ca/content/www/ca/en/software/programmable/quartus-prime/model-sim.html
Free version has 10K executable lines limit, paid version is 33% faster.

In Xilinx, how long does it take to simulate my Geometry test-bench above running the:
GEO_tb_art.txt  script,  (Altera MS = 1 sec for 718,400 ns runtime)  (System Clk toggle rate = 100MHz)
And the
GEO_tb_45deg_zilog.txt script. (Altera MS no waveform = 25 sec for 13,851,400 ns runtime, all waveforms logged = 45sec.)

Includes the generation of the .bmp.

No idea. I don't have time to port it to 7 series platform.

Port, how so.  It's pure SystemVerilog.
1 folder with 7 .sv files, the top one being the 'GPU_GEO_tb.sv'.  The setup do files are just the vsim include all .sv and compile command while the optional run.do selects which waveforms you wish to see in the waveform window.

[nockieboy]

I know it's a bit of off-topic, but have you considering buying DECA board mentioned in the thread nearby? https://www.eevblog.com/forum/fpga/arrow-deca-max-10-board-for-$37/
For the price, it's an absolute bargain, Among other things, it's got HDMI TX, microSD card socket, healthy 512 MBytes of DDR3 RAM, 100MBit Ethernet, USB 2.0 ULPI, audio codec, and it's got 69 digital GPIO pins on connectors, which should be more than enough to connect the rest of your system - I seem to recall you mentioned you need 63 FPGA IO pins. And, most importantly, it's got a rather large FPGA device with 50K LUTs.
I've ordered two even though I'm not really sure what I'm gonna do with them yet The reason I ordered two is to get the order over $50 for free shipping, as a single board with shipping charge was actually more expensive than two boards with free shipping
I suspect the stock won't last for long, so you might want to grab one (or two ) while you can.

I think 44 pins absolute bare minimum just to interface with the host computer.  I took a look at the DECA - does look like a good deal, though shipping is more than the cost of the board itself so I see what you're saying about ordering two!  I'm not too far off getting this CV board finished (though the inclusion of DDR3 is a bit of an iceberg).  Not sure what I'd do with the DECA to be honest, let alone two of them, but it's very tempting!

EDIT: Wrote that before I saw the rest of your conversation above.  So maybe getting one (or two!) would be a good idea for DDR3 controller testing etc?

[nockieboy]

Everything else shouldn't be wired.  The DDR3 gets absolute priority, then you can think about everything else.

I do have some physical constraints with the board layout that I have to consider.  How much impact they have on the design is up for grabs, but there's the power supplies around the board, 26 address signals from the left side of the board, 18 data and control signals from the right side, SD (which I'm putting on the underside of the PCB) and audio jack at the top and DVI/HDMI, USB/PS2 need to be at the bottom.  Other than rotating the FPGA and shunting the modules whose position is only limited to one side of the PCB around, there's not a lot else I can do. (Purple areas are power supplies).

Please check Cyclone V Device Handbook: Volume 1: Device Interfaces and Integration, page 216, Figure 6-8: PHYCLK Networks in Cyclone V E A2 and A4 Devices to show you the PLL connection to the banks.  You want to select IO banks which share a PLL and whose PLL has a dedicated outputs directly to one of the bank.  Make sure that your reference clock oscillator input is on a positive clock pin which goes to that PLL.  Page 206/207 shows the connections to the DQS groups and which shared DLL have direct connections.

Banks 1 & 2 are fed solely by the left PLL and banks 5 & 6 are fed by the right PLL.  All other banks have access to both PLLs.  But you've said not to use bank 5A, so that writes off the right hand side.  Bank 1 doesn't seem to exist and the rest of the left hand side (bank 2A) has 10 DQ and 2 DQS IOs.

Banks 7 & 8 seem to be the best option as they have 32 IOs between them, plenty of DQ and DQS pins, the reference clock feeds into bank 7A and the only disruption to existing connections would be to the auxiliary equipment on the top edge of the board (SD card, audio output, PC serial and debug serial, LEDs) - none of which would suffer from longer traces to other parts of the FPGA or being relocated somewhere else on the PCB entirely (except for audio).

Unless the fact it would take a PLL out of the equation for one other side of the FPGA would be an issue?

Do you agree?

[asmi]

Not sure what I'd do with the DECA to be honest, let alone two of them, but it's very tempting!

Same here - I'm not sure yet what to do with that, but the price is just too good to pass up! Just check how much FPGA itself is that's on the board - it's several times more expensive than entire board!

EDIT: Wrote that before I saw the rest of your conversation above.  So maybe getting one (or two!) would be a good idea for DDR3 controller testing etc?

Yea, I would definitely do that. But that's me as someone who never used Altera's DDR3 controller, which is why I see it as a big design risk. To me $37 * 2 = $74 is a very good price to be certain as I suspect that PCB + BOM cost for a single custom board will be in the same ballpark. And I think you can find some other uses for these boards once the prototyping is over. Peripheral set is very good on it - pretty much everything you'd need for a typical single-board computer, with microSD wired through voltage translator so that it partially supports SD 3.0 specification with 1.8 V signaling (except for the highest 104 MHz SDR clock, which is beyond spec for the voltage translation IC used). USB 2.0 ULPI PHY onboard allows implementing a full-on USB 2.0 host interface, which, if connected to a hub, can be used to connect keyboard/mouse and have some leftover ports for stuff like thumb drives. 100 Mbit Ethernet can be used to add networking support. And 512 MBytes of DDR3 is plenty for all RAM needs, including video/GPU framebuffers, scratch/DMA memory for Ethernet MAC or USB 2.0 EHCI modules, as well as general purpose RAM for the needs of applications.

[nockieboy]

Not sure what I'd do with the DECA to be honest, let alone two of them, but it's very tempting!

Same here - I'm not sure yet what to do with that, but the price is just too good to pass up! Just check how much FPGA itself is that's on the board - it's several times more expensive than entire board!

EDIT: Wrote that before I saw the rest of your conversation above.  So maybe getting one (or two!) would be a good idea for DDR3 controller testing etc?

Yea, I would definitely do that. But that's me as someone who never used Altera's DDR3 controller, which is why I see it as a big design risk. To me $37 * 2 = $74 is a very good price to be certain as I suspect that PCB + BOM cost for a single custom board will be in the same ballpark. And I think you can find some other uses for these boards once the prototyping is over. Peripheral set is very good on it - pretty much everything you'd need for a typical single-board computer, with microSD wired through voltage translator so that it partially supports SD 3.0 specification with 1.8 V signaling (except for the highest 104 MHz SDR clock, which is beyond spec for the voltage translation IC used). USB 2.0 ULPI PHY onboard allows implementing a full-on USB 2.0 host interface, which, if connected to a hub, can be used to connect keyboard/mouse and have some leftover ports for stuff like thumb drives. 100 Mbit Ethernet can be used to add networking support. And 512 MBytes of DDR3 is plenty for all RAM needs, including video/GPU framebuffers, scratch/DMA memory for Ethernet MAC or USB 2.0 EHCI modules, as well as general purpose RAM for the needs of applications.

Well you've persuaded me asmi,  I've pulled the trigger on ordering two of those cards.   I had a quick look on AliExpress and they're selling the same cards (well, the picture is the same!) for £230 (your mileage may vary in your home currency) including shipping!  The DDR3-testing argument was what won me over, though.  If we do wind up writing our own DDR3 controller, I've got a way of testing it physically I suppose.  Plus it's general gadgetry that appeals to my (not so) inner geek. 

EDIT: Holy cow!  I've just looked up the FPGA (on its own) on Mouser.  They don't do the -6 speed variant in the DECA, just slightly slower -7 and -8 variants.  The -8 speed variant is still over £100, with the -7 around £114! 

[asmi]

Well you've persuaded me asmi,  I've pulled the trigger on ordering two of those cards.   I had a quick look on AliExpress and they're selling the same cards (well, the picture is the same!) for £230 (your mileage may vary in your home currency) including shipping!  The DDR3-testing argument was what won me over, though.  If we do wind up writing our own DDR3 controller, I've got a way of testing it physically I suppose.  Plus it's general gadgetry that appeals to my (not so) inner geek. 

Just skimmed through the user guide, and it appears that the board comes with WiFi-BLE module and MIPI camera module! This is an absolute bargain! My order apparently had some issues, but after I called them they said they released it to the warehouse today, so hopefully they will arrive shortly.
Also if you can persuade BrianHG to buy one as well, he will be able to go beyond simulations and do an actual hardware checkout of stuff you guys are working on

EDIT: Holy cow!  I've just looked up the FPGA (on its own) on Mouser.  They don't do the -6 speed variant in the DECA, just slightly slower -7 and -8 variants.  The -8 speed variant is still over £100, with the -7 around £114! 

Yea, that's what I meant. FPGA devkits are often subsidized (just check out Xilinx devboards - a lot of them are cheaper as a full kit than just FPGA on it), as they are prototyping platforms which lead to device sales once you go into production with your products using these chips, but never to that extent!

[RoGeorge]

Just skimmed through the user guide, and it appears that the board comes with WiFi-BLE module and MIPI camera module!

I'm afraid not, the package content is pretty clear.  It has a MIPI connector, but no camera and no WiFi-BLE are included.  Can you give a link please to the shop that includes all those?

Also, if you like to buy FPGA bargains, there is yet another one even better:  EBAZ4205 with (IIRC) Zynq 7010, ~25 kLE FPGA) plus 2 embedded hardcore ARMs/~700MHz, with 256MB DDR3/1066, LAN, microSD and a few optpcouplers:
https://www.eevblog.com/forum/fpga/ebaz4205-(zynq-7000-based-development-board)/

Those boards are from former cryptocurrency miners, and a board is about $10-15 on AliExpress.

[asmi]

I'm afraid not, the package content is pretty clear.  It has a MIPI connector, but no camera and no WiFi-BLE are included.  Can you give a link please to the shop that includes all those?

I'm just reading a user guide which is linked in the item description on Arrow's website.

Also, if you like to buy FPGA bargains, there is yet another one even better:  EBAZ4205 with (IIRC) Zynq 7010, ~25 kLE FPGA) plus 2 embedded hardcore ARMs/~700MHz, with 256MB DDR3/1066, LAN, microSD and a few optpcouplers:
https://www.eevblog.com/forum/fpga/ebaz4205-(zynq-7000-based-development-board)/

Those boards are from former cryptocurrency miners, and a board is about $10-15 on AliExpress.

No offence, but this board is utter garbage. No schematics, no datasheet, no support, no code/RTL examples, no nothing. I'd rather make my own board, that buy this noname crap. So - no, it's not "even better", it's much worse.

[RoGeorge]

That EBAZ board has a lot of value for the money, too.

Zynq has a hardcoded dual core ARM, while MAX10 will use FPGA resources to create a softcore processor (NIOS II).  Vivado seem to have all the required IP blocks for that board for free, while the MAX10 will need a payed NIOS license for some IPs you might want.

About the docs, there is a github repository for the EBAZ board, with all the docs and board support files for Vivado.  There is also a working Linux for it, while the Altera board doesn't seem to allow Linux for free (requires IP license for NIOS II softcore processor with MMU, also I'm not sure if the DDR3 IP is free or not for Altera).

Both boards are nice to have for their price. 

Not sure how useful that will be for this particular project.
Sorry for any offtopic, I didn't read the previous 96 pages before posting.   

[asmi]

That EBAZ board has a lot of value for the money, too.

I don't think so. You are comparing a purpose-built devboard with some specialized board designed for anything except being an actual devboard. Which is why it's so limiting.

Zynq has a hardcoded dual core ARM, while MAX10 will use FPGA resources to create a softcore processor (NIOS II).  Vivado seem to have all the required IP blocks for that board for free, while the MAX10 will need a payed NIOS license for some IPs you might want.
About the docs, there is a github repository for the EBAZ board, with all the docs and board support files for Vivado.  There is also a working Linux for it, while the Altera board doesn't seem to allow Linux for free (requires IP license for NIOS II softcore processor with MMU, also I'm not sure if the DDR3 IP is free or not for Altera).

if your goal is to just run Linux, maybe you have a point, though I think this is a very pointless goal in and of itself. In embedded world Linux is a tool, not an end goal, so you use it if you need it to do something (for example USB support, or TCP/IP stack), but not just to run itself and just stare at a terminal being proud of your ability to enter few commands in a command line and follow well-defined instructions on how to get it up and running.

Both boards are nice to have for their price. 

Again, these are not comparable. Purpose-built devboards are far superior options because they are actually designed to be used as prototyping platforms, and so they usually have required facilities like integrated JTAG with live debugging support, some kind of expansion support and other specific features normally not present on production boards. Using random application-specific boards for prototyping is like using a microscope to drive in nails - yes, it can be done (microscope bases are heavy!), but nobody in their right mind would ever do that.

[RoGeorge]

EBAZ has JTAG pins but can be programmed without additional programmers.  The Zynq board also has tens of I/O pins at its connectors.  There is a schematic and there is even Altium and Kicad PCB files.
https://github.com/xjtuecho/EBAZ4205/blob/master/HW/ebaz4205/EBAZ4205-SCH.pdf
https://github.com/xjtuecho/EBAZ4205

Also, free IP blocks are very important (Quartus seems to have less free IP) when one want to make use of the board for anything other than learning.  For example, nobody writes a DDR3 controller or a network stack, but uses available IP blocks instead.  If these blocks are not free to use, than they are certainly too expensive for hobby projects anyway, so it is very important to have them for free in the toolchain.  If we consider the free part of the software toolchain, then the Zynq become even more attractive.  I didn't really work with Quartus/Nios, but from reading the specs so far it seems Vivado has more free goodies and will be more productive for projects.

Same with Linux, very important not for exercising shell commands, but because it will allow access to all the drivers and tools and applications already existing for Linux.

I won't try to convince you any further about the value of that Zynq board, not trying to sell anything.   

I would also rather buy the Altera board, same as you, just that for different reasons (e.g. has a MIPI connector, or the two SMA for the ADC, good to improvise a DAQ if it only were a free Linux for it, and it seems it is one, but I'm too new to this board+toolchain to disseminate between facts and marketing hype).  In fact the only thing that kept me not to buy one yet was that I don't know what IP blocks are free for Quartus/Nios II.