Arrow DECA MAX 10 board for $37

[Jope]

The Arrow DECA MAX 10 board is now available for $37: link.
Originally $169, then $65 (according to this article).

AFAIK the cheapest MAX 10 board currently available.

[SiliconWizard]

The Arrow DECA MAX 10 board is now available for $37: link.
Originally $169, then $65 (according to this article).

AFAIK the cheapest MAX 10 board currently available.

Not the cheapest; QMTECH actually has a cheaper board: https://qmtechchina.aliexpress.com/store/4486047

But the DECA board is likely better designed with more features.

[isometrik]

• QMTECH's MAX 10 board has a 10M08 device [8K programmable logic elements].
• The Arrow DECA MAX 10 board has a 10M50 FPGA [50K programmable logic elements].

[Jope]

Not the cheapest; QMTECH actually has a cheaper board

The QMTECH board has a 10M08, while the Arrow has a 10M50 (8k vs 50k logical elements). The Arrow board also has DDR3 RAM, Flash, Ethernet und USB PHY, etc. The QMTECH has just a USB UART.

[BrianHG]

The Arrow DECA MAX 10 board is now available for $37: link.
Originally $169, then $65 (according to this article).

AFAIK the cheapest MAX 10 board currently available.

Not the cheapest; QMTECH actually has a cheaper board: https://qmtechchina.aliexpress.com/store/4486047

But the DECA board is likely better designed with more features.

