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?
|
|
Would you class these as adages, aphorisms, axioms, dictums, epigrams, maxims, precepts, saws, truisms, or... well, what?
Here we discover how to use the XADC (Xilinx Analog-to-Digital Convertor) in the Zynq All Programmable SoC to read the chip's internal temperature and voltage parameters and output them over an RS-232 link.
When extreme thermal cycling causes circuit boards and chip packages and the silicon die in the packages to expand and contract at different rates, problems may ensue.
In part 3 of this epic tale we consider how we might use tri-state buffers, leading up to the legendary bi-directional buffer.
Digital engineers are often confused among operational amplifiers, differential amplifiers, and instrumentation amplifiers; this is exacerbated by the fact that their circuit symbols can be similar.
|
Tweet This
