Home    Bloggers    Messages    Webinars    Resources   
Tw  |  Fb  |  In  |  Rss
Discovering FPGAs: Loading the .BIT File
7/16/2012

< Previous   Image 4 of 6      Next >

Loading the FPGA -- Selecting the 'Digilent' option.
Loading the FPGA -- Selecting the "Digilent" option.

< Previous   Image 4 of 6      Next >

Return to Article

Page 1 / 3   >   >>
tomii
tomii
11/16/2012 3:04:06 PM
User Rank
Blogger
Programming w/ Opal Kelly board
I said earlier that I'm following along with an opal kelley XEM3005 board.  While there is a JTAG connector on the breakout board (well, a place to solder it in on your own...), the primary way of banging bits is via USB - over their "FrontPanel" software.

First, you load FrontPanel, then you click the load button.  Once you do that, you browse to the *.bit file of interest. When select the file, it squirts it into the board for you.

One of the things I find interesting about this is that they have an API behind all this stuff, too - this way, when I get to one of my "real" projects, I should be able to keep the bit file on the host computer, and bang those bits at every startup.  This makes life a little easier for firmware updates (maybe) for a system that's connected directly to a PC.

It's also nice that their API handles bidirectional comms - I'm hoping to someday have a couple projects that make good use of this capability.  I'm hoping that their API is loadable by LabWindows, as that's my preferred tool for buiding instrumentation software (I really like their GUI interfaces)

 

'nuff rambling.  Thanks for the series.

50%
50%
Duane Benson
Duane Benson
7/27/2012 12:23:56 PM
User Rank
Blogger
Re: LCD
SimonC  - For my next steps, I'm going back to the manual again to put some more of it in context based on what I've done so far. After that, I'm going to start adding in to the code I have and just exploring the I/O.

50%
50%
SimonC
SimonC
7/24/2012 8:37:12 AM
User Rank
Beginner
LCD
Hi,

 

thanks for the help, we were able to configure our virtex 5 ml507 education platform, finally ;)

I have already done some programming and testing with the LED's and the switches, but I would like to use some of the other features of the board. For example the 16 character  x 2- Line LCD or  input from an RS-232 into the fpga (for example to light some leds). So far I have no idea how to do this.

Any ideas for the next step in my FPGA learning process? :)

grtz, Simon

 

 

50%
50%
rfindley
rfindley
7/23/2012 4:29:06 PM
User Rank
Blogger
Re: What did I miss?
True that!

50%
50%
Duane Benson
Duane Benson
7/23/2012 4:23:07 PM
User Rank
Blogger
Re: What did I miss?
Of course, one of the difficulties of being a rookie is that I can't always figure out the warnings and determine if they're innocuous or not. I will at some point, but haven't yet. It bugs me to leave something like that hanging.

50%
50%
rfindley
rfindley
7/22/2012 8:25:45 PM
User Rank
Blogger
Re: What did I miss?
@Duane, I agree.  I guess the real underlying principle is: Good practice dictates that we pay attention to the warnings, and document our decisions/conclusions somehow.

50%
50%
Duane Benson
Duane Benson
7/22/2012 8:08:38 PM
User Rank
Blogger
Re: What did I miss?
rfindley - I have certainly left warnings in code before, but I really don't like to. I'd much rather understand what's going on and code is such a way that the tools and the chip are happy with what I've built.

50%
50%
rfindley
rfindley
7/20/2012 11:20:36 PM
User Rank
Blogger
Re: What did I miss?
Duane,

It's always great to see people not ignore compiler warnings!  I often do maintenance work on existing projects, and not many FPGA projects have absolutely no warnings.  Even when the warnings turn out to be a non-issue, a persistent warning icon makes it too easy to miss any new warnings that crop up.

Some of the FPGA tools have started adding an option to only show 'new' warnings, making it easy to spot them as they crop up.  I would much rather see a method where, in the source code, the engineer can acknowledge and suppress specific instances of warning triggers (i.e. "Hush, I meant to do that!").  Better yet, make the code unambiguous enough that no warning is triggered in the first place, though sometimes that is easier said than done.

50%
50%
Duane Benson
Duane Benson
7/20/2012 5:21:10 PM
User Rank
Blogger
Re: "manually tell the software where to find your cable"
Hamster - Thanks for posting the link. I'll download and install it this weekend.

50%
50%
Duane Benson
Duane Benson
7/20/2012 5:20:15 PM
User Rank
Blogger
Re: "manually tell the software where to find your cable"
Brian -  I think the "Help me, I am confused!" is more likely to be coming from me than froma dialog box.

That's an intersting question to ponder - multiple boards of the same type plugged in.

50%
50%
Page 1 / 3   >   >>
More Blogs from Duane Benson
Duane is now poised to use his I2C interface to send commands to the driver boards controlling his robot avatar's motors.
There are a number of methods Duane could use to send data to his I2C module, but he decided on a "homegrown" FIFO buffer.
Hurray! Break out the party hats and chocolate cigars -- Duane's I2C finite state machine (FSM) controller is finally working... well, sort-of.
Duane Benson has decided the FPGA fabric in the Zynq All Programmable SoC will handle the short-term obstacle avoidance navigation in real-time. The Linux OS will handle longer-scope activities like point-to-point navigation.
Duane has decided that the time is ripe to get his ZedBoard bolted onto his robot with a Linux distribution up and running. That was the ultimate plan anyway, so why wait?
flash poll
follow us on twitter
follow Xilinx on twitter
like us on facebook
like Xilinx on facebook
All Programmable Planet     About Us     Contact Us     Help     Register     Twitter     Facebook     RSS