Home    Bloggers    Messages    Webinars    Resources   
Tw  |  Fb  |  In  |  Rss
Discovering FPGAs: Sorting Out the Pins
6/4/2012

< Previous   Image 3 of 3   

Locations of the four LEDs used in this tutorial.
Locations of the four LEDs used in this tutorial.

< Previous   Image 3 of 3   

Return to Article

<<   <   Page 4 / 5   >   >>
Duane Benson
Duane Benson
6/4/2012 11:45:13 AM
User Rank
Blogger
Re: Implementation
I've just started in code. I'm debating VHDL vs. Verilog. Although at the level I'm at right now, I seem to be able to write the same code in each for comparison. I'll certainly be asking questions as I run into stumbling blocks here and there.

50%
50%
Duane Benson
Duane Benson
6/4/2012 11:42:39 AM
User Rank
Blogger
Re: FPGA design engineer vs. PCB layout designer
Max - I can definitely see the blessing/curse aspect of this. Mostly the blessing though - provided there is coordination between FPGA designer and PCB designer. If a routing is getting particularly difficult, a quick chat between the two folks can solve a really difficult problem on either side. I've certainly had cases on my own boards where, once the PCB is in my hands, I discover a mis-routing. With an FPGA, I could most likely make a change in the chip and not have to re-spin the PCB.

50%
50%
Adam Taylor
Adam Taylor
6/4/2012 11:42:17 AM
User Rank
Blogger
Re: Implementation
The model is pretty simple within a architecutre everything executes concurrently, although within a process which is contained within a architecture the code executes sequentially. So multiple processes execute at the same time, communication between them uses signals. 

Have you started writing any code or simulating code yet ? is there anyway I can help you ?

 

50%
50%
Duane Benson
Duane Benson
6/4/2012 11:38:23 AM
User Rank
Blogger
Re: Implementation
Adam - this parallelism has my head swimming (in a good way). Multi core is a pretty hot topic in the microcontroller world right now and a big challenge there is still how to best program to fully take advantage of the available parallelism. This seems significantly easier.

50%
50%
Duane Benson
Duane Benson
6/4/2012 11:34:09 AM
User Rank
Blogger
Re: A crucial point
Max- You're correct here. Most MCU functions are set on a specific pin. Most pins will have more than one function multiplexed on to it, but the ability to move things around is very limited. A good example of this is the PIC18F2320, from Microchip, that I've used in a number of projects.

Pin 12 can be GPIO, an oscillator input or the PWM output CCP2. The pin can only be one of those functions at a time, bu they are all there and can be designated in software.

If we go over to pin 24, it can be GPIO, A to D in or PWM output CCP2.

You need to set a configuration bit to switch CCP2 from pin 12 to pin 24 and once set, it can't be changed until the chip is re-programed. The other functions can be switch to in code on the fly. CCP2 can only be switched between those two pins.

100%
0%
Max Maxfield
Max Maxfield
6/4/2012 11:27:48 AM
User Rank
Blogger
Re: Implementation
@Duane: "Is the FPGA concept I outlined here more or less accurate?"

 

Yes :-)


50%
50%
Adam Taylor
Adam Taylor
6/4/2012 11:27:20 AM
User Rank
Blogger
Re: Implementation
Thats the beauty of FPGA you can have it doing multiple different things at the same time which are completely independant. While all modules operate concurrently you can chain them together such that the output of one affects the inut of another for example if your doing mathematics. 

You might find my next ask Adam blog on entities architectures etc useful in helping to understand this

50%
50%
Duane Benson
Duane Benson
6/4/2012 11:21:52 AM
User Rank
Blogger
Re: Implementation
Adam - It's starting to make sense. My thought process doesn't want to leave the software model - compile, assemble, link, upload - but I don't think that's hindering my understanding of the FPGA as much as I had thought it would.

Another convention issue going through my head has to deal with the accessibility of modules (operational modules?). In software, after the code has been uploaded to the MCU, all of the functions are there juat waiting to be called. In general, operation will be linear with one function used at a time. Each chunk of code is dependent on another chunk. It doesn't do anything until called.

In an FPGA, I'm envisioning a set of operational modules more or less in parallel. A big set could be connected to a single clock and thus operate at the same time. Some operational modules could be completely independent and operate without any interaction with other modules that might be operating at the same time. Some could act conceptually more like software and not operate until accessed by another module.

Is the FPGA concept I outlined here more or less accurate?

50%
50%
Adam Taylor
Adam Taylor
6/4/2012 11:12:29 AM
User Rank
Blogger
Re: FPGA design engineer vs. PCB layout designer
Max this is where the mentor graphics tool IO designer is excellent. it allows the schematic, FPGA pinout and layout to become controlled from one source. It also allows lots of what if scenarios to once in layout and th pins need swapping.

50%
50%
Max Maxfield
Max Maxfield
6/4/2012 11:12:06 AM
User Rank
Blogger
Pin mapping "Huh?"
Hi Duane – I have a question...


1) In your column you say that Line 5 of the .UCF file associates "LED 0" (note the '0') in the HDL with Pin P4 on the FPGA

2) Later you say that in Sheet 7 of the schematic, Pin P4 on the FPGA has been identified by the board designer as net "FPGA_GPIO_LED1" (note the '1').

3) Still later you say that this connects to the physical component LED D2 on the board (note the '2').

So, is it just me, or is this 0 - 1 - 2 naming convention just a tad confusing?

50%
50%
<<   <   Page 4 / 5   >   >>
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