Arrow DECA MAX 10 board for $37

[BrianHG]

Image is corrupted see attachment,  connected to a DELL P2419HC it does report 1920x1080 60Hz
Tried on a LG C9 as well ... same image

LED 2,4,5 does lit on both files when loaded with Quartus 15.0 programmer

Did you flip the 2 switches or press the buttons?

I have confirmation it works on someone else's DECA board unlike my first lemon release.

That looks like the DDR3 ram powered up un-initialized.  A feature if you have the ellipse SW0 disabled.
IE, enable the ellipse, the disable, then powered the board on and off and you will see how much ram was retained.

(Side note, I tried a still large text B&W still image powered on for 2 days, and bits of the image was retained in tons of grain after turning off the PCB for an hour...)


LED4 = pll locked good.
LED2 = DDR3 controller has successfully powered up and read data calibration worked without errors.
LED5 = DDR3 controller ready and running.

[Wiljan]

Flipping the SW both files does work, elipses all over, nice work 

[BrianHG]

Flipping the SW both files does work, elipses all over, nice work 

Right now, that ram controller isreading 600 megabytes per second to maintain that image while when drawing filled ellipses, or static, it is also writing around 500 megabytes per second at the same time.  Though, the thin lined ellipses is around quarter speed speed due to there being no sequential bursting due to the nature of the thin line pixels randomly addressing everywhere in ram.

[ale500]

Hei Brian,

it also works on my DECA board. I didn't have to flip any switches, though, but SW1 stops the scrolling, SW2 stops the ellipses. Great work !
LED2 is on
LED4 is on
LED5 is on

That's a demo !

The quartus 20 version scrolls only up and down and one sees where the framebuffer ends kind of at the first third of the screen, the 15 did the scrolling in both directions.

[BrianHG]

The quartus 20 version scrolls only up and down and one sees where the framebuffer ends kind of at the first third of the screen, the 15 did the scrolling in both directions.

Are you serious?    I'm going crazy here.  My first version worked only on my DECA board.  This version works perfectly on 2 others except yours has a problem with the Q20.1 build.  Q20.1 takes 6 min to compile and only a minor missing on ~5MHz on the 300MHz clock @85 degrees.  This clock has nothing to do with the screen scrolling, that logic operates down at 150MHz.

Originally, nothing I would build functional in Q15, yet all my code simulates perfectly.

Q15 takes 11 minutes to compile this project and yields a lemon 260MHz for the DDR3 clock @85 degrees.  That's a ton worse and still a few MHz shy @299Mhz with the junction temp of 0 degrees.  Yet, that one seems better?

Something is fishy between the compilers.  The code between Q15 & Q20 is identical.  All I have been doing is adding a ton of D-registers between sections of my code at strategic points and where I cross clock domain boundaries except whatever cross domain boundaries controls I have are designed to operate at well below 10MHz with separate latch enable controls delayed another clock further.

What was once clean nice code now have all the middle link logic making a mess of things.  But I need that official above 300MHz performance.

Originally, turning on the compiler's highest speed optimization was the only way to get things to work.  Now, the only way to get my code to work is to choose Balanced or Area optimization.  Something is fishy with this series of FPGA.  I never had such issues with Cyclone series.

Just a side note:  Max10 support files for Quartus = 11 megabytes, CycloneIV support file = 475 megabytes...

[Wiljan]

Hehe, don't go crazy,

I also saw that the scrolling was also only up/down on one of the images first time after power the board
but when I reloaded the opposite image it it did scroll both H+V and on next reload of opposite image again H/V

I guess it's some uninitialized direction flag or a counter out of range.

Except for outputting a HDMI which are great 
What kind of input have you in mind?

TS over IP?

I have been using a lot of VGA output on some FPGA boards for debugging ...
I typical just have a font in BRAM and hex to ascii convert so I can hook up a lot of like 64 x 64 bit buses to show internal values as HEX on the VGA

I did play with RLE decoding (FSM) of images (Bart Simpson) which I places in a BRAM and just decoded on the fly on every V, that worked great

So I didn't used and DDR ram at all, that approach will work on HDMI out as well.

[BrianHG]

