Arty (A7) difference between revision C and revision D

[Josef]

Hello everyone,

I searched for something information about programming interface for DDR3L on Arty board what I bought and I got on page - reference manual for Arty board and there is information saying that Arty reference manual is for revisions A - C of board. I have looked on my revision and on board is printed REV. C. Before I met this information I used schematics, reference designs and et cetera files from page Arty A7 and it seemes that all works fine. So I have two questions. If I downloaded materials for Arty A7, must I download materials for Arty, if I have revision C, or files for newer revisions is backward compatible with older revision of board? I think yes, because no warning information is on Arty A7 reference manual page. And I also have question what difference is between revision C and newer revision of Arty board? I haven't found any difference, but it's very likely that I have overlooked something.

Thanks in advance for any response

Best regards

Josef

[D@n]

I know of at least one difference. 

Dan

[Josef]

Dan, thanks for your answer.

[Josef]

So if I understand Dan, Arty (revision C and earlier) have a flash config memory from Micron (IC3 or IC4 location) what have internal design problem caused by sometimes problematically power-on reset? So if I want Arty without problems, I have to exchange memory from Micron (N25Q128A13ESF40) to memory ideally from Spansion (I only found Cypress S25FL128SAGMFV003) on board, am I right?

Best regards

Josef

[D@n]

@Josef,

One of my personal goals is to try to build a single/universal flash driver that can work with both boards.  This includes a startup script that will pull the Micron out of whatever reset configuration/state it is in.  I think I've got it, but the Spansion flash will need at least two configuration changes: 1) the number of "dummy" cycles needs to be changed.  These are the number of cycles between the read address and the first clock with read data in it.  This change needs to be made both to the open source flash simulator I have, as well as to the RTL code and the software driver I have.  All are possible, just annoying to do.   2) The startup script within the driver itself (probably) needs to change.

Once done, my OpenArty design should work with the new hardware as well.  At least, the different flash is the only change I know of.  Since I don't have one of the newer Arty boards, it will be hard for me to know for certain.

Dan

[Josef]

So problem is in driver in PC, right? I looked once again and I think that newer board can also fit 100T version of Artix (some ceramic capacitors are also near of FPGA package diagonal on top side of board, what I doesn't have on my board). Can I ask for problem with flash, how you Dan found problem with memory power-on reset? What are symptoms and what steps I can also get into this trouble?

Best regards

Josef

[D@n]

@Josef,

At the time, I was trying to build a high speed flash controller.  As part of any design work I do, I start by downloading the specifications for all the parts on any board you will be working with.  Then, when I'm ready to work with a given part, I start reading the specification for the part I want to work with.

I would recommend this to you as well.

In this case, I found the "problem" by reading the specification for the Micron flash chip.  In Micron's zeal for creating a faster/better/cheaper chip, they created a chip that could start in QSPI/XIP mode.  This is in many ways a sales point, since a chip that can start in that mode is going to run faster than one that starts in SPI mode and then needs to transition to QSPI.  The problem, though, is trying to figure out which mode the chip started in if you have no idea what the configuration register is set to.

In the middle of this, there arose a question as to whether or not the FPGA could properly place the chip into the necessary SPI or QSPI mode, from whatever state the user had left it in, in order to configure the chip initially.  I'm still not certain of the answer to that question.

In my current work, I'm resolving this problem by sending a carefully chosen command to the flash that, if the flash is in SPI mode, will have no meaning, but if the flash is in QSPI mode it will return the flash to SPI mode.  Once the flash has been returned to a known state, I can then place it into the state that I want it to be in--usually the QSPI/XIP mode I wanted to work with in the first place.

This approach has another benefit as well.  When you load a design onto an FPGA via the JTAG, the flash chip doesn't change modes like it will if you load your design from the flash.  In other words, the flash might already in its QSPI/XIP mode when my design starts up separate from whatever reset mode the flash might be in.    (This issue has caught me by surprise more than once, and not always with the flash, where some piece of hardware is already initialized upon design startup--something worth watching out for.)  By first taking the flash out of whatever mode it is in initially and placing it into a known mode, the design can reliably start when loaded from JTAG as well as when loaded from flash.

Dan

[Josef]

Thanks for describe of troubles. So if I understand, problem is only when user access the flash from design (or own software in computer) and leave the memory in unknown type of communication SPI or QSPI/XIP and next time you want to download some data to this flash from computer, am I right? So driver from Digilent uses one type of communication (I guess, if you mentioned about high speed flash controller type SPI) and if I access the flash from design and leave the flash in QSPI/XIP, Vivado HW Server can next time have problem with download design to flash? Or standard download programs implements approach you also mentioned about switching memory from any type of communication to wanted type? So Micron memory I can left in board and use also for my configuration without any fear of incorrect boot?

Best regards

Josef

[D@n]

@Josef,

I'm not sure I know enough to say the problem only exists in the case where a user places the flash in a specific configuration.   I do know that I never loaded the flash using the GUI.  I always loaded my design into the flash myself, so I can't really comment on the GUI approach and how well it works.  I know that more than one person has struggled to load their design from the GUI, and I've always suspected that this was part of the cause.

I do know enough to say that you want your flash device in a QSPI/XIP configuration for fastest access.

I also know that, if you are concerned, it's not that hard to read the ID off of the flash to see who the manufacturer is, what the size of the chip is, and which chip from the manufacturer it represents.

Dan

[jpeyron]

Hi @Josef,

I have not found any issues with using the resource center information like the xdc, reference manual , tutorials, demo or examples with a newer revision of the Arty A7. Here is the Digilent GitHub MIG  information for the Arty A7.

cheers,

Jon

[Josef]

Hello @jpeyron

Thanks a lot. I only found that DDR memory on revision D have resistors on data lines what missing on revision C, memory type is the same. Does it mean that DDR on Arty wouldn't work on same high speed as on Arty A7? Or I overlooked something in schematic?

Best regards

Josef

[Josef]

Hello,

can anyone tell me how I can check if any elemenent (e.g. switching matrix, etc.) of ArtixA7-35T is not broken? I have accidentally wrote to my Basys3 board bit file created for Arty... I have tested it with onboard demo (LED display, switches, LEDs and buttons) and everything look ok, but I have read that bit file programming internal switch transistors in switching matrix and there can be something damaged.

Thanks in advance for any response

Best regards

Josef

[jpeyron]

Hi @Josef,

We reached out to one of our layout engineers about the additional capacitors and resistors on the DDR3. They responded that 'When we switched the Arty over to the New Arty A7 we added the termination to clean up some noise on the DDR3 bus to better meet specifications.  This should not affect the performance from a user perspective."

I'm not aware of a specific way to test this other than configuring the FPGA with a larger more complicated project that will use more of the FPGA's resources. If everything is working as expected with the larger project then I would think that there is not an issue.

Here is our Arty-A7-35 GitHub projects

I would also go through the Getting started with microblaze servers tutorial in the Additional resources section of the Arty-A7's resource center here. There was an issue with the Ethernet IP core for Vivado 2018.2 discussed in this forum here.  I believe it has been resolved for Vivado 2018.3.

 

thank you,

Jon