OMG, you are comparing a phony slowest MAX10M08CU169C8G (it's a smaller one relabeled as Intel's first 3 MAX10's all have the same die) running in lower single supply mode to a true highest speed 50K gate 1.6megabit core ram 10M50DAF484C6G in full power dual supply mode with a 512meg 16bit DDR3, flash + and SD card slot, HDMI transmitter with audio, audio codec line in and out, ethernet, and so much more....

[retiredfeline]

The Arrow DECA MAX 10 board is now available for $37: link.
Originally $169, then $65 (according to this article).

AFAIK the cheapest MAX 10 board currently available.

How much was shipping for you? I doubt if they'll ship free to here and I didn't want to register to find out.

[Jope]

How much was shipping for you? I doubt if they'll ship free to here and I didn't want to register to find out.

No shipping charges to EU. I paid €37 including shipping (= 0), VAT and customs. Board should arrive this Wednesday.

[SiliconWizard]

Not the cheapest; QMTECH actually has a cheaper board

The QMTECH board has a 10M08, while the Arrow has a 10M50 (8k vs 50k logical elements). The Arrow board also has DDR3 RAM, Flash, Ethernet und USB PHY, etc. The QMTECH has just a USB UART.

Certainly, as I said, the DECA has more features and a better design. (And OK I should have added, by far.)

My point was just that it was technically not " the cheapest MAX 10 board currently available", as you had said. Nothing more.
And sure, the DECA is definitely a much better deal there, especially at this price.

[RoGeorge]

Tempting price!

It seems the only NIOS II processor core (IP) available for free is the light one, a version without MMU (Memory Management Unit).  The license for the biggest and fastest NIOS II core IP (with MMU included) is about $400.  In the NIOS II manual is written that a fast core without license can run in hardware but it is "time-limited", whatever that means (couldn't find how long is "time-limited").

Can this board run Linux for free?

[RoGeorge]

I didn't find any estimation for bigger NIOS II softcores, but the light one takes only 600-700 LE.  My wishful thinking says the bigger version won't be 100 times bigger.  I'm more concerned about the availability of free IPs than the size.

Without an OS the board will be painful to use for example as a DAQ, or as a MIPI to LAN, or as camera to HDMI, or for any other project that is useful and not just a blinky demo.  My hope is the board will be able to run Linux, otherwise why adding so much DDR3 to it (512MB).

Anybody knows if this board can run Linux at all, please?

LATER EDIT:
Found that it can run Linux, not sure about the license.  It's from 2015, I didn't even know MAX10 is that old.   
https://www.intel.com/content/dam/altera-www/global/en_US/uploads/c/ca/DECA-Linux-Tutorial_15_1.pdf

[retiredfeline]

I just ordered my two copies to make their $50 minimum free shipping threshold.

It looks like this is the situation for me and shipping for one board costs more than one board. 

[Daixiwen]

You need the MMU version of the Nios2 CPU to run Linux, and even then IIRC it's a heavily patched version of Linux, not an official one. And it runs rather slowly. A smaller real time OS optimized for embedded platforms, such as FreeRTOS, could be a better choice. Those usually don't even require an MMU.
As you said the free version of Nios doesn't have an MMU. You can still make your own project with the full Nios CPU with MMU, but then it will run in "opencore evaluation mode", meaning that the JTAG needs to be tethered to your PC while you run your application. As soon as you disconnect the USB port doing the JTAG communication (of after a fixed time delay after that) the Nios CPU stops working.

[mon2]

@retiredfeline, we have free shipping with their loyalty program. Need to confirm but would you be interested if the price is $49.95usd? Need to confirm our cost and resell for us to process. Send us a private message if of interest.

[mon2]

@retiredfeline, You can also join their program and get the same deal, I think. Please see their website for full details.

[retiredfeline]

I did join the loyalty program. Free shipping only if I purchase over $50.

[mon2]

Ok. I understand. We buy in high volumes so get free shipping for even a $1 purchase. Have been with Arrow for decades. Let us know what is a fair purchase fee for this kit. Will confirm when our office opens. The local taxes will have to be paid by you. That is normal.

[mon2]

You could bump up the order with this kit and add a few usb and ethernet cables to reach the $50 min buy. Just an idea. Or let us know if we can help you.

[retiredfeline]

You could bump up the order with this kit and add a few usb and ethernet cables to reach the $50 min buy. Just an idea. Or let us know if we can help you.

Thanks. Yes, I could buy two. The question really is am I ready for it. I still have to get a round tuit to play with the knock-off MAX10 board I bought some time back. Currently I don't have access to my workbench due to renovations. So I think I'll ignore my FOMO. There'll always be something around the corner.

[woofy]

GBP27.50 + VAT, no MOQ and free shipping to the UK. I couldn't resist.
I can't find a specific data sheet for the 10M50DAF484C6G, but from the part number I'm guessing the 10M50DAF484C6G is just a faster version of the 10M50DAF484C7G.

[ResistorsAreFutile]

OMG, you are comparing a phony slowest MAX10M08CU169C8G (it's a smaller one relabeled as Intel's first 3 MAX10's all have the same die)

How do they pull that one off? Surely the Intel tools won't flash a different part?

[dolbeau]

Can this board run Linux for free?

Linux-on-LiteX-VexRiscv works on the de10-lite, which has a very similar FPGA (10M50DAF484C6G vs. 10M50DAF484C7G) and only 64 MiB SDRAM, so theoretically you could run it on the Deca board. It depends if LiteX can be made to work with the specific implementation of peripherals in this board...

Update: litedram has a generic SDR PHY and specific DDR PHYs, but not for the MAX10 - so for the Deca board the onboard DDR3 is unsupported at this stage :-(

[Scrts]

The Arrow DECA MAX 10 board is now available for $37: link.

Such size FPGA with all the available peripherals is truly a very good price!

I remember running Nios II/f with hardware multiplier, but no MMU on Cyclone III 55kLE part and Nios was around 3700 LEs. So plenty of space for other logic.

[asmi]

I don't really know what I'm gonna do with them, but I ordered a couple anyway I wonder what's the internal flash endurance? How many times can be in overwritten before it goes bust?

[woofy]

I don't really know what I'm gonna do with them, but I ordered a couple anyway I wonder what's the internal flash endurance? How many times can be in overwritten before it goes bust?

I wondered that as well so looked it up, its 10,000 Erase/write cycles/page.
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/max-10/m10_datasheet.pdf
Page 8.

[BrianHG]

OMG, you are comparing a phony slowest MAX10M08CU169C8G (it's a smaller one relabeled as Intel's first 3 MAX10's all have the same die)

How do they pull that one off? Surely the Intel tools won't flash a different part?

Here is what it's like for CycloneIV: https://www.eevblog.com/forum/fpga/quartus-prime-18-1-cant-fit-design-in-device/msg3179082/#msg3179082
I've found out if the lower package IO pin count matches between devices, the die matches.  For any the Cyclones, Quartus cant even tell which device your JTag is connected to, you need to tell Quartus during compile, IE, the limitations Quartus tells you based on your compiled device is purely software limited.  Once the free IO count drops for a given package, the die is different.  Since MAX10 has a built in flash, it may have a hidden fuse or once tricked into a larger device, it becomes that device.

[asmi]

I've found out if the lower package IO pin count matches between devices, the die matches.  For any the Cyclones, Quartus cant even tell which device your JTag is connected to, you need to tell Quartus during compile, IE, the limitations Quartus tells you based on your compiled device is purely software limited.  Once the free IO count drops for a given package, the die is different.  Since MAX10 has a built in flash, it may have a hidden fuse or once tricked into a larger device, it becomes that device.

In Xilinx world each device density have it's own JTAG ID, even though some devices share the same die (there are four different Artix dies - one for 15T/35T/50T, 12T/25T, 75T/100T and the largest 200T). So you can't cross program different densities, however it might be possible to program in different speed grade (which of course with throw away all performance guarantees).

[Jope]

I don't really know what I'm gonna do with them, but I ordered a couple anyway I wonder what's the internal flash endurance? How many times can be in overwritten before it goes bust?

According to the "Intel® MAX® 10 FPGA Configuration User Guide" you can both program the internal flash and the internal configuration SRAM (called CRAM) over JTAG. So you don't have to program the flash every time you want to test something (see page 5 of the configuration manual).

[ResistorsAreFutile]

In Xilinx world each device density have it's own JTAG ID, even though some devices share the same die (there are four different Artix dies - one for 15T/35T/50T, 12T/25T, 75T/100T and the largest 200T). So you can't cross program different densities, however it might be possible to program in different speed grade (which of course with throw away all performance guarantees).

That seems to be how it is with the MAX 10 also. Running a JTAG auto ID gives a list of parts with the same density, but requires the user to pick the feature set (SC, DA, etc) and speed grade.

[Someone]

In Xilinx world each device density have it's own JTAG ID, even though some devices share the same die (there are four different Artix dies - one for 15T/35T/50T, 12T/25T, 75T/100T and the largest 200T). So you can't cross program different densities, however it might be possible to program in different speed grade (which of course with throw away all performance guarantees).

It is possible to program different device densities/utilisations:
https://www.eevblog.com/forum/microcontrollers/artix-7-only-has-three-different-die-sizes/msg837185/#msg837185
The same method should work for other parts. There are no checks for speed grade on most (all?) parts, so its something that needs to be carefully checked before releasing to production!

[asmi]

It is possible to program different device densities/utilisations:
https://www.eevblog.com/forum/microcontrollers/artix-7-only-has-three-different-die-sizes/msg837185/#msg837185
The same method should work for other parts. There are no checks for speed grade on most (all?) parts, so its something that needs to be carefully checked before releasing to production!

Interesting. Still - I would never do something like that for production. Maybe for hacking stuff around, but that's about it. Manufacturer's performance guarantees matter to me much more in production designs than some difference in price. Especially since customer is paying for it anyway. Same goes for speed grade - I don't have equipment to properly qualify my boards over PVT, so I have to rely on manufacturer's guaranteed performance values when creating design.
Another curious fact is that Xilinx apparently planned to have offer higher Artix density (350T), but it was cancelled for some reason.

[BrianHG]

  I'm going over their schematic.  They tied the DDR3 CLK_n&p to a general emulated differential IO pair instead of going right to the PLL dedicated differential outputs.

I know this is functional, but the dedicated PLL outputs are ultra-precise, extra low noise, support to 475MHz, lower temperature phase drift outputs which have direct routing to the PLL, (not to mention that those pins can also be configured as a differential IO) where I can choose a custom offset phase which does not need to be routed throughout the FPGA clocking network.

[asmi]

I'm going over their schematic.  They tied the DDR3 CLK_n&p to a general emulated differential IO pair instead of going right to the PLL dedicated differential outputs.

I know this is functional, but the dedicated PLL outputs are ultra-precise, extra low noise, support to 475MHz, lower temperature phase drift outputs which have direct routing to the PLL, (not to mention that those pins can also be configured as a differential IO) where I can choose a custom offset phase which does not need to be routed throughout the FPGA clocking network.

It could be that they had to do it this way for layout reasons. As you will see shortly, the board is incredibly densely populated in that region.

[BrianHG]

Those FN DAMN BLUE LEDS!!!!!

Whats with everyone and FN blue...
Green would green, or orange and red would have been much nicer and more comfortable to the eyes.

[asmi]

Those FN DAMN BLUE LEDS!!!!!

Whats with everyone and FN blue...
Green would green, or orange and red would have been much nicer and more comfortable to the eyes.

I like blue, it's more comfortable to my eyes than other colors
I guess you can replace them if they bother you so much.

[RoGeorge]

For blue or too bright LEDs, cut a small piece of yellow post-it (from the rubber-glue area) and stick it on top of the LEDs.

[BrianHG]

For blue or too bright LEDs, cut a small piece of yellow post-it (from the rubber-glue area) and stick it on top of the LEDs.

I like working in the dark, they illuminate the entire room and are blinding to look at...
It's ok, I just program them off, or make them extra dim when in use.

[asmi]

I like working in the dark, they illuminate the entire room and are blinding to look at...

This is not good for you eyes. You'd better have some ambient lighting.

[BrianHG]

I'm going over their schematic.  They tied the DDR3 CLK_n&p to a general emulated differential IO pair instead of going right to the PLL dedicated differential outputs.

I know this is functional, but the dedicated PLL outputs are ultra-precise, extra low noise, support to 475MHz, lower temperature phase drift outputs which have direct routing to the PLL, (not to mention that those pins can also be configured as a differential IO) where I can choose a custom offset phase which does not need to be routed throughout the FPGA clocking network.

My mistake, they are using a CLK output port designed to drive a DDR CK & CK# pin (as described by the pin name in the data sheet), though it is not a directly 'PLL' driven port.  I cannot find any 'explicit' description of the pins other than they are DDR IOs.

[slburris]

I ordered and received a couple a few days ago.  But now when I go to the Arrow site, it shows plenty in stock but no longer shows a price, just a “quote” button.  I wonder if they got a bunch of orders from this post and decided it was too much of a good thing?

[migry]

This offer doesn't appear to be available in the UK :-(

Some time ago I saw a reference to this dev board on the channel "MickMake". Then having made regular videos Mick appears to have disappeared completely. It seemed really well featured, had HDMI, so I was interested at the time, but it wasn't available then either. I did check the date of the first posting, as I expected it to be several years old, but nope it was posted in 2021.

[asmi]

This offer doesn't appear to be available in the UK :-(

It looks like it disappeared everywhere. So it was good that I was quick
If you still want one, you might want to PM nockieboy and ask if he will be willing to sell you one as he said he got two.

[asmi]

I ordered and received a couple a few days ago.  But now when I go to the Arrow site, it shows plenty in stock but no longer shows a price, just a “quote” button.  I wonder if they got a bunch of orders from this post and decided it was too much of a good thing?

Yea looks the same on my side. That said, when I placed my order, there were over 2K in stock, and now it's below 1.5K. So they sold at least 500 units in this timeframe.
As for "Quote" thingy, it could be that they ran out of stock in their "hot" warehouse, and have the rest of units at some other facility, and so they require an order to move units out of long-term storage into a "hot" one. Or maybe they've realized that they underestimated the demand, and initiated the move already, so that we can expect to see more items in actual stock in the coming days.

Whatever the reason is, if you want them, it would make sense to request a quote, as they typically come with no obligations to actually complete a transaction.

[Jope]

That said, when I placed my order, there were over 2K in stock, and now it's below 1.5K

I'm sure you are wrong. When I posted the link, there were 1600 and something in stock. So they sold about 100+, but certainly not 500. I checked the stock before I posted the link, because I was interested in how many would order it.

[migry]

OK, I went ahead and asked for a quote. If the price is really low then I could order a couple and try to flog the other one  .

The thing I liked about this board, apart from the HDMI, which I enjoy playing with, despite the demise of the excellent HamsterNZ website, is the I/O expansion is 0.1" which gives lots of spare pins, hopefully enough to wire up a large SRAM (for video memory), since I don't want to go down the DD3 rabbit hole.

On another Terasic board (2nd hand Ebay purchase) I was able to get the NIOS processor to work, but it only works while the JTAG is hooked up. I think that the DDR2(3?) is not a free licenced IP. It would be useful to have a small CPU as part of my FPGA projects, but for the reasons mentioned it won't be a NIOS.

[Jope]

I think that the DDR2(3?) is not a free licenced IP.

Haven't tried it yet, but AFAIK the UniPHY IP core is free and works with this MAX 10 (speed grade 6).

[BrianHG]

I think that the DDR2(3?) is not a free licenced IP.

Haven't tried it yet, but AFAIK the UniPHY IP core is free and works with this MAX 10 (speed grade 6).

Yup, just noticed that the other day.  It should make controlling the DDR3 easy.
I'm looking into the hard custom way.  Come back in 7 days...

[slburris]

Anyone get a response from Arrow?  I've sent several quote requests at different quantities, but they seem to be landing in a black hole.

[Miti]

Anyone in the GTA interested in splitting a purchase?

[up8051]

Anyone get a response from Arrow?  I've sent several quote requests at different quantities, but they seem to be landing in a black hole.

Did you get any response?

[slburris]

Anyone get a response from Arrow?  I've sent several quote requests at different quantities, but they seem to be landing in a black hole.

Did you get any response?

Nope, no response at all from Arrow. 

[slburris]

I finally heard back from Arrow.

“ Thank you for your interest in Arrow.com. In reference to the quote you requested on 2/21/2021.
The requested part is not currently listed and may require further research to quote.”

Say what?  Their site says: Total In Stock: 1,397 parts

They really don’t want to sell these boards.

[RoGeorge]

My guess is the listed stock is only ordered/reserved by Arrow, but not yet in their storage house, so they don't know for sure when they can ship, and at what price will be the new lot, maybe the hardware will be slightly different (e.g. more RAM) and so on.

Since the previous sell was a promotion to liquidate the existing stock, most probably the new price will not be the same.

[migry]

Yep! I got the exact same reply "The requested part is not currently listed and may require further research to quote".

[slburris]

And nearly two weeks later these are still in stock but unorderable from Arrow.  At that price point, I was thinking of a few projects that could use a nice FPGA board.  I could spin my own board, but when someone has already done the hard work for you on SDRAM and HDMI, it’s nice to take advantage of that.

[woofy]

Though I couldn't find a price for the 10M50DAF484C6G, Mouser sells the 10M50DAF484C8G for $137 and the 10M50DAF484C7G for $152. That makes $37 for the DECA an amazing bargain. Someone somewhere had to be subsidising that price, accidentally or otherwise.

[BrianHG]

Public domain DDR3 controller update: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg3533050/#msg3533050

[slburris]

It’s been awhile, so I asked them to quote me 10 boards.  Will they offer them to me for $370?  My bet is they will do the “part is not currently listed” thing again, but we will see.

[Scrts]

Seems like it's back for $37.03. I was thinking to buy it, but decided that I already have too many FPGA kits laying around 

[RoGeorge]

I want to make a Linux virtual machine, to preserve the toolchain and the settings, so to avoid future OS incompatibilities.

The only DECA specific tool (in the CD downloaded from Terasic) seems to be a Windows executable "DECA_SystemBuilder.exe".  It runs in Linux (with WINE), and generates some Quartus project files.  Not sure if there are some other windows specific things that I might have missed.  Also, In the DECA_SystemBuilder generated .qpf file is a line QUARTUS_VERSION = "14.1".  Current version of Quartus is 20.1.

- 1. Which version to install, Quartus 14.1 or the latest 20.1?
- 2. Can this board (and demo projects) be used from Linux?  There are some .bat files in the demos, .bat that apparently only load the demo bitstreams into FPGA, and they seem to have a .sh, too, for Linux, so I don't know if Windows is a must.  (can not test for myself, the board has not arrived yet)

[BrianHG]

I want to make a Linux virtual machine, to preserve the toolchain and the settings, so to avoid future OS incompatibilities.

The only DECA specific tool (in the CD downloaded from Terasic) seems to be a Windows executable "DECA_SystemBuilder.exe".  It runs in Linux (with WINE), and generates some Quartus project files.  Not sure if there are some other windows specific things that I might have missed.  Also, In the DECA_SystemBuilder generated .qpf file is a line QUARTUS_VERSION = "14.1".  Current version of Quartus is 20.1.

- 1. Which version to install, Quartus 14.1 or the latest 20.1?
- 2. Can this board (and demo projects) be used from Linux?  There are some .bat files in the demos, .bat that apparently only load the demo bitstreams into FPGA, and they seem to have a .sh, too, for Linux, so I don't know if Windows is a must.  (can not test for myself, the board has not arrived yet)

Install both Quartus.  The projects will load on the new one, but, once you have done so, it sometimes will not load again backwards in earlier versions.  So, keep a copy of the source files.
The .bat files are there to automatically JTAG program the pre-compiled projects onto the DECA board.  You do not need them.  All you need to do is open the Quartus programmer, select JTAG, load the .sof programming file and program away as the projects on the CD have already been compiled.  Or, you may also open the full project in Quartus and compile, then program.

Windows is not a must.  The projects should run in the Linux build of Quartus.

[RoGeorge]

Great, thanks!   

In this case maybe I should make the VM with Linux and Quartus 14.1 as a fallback, and to keep the VM size reasonable small, and install the latest Quartus on the physical machine.  Not sure yet, will see after working for a while with each version, to spot their ups and downs.

Meanwhile I've found that back then (Quartus 14) it was ~ Ubuntu 12, and apart from the DECA demos CD, there is also a DECA LinuxTutorial pdf for how to put Linux on DECA, and 8 DECA Labs (for bare metal, not Linux):
https://community.intel.com/t5/FPGA-Wiki/DECA/ta-p/735458

[RoGeorge]

-1. On the search page Arrow shows about 1400 pcs of DECA boards on stock, shipping today.
https://www.arrow.com/en/products/search?cat=&q=deca&r=true

-2. On the DECA product page is shown "Ships from US"
https://www.arrow.com/en/products/deca/arrow-development-tools

-3. On my order it is written "Ships from non-US location"

-4. I made the payment 3 days ago, with debit card, the payment was confirmed by my bank a few seconds after finalizing the Arrow order, yet the order is still pending.  All I have is an order number and an email saying they will email a tracking number after processing.  I am ordering from EU/Romania.

-5. Also, the VAT seems wrong (7%), but they say Arrow will pay the shipping and DDP (the email says free shipping with DHL - DDP)

Anyway, no shipment after 3 working days.  I wonder if they really replenished the stock.   

Anybody from EU ordered this month?
How long does it took between payed and delivered (they say one day usually)?

[up8051]

I ordered yesterday, but at this moment has status "Pending".

[RoGeorge]

Today (7 days later) the order status went from pending to "Fully Shipped" (ships from US, NV) and got a DHL tracking number.   

with a SiLabs gesture sensor, placed on the bottom side of the board

Could be on the other side because the pulsing light coming from the rest of the LEDs might blind or confuse the sensor, just a wild guess.

[dolbeau]

-2. On the DECA product page is shown "Ships from US"
-3. On my order it is written "Ships from non-US location"

Mine did a trip from the U.S. to a city in Germany, then went to the Netherlands, then right back to the same city in Germany (and likely the same warehouse...) before shipping to France.

I suspect the reason is that the US-Germany-Netherlands[-Germany] part of the trip was "internal" to Digikey, and it cleared customs "in bulk" as part of an internal shipment between Digikey locations. Then the rest of the trip was to deliver to me, internally in Europe in the common market - so no customs to deal with for me, the customer. And perhaps export control is also a motivation to ship from the "non-US location".

[migry]

Thank you @RoGeorge, 

   I re-visited the Arrow website using your links and they were in stock. I bought 2 off for 75$ including shipping and tax, £55 in local currency, a hell of a bargain for such a well featured FPGA board. I like the fact that it has HDMI, as I have really enjoyed experimenting, thanks to the excellent code and instructions of Mike Field (HamsterNZ). It should be more than powerful enough to host several 80's retro computer designs (with some tweaking).

[migry]

Well I'll be <whatever>!

My two DECA boards arrived at 8.30AM this morning (today is the 26th). I ordered them the same time as my last post on the 22nd at 11PM . £28 each. Wow! The cheapest FPGA boards I have ever purchased.

That MAX10 is quite a meaty FPGA and should be great for some of my retro projects. Currently I'm trying to get audio data islands inserted into a HDMI data stream and something isn't quite right. I might be one bit out, or quite a lot  , there's no way to know. I have done many searches but there is a lack of clear information. I get audio but it is distorted.

The DECA uses an Analog Devices parallel to HDMI transmitter and has separate audio codec. I haven't yet checked the data sheet to see if this chip can pass through data islands. If not I guess I will need to wire up my own HDMI connector to the spare LVDS GPIOs and "bit bang".

[RoGeorge]

Mine just arrived today, too, and WOW!!!   
It certainly looks like an expensive and high quality board.

The blue LEDs are indeed eye piercing bright, so this time I had to use not one, but two layers of yellow post-it paper cut and stick on above any LEDs. 

The included power adapter can work for either 110 or 220V, but the socket is US type.  There is no 220/110 plug adapter included, just saying, not complaining.

I'm quite impressed so far, will give it a ride in the next days and see how it performs.   
Thank you all who pointed out to this devboard.
 

[BrianHG]

The blue LEDs are indeed eye piercing bright, so this time I had to use not one, but two layers of yellow post-it paper cut and stick on above any LEDs. 

I did warn about this a number of posts back...

[RoGeorge]

Just for the docs, former alterawiki com website addresses have become broken links.  For example if one goes to the arrow product page https://www.arrow.com/en/products/deca/arrow-development-tools and clicks on the link "DECA Wiki page" will get a "404 Not Found" error.

The broken link "DECA Wiki page" points to the address https://www.alterawiki.com/wiki/DECA .  To "translate" the old URLs into the current Intel com URL format, replace "www.alterawiki" with "fpgawiki.intel":

Code: [Select]

- [url]https://www.alterawiki.com/wiki/DECA[/url]  <---    404 page not found
- [url]https://fpgawiki.intel.com/wiki/DECA[/url]  <---    will redirect automatically to

- [url]https://community.intel.com/t5/FPGA-Wiki/DECA/ta-p/735458[/url]


[RoGeorge]

To user "extensie":
I can not reply to your PM because your inbox is full.  Please empty your PM inbox.

For me, I had a 10% discount coupon, free shipping and all taxes payed by Arrow as a new Arrow client.  In total payed $40.32  from the lei card. (172.32 lei - the bank automatically makes the currency exchange from lei to USD)

There were no extra payments for taxes or for package delivery, just what I payed to Arrow.  Package had a DHL tracing number.  Bought the board as a private person, not as a company.



Two questions for everybody else, please:

I'm new to the Altera toolchains.  So far I've installed:
- Quartus
- Quartus Help
- Quartus Programmer
- MAX10 support files
- Modelsim

Q1.  Did I missed any?  Are there other useful components I should install for the DECA board?

So far I've downloaded:

The DECA CD-ROM from Terasic (has demo bitstreams, docs and datasheets) https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=944&PartNo=4
- DECA_v.1.0.1_SystemCD.zip

Workshop lessons for DECA, from the Altera wiki https://community.intel.com/t5/FPGA-Wiki/DECA/ta-p/735458
- deca_lab_files.zip

Tutorial for how tu run Linux on the DECA board, from the Altera wiki https://community.intel.com/t5/FPGA-Wiki/DECA/ta-p/735458
- DECA-Linux-Tutorial_15_1.pdf
- Deca_linux_package.zip

Q2.  Did I missed any?  Are there other learning resources worth to know about?

[Daixiwen]

If you plan to have a softcore CPU in the FPGA then you will also need a C compiler for it, and they provide a full Eclipse environment for it. It used to be called the Nios II Software Build Tools, but right now I can't find it on Intel's website and who knows what it is called now. Just be sure to download the one for the Nios II CPU and not the ARM version that is designed for the SoC FPGAs.
Intel's FPGA website is a complete mess and it isn't getting any better.

[RoGeorge]

Didn't got there yet, will keep in mind, thanks!



Regarding the name changes of the components and tools, it seems Quartus 15.1 was the last version with Altera naming, then starting from Quartus 16 the naming was switched to Intel.

Since the DECA training workshop was made with Quartus 15.1, I've installed 15.1 in a Kubuntu 20.04 virtual machine.  Some names of the software components, and some Quartus menu entries are named different in more recent versions, so for somebody that didn't work before with Quartus, I recommend using 15.1 in order to be able to follow the workshop labs.  Not to say 15.1 is smaller in disk size, so it will save you a lot of GB.

The only thing to take care for the Quartus 15.1 to run on recent Linux, is to manually download and install libpng12.

Code: [Select]

=====================
- if missing libpng12.so.0, with Quartus launch error:

    $ ./quartus
        quartus: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory

- Download libpng12 for the correct Ubuntu version from
    - http://ppa.launchpad.net/linuxuprising/libpng12/ubuntu/pool/main/libp/libpng/
    (or e.g. for xenial - https://packages.ubuntu.com/xenial/amd64/libpng12-0/download)
   
    - sudo dpkg -i ./libpng12-0_1.2.54-1ubuntu1.1+1~ppa0~focal_amd64.deb
    (for ubuntu 20.04 focal fossa)



To find out what other Altera components might be there to evaluate, all the extra tools seems to be listed when opening the "Design Software" menu from the official download page:
https://fpgasoftware.intel.com/20.1.1/?edition=standard&platform=linux

Don't count on the drop down boxes called "Select edition:" and "Select release:", they doesn't seem to be working properly (for example when selected the 15.1, only Quartus Standard is displayed to download, for Quartus Litte 15.1, one should navigate to Quartus Lite through the left hamburger menu "Design Software").

For the Q1 answer, I guess following the entries from the download page will reveal all the other tools or components Altera used to have.

For Q2, still looking for more tutorials and/or project links.

[RoGeorge]

Anybody else get this error with the 3rd workshop "Lab 3 - Embedded Systems Lab" from these lessons https://community.intel.com/t5/FPGA-Wiki/DECA/ta-p/735458 :

Code: [Select]

13:17:22 **** Build of configuration Nios II for project LM71_temp ****
make all
Info: Building ../LM71_temp_bsp/
make --no-print-directory -C ../LM71_temp_bsp/
[BSP build complete]
Info: Compiling lm71.c to obj/default/lm71.o
nios2-elf-gcc -xc -MP -MMD -c -I../LM71_temp_bsp//HAL/inc -I../LM71_temp_bsp/ -I../LM71_temp_bsp//drivers/inc  -pipe -D__hal__ -DALT_NO_C_PLUS_PLUS -DALT_NO_INSTRUCTION_EMULATION -DALT_USE_SMALL_DRIVERS -DALT_SINGLE_THREADED    -O0 -g -Wall   -mno-hw-div -mno-hw-mul -mno-hw-mulx  -o obj/default/lm71.o lm71.c
In file included from ../LM71_temp_bsp//drivers/inc/altera_avalon_pio_regs.h:34:0,
                 from lm71.c:40:
lm71.c: In function 'main':
lm71.c:54:7: error: 'TEMP_LM71CIMF_BASE' undeclared (first use in this function)
  IOWR(TEMP_LM71CIMF_BASE, WRITE_MODE, 0xffff);  //set shutdown
       ^
../LM71_temp_bsp//HAL/inc/io.h:70:23: note: in definition of macro '__IO_CALC_ADDRESS_NATIVE'
   ((void *)(((alt_u8*)BASE) + ((REGNUM) * (SYSTEM_BUS_WIDTH/8))))
                       ^
lm71.c:54:2: note: in expansion of macro 'IOWR'
  IOWR(TEMP_LM71CIMF_BASE, WRITE_MODE, 0xffff);  //set shutdown
  ^
lm71.c:54:7: note: each undeclared identifier is reported only once for each function it appears in
  IOWR(TEMP_LM71CIMF_BASE, WRITE_MODE, 0xffff);  //set shutdown
       ^
../LM71_temp_bsp//HAL/inc/io.h:70:23: note: in definition of macro '__IO_CALC_ADDRESS_NATIVE'
   ((void *)(((alt_u8*)BASE) + ((REGNUM) * (SYSTEM_BUS_WIDTH/8))))
                       ^
lm71.c:54:2: note: in expansion of macro 'IOWR'
  IOWR(TEMP_LM71CIMF_BASE, WRITE_MODE, 0xffff);  //set shutdown
  ^
make: *** [Makefile:775: obj/default/lm71.o] Error 1

13:17:22 Build Finished (took 488ms)


There are 4 program examples written in C for the "Lab 3 - Embedded Systems Lab", the ones included with the lab files:
- hello_led.c
- cap_sense_example.c
- rh_temp.c
- lm71.c

Each C file is for a different Eclipse software project running on the same NIOS II hardware.  I could compile and run the first 3 projects with no errors, except for the LM71 one.

Any ideas why the error, and why only with the LM71 file?

[RoGeorge]

Found it!   

When adding in Qsys the IP called "TEMP_LM71CIMF", the default instantiated IP's name was "TEMP_LM71CIMF_0", with an "_0" suffix added automatically (which suffix is usually incremented at each new instantiation of the same IP).  However, the instantiated name must be renamed to "TEMP_LM71CIMF" (suffix removed).

In the lab's PDF guide https://www.intel.com/content/dam/altera-www/global/en_US/uploads/d/da/3_Embedded_Systems_Lab.pdf (Chapter 3.4.20 - Add the temperature sensor component) the renaming step is missing, yet the following Qsys printscreen and the zipped files with their completed project shows the suffix was removed.

Seems like the C macros used in the BSP files doesn't work as expected when the instantiated IP name has that suffix "_0", suffix that is added automatically by Qsys.
 



Later edit:
--------------
AS Daixiwen pointed out in the next reply, the macros and the BSP files are just fine.

In my case, the "TEMP_LM71CIMF_0" had to be renamed only to match the names provided in the C code example provided by the "lm71.c" file.  The naming must correspond, so one could either adjust the IP name, or the C code.

[Daixiwen]

They do work but you'd need to add the _0 in the BASE parameter:

Code: [Select]

IOWR(TEMP_LM71CIMF_0_BASE, WRITE_MODE, 0xffff);  //set shutdown

[RoGeorge]

Now it makes sense, thank you.   

I've dig for a while through the header files like system.h to see the expected names, but I guess this is not the way.

How and where does one find the expected naming without code examples?
Are there any docs specific to each IP, or docs for generic naming rules to follow?

[Daixiwen]

The macros usually just take the component name, uppercase it and add prefixes to generate the different constants in system.h. The actual constants generated can change depending on the IP type, but all IPs have at least the base address declared as *_BASE.
A lot of the IPs available in QSys are documented here: https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_embedded_ip.pdf and some more specialized IPs have their own documentation.

[RoGeorge]

Great, thanks again!
Will browse the doc.

I was trying to find the same pdf corresponding to Quartus v15.1 (the version I am using with the DECA board).  I don't expect big differences, only hoping for a more concise pdf with less pages.

Since the former Altera website is now hosted inside the Intel website, most of the Quartus doc buttons and links are now redirecting to some generic unrelated Intel page.

I was trying to see if there's any doc installed locally, and a search inside the Quartus 15.1 install folder

Code: [Select]

find ./ -iname "*.pdf" | wc -l returned 142 pdf files.   

Xilinx use to have a dedicated tool called Xilinx Documentation Navigator, able to download their documentation locally, and keep track of various pdf versions and their content, the tool was also able to search inside all the pdf files without opening each one.  I've googled and couldn't find if there is something similar for Altera.

Is there any "Documentation Navigator" for Intel Altera, or some other tool similar in functionality with the Xilinx one?



Found another small mismatch in the lesson 4 files.  In "4_Gesture_Sensor_Lab" files, the C and header files starts with capital letter, while inside the code they are written in lower letters, for example inside "Si114x_functions.c" there is an attempt to include "si114x_functions.h", while the provided file is called "Si114x_functions.h".

In Linux the file system is case sensitive, so it won't find that header file.  Same files will probably work OK in Windows (IIRC Windows file system will only preserve the case, but it is not case sensitive).

[RoGeorge]

Found various versions of UG-01085 (Embedded Peripheral IP User Guide).
- 2014.24.07 - 336 pages
- 2015.11.06 - 480 pages
- 2016.12.19 - 538 pages
- 2021.03.29 - 579 pages

It has had more than 40% increase in the number of pages between 2014 and 2015, thought diffing the ToC there's not much difference.

[wilfred]

I ordered a couple of these and my order has been stuck for a week now in "Submitted" status. Is this to be expected with Arrow and I just need to be patient?

I'm in Australia, I paid with Paypal and the funds are not yet withdrawn from Paypal. I am eligible for free Fedex shipping and I got the first order 10% discount. The website lists stock at more than a thousand.

I sent a message and only have an automated reply saying that replies are delayed due to Covid.

Is this to be expected with Arrow and I just need to be patient? Or is there some action I can do to shake things loose. Thanks


Edit: I got a Fedex tracking number today (18th May). That is a delay to ship of about 9-10 days.

[RoGeorge]

For my order (EU/Ro w debit card) it took 7 days for the order to change from "Pending" to "Fully Shipped".
Overall, the board was ordered on 14th and arrived on 26th.

[wilfred]

Thanks. And thanks for your posts here. I'm making notes.

[RoGeorge]

Two more remarks about the DECA board and the workshop:
- both onboard temp sensors are heated by the PCB, so they rather measure the PCB temperature than the room temperature.
- in the "6_USB_to_SDHC_Lab" of the workshop there is an encrypted proprietary IP, with a license file provided in the project's folder.  However, the license is valid up to 2015-Aug-31, so it won't be valid in 2021.  If you just set the datetime year back to 2015, FlexLM will notice the date was set back, and the provided license .dat file still won't work.  I didn't bother to reinstall everything clean like it would be 2015, because the workshop doesn't teach anything new anyway.  "6_USB_to_SDHC_Lab" is more like a demo than like a lesson.  The project can still be run with the already existing bitstream if you unzip the "6_USB_to_SDHC_Lab_Completed.zip" files instead of "6_USB_to_SDHC_Lab.zip".

If any Linux users bother running that 6th lab, it will appear as "SLS USB2.0" removable device (so the new USB device won't need to be added to the udev rules, like the programmer needed to be added to the udev rules).

Code: [Select]

~$ lsusb
Bus 001 Device 005: ID 1772:0002 System Level Solutions, Inc. USB2.0
Bus 001 Device 004: ID 09fb:6010 Altera Arrow MAX 10 DECA



Just for the docs, by default Linux denies access to any place or device that was not explicitly specified as granted access.

Some USB devices, like the removable USB storage type, are already granted by the OS setting (like Ubuntu use to do).  However, for other hardware devices like the JTAG programmer of this DECA board, access is not granted by default.  An udev rule is required in order to grant access to the JTAG programmer, or else the device can only be seen by lsusb, but can not be used.

My udev file "/etc/udev/rules.d/51-usb-blaster-etc-udev-rules-dot-d.rules" added more devices, but for the DECA board only the line for "09fb:6010" should be enough.  This is the content of the .rules file, copied from an online blog I don't recall, sorry for the lack of proper credits:

Code: [Select]

# USB Blaster
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6001", MODE="0666", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", RUN+="/bin/chmod 0666 %c"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6002", MODE="0666", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", RUN+="/bin/chmod 0666 %c"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6003", MODE="0666", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", RUN+="/bin/chmod 0666 %c"

# USB Blaster II
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6010", MODE="0666", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", RUN+="/bin/chmod 0666 %c"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6810", MODE="0666", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", RUN+="/bin/chmod 0666 %c"
This .rules file is not something for "6_USB_to_SDHC_Lab" only.  The udev file is required for any workshop or demo of this board when used from Linux, or else the JTAG programmer can not be accessed.  No additional drivers required for Linux (in contrast with Windows, which requires JTAG drivers to be installed), but udev rules must be created manually. 

Didn't mention this before because this is the usual thing to do in Linux for any new USB devboard or other unknown USB devices, not just for this DECA board.

[SuperFungus]

Have not tried it yet, but I noticed that there is a tutorial for targeting this board using the Clash HDL: https://clash-lang.org/blog/0006-deca-starter/

[SiliconWizard]

So, anyone here having now experience with the MAX10 and who could share opinions?

[RoGeorge]

I absolutely loved it.  Worth every penny.  Highly recommended to anyone interested in FPGA.

The FPGA is quite generous in size, the board has lots of onboard peripherals to play with, has gesture detector, ADC with analog level shifting (that allows +/- voltage input, not only positive voltage like the usual ADC), accelerometer, humidity sensor, etc.  It even has 512kBytes of DDR3 and can run Linux if you want, and it is built very nicely, with high quality parts.  Even the packaging was impressive.  Also, it's a bargain for that price.

There are some free classes/workshops I found to be very usefull to get one started with this board, and with Quartus IDE in general.

OTOH, it's still an FPGA, so harder to start with than a casual Arduino board, it's a steep learning curve and it's about hardware mostly not about programming like other microcontroller based devbords.  Thought, one can place an MCU core inside, or maybe a few, and write C for them.  Has even a debugger, not like Arduino that still doesn't has a debugger after so many years.

That workshop was very important to follow (I posted links to it here, somewhere in the previous posts), without that workshop to me would have been a more cumbersome start, because I didn't use Quartus before.  Now I like it, honestly I like it more than Vivado, no idea why, sorry Xilinx 

About the Quartus license, the free one is enough, and as a side note, the commercial licenses from older versions can still be used for newer versions of Quartus.

I highly recommend to use the exact version of Quartus used in that workshop if you are new to Quartus, because in the newer Quartus there are a few cosmetic changes in the menus and the naming of those menus than they use in the workshop.  Otherwise the workshop still applies, except one or two lessons where they used a time limited license for a demo hardware IP I didn't care about anyway.

Requires more determination than other devboards, but it's a fun toy to play with, good for both learning or projects.
Go get one, you wont regret!   

[Mechatrommer]

subscribing... why https://www.arrow.com/en/products/deca/~/media/3c3f9da78c4b4b8d880a68fcb7a4e4cf.ashx is blank to me? (linked from https://www.arrow.com/en/products/deca/arrow-development-tools)

[RoGeorge]

Same here, first link is a a blank page.  Probably because the board was launched in 2015, and since then Altera was bought by Intel, and Arrow probably upgraded or migrated their website many times since then.  I remember not all links from arrow were working when I start learning about the board.

Even the wiki pages from the former Altera were moved.  They are still available, but now they are inside the Intel website.  So if you google or find info with links to former Altera, there is a way to translate that links to the current site.  Most of the times it worked, if not try searching for the same words and restrict the results to be from "site:intel.com" only.  I posted somewhere in this thread how to translate the links, but that is only from Altera to Intel wiki pages, no idea how to find the missing Arrow pages.

Anyways, I remember most of the Arrow links were pointing to the same info that can be find either in the CD that can be still downloaded from Terasic (they manufactured the board), Altera wiki or Intel.

What was the text you clicked for that blank page?

[steamedhams]

Has anyone found a camera that works with this MIPI connector? 

[Mechatrommer]

What was the text you clicked for that blank page?

its in the line where..
"Getting Started:
Click here to download the DECA lab materials.  Includes software and hardware lab manual and source files."

i'm like a baby expecting to be spoonfeed here. i expect some place that teach me everything from downloading what IDE to use, some hello world example and then what device/programmer and how the connection to do programming, exactly like arduino guide for dummy. i bought china fpga dev kit module few years ago for pennies but never got into the game ever, mostly i think due to many other tasks to do and enthusiastic to learn fpga is very downhill due to lack of these fpga for dummies guide, or i may not search hard enough or never found it... i can print a vhdl/verilog book however thick they are to learn the programming but what for? if i cant get the toolchain right (transfer the code to hardware) i might be lacking some programmer hardware that i'm not aware of then i might be chasing my own tail..

from time to time i browsed some fpga dev kit but they are unreasonably expensive, let alone the license and IP legal issues on SW/IDE side which makes things look scary... i downloaded few version of quartus trying to get acquainted but never got a clue, hence i have few GBs of idle storage here storing them.. now this deca dev kit is very teasing at much less than $50, but then, its not available where i used to purchase online (i'm not sure if i register in their website, if they even want to ship to my country) and its official dummy guide is missing. i can see some guide links in this thread thumbs up, i will get back to this... i'm sorry for myself, who else?... so i'm just subscribing here to get the latest update, not much more... this thread is few months already but i missed it, how ironic?...

[RoGeorge]

What was the text you clicked for that blank page?

its in the line where..
"Getting Started:
Click here to download the DECA lab materials.  Includes software and hardware lab manual and source files."

Don't know what it was there, but the main links to start with this board could be this one instead:  https://www.eevblog.com/forum/fpga/arrow-deca-max-10-board-for-$37/msg3559571/#msg3559571



Download and install http://Quartus 15.0, not newer or else the workshop lessons won't match with the IDE, then try this workshop and see if it makes sense:
https://community.intel.com/t5/FPGA-Wiki/DECA/ta-p/735458

There are a few more links in the workshop wiki page, but the workshop I am talking about starts somewhere in the middle of the webpage, where it says:
"

Workshop Reference Designs
Lab 1: FPGA Intro Lab

    A step-by-step guide to FPGA design using Quartus II

"

Read the Lab Document PDF, then try to practice on your installed Quartus, even without the board, to see if it makes sense for you.

To program this board you don't need an external programmer.  The board has an onboard JTAG programmer and a USB cable.  Plug the USB and that's it, to program the board just click the right menus from Quartus (it is explained how in the PDF).

[BrianHG]

All software DDR3 controller update....

16 read, 16 write ports with smart cache, configurable priority encoding and data width per port done.
4096x2160 screen scrolling on a 1080p 32bit color out HDMI with geometry test drawing program done.
Auto DDR3 PLL calibration finally done.

  !!!400MHz with data integrity!!!   With a +/- 3 PLL tuning step valid data window.

Yes, Altera/Intel's software DDR3 solution is only rated at 300MHz.  Not even the minimum 303MHz rated by the DDR3 spec.
It also only has a single read and write port.

It's Altera's hardware dependent PHY which has multiport and runs at 400MHz.

Things left to do:
Upgrade my software FIFOs in my multiport module as they currently have a bottleneck of 125MHz because of the way they are written.
Improve the cross clock domain boundary as the DDR3 sequencer sends commands to the DDR3 CK clock domain.  (The solution I'm looking at might get the DDR3 running at 500MHz on a -6, but definitely working at >300MHz on a -8, even on old Cyclone III & IV.)
The goal for the above 2 is at least 300MHz allowing for a 'Full Rate' controller where as if you want the 400MHz (officially overclocking Altera's IOs), you will probably need to run it at 'Half Rate', or 'Quarter Rate'.

Without the Multiport module, IE, directly communicating with my DDR3 controller, 1 read & 1 write port, the controller consumes just under 3K logic gates for a 16bit DDR3 ram chip.  And it is smart, keeps banks open and aware when you access across banks, it will keep banks open if it can, only close and open individual banks as it needs to.

I should be ready to post the source next week.

[andybrandi]

The Arrow.com shop is asking for a valid VAT ID, even when ordering as a private customer. Is there any way to get around that?

[RoGeorge]

Somebody else from Poland was asking about the same thing on PM.

I didn't need a VAT ID three months ago when I bought mine, but it seems something has changed since then.

[BrianHG]

This is just a test demo of my DDR3 controller with 32 bit color 1080p display and a ellipse geometry drawing processor.

I have attached 2 demo files for to test in the .zip archive.

They are .sof programming files, so, all you have to do is:
Open the Altera programmer,
Select the DECA JTAG programmer,
Make sure the programmer is set to JTAG mode.
And add only 1 of the files and program.

There are 2 files, a good one and a lemon one.

The good one should generate a picture holding a 32 megabyte 4096x2160x32bit bitmap.

Switch 0 should enable/disable the drawing of ellipses.  (Power-up with the ellipse draw disabled and see what the DDR3 ram's memory looks like un-initialized.)
Switch 1 should enable/disable the scrolling over the 4096x2160 bitmap on the 1080p output.

Button 0 should render random static into the bitmap.
Button 1 should render a colored test pattern into the bitmap.

Please inspect for any garbage around the left&right border carefully as it draws.  I need to use a 30 foot HDMI cable because of my setup location and that cable leaves speckles throughout my picture.  The output should be clean but I cannot tell for sure if there are buffer under/over-run bugs while drawing, but it does look perfect.

The lemon file should make a red-orange-green pattern.  If so, I have a coding bug.  If it draws the ellipses at half speed, then my coding is good, but, I have a lemon FPGA.
I tried re-compiling in Quartus 15.0, but, there it crashes right at the last 'assembler' step.  (Besides compiling really slow compared to Quartus Prime.)  I'm downloading Quartus 15.1 to see if it crashes.

If anyone is willing to wire up the RS232 for use with my RS232-Debugger code here: https://www.eevblog.com/forum/fpga/verilog-rs232-uart-and-rs232-debugger-source-code-and-educational-tutorial/msg2801388/#msg2801388

This is the wiring:
TXD out of the DECA board to PC is on pin GPIO0_D[1].
RXD into DECA board from PC is on pin GPIO0_D[3].

The contents on 'In0' at the bottom left of my debugger is of use to me, but not crucial.

Please let me know the results.


In the lemon file, the DDR3 is still working fine as the RS232-Debugger can read and write to it, but, the read-requests on the display port are being dropped or ignored and it should work fine.  The bug is affecting my multi-port module, but all I did was run the section at 1/4 speed instead of half speed.  Cycling the software reset in the RS232 debugger sometimes brings up a frame on the display, but it then dies instantly and yet it simulates properly.  This is a fishy problem where multiple command FIFOs and selection priorities interact and there isn't an effective way to simulate the millions of cycles to generate the crash in Modelsim.
There are other weird sings where some compile builds fail to do anything just by changing a simple parameter or compiler option which should have no bearing on the functionality, so I am wondering what is going on.

It should take a few more days to find this bug, then I will release the full source code on a new thread here.

Link to patched V2 code: https://www.eevblog.com/forum/fpga/arrow-deca-max-10-board-for-$37/msg3601248/#msg3601248

[BrianHG]

Ok, after a report on both demo files failing to show the ellipses on someone else's DECA board, it appears my multiport code is unstable as it seems to completely seize up when receiving too many requests too fast.

You would think this shouldn't be able to happen.  Though, I did manage to get my code to compile in Quartus 15 and it also seized up.  So much for this warning:
'Warning (334000): Timing characteristics of device 10M50DAF484C6GES are preliminary'

Preliminary?  Compiled with Quartus 20.1.  Still? For a 5 year old FPGA?


Note on the blue status LEDs:
LED4 = reset released and PLL is locked.
LED2 = DDR3 controller read calibration has passed and the DDR3 is ready to use.
LED5 = Power-up initialization complete, DDR3 ready to use.

If these 3 LEDs are on and you only see the junk red-orange-green test pattern, then it's my multi-port code which has seized up.  It looks like it may be a cross clock domain meta-stability issue which wont show in my Modelsim simulations.

[RoGeorge]

'Warning (334000): Timing characteristics of device 10M50DAF484C6GES are preliminary'

Preliminary?  Compiled with Quartus 20.1.  Still? For a 5 year old FPGA?

IIRC from the datasheet there's no -6 speed grade commercially available.

I took it as being some sort of engineering sample.  It will make no sense commercially to fully characterize something that will never be available for sale.  It will always remain preliminary, never guaranteed, only good enough when using -6 speed grade to develop designs that will be deployed on lower speeds grades only.

[BrianHG]

Ok, this version of the DDR3 demo should work.

I've included a build in Quartus 15.0 and Quartus 20.1.

If anyone sees the lemon red-to-green failure image, please let me know which build failed and which blue LED #s were lit up.

Attached files below.


Really had to make individual latched nets for some control signals which cross clock domain boundaries.  A bunch of them.  If these demos work, then there is just some cleaning up to do and I will be ready to post the full source code & examples.


(If the picture is still or scrolling noise, just flip 'Switch 0'.  You just powered up the demo in frozen picture mode and you are looking at the powered up random blank memory.)


Switch 0 = Enable/Disable drawing of ellipses.
Switch 1 = Enable/Disable screen scrolling.
Button 0 = Draw data from random noise generator.
Button 1 = Draw color image data from a binary counter.

[Wiljan]

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

[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

[BrianHG]

          
  500MHz/1GTPS
          

Error free, well, on my DECA board anyways...
So much for Altera's software DDR3 300MHz limit.
Though, the reported FMAX at 0C reads only 461MHz.
(This basically means 400MHz can now clear 85C model with 0 timing violations)

If anyone here would like to test my 1GHz controller for me on their DECA board, get the .sof programming file here and let me know:  (Please report any errors, 1GHz on a Max10 software controller should be impossible)
https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3630084/#msg3630084

[SpacedCowboy]

Deca board supposedly arriving on Wed, Brian. I’ll try and give it a go

The only downside to this board seems to be that they’re not manufacturing the device any more (according to digikey, anyway) so presumably the price reflects a “clearance sale” to get rid of inventory. Perhaps that explains some of the delivery woes as well…

[BrianHG]

It's just the particular -6 which isn't available anymore, here are the currently available, (well not in stock) but still being made:

https://www.digikey.com/en/products/filter/embedded-fpgas-field-programmable-gate-array/696?s=N4IgjCBcoLQExVAYygFwE4FcCmAaEA9lANogCcIAugL7X4KSkBmADgOYCGABGAAwC2AVl5V8ANkQgAlgBMoIGHwj4WqeSHyoAni2zyOAZxS0gA

You can compile -7/-8 as a -6 & program, well, in the past I had no trouble making -8 operate faster than a -6.

My DDR3 code will run on a -8 up to 350MHz officially and to 400MHz on a -7 officially if you are willing to adjust the compiler settings and wait a little longer for the final build before production.  Otherwise, having a around 5-10 timing signals in the red by ~0.200ns on one clock only at 85C doesn't seem to affect my controller as the FPGA never gets that hot.

Also, I just finished testing Cyclone IV, it performs around 5-10% faster than the equivalent MAX 10.  With effort, you can get it to do a true 450MHz with all timing in the black.  No code changes.

Cyclone III has also been tested and it has same speed as the Max10, but you will need to go back to Quartus 13.0sp1.

I'm having trouble with Cyclone V because it has a different PLL and it's slower.

Here are the available Cyclone IV, (Basically the same as the MAX 10, but you need an external serial bootprom.)

Here are all the available CycloneIVs
https://www.findchips.com/search/ep4CE
When you see stock, do not click on the link and go to your distributor's website directly and re-type the number, otherwise some distributors like DIGIKEY will give you a false increased price just from linking in from 'FindChips'.

Right now, only Mouser seems to have any stock of larger Max10.
https://www.mouser.ca/c/semiconductors/programmable-logic-ics/fpga-field-programmable-gate-array/?q=max+10+fpga

Stay away from the few C9 fpga, I have not tested with them and they are usually for slow low power applications.

[Miti]

If anyone here would like to test my 1GHz controller for me on their DECA board, get the .sof programming file here and let me know:  (Please report any errors, 1GHz on a Max10 software controller should be impossible)
https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3630084/#msg3630084

I tried it on my Deca board and it works fine. The blue LEDs 2 to 7 are on.
Even though I will probably never need it, thanks Brian!

[asmi]

Here are all the available CycloneIVs
https://www.findchips.com/search/ep4CE
When you see stock, do not click on the link and go to your distributor's website directly and re-type the number, otherwise some distributors like DIGIKEY will give you a false increased price just from linking in from 'FindChips'.

No it doesn't. It redirects you to DK's canadian website and so the price is in CAD$, same as on FindChips. I just verified it, the price is the same as you would see if you just search on DK's canadian website.

[BrianHG]

If anyone here would like to test my 1GHz controller for me on their DECA board, get the .sof programming file here and let me know:  (Please report any errors, 1GHz on a Max10 software controller should be impossible)
https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3630084/#msg3630084

I tried it on my Deca board and it works fine. The blue LEDs 2 to 7 are on.
Even though I will probably never need it, thanks Brian!

6 out of 8 LEDs @1GTPS, shit that's good for a FPGA which supposed to only go to 600MTPS.

[BrianHG]

Note that each on LED represents 22.5 degrees tuning step where after 256 consecutive read burst tests, no data bit errors were found.  IE: 8 on leds/steps would be the perfect maximum possible 180 degrees of error free read clock phase tuning positions.

6 LEDs = 45 degree phase has read errors, 135 degrees with valid read data.

My DECA board runs that code with 5 LEDs, 67.5 degrees with read errors, 112.5 degrees with valid data.

[SpacedCowboy]

So the board turned up - not bad since I ordered it on Sunday - and FREAKING $DEITY DOING DONUTS ON A UNICYCLE. Those blue LED's !!!

[sigh] Resistors, that's all it would take... I'm sure there's a competition amongst board designers to get the brightest, center-of-the-sun-brilliance LEDs onto their boards. Anyway, time to install Quartus this evening and see how it goes - you know, if I'm not blind by then.

I'm assuming the best one to install is the latest one (I've used Xilinx, Lattice and Efinix software, but strangely never Intel née Altera before...)

[BrianHG]

So the board turned up - not bad since I ordered it on Sunday - and FREAKING $DEITY DOING DONUTS ON A UNICYCLE. Those blue LED's !!!

[RoGeorge]

Yep, that research should have been locked in safe.  Giving a Nobel prize for it led to the killer LED.   

The resistors are hard to replace.  Cut a small piece of yellow post-it, about the size of all the 8 LEDs together, and stick it on top.  If still too bright, repeat.   

[TK]

I'm assuming the best one to install is the latest one (I've used Xilinx, Lattice and Efinix software, but strangely never Intel née Altera before...)

You might have better experience with the DECA board installing 16.1. I tried version 20 and it did not have the project templates for the DECA board. You also need to download the board CD from Terasic to run some demo. If you are creating empty projects with MAX 10 support, then latest version should be fine

[BrianHG]

If you are a beginner with Quartus, begin with the Q16.1 and scan back 3-4 pages on this thread for all the source install files.

If you know how to use Quartus, Q20.1 is fine.  The DECA cd projects will still load and be upgraded to Q20.1.

Alsom if you are beginning a project from scratch, the .qsf files on the DECA CD projects contains the pinout definitions while any top hierarchy .v file will have all the IO defined.

Note that you can install multiple versions of Quartus.  They do not interfere with each other.

[SpacedCowboy]

Looks like I'm diving into the deep end with 20.1 (which installs fine). I can't get 16.1 to get past the 'Installing Quartus Prime Help 16.1.0.196' dialogue - it runs the installer, and the log file looks clean...

Code: [Select]

Log started 08/24/2021 at 22:54:28
Preferred installation mode : unattended
Trying to init installer in mode unattended
Mode unattended successfully initialized
Preparing to Install
Preparing to Install
Unpacking files
Unpacking files
Unpacking files
Installing Quartus Prime Help files...
Executing /raid/opt/Quartus/16.1/quartus/common/help/unzip -q -o "/raid/opt/Quartus/16.1/quartus/common/help/webhelp.zip"
Script exit code: 0

Script output:
 

Script stderr:
 

Creating Uninstaller
Creating uninstaller 25%
Creating uninstaller 50%
Creating uninstaller 75%
Creating uninstaller 100%
Installation completed
Log finished 08/24/2021 at 22:54:37

... but the dialogue won't actually dismiss, and the installation just hangs (see thumbnail...)

 

The only thing I can do is click on 'Cancel' in the parent installer window, which then runs the uninstaller (!) so I end up without anything installed ...

Well, 20.1 installs fine. I'll just have to muddle through

[BrianHG]

Try installing 16.0 first.  16.1 might need a registry entry from 16.0.

I've successfully installed 13.0, 15.0 and 15.1 on a 64bit windows.

I believe that the DECA were done in Quartus 14.1.

[TK]

Looks like I'm diving into the deep end with 20.1 (which installs fine). I can't get 16.1 to get past the 'Installing Quartus Prime Help 16.1.0.196' dialogue - it runs the installer, and the log file looks clean...

Code: [Select]

Log started 08/24/2021 at 22:54:28
Preferred installation mode : unattended
Trying to init installer in mode unattended
Mode unattended successfully initialized
Preparing to Install
Preparing to Install
Unpacking files
Unpacking files
Unpacking files
Installing Quartus Prime Help files...
Executing /raid/opt/Quartus/16.1/quartus/common/help/unzip -q -o "/raid/opt/Quartus/16.1/quartus/common/help/webhelp.zip"
Script exit code: 0

Script output:
 

Script stderr:
 

Creating Uninstaller
Creating uninstaller 25%
Creating uninstaller 50%
Creating uninstaller 75%
Creating uninstaller 100%
Installation completed
Log finished 08/24/2021 at 22:54:37

... but the dialogue won't actually dismiss, and the installation just hangs (see thumbnail...)

 

The only thing I can do is click on 'Cancel' in the parent installer window, which then runs the uninstaller (!) so I end up without anything installed ...

Well, 20.1 installs fine. I'll just have to muddle through

what OS are you using?

[SpacedCowboy]

I'm running Linux (in this case Ubuntu 20.04 LTS, on a real machine, not a virtualized one).

Seems like RoGeorge had it working in 15.1 (which the examples are for) so I might try that one as well...

[TK]

I'm running Linux (in this case Ubuntu 20.04 LTS, on a real machine, not a virtualized one).

Seems like RoGeorge had it working in 15.1 (which the examples are for) so I might try that one as well...

Ubuntu is unsupported. It still runs but you need to do some additional installations and setup to run modelsim-altera. Google how to run quartus and modelsim on ubuntu 20

[BrianHG]

Without Modelsim, you wont be able to do any serious engineering.

[SpacedCowboy]

Thanks folks.

I'd foolishly looked at the supported operating system matrix, seen that Ubuntu 20 LTS was on there and had a tick next to the Lite version, and not read further down the rows to see that Modelsim was a separate line-item.

Doing this now, it seems like Nios EDS is only supported on old-SUSE (or Windows) as well, and I was kind of hoping to embed a soft processor into the fabric...

Perhaps I'm best off swallowing down my loathing for all things Microsoft and spinning up a Windows-10 license in a VM.

[TK]

I followed instructions similar to this one: https://pcotret.github.io/modelsim-ubuntu/ and was able to run modelsim-altera on ubuntu 20.4 

The main issue is that modelsim-altera requires some 32-bit libraries that are not included in ubuntu.  The hack is to download the required libraries sources, compile in 32-bit mode, copy them into some directory and modify a script that launches modelsim.

I agree that the best option is to run it on Windows.  Everytime I get some strange error message on modelsim, I suspect it is due to running it on ubuntu, but it ends up being a different reason, but you are always suspecting it is ubuntu...

[BrianHG]

Give Modelsim running stand-alone a test with a test-bench I wrote here:
https://www.eevblog.com/forum/fpga/systemverilog-example-testbench-which-saves-a-bmp-picture-and-executes-a-script/msg3465172/#msg3465172

To test if the Altera embedded libraries are working, you can run one of the test-benches in my DDR3 thread.

As for running Modelsim through Quartus, you will have to do that one on your own.
(I might add a PLL Modelsim tb which can be run through Quartus in my upcoming DDR3 release.  All my other DDR3 YBs were designed to run with Modelsim stand-alone.)

[RoGeorge]

Perhaps I'm best off swallowing down my loathing for all things Microsoft and spinning up a Windows-10 license in a VM.

That will be a funny setup, given that, AFAIK, the FPGA toolchains for either Xilinx or Altera were always developed on Linux, then ported to Windows, too.   
Same for Modelsim.

On whatever OS you are using now, make a new virtual machine with a clean install of Ubuntu 20.04LTS.  I used Kubuntu and VirtualBox, but that's irrelevant.  Choose whatever you like most.  It takes at most 30 minutes and about 4GB.  That's nothing compared with the rest of the Altera installers.

That will give you the ability to make snapshots of the whole virtual machine, and to roll back from where you left in case any install doesn't work as expected, or in case you choose wrong installing option.  It will also give the advantage that you can isolate the virtual machine from internet, so to be sure 10 years from now no update will ever mess your install.

There is no visible loss in performance for a virtual machine.  And if you'll ever need more, you can allocate more processors, RAM or disks later.

There are 2 types of installers for any Altera version, one huge, and one where you install only what your board can use.  Use the former one.  From my the logs, I've used these components:

Code: [Select]

        https://download.altera.com/akdlm/software/acdsinst/15.1/185/ib_installers/QuartusLiteSetup-15.1.0.185-linux.run
        https://download.altera.com/akdlm/software/acdsinst/15.1/185/ib_installers/ModelSimSetup-15.1.0.185-linux.run
       
        https://download.altera.com/akdlm/software/acdsinst/15.1/185/ib_installers/max10-15.1.0.185.qdz
       
        https://download.altera.com/akdlm/software/acdsinst/15.1/185/ib_installers/QuartusHelpSetup-15.1.0.185-linux.run
        https://download.altera.com/akdlm/software/acdsinst/15.1/185/ib_installers/QuartusProgrammerSetup-15.1.0.185-linux.run


2021-04-30 04:22, Fri
=====================
- if missing libpng12.so.0, with launch error:

    $ ./quartus
        quartus: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory

- Download libpng12 for the correct Ubuntu version from
    - http://ppa.launchpad.net/linuxuprising/libpng12/ubuntu/pool/main/libp/libpng/
    (or e.g. for xenial - https://packages.ubuntu.com/xenial/amd64/libpng12-0/download)
   
    - sudo dpkg -i ./libpng12-0_1.2.54-1ubuntu1.1+1~ppa0~focal_amd64.deb
    (for ubuntu 20.04 focal fossa)



2021-05-02 01:47, Sun
=====================
- install wine in order to be able to run the DECA_SystemBuilder.exe project wizard (periferal definition)

    sudo dpkg --add-architecture i386 && sudo apt update
    sudo apt install wine64 wine32
    wine --version
   
    #if it doesn't exist already, create folder '/home/kubuntu/.local/share/application/'
    cp /usr/share/doc/wine/examples/wine.desktop $HOME/.local/share/applications/

Another note if later you want to install more recent versions, Quartus Pro is for Aria FPGA family, it does not support MAX10.

[BrianHG]

BrianHG_DDR3_Controller V1.00 has been released.
https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3649396/#msg3649396

Sad news about Cyclone V, see here:
https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3649318/#msg3649318

[BrianHG]

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

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

[Morgan127]

Intel/Altera devices are now supported by Instant SOC. I.e. MAX 10 and the DECA board is also supported.
They have also a created an example for the DECA. Here you can find the DECA MAX 10 board tutorial.

[BrianHG]

LOL, Arrow had ~160 Deca boards in stock for around since the beginning of this thread.
I post my DDR3 thread on GitHub, 2 weeks and nothing.
Now, all of a sudden as my fork count increased, all stock gone since I last checked 3 days ago...

[Scrts]

LOL, Arrow had ~160 Deca boards in stock for around since the beginning of this thread.
I post my DDR3 thread on GitHub, 2 weeks and nothing.
Now, all of a sudden as my fork count increased, all stock gone since I last checked 3 days ago...

Power of open source! Thank you! 

[FenTiger]

It looks like the DECA makers themselves have taken an interest in your controller!

https://github.com/DECAfpga

https://github.com/DECAfpga/BrianHG-DDR3-Controller

[SiliconWizard]

That is nice, but I don't like all those forks much.

In particular when the project is still young, and there is absolutely no reason to fork. Forking makes sense, IMHO, only when you want to make contributions that the original maintainer doesn't want to take, or you otherwise want to make the project go in different directions. Otherwise, you just end up with a ton of the same project in different states, nobody knows which one they should really use, and the original author of the project doesn't get the contributions, unless they go look at all forked projects and does the nasty work of merging things into their own.

Now I notice many github users do that as some kind of bookmarking. Forking is not meant for bookmarking a project for heaven's sake.

So again unless there is a *good* reason, forking is just disrespectful to the author and just tends to spread out contributions instead of aggregating them. Just my 2 cents.

[SMB784]

That is nice, but I don't like all those forks much.

In particular when the project is still young, and there is absolutely no reason to fork. Forking makes sense, IMHO, only when you want to make contributions that the original maintainer doesn't want to take, or you otherwise want to make the project go in different directions. Otherwise, you just end up with a ton of the same project in different states, nobody knows which one they should really use, and the original author of the project doesn't get the contributions, unless they go look at all forked projects and does the nasty work of merging things into their own.

Now I notice many github users do that as some kind of bookmarking. Forking is not meant for bookmarking a project for heaven's sake.

So again unless there is a *good* reason, forking is just disrespectful to the author and just tends to spread out contributions instead of aggregating them. Just my 2 cents.

Agreed, forking is not for bookmarking and is genuinely detrimental to the original project if not done for the explicit purpose of making changes that the owner does not want in their release.  Better to just star & follow the project on github and clone the repository, and submit pull requests if you want to see features added.

[RoGeorge]

Forking is not stealing.  Certainly not disrespectful either.  You can still see where from it was forked, also github tells if a fork is above or behind the original, and can show all the forks and their status, etc.

Makes sense to fork for many reasons.  One of them is to have a copy in case the owner decides to nuke the project.  Then, you can never know these days that, for whatever reasons, the owner or the project won't be banned or deleted from the somebody else's computer called cloud.

[BrianHG]

Forking is not stealing.  Certainly not disrespectful either.  You can still see where from it was forked, also github tells if a fork is above or behind the original, and can show all the forks and their status, etc.

Well, it is there, but tiny at the top left, easily missed unless you are acquainted with GitHub.

As for the stock of Arrow Deca boards, they all went between 2 days I checked and I do not have that kind of traffic on my DDR3 controller.  Though my controller does specify Arrow's link and price for the FPGA in the readme.

With today's chip shortage and the fact you are getting a 280$ FPGA for 37$, it is most likely that 1 person bough the entire stock and they probably have the tools to salvage the FPGAs.  I don't like this because the 5v supply, Ethernet cable, usb cables and rest of the PCB will almost be guaranteed to be thrown out.

[RoGeorge]

Forking is not stealing.  Certainly not disrespectful either.  You can still see where from it was forked, also github tells if a fork is above or behind the original, and can show all the forks and their status, etc.

Well, it is there, but tiny at the top left, easily missed unless you are acquainted with GitHub.

Might be, but "BrianHG" appears 113 more times in the rest of the page, look:



Nobody can miss that.

[BrianHG]

Forking is not stealing.  Certainly not disrespectful either.  You can still see where from it was forked, also github tells if a fork is above or behind the original, and can show all the forks and their status, etc.

Well, it is there, but tiny at the top left, easily missed unless you are acquainted with GitHub.

Might be, but "BrianHG" appears 113 more times in the rest of the page, look:

Nobody can miss that.

Damn, the folder 'screenshots' wasn't named 'BrianHG_DDR3_Screenshots'. 

[RoGeorge]

Damn, the folder 'screenshots' wasn't named 'BrianHG_DDR3_Screenshots'.

That one intrigued me, too   

[dolbeau]

In particular when the project is still young, and there is absolutely no reason to fork.

"Forking" in GitHub is not the same as "forking" a project to take it in a different direction. "Forking" in GitHub is just replicating the data so that you can modify them, as you normally don't have write permission to the original (and so can't rely on e.g. branches). Your comments seem targeted at the other kind of "forking", when there's no intention to actively contribute to the original project.

"Forking" in GitHub is pretty much a requirement for contributing to a project if you're not a direct contributor to it. If someone wanted to e.g. add support for another FPGA in BrianHG's controller, the "normal" way of doing it would be: (a) "fork" the project in GitHub, (b) clone the fork locally, (c) do the work on a local branch, (d, optional) perhaps push that local branch publicly if it's a collaborative work or needing outside input, [repeat (c) and (d) as needed], (e) when the work is done, push the branch to their "fork" on GitHub, (f) create a pull request on BrianHG's own repository to merge said branch, (g) when the work has been merged, GitHub will offer to delete the branch from the fork (and even the whole forked repository).

Do to the same thing without a GitHub "fork", BrianHG would have to authorize the direct modification of his repository, which is not a good idea.

Unfortunately you can't tell beforehand if the GitHub "fork" is a 'contribution' fork (someone wanting to actively contribute to the upstream repository), a 'bookmark' fork (someone wanting their own copy and control how it tracks the original repository), or a 'project fork' fork (someone wanting do their own thing based on an existing work).

[SiliconWizard]

Whatever, github or not, forking is forking. Once forked on github, the projects, even though you can see they are forks, are decoupled, at least AFAIK. So any contributions in one is completely separate from the others. That leads to project fragmentation, and, as I said, is usually completely counter-productive unless there's a good reason to do so.

A lot of projects have many forks on github, and as a user, it's almost impossible in the end to tell which you should use/which is the most up to date/which is the most stable/which you should rather contribute to/... It's just a bad situation.

Write access? If you want to contribute and the maintainer of a project doesn't want to take your contributions/give you access/or even reply to your requests, then of course this becomes a good reason for forking. But at least try first. It's the same for contributing to any open source project. You don't (primarily at least) do this by forking.

There's no difference with github, as, as I just said, even though you can at least see some project is a fork of another, there is otherwise no link between the two that I know of. So this just fragments the project.

Regarding contributing source code through github this is what "Pull requests" are for as far as I've understood. You can absolutely set up your project so that a given contribution only gets in the base branch if you accept the pull request. Otherwise, contributors work on their own branch. No need for forks.

And with that said, seeing how many people find this completely appropriate when working on github, we can see how github, willingly or not, promotes those idiotic behaviors, such as using a VCS as backup (as we talk about on a regular basis), and needlessly fragmenting open-source projects. But I'm not surprised, because this is pretty much what you're bound to get when you "open" such tools to the masses.

[RoGeorge]

There is a way to see the forks tree, and which one is ahead or behind the "original", and with how many submits, etc.
https://docs.github.com/en/repositories/viewing-activity-and-data-for-your-repository/understanding-connections-between-repositories#listing-the-forks-of-a-repository

Your rant seems to be against the fact that there is no such thing as uniquely "best" or "latest" fork in a distributed versioning system.

Github is mostly a nice web interface for git.  Git is a distributed versioning system, it was meant to fork and merge.  Git is not a Centralized Versioning System, it is distributed.  By design is distributed.  That's the main reason it took over the older CVS stile.

https://www.geeksforgeeks.org/centralized-vs-distributed-version-control-which-one-should-we-choose/

The only major difference you will find here [in distributed versioning] is, instead of one single repository which is the server, here every single developer or client has their own server and they will have a copy of the entire history or version of the code and all of its branches in their local server or machine.

You are asking developers to use Git/Github as it would be centralized, while git was invented to get rid of centralization.

Do not confuse Github with a repository of stable distributions, like Apple or Android, Linux, Windows, etc. have.  It is not for distributing the most latest and the most official and the "best" version.

Git/Github is for developers to be able to write code, together or independent, and without any central authority over a (public) project.  Github being also a source distribution platform is only a side effect.

[BrianHG]

Might be, but "BrianHG" appears 113 more times in the rest of the page, look:

Nobody can miss that.

Now that I checked, it also appears over 200 times throughout all the .sv source files.

[RoGeorge]

Hehe, so what?  I hope you do not plan to change that.

Yes, I was teasing you a little, in a familiar way, because I know how it feels when giving vanity names, did that myself, look:
https://hackaday.io/project/7542-rogeorge-cell
 

Just so you know, I appreciate very much that you wrote a DDR controller, and that you also open source it.  Thank you!

[Mario87]

Went to order one of these just now (why not, its fairly cheap and if I bump the order up to $50 (£36) it's free delivery to the UK), no doubt have to pay 20% VAT + some kind of £10-£15 "handling fee", so probably cost in the region of £50-£60 delivered.

I can live with that, but when I go to order, even if I set my address as "Personal" the Arrow website demands a valid GB VAT ID which I don't have. So how do I order this to the UK? Just put in a random number?

Surely that won't go down well if they report it to HMRC (UK VAT) and HMRC just turn round and say "that number doesn't exist".

Anyone on here ordered from Arrow to the UK before? How do you get around this? This is my first order with them.

[BrianHG]

Demo for V1.5 of my BrianHG_DDR3_Controller here: https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3785711/#msg3785711

And on my Github page here: https://github.com/BrianHGinc/BrianHG-DDR3-Controller

[mfro]

So again unless there is a *good* reason, forking is just disrespectful to the author and just tends to spread out contributions instead of aggregating them. Just my 2 cents.

Nonsense, with all respect. Not disrespectful at all - rather the opposite: it shows the author there is serious interest in his work.

A fork is git's way of generating a personal copy to play with (that probably tells you I have forked Brian's repository as well). It's even more transparent to the original author than an anonymous personal copy from a simple download as (if wanted) he can follow closely what happens with his work.

[SiliconWizard]

I guess we'll never agree on this. And I gave reasons why. It seems pretty obvious that contributing (first through tickets, for instance) is much better and easier if it's done in one project rather than a bunch of them all over the place.

Now we can move on, this thread is not about that, but I find it pretty fun how some of you can defend a way of doing things that hinders collaboration.

Getting back to the example of Brian's project, for which he put significant effort in: I go to his github repo, and there isn't even a single ticket in the "issues", whereas at this point, I'm pretty sure a number of people have already tested it and possibly found problems / or at least have had questions or suggestions for improvements. Where's the collaboration in that? Sorry, but claiming "personal copies to play with" is collaborating does not make any sense. Everyone is certainly free to do it, that's the principle of open source. But that's not promoting collaboration at all.

I personally have had time to test/evaluate Brian's controller, I'm intending on doing so on the Lattice ECP5 when I get the time and a board for this (or design my own board.) At this point, I'll certainly report back in Brian's github project rather than start my own fork.

[BrianHG]

Getting back to the example of Brian's project, for which he put significant effort in: I go to his github repo, and there isn't even a single ticket in the "issues", whereas at this point, I'm pretty sure a number of people have already tested it and possibly found problems / or at least have had questions or suggestions for improvements.

Improvements? 
I'm running circles around Altera's official controller on their own FPGAs.
My V1.5 corrects the final multiport FMAX bottleneck.

As for tickets, it just works.  Provide an address and WE when the port's busy isn't high, and it will be placed in the DDR3, or, 8-16 clocks later, a read command comes back with an optional user provided 'vector' word which was issued when the read command was sent.

I've even gone as far as within the background to even accept 1 additional read/write command without error even while the busy flag is high so poor designs which slip-up here will still function 100% perfectly.

[SiliconWizard]

I'm glad your design is so good that it doesn't need any improvement and wouldn't benefit from any outside contribution.

[asmi]

At this point, I'll certainly report back in Brian's github project rather than start my own fork.

And when you will do that, you will realize that you have to fork to do anything because that's how git works

[SiliconWizard]

At this point, I'll certainly report back in Brian's github project rather than start my own fork.

And when you will do that, you will realize that you have to fork to do anything because that's how git works

Absolutely not. Not only it's not the way git works, but git itself has no concept of a fork.

You could have said "that's how github works", which would have been already a little less wrong, because that's github that actually introduced forking as a collaborative model, which it never was before, since "forking" was definitely not about collaborating per se, but creating, you guessed it... forks. Derivatives of projects going in different directions, essentially.

But even if github has "promoted" this fork model, it's not even the only way of using github, and as I explained, I find this model has more drawbacks than benefits, and gave reasons why.
Just for starters: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models
As already discussed, I favor asking to be a collaborator if you have anything interesting to contribute - and then of course if the maintainer refuses or doesn't respond, forking as a second intention would make sense. Not as a first. Otherwise if it's just for personal use, just clone the repo locally and play with it.

Now I get it that many people have been first exposed to git - and even more generally to VCS - using github, but github is not git. And github, IMO, gives bad habits, including this frantic forking and using a VCS as a backup. The fact it's now owned by MS hasn't helped me having a better impression of it either, but that was just icing on the cake.

[asmi]

Absolutely not. Not only it's not the way git works, but git itself has no concept of a fork.

You could have said "that's how github works", which would have been already a little less wrong, because that's github that actually introduced forking as a collaborative model, which it never was before, since "forking" was definitely not about collaborating per se, but creating, you guessed it... forks. Derivatives of projects going in different directions, essentially.

But even if github has "promoted" this fork model, it's not even the only way of using github, and as I explained, I find this model has more drawbacks than benefits, and gave reasons why.
Just for starters: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models
As already discussed, I favor asking to be a collaborator if you have anything interesting to contribute - and then of course if the maintainer refuses or doesn't respond, forking as a second intention would make sense. Not as a first. Otherwise if it's just for personal use, just clone the repo locally and play with it.

Now I get it that many people have been first exposed to git - and even more generally to VCS - using github, but github is not git. And github, IMO, gives bad habits, including this frantic forking and using a VCS as a backup. The fact it's now owned by MS hasn't helped me having a better impression of it either, but that was just icing on the cake.

You just don't understand how git works. The entire point of git (and one of it's chief advantages over legacy SC like SVN et al) is that forks are very easy and lightweight. So the way you are supposed to work with it is as follows: you have a single master branch which contains a stable version, and for each change you create a separate fork, implement the change in fork, test it, and once it's ready, you merge it back into the master branch. Advantages of this approach are that 1) every developer always have a stable codebase when he/she begins working on a change, and if that change will turn out to be the dead end, you just leave it as is and don't merge it back, 2) each developer can work independently of each other (because of distributed nature of git), and 3) you can cherrypick which changes are going to be released (this is typically implemented by having additional "release" branch which devops people use for actual deployment).

This is how git is designed to be used, and so this is how it SHOULD be used. If you don't use it this way - you are doing it WRONG. This has absolutely nothing to do with Github (or BitBucket, or others) - they merely implemented a  GUI around git (and it's actually pretty thin layer above it - most of functionality you see on Github et al is provided by the git itself.

Incidentally, lightweight forks is exactly why git has been so wildly successful in huge projects like Linux kernel with thousands of developers working on it.

[SiliconWizard]

Sure, lecture me on how DVCS work, it was obvious I didn't know.
The workflow you implement on top of DVCS, including how you manage branches, is completely context-dependent. No two organizations have the same approaches. You are probably confusing forking, branching and clones. Interestingly, excessive branching itself now tends to be considered less than ideal, but it again all depends on a team's specific workflow. There isn't just one.

The github link I gave shortly explains the two approaches you can use, and I explained numerous times why I favor the collaborator approach to the fork approach UNLESS you have a good reason to do it with forks. I have given my main reasons, which seem to be consistently ignored. Good, I just hope at least a few people have gotten my points. For the others, I don't care. And I have used DVCS for years, thank you. Using the collaborator model doesn't mean that you're not using git as a distributed system either. DVCS have a number of benefits over centralized systems even when not "forking". But I think the term "fork" has been largely abused here.

Again, while forking can be alright if you're actually working on say a feature that is far from being ready, that may not get accepted in the mainline for months, and, most of all, that several developers may work on in parallel, if it's just a convenience as a personal backup or even just as a sort of bookmark (as we said earlier), this just dilutes projects. The more forks, and the more the dilution - this point has nothing subjective about it, it's not opinion, it's just mechanically inevitable. And unfortunately, those cases seem to be the norm rather than the exception on github. This goes hand in hand with the excessive use, IMHO, of "cloud" storage as well. I haven't seen recent figures, but the ones I saw from a couple years ago showed a lot more forks than pull requests, and even fewer merges. That may raise a few questions about the efficiency of it all. And yes, it's probably obvious by now that I don't like github much. And that yes, you can absolutely use git or other DCVS on your own organization's terms, on your own servers, without breaking the spirit of DVCS.

Oh and a final thought related to this discussion. The most successful open-source projects have pretty much all used a form of vertical organization - the Linux kernel being a prime example - which is likely how they could become successful in the end. As Linux shows, the use of a DVCS is absolutely not contradictory to having some amount of vertical project management, and is still quite useful in this setting. Github, while promoting, whether they want it or not, the dilution of open-source projects, hinders vertical project management. Not saying it prevents it, but it makes it unnecessarily harder. Now, what happens, to be honest, is that many of the successful projects, even when they have a github repo, are primarily managed outside of github. And to get back to Brian here, even if it's a small project, what I've seen so far is that it's what he does. (IIRC, he has even stated on his github page to use this forum for any communication... )

[asmi]

Sure, lecture me on how DVCS work, it was obvious I didn't know.

Yes, that much was obvious...

The github link I gave shortly explains the two approaches you can use, and I explained numerous times why I favor the collaborator approach to the fork approach UNLESS you have a good reason to do it with forks. I have given my main reasons, which seem to be consistently ignored. Good, I just hope at least a few people have gotten my points. For the others, I don't care. And I have used DVCS for years, thank you. Using the collaborator model doesn't mean that you're not using git as a distributed system either. DVCS have a number of benefits over centralized systems even when not "forking". But I think the term "fork" has been largely abused here.

...and so is the fact that you don't use it properly. When using git you stick to a "single branch/fork - single developer" approach, or you going to have massive headaches when several devs will constantly step on each other's toes.

Oh and a final thought related to this discussion. The most successful open-source projects have pretty much all used a form of vertical organization - the Linux kernel being a prime example - which is likely how they could become successful in the end. As Linux shows, the use of a DVCS is absolutely not contradictory to having some amount of vertical project management, and is still quite useful in this setting. Github, while promoting, whether they want it or not, the dilution of open-source projects, hinders vertical project management. Not saying it prevents it, but it makes it unnecessarily harder. Now, what happens, to be honest, is that many of the successful projects, even when they have a github repo, are primarily managed outside of github. And to get back to Brian here, even if it's a small project, what I've seen so far is that it's what he does. (IIRC, he has even stated on his github page to use this forum for any communication... )

Git was designed by Linus precisely for Linux, and each kernel dev always works in his own branch, and once a feature is implemented, there is a pull request (PR) to merge it back into the mainline, primary job of maintainers do is pick-and-choose which PRs to include into the release. And the exact same mechanism is used for accepting code from external entities for inclusion into the mainline (for example, this is how RISC-V and ARM support was added into the mainline).

So yeah, forks are the norm in git, not exception nor any sort of insult or whatever other nonsense you fantasized. With that, I think this discussion is over.

[SiliconWizard]

So yes, it's obvious I don't know. Sure. Looks impossible to have a different view on some topics, in particular anything related to software development, the discussions of which often end up very badly. I'm not surprised. You can absolutely disagree with me and find my concerns invalid or at least largely exxagerated, no problem. Claiming I don't know how a DVCS work is something else. Thanks for the smile =)

It's also obvious you didn't address most of the points I made, nor cared to understand them. That's possibly actually mainly due to how the term "fork" is abused here, although I tried explaining what my concerns were, and how making forked projects *public*, as with github, was NOT quite the same thing as each developer working on their own repo, because it precisely promotes project dilution - diluting the number of potential users and contributors to several instances of the same project, which is a concern that I'm far from being the only one to have expressed, and while you can indeed perfectly do so using DVCSs, there are myriads of ways to use them with different workflows. Not to talk about closed-source projects for which DVCSs are also used a lot these days. There are a ton of different workflows, very few of them including each developer in a team having their own forked *repo* on a (or several) shared server(s). A branch is not a complete forked repo. Dunno - I get the impression you absolutely see no difference. Again, git as no concept of fork by itself. All it has are clones and branches. Even a cloned repo is a slightly different beast from a fork (as in github and gitlab), which they themselves explain if you care to read the docs. But I'm the one not knowing here.

As to my comment on excessive branching, this is also nothing new. In well managed projects, excessive branching is avoided - using the right workflows - because they can quickly make merges an untractable problem. That doesn't mean DVCSs are not appropriate. Not at all. It's all about structuring things a bit instead of pure anarchy.

I still stand by the opinion that Github tends to promote bad use of git and VCS in general because it's used a lot as *cloud storage* rather than a truly collaborative tool. Small projects are likely to be more affected than the big ones, for which users will naturally tend to flock to the repo that has the most activity. I've seen some stats showing that a large majority of forks on github were just dead beef. I prefer personal dead beef on personal computers rather than being public and polluting projects. I'm not just saying that in theory. I've seen a lot of projects, some I'm interested int, being diluted this way and thus harder to contribute to or even use. I doubt I'm the only one.

Again, everyone working on their own branch and having multiple *public* forks of a project are two different things, which you apparently don't want to acknowledge, good. Maintaining or contributing to a an open-source project takes some work and active collaboration, even if it's just to report bugs (which can be every bit as useful as contributing code, btw, and for which splitting reports on many different projects makes it all the harder to aggregate them. That was one of my point too.) Clicking on a "fork" button takes a split second, otoh.

As to the way the Linux project is handled - it definitely doesn't use git in the way that is common in Github, and has indeed a very specific workflow. It doesn't take anything from github. See what every pull request gets as answer: https://github.com/torvalds/linux/pull/805 . The github repo is read-only as they explain, but "funnily" enough, there are almost 40k forks. Not, Linus himself certainly doesn't use git the way that looks "usual" on github.

So yeah, I'll leave it at that, but just wanted to make my points clear. If they are still not, oh well.

[BrianHG]

LOL, Arrow now has just received 2 more DECA boards in stock.

[BrianHG]

The new complete BrianHG_DDR3_Controller v1.50 here:
https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3606415/#msg3606415
And here:
https://github.com/BrianHGinc/BrianHG-DDR3-Controller

[migry]

I hope you all enjoying using your dirt cheap DECA 

I have used mine in a project to extract digital level video from an Atari STe, and then use the DECA to generate HDMI (since it has a nice easy HDMI transmitter chip to utilise).

The picture shows the video (4 bits each: R,G and B) buffer and level translator, for which I had a PCB manufactured by JLCPCB. I used the wrong footprint for the buffers 

On the DECA is a "hat". There is a 20 way IDC cable with headers which connects them. I couldn't get the built in audio to work so I added an external PCB/module.

Verilog software was developed while it was a still a mess of wires. But I was rewarded with a pixel perfect 50Hz Atari medium res display. Much better than the jail bar ridden mess which came out of the composite video. I do not have a RGB (15kHz) monitor or TV (BTW).

Initially scoping the signals, they were a horrendous mess. Lots of spikes everywhere. I output the received vsync and hsync on debug output pins, and they looked horrendous. I eventually figured it was all down to @@@@-poor high speed (high slew rate) signal mis-management. As an experiment, as seen in the photo, I added 1k resistors into the hsync and vsync lines out from the Atari and this fixed the syncs. The debug outputs from the FPGA were now clean.

I am now suffering from a new problem. I use the 32MHz clock, generated on the FPGA to sample the incoming signals. Apart from vsync and hsync is "display enable" or de. I use this to detect the start of active video. I am pretty sure that I am not sampling this signal cleanly using the 32MHz. It worked on the mess of wires since code would be compiled differently and delays would be different.

Oh BTW, the 32MHz clock generated by the DECA FPGA goes to the STe and is used as the video clock, so it is synchronous with the RGB and sync outputs back from the STe. This feature is not available on the standard Atari ST (note no 'e').

I simply want to use the input delay feature of the IO pins, to tweak de. I know that this is a bad one off solution, but I do not plan to publish the code and the project is a one off. I just need it to work. I need to tweak de, by adding a small delay so that it is not transitioning when sampled by the 32MHz clock. Over time the picture stabilises, then jitters again, then badly jitters, repeat and rinse. Adding finger capacitance changes the jitter, which makes me confident that the issue is simple a sampling point problem.

My question is, how do I use the MAX10 input buffer delay feature, and how do I code this in Verilog?

NOTE: I did some googling and found a solution for the Xilinx Spartan6, where you can specify directives to the compiler in comments (IOB).

I have read the PDF for the MAX10 I/O and I do see what looks like a programmable delay for the input signal on DDR pins. I tried to find some example Verilog code, but my google foo failed me once again.

[BrianHG]

I simply want to use the input delay feature of the IO pins, to tweak de. I know that this is a bad one off solution, but I do not plan to publish the code and the project is a one off. I just need it to work. I need to tweak de, by adding a small delay so that it is not transitioning when sampled by the 32MHz clock. Over time the picture stabilises, then jitters again, then badly jitters, repeat and rinse. Adding finger capacitance changes the jitter, which makes me confident that the issue is simple a sampling point problem.

Get rid of the capacitors...  Input delay buffers operate in to +/-50 picosecond range, up to +/- a few nanoseconds.  Way too small and useless for 32MHz.  This was designed to correct for pin-pin and PCB routing delays for buses above 300MHz way into the 900MHz range.

Here is what you should do:  Take in 32MHz.  Multiply by 8 on the MAX10 PLL for an internal 256 MHz.  Now, sample the input at 256MHz and have your HDL code select 1 of the 8 phases to sample from to get that 'sweet' 32 MHz sampling spot.

You can have a user set selection which phase to use, or if you want smart HDL, you can work out the sweet spot on the fly by looking for when the inputs transition and when the data has a 2-3 position clean stable value.  (I used to sample the Amiga's DENISE 12bit video output and different revisions of the chip has different ns delay skews on the data output bus VS it's 14.31818 MHz source clock  A smart self timing alignment is the best way to go whereas in the old days, we used to use a re-clocking PLL with a trimpot to phase adjust our data capture clock to zero in on that sweet data sampling spot.)

If you truly want to go all out, you can also use DDR input buffers for your input giving you an equivilant 512MHz sampling rate with 1 of 16 phase positions to select your source data from.

And, don't forget about using 'Signal-Tap' within Quartus where you can get your 256/512MHz logic analyzer of the input data + your HDL code's registers allowing you to capture/see what's actually happening on your inputs and HDL in real-time.


I doubt you would need to, but if the ST's output is crap beyond belief, you may select a different 1 or 8 sampling position phase for each input, though, this is an extreme case of fixing a problem which is generated elsewhere.

An example is if the Atari ST has a different logic IC generating the video sync output compared to the 12 bit RGB data and you have no choice but to correct for a different skew delay where in an analog RGB monitor, this skew would have no effect.

[RoGeorge]

Nice project! 

I didn't used my DECA recently, though there is a pile of projects for it in the bucket list.

Analog TV signals are using 75 ohms impedance.  If that Atari output is for a standard video monitor, then you need to use 75 ohms impedance coax cables (preferably same length for vertical and horizontal sync).  These 75 ohms coaxial cables (can be as well video cables, often RCA terminated coax cables, like the ones for old VCRs) must be terminated by a 75 ohms resistor at the other end of the cable, in parallel with the input of the FPGA.  Without impedance matching, the signals will reflect back and forth in the cable, creating horrible spikes, echoes and waveform degradation.

I don't recall if the ADC inputs in the DECA board already have 50 ohms low impedance input, I suspect they are not.  In case they do have 50 ohms, then a series resistor of 25 ohms is needed at the FPGA side of the cable.

Series 1k could be a workaround, but that is expected to degrade high frequencies, so more jitter and less detailed edges for pulses.  A proper 75 ohms impedance matching and 75 ohms coaxial cables should work better.



TV signal synchronization can be very tricky when the signal source has an independent clock.  I did once a machine to overlay video subtitles, which immediately showed the same clock and syncro problems you are are talking.  Back then I simply synchronized the clock of subtitling computer by pausing the clock (it was a ZX Spectrum, not Atari) so to make the computer clock "driven" by the analog video signal coming from a VCR.

Not sure if your Atari setup allows this trick.  If not, whatever you do, there will be skew between the clocks, maybe buffering a full frame might fix it.  I have no idea how sensitive the HDMI standard is against time jitter.

Also, analog TV were very tolerant regarding lines jitter, or frames jitter/frequency, and they were locking well with the source signal in a much broader range than the specs of broadcasting TV standards.  Therefore many computers back then were far for compliant, so I wouldn't be surprised if some of the jitter comes from the Atari hardware itself, but let's hope it is not that.



I'm sure many will chip in with new tricks and ideas for many pages to come, video conversion is a tricky problem, this new project of yours deserves its own topic. 

[BrianHG]

Analog TV signals are using 75 ohms impedance.  If that Atari output is for a standard video monitor, then you need to use 75 ohms impedance coax cables (preferably same length for vertical and horizontal sync).  These 75 ohms coaxial cables (can be as well video cables, often RCA terminated coax cables, like the ones for old VCRs) must be terminated by a 75 ohms resistor at the other end of the cable, in parallel with the input of the FPGA.  Without impedance matching, the signals will reflect back and forth in the cable, creating horrible spikes, echoes and waveform degradation.

It sounds like he is generating the video clock for the STe and sampling the binary data from the ST's display chip.  Otherwise, he would still get the jail bars and not have any jitter issues.

IE, if he makes the video clock, there cannot be any jitter on the HDMI output.
I have made enough video output on the DECA, now at 1080p, 720p, 480p, 960p, and a few other modes, no jitter at all.  Maybe he isn't driving the HDMI output IC properly?
I never had to use any fancy delays.

Look at the ribbon cables on his PCB where the silkscreen says red/green/blue, it has 4 wires on each ribbon, ie 12 bit digital color.

There are also 3 wires labeled sync and DE.  My guess is just like the Amiga (IE: the sync signals toggle on the rising clock while the digital video out toggle on the falling clock unless it is the ECS DENISE with the 28.63636MHz video out mode where the output timing has all new timing problems), the output timing of the sync VS the RGB color data has a fine but definite skew.  Using my trick of running the FPGA inputs at 8x frequency and sweet-spot selecting the RGB data and sync/de inputs from the ST will allow a perfect clean jitter free experience at each 8x sample position will proved a programmable tunable +/- ~4ns step size delay line.

[migry]

Sorry if I wasn't clear, and sorry for not knowing how to quote properly.

"It sounds like he is generating the video clock for the STe and sampling the binary data from the ST's display chip."

Yes.

The STe version of the Atari allows the video chip (aka the shifter) to be driven from an external 32MHz clock.

The HDMI generation (which I have done many times on various different hobbiest FPGA boards and found amazing interesting) is given below and I chose a 50Hz mode which needs a 54MHz clock. I use a Dell monitor as my display.

Code: [Select]

// FORMAT_1440x576p_50Hz
// FORMAT 29,30  == 1440 x 576 Progressive @ 50Hz
// pixel clock =  54.000MHz
// aspect ratio = 4:3 & 16:9
// horiz = 32.0us => 31.250kHz
// frame = 20.0ms => 50Hz
The line frequencies and pixel count work out perfectly at 50Hz, but unfortunately not for 60Hz (although I found something close, but the Atari VSYNC was 58Hz or thereabouts).

The prototype, which used a plug in breadboard and lots of "dupont" wires, eventually worked flawlessly. Each set of 4 digital RGB outputs from the "shifter" which go through resistors to generate an analogue voltage are buffered by my 74LVC8T245 voltage translator/buffers and are then input to the FPGA. Same for the VSYNC, HSYNC and DE. Only the 32MHz external clock comes from the FPGA back to the Atari (there is a pin on the 13 pin video connector for this). I had two PCBs made to tidy up the setup, but I didn't consider issues related to having a bus running at this speed. Anyway the glitch problem is fixed with 1k resistors which just "take off the edge" so to speak, working with the input capacitance of the FPGA pins.

It's been a while, but the digital parallel video rate is 16Mb/s for medium res and 8Mb/s for low res.

In order to find the first pixel on the top active video line, I use the DE (display enable) input. This input is sampled by the 32MHz clock. I am pretty sure the current configuration has a bad sampling point of DE, and that the pos edge of the 32MHz clock is too close to where DE transitions. I simply need to find a way to delay DE in order to get a clean sample. Also the Atari has a feature (bug) where it can come up in one of 4 clock positions relative to DE.

Just FYI, the digital video (with 15.625kHz sync rate) is read into a memory, then  each scan line is output twice at the HDMI rate of 31.25kHz.

As long as I sample the RGB input busses and DE "cleanly" the picture is rock solid.

As a side note I made several attempts to use the DECAs audio codec and failed miserably. So I used a fairly dumb analogue to I2S converter board instead. So the HDMI output, thanks to the HDMI chip on the DECA carries video and audio.

The problem is that I don't know how to utilise the I/O features of the MAX10 FPGA. I currently use them in rather a dumb way. I am looking for any insight or pointers to example code where I can learn how to properly use the advanced(?) features of the I/O, just like the DDR controller that is already described in this thread, where I assume the clock needs aligning to the data window, which is more or less the same problem which I face.

Please dumb down your replies! 

[BrianHG]

In Quartus, use the IPcatalog and select basic Functions / I/O - GPIO-Lite Intel FPGA
Choose a verilog or vhdl file name and configure your IO port.
You can set the port register to DDR and look at the documentation there.

You will not find the IO timing de-skew features here.
Such fine timing is useless for a 32MHz as the adjustable skew is in the +/- 50ps delay adjustments.
(Do you know how fine 50ps is?)

To confine your IO port to a specific time, you will need to create an .sdc file.  This may be out of your league for now, but again, this constraint file is for +/- a 0.5 to a few nanoseconds.
(Your video clock is 16MHz, do you know how many nanoseconds this is?)

My recommendation to run your inputs clocked at 256MHz, 8x your current 32MHz reference clock, 16x the speed of your video output data is your best solution.  Create a software adjustable pipe delay, 1 for your syncs and DE, another for your video data and operate there in standard verilog.
(With a 256MHz input data clock, do you know how many positions you may take from that Atari ST source 16MHz video output?)

The super complicated +/- 50ps alignment delay wont do a thing for your 16MHz clocked DE signal coming from your Atari ST.  If you Atari's video was clocked at 500MHz, then I would first say your PCBs and wiring needs to be improved, then you would want to use the super complicated +/- 50ps alignment delays capabilities in the advanced IO features of the MAX10 to compensate for signal timing.


Q: How did you divide your output 54MHz into the ST's 16MHz?

[migry]

So Brian, thank you for taking the time to read and answer my questions. You have made suggestions and I will explore those which make sense to help me to a solution. I haven't used anything except the basic I/O pad, so I really ought to find some learning material to understand more about these special I/O pins (features?) and how to instantiate them. I've found a few useful PDFs, but nothing regarding delay primitives.

(Do you know how fine 50ps is?)
(Your video clock is 16MHz, do you know how many nanoseconds this is?)
(With a 256MHz input data clock, do you know how many positions you may take from that Atari ST source 16MHz video output?)
This may be out of your league for now...

Is there really any need to be so insulting?

Q: How did you divide your output 54MHz into the ST's 16MHz?

Code: [Select]

PLL_HDMI pll_hdmi_inst (
  .inclk0 ( MAX10_CLK2_50 ),
  .c0     ( w_pll_hdmi    ) // 54MHz
);

PLL_ATARI pll_atari_inst (
  .inclk0 ( w_pll_hdmi  ),
  .c0     ( w_clk_atari ) // 32MHz
);

The numbers work out in that: 54 * 16 / 27 = 32.

[BrianHG]

(Do you know how fine 50ps is?)
(Your video clock is 16MHz, do you know how many nanoseconds this is?)
(With a 256MHz input data clock, do you know how many positions you may take from that Atari ST source 16MHz video output?)
This may be out of your league for now...

Is there really any need to be so insulting?

No insult intended.  I was just trying to convey the vast scope of timing between a 16/32MHz system in the day of 25-15ns PLDs and an FPGA which can easily do 400MHz and when they talk about IO timing, the kind of scope of their available adjustments are for correcting timing inside this tiny period where simple coding cannot accommodate those required tiny delays.

You are working in a world where the kind of timing adjustments you are doing is done in HDL code, not the realm of adjusting an IO's delay by +/- a few hundred picoseconds.

For your 'PLL_ATARI pll_atari_inst', if you are outputting that 32MHZ on an IO directly, unless it is a specific dedicated PLL output, timing isn't guaranteed.  Your output will be better quality if you ran the PLL at 64MHz and make an output @ that clock ' out <= !out; ' making a logic output at half frequency.


I still say make your PLL generate the 256MHz and from that 54MHz, generate the 32MHz out, IE count 8 clocks out, and select an adjustable position withing to sample 1 every 16 clocks making your adjustable delayed input for the DE.

[normi]

Only option for quote available on Arrow site, says only 2 in stock but I doubt they have any available. When was the last time that these were in stock at the $37 price.
Di a quote request but waiting for response. 

[lintweaker]

Only option for quote available on Arrow site, says only 2 in stock but I doubt they have any available. When was the last time that these were in stock at the $37 price.
Di a quote request but waiting for response.

I did use the quote options a few days ago and got response: they do not have any stock currently.

[ArsenioDev]

Yeah the stock on these has totally dried up, plus the FPGA silicon shortage is BRUTAL.
I snagged one for $56 on ebay recently as an entry into soft silicon world.

[BrianHG]

   Can somebody tell me which YOYO decided to wire the audio codec TLV320AIC3254 line-out jack to the audio codec's line out pins instead of the headphone out pins?  I mean, the entire difference is that the line out's A-weighted Dynamic range is 100db VS the headphone out being 99db.  Absolutely every other spec is the same except the headphone pins can drive a 16ohm load, IE: headphones directly.  Their decision to use the codec's line out designed to drive a 10k load means I now need to find separate transfer audio cables and a headphone amp just to use this tiny board.  I mean, couldn't they think a little or read the data sheet?

Maybe they only wanted people with a suite of analog audio equipment to accompany this DECA board just to hear any sound.

[BrianHG]

Sounds like a bad design decision surely.  Though how much I'd trust the analog level audio quality / SNR / reliability / ESD protection from what's intended to be a cheap FPGA board would be small regardless of what interface they used.
I'd worry about frying the FPGA / board based on plugging the audio cable or something unless proven otherwise by CE testing and schematic review.

Anyway though highly inconvenient vs. a correct PCB design, surely there has to be basically an 3.5mm-stereo-line-in to buffer-op-amp / line driver to 3.5mm stereo line / headphone out with micro-USB power input chinese gadget for like $10/5pcs or something?  I'd probably buy or design / build / use something like that just to add some EMC filtering and ESD protection and "jack saver" lessening the amount I'd physically handle / plug into the "unprotected"/"naked" FPGA board to make an audio connection and similar for HDMI, ethernet switch, etc.

I mean really.  I have a project where I just want to demonstrate some audio to someone.  Now I need to carry a crap of audio equipment just to listen instead of just headphones.  It was merely the difference of moving 2 ping over to the left on the IC...

That audio IC would need a serious zap going into it before it made its way far enough through it to make it to the FPGA to damage that IC.  Otherwise, even my home PC with an audio codec chip on the motherboard must be in great danger every time I touch my headphones.

[mopplayer]

Wow, that's interesting, people love to do something on a board of EOL and more worst, a ES silicon.

The EOL product means you have no support, and you will solve problems on your own.

The ES silicon means there are some bugs in it, no guarantee, and the C6G (not I6G) device is still not available on the market, so that device is discontinued and only used for fun (or education?)

You could imagine why Intel Core "ES" devices are so cheap, and there are still "QS" devices.

Arrow is a commercial company that all realized that point and released them at a low price to get rid of them.

To be honest, I will not waste money on that electronic waste, even though it's only $39.

If you want to use a MAX10 device, the DE10-Lite platforum is more reliable and used to develop products nowaday.

[RoGeorge]

To be honest, I will not waste money on that electronic waste, even though it's only $39.

If you want to use a MAX10 device, the DE10-Lite platforum is more reliable and used to develop products nowaday.

It's out of stock for a very long time anyway, though $39 was a very good price for the a MAX10 devboard with the biggest/fastest MAX10 FPGA and all those peripherals.  The one you like is $140 instead of $40, and how do you know it is more "reliable", since you don't have a DECA board for comparison?

[BrianHG]

If you want to use a MAX10 device, the DE10-Lite platforum is more reliable and used to develop products nowaday.

What if you want 1600megabytes per second a digital 24bit 1080p multilayerd graphics included HD embedded sound, with a 512megabyte display buffer?

That DE10-Lite uses obsolete discontinued SDRam.  A technology if you are learning to use will develop nothing but cheap old slow bad habit skills, never learning how to use advanced high speed ports or using .sdc time constraints files to operate those super high speed DDR IO ports properly.

Yes, the C6 50k Max10s exist.  The ES was just an advanced engineering sample.
All, C8, I8, C7, I7, and C6 speed grades all function the same and you can get identical functio0nality between them.
Also, it is an FPGA, who cares which exact versions are available?

[mopplayer]

If you want to use a MAX10 device, the DE10-Lite platforum is more reliable and used to develop products nowaday.

What if you want 1600megabytes per second a digital 24bit 1080p multilayerd graphics included HD embedded sound, with a 512megabyte display buffer?

That DE10-Lite uses obsolete discontinued SDRam.  A technology if you are learning to use will develop nothing but cheap old slow bad habit skills, never learning how to use advanced high speed ports or using .sdc time constraints files to operate those super high speed DDR IO ports properly.

Yes, the C6 50k Max10s exist.  The ES was just an advanced engineering sample.
All, C8, I8, C7, I7, and C6 speed grades all function the same and you can get identical functio0nality between them.
Also, it is an FPGA, who cares which exact versions are available?

Not really.

I only consider availability, reliable and consistency, so an ES device is not an option.

That's why Intel also discontinued MAX 10 FPGA Development Kits. So where is the commercial C6 device? Oh... there is also no ES device.
C6~C8 is speed grade, a high speed application also will consider that.

Yeah, just for fun, that's OK.

Why do you only see the SDRAM/DDR, framebuffer?
I do not need the SDRAM/DDR, there is always a bandwidth bottleneck. On the other hand, the device is not only for video applications.

So DE10-Lite is better for students and hobbyists, that is the truth.

Beside MAX10, there is still Cyclone V and even Cyclone IV E, there is not much expensive, and more resources on that device. DE0-nano is an example. I have also recommanded the board.

I have used other non-ES device to do my project a long time, and those ES boards in my country is cheap. Do not need $39.

[Wiljan]

Hi
I was involved in project  a MIPI camera, and then I remember that the DECA does have a MIPI CSI-2 port on board and wanted to play a bit with a camera to FPGA

The DECA MIPI port does have an 30 pin connector and was original made for an AR0833 camera which you can't find anymore for the DECA layout.

So I have a IMX219 (RPI V2.1) Cam using a 15 pin FFC connector with 3V3 and I2C, enable, and the 1x CSI clk and 2 X CSI data lanes.

I did solder some thin wire on the diff pair DHPY term resistors (see schematic on page 15 of the DECA board) and the to to a small 15 pin FFC (made from a FFC to FFC connection board cut into half.

The I2C was just connect to the GPIO header as well as the GND and 3V3

Some search on the internet and I found a  place where the I2C for 640x480 was used in a FPGA implementation
 https://purisa.me/blog/mipi-camera-progress/

I used the imx219.sv for the I2C https://github.com/hdl-util/mipi-ccs

which basic does the the 640x480 driver part from the linux and it works fine on the DECA and the camera.

I also added in the camera.sv from https://github.com/hdl-util/mipi-csi-2

I did expect to get a "frame_start", "frame_end", "line_start", "line_end", "image_data_enable"
Those signal are not steady 

So when measuring on the MIPI clk lane I see it's sending in bursts as well on the 2 data lanes.

My scope is a 200Mhz one, so the signal get very weak above 200Mhz.

In the datasheet for the IMX219 I can see what registers does and what the FPGA set it to.

The Camera is a a
Max. 30 frame/s in all-pixel scan mode
Pixel rate: 280 [Mpixel/s] (All-pixels mode)
180 frame/s @720p with 2x2 analog (special) binning, 60 frame/s @1080p with V-crop
Data rate: Max. 755 Mbps/lane(@4lane), 912Mbps/Lane(@2lane)

Total number of pixels : 3296 (H) × 2512 (V) approx. 8.28 M pixels
Number of effective pixels : 3296 (H) × 2480 (V) approx. 8.17 M pixels
Number of active pixels : 3280 (H) × 2464 (V) approx. 8.08 M pixels

The Cam module does have a local 24Mhz osc and the there is a few PLL in the cam to generate the right pixel clk and MIPI clk

There is a register 0x030d which set the "PLL Output System multiplier Value", if I lower that one to 0x20 I the get 128Mhz on the MIPI clk and clk get continues and I get frame start and end.

So my question:

If the camera does have a total area of 3280x2464=8M pixels/frame and only 640x480= 0.3Moixels/frame are set as Point Of Interest.

Can that be clocked out on the MIPI with a lower clk?

So when you have the first line of 640 will the 640 need to clocked by the speed of the 3280 or will it be possible to clk it slower.
I understand the it will require the the cam does hold 1 line of date, in the datasheet I see there is a FIFO in the  cam but I cant see if it does only hold the active pixel of a line or not.

Cam data sheet says says  912Mbps/Lane(@2lane) and MAX10 data sheet the the LVDS mode on the MAX10 it says 800Mhz.

That's why I want to reduce the speed on the MIPI clk lane but still get the 640x480

Let me hear what you think?

Code: [Select]

{1'b0, 16'h0100, 8'h00}, // Stop Streaming
 //--Access command sequence Seq. No. Address (Hex) data---
 {1'b0, 16'h30eb, 8'h05}, // init seq
 {1'b0, 16'h30eb, 8'h0c}, // init seq
 {1'b0, 16'h300a, 8'hff}, // init seq
 {1'b0, 16'h300b, 8'hff}, // init seq
 {1'b0, 16'h30eb, 8'h05}, // init seq
 {1'b0, 16'h30eb, 8'h09}, // init seq
 //--Output Set-up Registers--
 {1'b0, 16'h0114, 8'h01},  //CSI_lane_mode 0: Reserved, 1: 2-Lane, 2: Reserved, 3: 4-Lane
 {1'b0, 16'h0128, 8'h00}, //DPHY_CTRL MIPI Global timing setting 0: auto mode, 1: manual mode
 {1'b0, 16'h012a, 8'h18}, //EXCK_FREQ[15:8] RW INCK frequency [MHz] defauls 0x0C // 24 = 0x18
 {1'b0, 16'h012b, 8'h00}, //EXCK_FREQ[7:0] RW INCK frequency [MHz]
 {1'b0, 16'h0162, 8'h0d}, // LINE_LENGTH_A[15:8]  0x0d78 = 3.443 pixels
 {1'b0, 16'h0163, 8'h78}, // LINE_LENGTH_A[7:0]
//----offset X-----------
 {1'b0, 16'h0164, 8'h03}, // X_ADD_STA_A[11:8] x_addr_start 0x03e8 = 1.000
 {1'b0, 16'h0165, 8'he8}, // X_ADD_STA_A[7:0]
 {1'b0, 16'h0166, 8'h08}, // X_ADD_END_A[11:8] x _addr_end = 2.279
 {1'b0, 16'h0167, 8'he7}, // X_ADD_END_A[7:0]
//----offset Y-----------
 {1'b0, 16'h0168, 8'h02}, // Y_ADD_STA_A[11:8] y_addr_start 0x02F0= 752
 {1'b0, 16'h0169, 8'hf0}, // Y_ADD_STA_A[7:0]
 {1'b0, 16'h016a, 8'h06}, // Y_ADD_END_A[11:8] y_addr_end 0x06af = 1.711
 {1'b0, 16'h016b, 8'haf}, // Y_ADD_END_A[7:0]
//----output size----------
 {1'b0, 16'h016c, 8'h02}, // x_output_size[11:8] 0x0280 = 640
 {1'b0, 16'h016d, 8'h80}, // x_output_size[7:0]
 {1'b0, 16'h016e, 8'h01}, // y_output_size[11:8] 0x01e0 = 480
 {1'b0, 16'h016f, 8'he0}, // y_output_size[7:0]
 
 {1'b0, 16'h0170, 8'h01},
 {1'b0, 16'h0171, 8'h01},
 {1'b0, 16'h0174, 8'h03},
 {1'b0, 16'h0175, 8'h03},

 //---Clock Set-up----------
 {1'b0, 16'h0301, 8'h05},
 {1'b0, 16'h0303, 8'h01},
 {1'b0, 16'h0304, 8'h03},
 {1'b0, 16'h0305, 8'h03},
 {1'b0, 16'h0306, 8'h00},
 {1'b0, 16'h0307, 8'h39},
// {1'b0, 16'h0307, 8'h2b},
 {1'b0, 16'h030b, 8'h01},
 {1'b0, 16'h030c, 8'h00},
// {1'b0, 16'h030d, 8'h72},
 {1'b0, 16'h030d, 8'h40},
// {1'b0, 16'h030d, 8'h10},  // 0x10=63Mhz ok , 0x20 =128Mhz ok, 0x40 = 256Mhz
 //---Test Pattern Registers----
 {1'b0, 16'h0624, 8'h06}, //1640
 {1'b0, 16'h0625, 8'h68},
 {1'b0, 16'h0626, 8'h04},  //1232
 {1'b0, 16'h0627, 8'hd0},
 
 {1'b0, 16'h455e, 8'h00},
 {1'b0, 16'h471e, 8'h4b},
 {1'b0, 16'h4767, 8'h0f},
 {1'b0, 16'h4750, 8'h14},
 {1'b0, 16'h4540, 8'h00},
 {1'b0, 16'h47b4, 8'h14},
 {1'b0, 16'h4713, 8'h30},
 {1'b0, 16'h478b, 8'h10},
 {1'b0, 16'h478f, 8'h10},
 {1'b0, 16'h4793, 8'h10},
 {1'b0, 16'h4797, 8'h0e},
 {1'b0, 16'h479b, 8'h0e},
 {1'b0, 16'h0100, 8'h01} // Start streaming


[Wiljan]

Some progress, did have some success with this clk setting for the RPI v2.1 CAM IMX219

Code: [Select]

//---Clock Set-up----------
 {1'b0, 16'h0301, 8'h05},
 {1'b0, 16'h0303, 8'h01},
 {1'b0, 16'h0304, 8'h03},
 {1'b0, 16'h0305, 8'h03},
 {1'b0, 16'h0306, 8'h00},

// {1'b0, 16'h0307, 8'h10},
 {1'b0, 16'h0307, 8'h39},
// {1'b0, 16'h0307, 8'h2b},

 {1'b0, 16'h030b, 8'h01},
 {1'b0, 16'h030c, 8'h00},

 // {1'b0, 16'h030d, 8'h72},
 {1'b0, 16'h030d, 8'h20},
// {1'b0, 16'h030d, 8'h10},  // 0x10=63Mhz ok , 0x20 =128Mhz ok, 0x40 = 256Mhz

So I have the camera.sv using the 2x D.phy_receiver.sv running and a I2C master to set the I2C registers the cam

Using Signaltap I get those 2 different data out of the camera.sv and a fine frame start / end signal
one images is with lamp off and the other is with a lamp on shining on the camera.

Now I have to process the data to get some RGB and then try to feed it into the BrianHG_DDR3 ram so it will come on the HDMI output

[BrianHG]

This is where most of the 37$ DECA boards went...
DECA at 200$ on Aliexpress
Funny how the store just happened to open with the same timing of the 37$ special...