Hehe, don't go crazy,

I also saw that the scrolling was also only up/down on one of the images first time after power the board
but when I reloaded the opposite image it it did scroll both H+V and on next reload of opposite image again H/V

I guess it's some uninitialized direction flag or a counter out of range.

Except for outputting a HDMI which are great 
What kind of input have you in mind?

TS over IP?

I have been using a lot of VGA output on some FPGA boards for debugging ...
I typical just have a font in BRAM and hex to ascii convert so I can hook up a lot of like 64 x 64 bit buses to show internal values as HEX on the VGA

I did play with RLE decoding (FSM) of images (Bart Simpson) which I places in a BRAM and just decoded on the fly on every V, that worked great

So I didn't used and DDR ram at all, that approach will work on HDMI out as well.

Yup, I have done a RLE decoder as well.

I'm only making a DDR3 ram controller opensource freeware which can be ported over to Lattice and Xilinx with just the calling change of the PLL and DDR IO buffers.  All the serializers, multiport controller and other code is all written in easy Systemverilog.  The demo shows reading and writing to the DDR3 ram is working.

The ellipse drawing geometry demo will also be available with the source to show how easy it is to display from ram a bit-plane of any size and depth to a video out of any size and depth.

Nockieboy will be integrating his 8 bit GPU with my ram controller with it's multi-window layers, sprites and full geometry engine as well as adding SD-Card reader and sound support now that there is 512mb ram available.

My ram interface is designed for dummies and you can input and output anything you like, at any bit depth.  It identical reading/writing to a 32 port core FPGA ram block except the read and write enable has a busy flag and the read data has a data ready flag with a 'vector' you may feed at the read request which is returned with the read data in parallel.

Your RLE code's output can easily feed one of the 16 available input write ports to render what you like.  The advantage is that another CPU or camera can be on another port with access to the decoded image or whatever you like.  Though, having a single 16bit DDR3 ram chip is a little bit under-powered for 32bit color, but you can save access time by going down to 24bit in 3 separate 8 bit banks, or, 16 bit color, or lower res.

[tomeo.gonzales]

I try to buy from Arrow.com and VAT ID is mandatory at checkout.
How to buy from Arrow for personal use without a VAT ID?

[BrianHG]

I try to buy from Arrow.com and VAT ID is mandatory at checkout.
How to buy from Arrow for personal use without a VAT ID?

Did you try emailing customer support?

[tomeo.gonzales]

Yes, but no response. after five days.

[ale500]

Hehe, don't go crazy,

I also saw that the scrolling was also only up/down on one of the images first time after power the board
but when I reloaded the opposite image it it did scroll both H+V and on next reload of opposite image again H/V

I guess it's some uninitialized direction flag or a counter out of range.

I see, I loaded the 15.0 image first and the 20.1 later and the scrolling gets disturbed: the first time after power up always works, mostly. The second time, and third produce only vertical scroll.
15.0 seems to be rock solid.
Wasn't the MAX10 an improved cyclone iii ? I read it somewhere...

Anyways reading from DDR3 and producing the HDMI output works every time, on both versions

[BrianHG]

Hehe, don't go crazy,

I also saw that the scrolling was also only up/down on one of the images first time after power the board
but when I reloaded the opposite image it it did scroll both H+V and on next reload of opposite image again H/V

I guess it's some uninitialized direction flag or a counter out of range.

I see, I loaded the 15.0 image first and the 20.1 later and the scrolling gets disturbed: the first time after power up always works, mostly. The second time, and third produce only vertical scroll.
15.0 seems to be rock solid.
Wasn't the MAX10 an improved cyclone iii ? I read it somewhere...

Anyways reading from DDR3 and producing the HDMI output works every time, on both versions

I've worked with Cyclone II, III & IV and I've never seen such a tiny code, the scrolling part, mess up in such a weird way.  I'm telling you that it smells fishy.  Especially since the code is in reset until the DDR3 is ready where a default X&Y scroll number of +3x,+3y per frame is hard wired.

