• 0
bmentink

Artix-A7 non-GUI development

Question

Hi,

While I am waiting for my brand new board to arrive, I am setting up the tools to do primarily non-GUI development. I.E  From a Linux shell I just want to create a Makefile project that runs the tools to do the symthesis/routing etc and programming.

I have installed the Vivado tools and have them running on the command line, so I can do a simple "make bitfile" and it will do it .. however, I can't seem to find any information on this site to do the programming of the FPGA ram or Flash with command line tools, can anyone help with that.?

Also, since I am programming in Verilog, there does not seems to be a lot of examples (apart from the ADC one) that I can reference, they are in in VHDL. It would be useful to have some more Verilog examples and some more howto's on non-GUI development.

Last question :) Can anyone explain the format of the board restraints (*.xdc) file, I can understand the 1st line below, but the meaning of the 2nd one eludes me:
 

Quote

 

#set_property -dict { PACKAGE_PIN M3    IOSTANDARD LVCMOS33 } [get_ports { pio[01] }];

#IO_L8N_T1_AD14N_35 Sch=pio[01]

 

Many Thanks

Share this post


Link to post
Share on other sites

Recommended Posts

  • 0

Hi @bmentink,

I am glad that using a shorter usb cable has allowed you to flash the Cmod A7 without an issue. I have reached out to our senior design engineer about this forum.

thank you,

Jon

 

 

 

Edited by jpeyron

Share this post


Link to post
Share on other sites
  • 0

Hi @bmentink,

One of our design engineers spent some time looking into this issue. It appears that some of the USB cables we tested had all four conductors twisted together in a manner such that noise or GROUND or VBUS could couple into D+ or D- but not necessarily both. This is bad because that noise won’t be rejected and can result in data errors. Unfortunately it seems that a number of the cables out in world including some that Digilent provides as well have this issue. We are working on getting a new cable set to rectify this. At this point in time, we recommend that you ensure that you are using a USB .org certified high speed cable that has the proper wire construction as no errors were encountered when using those cables.

Thanks,
JColvin

Share this post


Link to post
Share on other sites
  • 0

@JColvin

 

Noted: Many thanks. Although it does seem strange that those same "faulty" cables work perfectly fine on other development boards like Lattice ICE40 boards, and Papillio Duo/Pro boards of which I have many and none have this issue..

Cheers,

Bernie

Share this post


Link to post
Share on other sites
  • 0

@bmentink,

Agreed. From my personal understanding, this issue only becomes an issue during high speed communication and is somewhat uncommon, or at least I was quoted from testing that the USB error occurred sometime between 9k and 300k iterations, so I imagine this does not come up frequently during single use cases as much as one would think from a poorly constructed cable.

Thanks,
JColvin

Share this post


Link to post
Share on other sites
  • 0

@JColvin

> 9k and 300k iterations

Not sure what that means: You did 300k programs on the one cable?

Testing should be trying a number of cables, because doing multiple tests on the same cable is pointless. (After all, the definition of madness is to repeat the same thing expecting a different result) :)

> I imagine this does not come up frequently during single use cases as much as one would think from a poorly constructed cable.

For me, and at least one other on this forum, it errors out every time on a cable and we tried  a bunch of cables. .... and I mean a bunch. I tried 7 different cables and they all did not program, it was only when I used a real short 6" cable that it worked. The other person refered to in a previous post had the same issue. I don't think you can deflect the problem onto just cables .. they all can't be bad, that's just not logical, especially given the fact that they work just fine doing high speed programming on other boards.

I would suggest you have a USB impedance matching / track layout issue on the board. If the design was "open" ;) us engineers could peer review it for you free of charge, but we can't.

My 2c.

Edited by bmentink

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now