Re: Easier to Use Micro/PicoBlaze MCU or Verilog?
Karl - I briefly looked over that "Verilog in one day" site. It looks pretty good at first glance. I'll spend some time on it at somepoint and report back on how it works for me.
Karl
5/31/2012 2:47:01 PM User Rank Guru

Re: Easier to Use Micro/PicoBlaze MCU or Verilog?
Duane, here is a tutorial that was useful when I jumped into Verilog. It has a "Verilog in one day" with simple examples of basics.
http://www.asic-world.com/verilog/veritut.html
One confusing but important thing is "blocking" vs "non-blocking" assignment. A paper by Cliff Cummings is great.
http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf
Something I have not tried is compiling Verilog with the Model_Sim simulator to do a quick simulation. That should be useful if going thru the whole design process is too slow for future projects. Probably no problem with your board.
To blink an LED should be as simple as add an output pin to drive the LED then add a T flip-flop then connect its output to the output pin.
To control the blink rate use a counter and pick a bit that changes at the desired freguency as the toggle input to the flop.
Repeat as necessary to blink several at the same rate or mixed rates.
DON'T WORRY, HAVE FUN.

Re: Easier to Use Micro/PicoBlaze MCU or Verilog?
Warren - I'm an absolute rookie with VHDL and Verilog - with FPGAs in general. Based on what I've learned so far, I'm thinking it will be easier to blink an LED in an MCU. What I'm looking forward to though, is verifying my assumption that the FPGA will be able to blink a lot of LEDs, or do other functions, at the same time.
Easier to Use Micro/PicoBlaze MCU or Verilog?
It will be interesting to see if you find it easier to blink an LED using MicroBlaze/PicoBlaze or writing code in Verilog/VHDL. Do you have any experience with Verilog/VHDL? If not, that will be another big learning curve. Start slow and only dig into what you need to for your initial program. Using examples as a starting point (known good ones) is always a big help...
Re: Open design content
Open cores is very good as is the free model foundary which does component level models for system level test benching.
Open design content
There might be some interest in Open Cores. (Not having any knowledge or experience in logic design I do not know if the projects hosted there are especially good, but the site might be a useful resource [or not].)
GitHub might also have some projects of interest.
Re: Bring Up
Adam - Thanks. That makes sense. There's only a handful of those on the Spartan-6 board.
Re: Bring Up
Just the pins which are connected between the FPGA and any peripheral inputs, as it is a small board there might not be that many.
Re: Promotion for Duane
@Duane: "At least I know that I don't know how much I don't know."
Are you sure? (grin)
Re: Bring Up
Adam - I have been looking into the UCF file. The one in the sample code I'm experimenting with only has four pin definition entries.
When you say "...You will need to ensure that you have these IO correctly driven...", are you referring to just the pins that have a definition line in the UCF file or all of the pins on the FPGA that could be set to be I/O?
|
 |
In addition to applications for reprogrammable hardware and processors in the Internet of Things, it also seems as if there will be a growing need to embed pieces of FPGA-like fabric into SoCs.
Colors are simply names we give to specific wavelengths or combinations of wavelengths that are received by our eyes. Maybe we each see colors differently.
Now we are ready to bring all the parts together and construct the GPS-driven, FPGA-decoded Nixie tube speedometer for use in a 1953 International pickup truck.
Here's an image of the week and a joke of the week. Also, this week's live online chat takes place Thursday, June 20, at 1:00 p.m. ET (10:00 a.m. PT).
Duane is now poised to use his I2C interface to send commands to the driver boards controlling his robot avatar's motors.
|