Also, Q15.0 takes a lot longer to compile than Q20.1.  I've jumped through hoops to ensure the DDR3 controller initializes properly with solid read/writes in every build.  Though, my multiport section is still having trouble because it just cant always hit the required 150MHz FMAX.  And the weird thing is it has better chance of functioning correctly if the compiler cant reach the FMAX.

Worse, if I run the multiport at 75Mhz (Quarter Rate mode where the DDR is still running at 300MHz), the board will never display an image but I can still read and write data through the RS232 as well as the test pattern/ellipse images are being written into ram.  Yet, 2 weeks ago, a picture was no problem in Quarter rate mode, but, only when compiled in Q20.1.

[Wiljan]

Hehe, don't go crazy,

I also saw that the scrolling was also only up/down on one of the images first time after power the board
but when I reloaded the opposite image it it did scroll both H+V and on next reload of opposite image again H/V

I guess it's some uninitialized direction flag or a counter out of range.

I see, I loaded the 15.0 image first and the 20.1 later and the scrolling gets disturbed: the first time after power up always works, mostly. The second time, and third produce only vertical scroll.
15.0 seems to be rock solid.
Wasn't the MAX10 an improved cyclone iii ? I read it somewhere...

Anyways reading from DDR3 and producing the HDMI output works every time, on both versions

I've worked with Cyclone II, III & IV and I've never seen such a tiny code, the scrolling part, mess up in such a weird way.  I'm telling you that it smells fishy.  Especially since the code is in reset until the DDR3 is ready where a default X&Y scroll number of +3x,+3y per frame is hard wired.

Also, Q15.0 takes a lot longer to compile than Q20.1.  I've jumped through hoops to ensure the DDR3 controller initializes properly with solid read/writes in every build.  Though, my multiport section is still having trouble because it just cant always hit the required 150MHz FMAX.  And the weird thing is it has better chance of functioning correctly if the compiler cant reach the FMAX.

Worse, if I run the multiport at 75Mhz (Quarter Rate mode where the DDR is still running at 300MHz), the board will never display an image but I can still read and write data through the RS232 as well as the test pattern/ellipse images are being written into ram.  Yet, 2 weeks ago, a picture was no problem in Quarter rate mode, but, only when compiled in Q20.1.

This is one of the thing which drive me crazy of the compilers that you don't get the same result on each compile of a design.
I know it's very complex when the compiler does optimize and reduce stuff to fit somehow.

But if you were doing a PCB you would place you logic symmetrical and in logic block's and not reuse some register form a´very different part witch might have the same data in  the other end of the board..... so thing like floor planning, Logic Lock region and partition design makes sense but require license for the Quartus tool. and even though it will not make all regions the same even with the same design.

People often say you should have a correct constrain file then you will not need to force placement to get Fmax.... but we all want Fmax on most of what we do. I can see in some stuff I made the when forcing placement the Fmax are reach better than without

Feel free to post you source even if it does not work as expected, more eyes might help to find a solution

[BrianHG]

Is the debug IP-CORE aux. UART output particularly important for debugging the remaining problems at this time?
If so, would I be correct to assume that you don't happen to have any variant build with the cores included that can tunnel the various debug UART
information out the USB / ethernet / internal usb blaster channels somehow?
If  not I'll have to find some devkit or programmer or something with compatible USB/UART bridging which is probably possible if not handy.

Though I use my RS232 debugger to peek at the ram contents and have a few handy buttons to send a reset and see 4 regs in my design, passing a reg called rdcal to the blue LEDs does give you enough info on the status of the DDR3 controller.  The RS232 debugger only requires 2 wires, RXD&TXD, 3.3v ttl to RS232 converter.  If you have code to bridge data to one of DECA's onboard ports & have a hex editor/viewer, it should be easy peasy to implement on one of the fully flexible available 16 read&write ports.

If the RAM isn't acting quite as expected across all modes / PCBAs I would generally wonder if they might have substituted a different DRAM IC than the one listed in the BOM for some lots, or if that particular chip has known or undocumented errata vs. the way it is hooked up in this unit.  I wouldn't even be shocked if there were mode dependent SI problems based on the circuit / layout / power supply which nobody may know of since it's just a devkit and most people wouldn't be doing rigorous DRAM channel validation testing and if they did they'd probably just be using mostly the altera based projects / core.
But I'm sure you'd have looked into any compatibility concerns that occurred to you when porting the core.

