It just occurred to me that learning to program FPGAs is making me feel young again. It's not taking years off my countenance or anything, but I'm once again working with circuits I was building in my high school electronics class back in the age of dinosaurs and dweebs.
In this column, I've added a binary to seven-segment decoder to the binary counting configuration I used in my previous blog. The seven-segment display I'm using is an old FND500 that I purchased in 1980 when building my first computer -- a CDP1802-based single-board thing.
My primary objectives with this project are to build on my starting project by adding more functions and to get something running that I can use to learn about the ChipScope virtual logic analyzer (a device discussed here before).
I've used almost all the available I/O on my Spartan FPGA, but I was able to bring out both the binary count and the seven-segment hex count. My push-on/push-off switch starts and stops the count, while my plain momentary contact push-button switch activates the decimal point. I've uploaded the complete UCF and Verilog file here, so you can follow our "create project" steps from previous blogs to start with working code before heading to ChipScope.
I named my project "FND500count." You can skip the "New Source Wizard" steps and just put the Verilog file and UCF into your empty project as complete source files. Copy the two files, "7-segment count.v" and "7-segment.ucf," into a "source" folder in your project folder. (Click here to see a larger version of the following image.)
After that, you just add the Verilog file, followed by the UCF file, into the project through the "Add file" option.
Since we'll be using ChipScope once this is all done, actual hardware isn't really necessary. However, if you want to build it up, here's what I've got.
In our previous sample code, the binary counting came out on the four LEDs built into the Spartan 6 LX9 board. I started out using that sample code (both the Verilog file and the UCF). For this exercise, I changed the binary count to drive four external LEDs, just to make it easier to see both the binary count and the seven-segment count.
My point f contention with my Opal Kelly board was to find that not all IO pins are I/O. Some are I only. I haven't delved deeper, but I assumethere may be a few O only, as well. he compiler spent a fair amount of time complaining that there was a contention with the IOB pins. Once I figured that out and moved my pins around, everything was copacetic.
I guess me putting this post up indicates that I'm caught up to here, anyway. I need to add a switch or two, yet, though. Still getting by on just a mom switch.
I mentioned before that I'm using an Opal Kelly XEM3005. Awesome little board, although considerably more expensive than your device.
For the 7-segment display, I thought I would try linking into the software hooks provided with the device. Turns out that's a bit harder than I thunk it would be. I spent a week trying to figure that out, with no success.
I then spent a week roaming around tutorials, videos, etc, just generally related things.
Then I went back and tried unsuccessfully tried to make things work that worked previously.
Then went *way* back to my first "helloworld" implementation (prior to picking up your series). This, I did using the Xilinx ISE schematic capture.
I've not yet remembered to pick up a 7-seg display, resistors, wire, and breadboard, so I've not completed this tutorial, yet. However, some thoughts:
First: A lot of things I've found (videos, etc) expect you to know a lot of things going in to them, but it's a pain to try to figure out what it is you *don't* know, so you can go back and try to pick some of them up.
Second: I've been told that, anecdotally, the USA has a pretty clean break between VHDL and Verilog. Apparently, the split is at the Mississippi river, and those to the West mostly use Verilog, while those tot he East primarily use VHDL.
Interesting.
I'm finding the Verilog a little harder to wrap my head around, I think, as I've been a hardware designer (with software as a side-line) for many years, now.
Also, I noticed some things about implementation. So, as I said, my first "hello world" was done in schematics. Looking in the technology implementation schematic, what I "drew up" matches very closely to what wasi mplemented in bit code.
On the other hand, the nearly identical thing in Verilog used over 2x the resouces (maybe 3x, depending on how you look at it. So, getting where you want to go may be easier in Verilog, but there certainly seems to be a price to be paid. In this case, it would appear to be in efficiency of hardware implementation. This doesn't really surrise me, but there it is.
So, I'l suht up for now, and leave you all with those (mostly) worthless pieces of information.
I've been looking into driving a LED directly from an I/O pin with a good old multimeter.
The drive strengths seem to indicate the amount of current that can be drawn/sunk while still keeping the H/L levels within the standard's specs. It doesn't look to be a current limit.
The short circuit current of the I/O driver looks to be a lot higher than the I/O drive strength, so direct driving LEDs is most likely a bad move for the LEDs service life.
Duane Benson 8/17/2012 12:52:02 PM User Rank Blogger
Re: Not including resistors in your drive chain.
I read up a bit on Mentor I/O Designer. It's not in the cards for me due to the cost, but it looks like a good tool and it looks like answers my questions relating to PCB layout. I had been wondering about the process of placing the FPGA pins and whether it's reasonable to map pins based on PCB layout rather than based on what's best for the internals of the FPGA.
Duane Benson 8/8/2012 1:54:00 PM User Rank Blogger
Re: Not including resistors in your drive chain.
"(although maybe obvious) is that all IOSTANDARDS in a given bank need to be compatible with each other and the actual bank I/O voltage"
That is obvious to me, but I still missed it at one point and spent a half hour searching for some "mystery problem" that just happened to be me mixing some LVCMOS18 and LVCMOS33 IOSTANDARDs in the same bank.
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?
To save this item to your list of favorite All Programmable Planet content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