The ram is acting fine.  The initial problems span from power-up controls originating on the CLK_IN 50MHz oscillator input feeding the core logic which operates on the PLL 300MHz DDR3 clock domain.  A number for D-flipflop regs in series bridging the commands from the CLK_IN domain to the DDR_CLK domain fixed all the issues except for 1.  Even though such logic wasn't necessary as I did code for the crossing of 2 different clock domain speeds, I guess that you cannot predict how the compiler or FPGA itself tries to do the wiring in this logic freezing up my code.  With a 50MHz source, I can only reliably boot the ram at 250MHz, 300MHz, 350MHz, 400Mhz, and sometimes 450MHz.  When setting frequencies like 320MHz or 310MHz, or 270MHz, each build returns random results.  (I know 270MHz is underclocking the ram, but 250MHz works fine.)  Once the ram has been properly booted, and everything is operating on the 300MHz and 150MHz clocks coming from the PLL, I have not seen the DDR3 controller logic fail, even if I seriously overclocked the FPGA.

At power-up, my code does do a read calibration inspection of the RAM and it does tune the PLL's read phase to the optimum position.  My code is to DDR3 spec, done by the book.  Different ram should not be a problem, especially at 300MHz.

Currently, I'm cleaning my source code and I need to create some additional documentation to post the code with a few different example implementations this weekend.

[promach]

Does the DECA board MIPI interface fully complies with Google's Coral Camera ?

Note: the coral camera is using some 24-pin FFC.

[BrianHG]

Nope, the DECA has a 30pin FFC.
Unless you can find an adapter cable.  Maybe google MIPI 30 pin cable to whatever...
I've attached the schematic:

[BrianHG]

It isn't even a flat flex.  It's a connector type you usually see mounted on then end of a flat-flex, see:

[promach]

So, this MIPI connector is not for camera module as I noticed that most of the MIPI camera modules in the market would not really fit into this MIPI connector on DECA development board ?

[BrianHG]

I don't think that DECA's MIPI connector is compatible with ANY camera standard today.
I have no clue where they got that pinout from.

If I needed to, I'd just wire one to the user IO SIP connector.

[Wiljan]

I have a camera in the MIPI socket on the DECA, will be able to send an image of it end next week since I'm abroad until then. The camera was a part of an Arrow traning course like 4 years ago and came with the board.
Could be nice to see if it can work with BrianHG's DDR HDMI

Just found some links to the LAB for the MIPI
https://www.intel.com/content/dam/altera-www/global/en_US/uploads/5/50/8_MIPI_to_HDMI_Terasic.pdf
https://fpgacloud.intel.com/devstore/platform/?page=2&acds_version=any&family=max-10&board=9
https://community.intel.com/t5/FPGA-SoC-And-CPLD-Boards-And/Arrow-DECA-MAX-10-lab-8-camera-driver-improvement/td-p/217778

[Wiljan]

Found all the labs
https://github.com/snikrepmada/DECA

[BrianHG]

My DDR3 controller is now available here:

https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3606415/#msg3606415

[Wiljan]

MIPI camera

Here is a few images of the camera which I got with the board on a course like 4-5 years ago.
No marking on the camera other than the number "9080AA" 30Pin MIPI

Back at the course we were out of time to run the lab with the Cam, but you can find the LAB and all the description in my link a few post ago

When get a bit time I will see if I can get something to work

[RoGeorge]

Back at the course we were out of time to run the lab with the Cam, but you can find the LAB and all the description in my link a few post ago

When get a bit time I will see if I can get something to work

The lab with the camera is using a proprietary MIPI IP that has a date limited license, so it wont work in 2021.  Trivial tricks like setting back the system clock to the year 2015 doesn't make with FlexLM licensing software (IIRC FlexLM is the one used by Quartus).  I've noted down some tests I made about it here:  https://www.eevblog.com/forum/fpga/arrow-deca-max-10-board-for-$37/msg3568744/#msg3568744

[BrianHG]

V0.95 of the DDR3 controller has been released:
https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3621074/#msg3621074