Adam Taylor 6/4/2012 10:12:22 AM User Rank Blogger
Implementation
Duane, I think Max is planning a blog on it but is is pretty straight forward in the xilinx IDE.
The first step is the synthesis which will take the VHDL, synthesis is where the behaviour of the design is extacted and mapped to available resources of the FPGA (Registers, LUTS, Memory etc).
The next three stage following that are the place and route sections of the design this will go through (translate, Map and place and route).
The translate process will bring together the synthesis output, constraints files and any other IP cores used etc and get them in a format ready for mapping and place and routing.
Mapping will attempt to fit the design into the avaliable resources of the selected FPGA and will if the right option is set place the design.
While place and route is pretty obvious is places and routes the design in a attempt to meet the design constraints
the final stage is to generate a bit file, the inital output from this is suitable for using to configure the device over JTAG (*.bit file) but you can also generate the file formatted in many different ways (PROM .mcs hex etc)
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?
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
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.
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 ?
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.
Duane, in your model "the functions are there just waiting to be called" in an FPGA becomes the functions are spinning on an input signal to begin execution. In a way the input does the "calling". If all functions receive the input(s) at the same time, they all take off.
One module generates output signals and modules spinning on those signals take off when the signals activate. Like a functions calling a functions instead of returning so the next can be called.
Parallel programming is more concerned with identifying parts of a process that can be done independently. The threads are all part of the same process, but the FPGA modules can be independent processes and therefore run in parallel.
When there is dependency between modules, then they run sequentually with the first triggering the second, etc.
Duane Benson 6/5/2012 11:34:53 AM User Rank Blogger
Re: Implementation
There's a discussion going on over at microcontrollercentral.com about asynchronous computing. I'm thinking that it may be easier to implement and possibly more common in the FPGA world than in the MCU world. Certainly there are clocks in FPGAs, but in the case of much of the logic, I don't see any reason it can't just respond as soon as the internal propagation delay allows it. Clocks will may be necessary for interfacing with the outside world or synchronizing independent processes, but I can see plenty of opportunities to not need a clock.
Duane, I promise you that there is much more to asynch than meets the eye. Some have conceeded that they are really talking about self timiing which means to delay long enough for the glitches to resolve before using a signal/buss.
It is up to the student to figure out the delay time and how to generate it. Before ICs there were tapable delay lines that could be used. Even coax cables cut to length at 1.6 nsec/foot were used.
It is standard practice in FPGAs to use static timing analysis to calculate path and circuit delay so the glitches resolve in time for setup before the clock edge. Flip-Flops are used rather than latches which are faster because the tools cannot handle them.
Believe me, you haven't lived until you have chased a glitch problem in the middle of the night.
Duane Benson 6/5/2012 12:25:40 PM User Rank Blogger
Re: Implementation
Karl - I think there's a lot more to all of this than meets my eye. :-) A long time ago, I found this thing in my dad's parts box that looked like a spring inside of a long, thin rectangular metal box. If I recall correctly, the "spring" went back and forth a few times. He called it a delay line. I newer knew what it was for until it just popped back into my head while reading your comment.
Duane, just remembered another use of a delay line. Never knew all the details, but it was used in the IBM Alphanumeric display which used a CRT that had to be refreshed to maintain the image like the TVs before flat screen. The image was input to the delay line and shifted so each character could be shifted out at the right time to be put on the screen again. The image was recirculated until it had to be upgated by shifting in a new segment.
Probably should have sent this to Jason -- hope he is watching.
A delay line clock was used in the 2860 IO channel to generate a pulse chain to move the data.
The development manager claimed it to be the biggest asynchronous design ever done. So asynch is not impossible, just tricky.
Duane, I think your dad's delay line used the length of that coiled up wire to generate the delay and coiled it up then put in the tube for space/handling reasons.
Signals propagate along a wire at about the speed of light -- 186000 mph? As I recall that equates to a delay of about 1.6 nsec/foot. And it can be tapped several times to get various delays.
Duane Benson 6/5/2012 3:08:56 PM User Rank Blogger
Re: Implementation
That's what I was thinking. I didn't take it apart and measure it, but the image I have of it in my head makes me guess at a foot or two if it were uncoiled.
Max Maxfield 6/4/2012 11:05:07 AM User Rank Blogger
A crucial point
Hi Duane -- thanks so much for this article. You have highlighted a crucial point. With most integrated circuits, the function of the pins is locked down: Pin 'n' does 'xyz' at that's it. In the case of microcontrollers, most pins have fixed functions. Some may have a limited number of choices (maybe two or three different functions). For example, Pin 'n' might be a bit in a generic fault by default, but the programmer might be able to swap it over to be part of an RS-232 interface. In some cases (and we are still talking about MCUs here) the programmer might use the C (or Assembly) code to select the function of these configurable pins. In other cases it might be necessary to use pragmas (special pre-processor directive comments) to set the configuration bits and the compiler then handles everything behind the scenes. I'm not an expert here, but it's my understanding that every C compiler and MCU manufacturer has a different way of doing things. And then we come to FPGAs. Generally speaking, in the case of the GPIO, it's completely up to the designer to decide which physical pins on the FPGA are going to be associated with which signals in the design (I was going to say "which signals in the HDL", but as we shall see in a future "Ask Max" column there are a number of different ways to capture a design, of which directly editing the HDL is just one).
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.
@Max: Duane's answer is correct, 'most functions on most MCUs...'
However, if you have ever worked with Infineon MCUs, you will find a different answer. They have flexible I/O where most functions can be moved to several different pins. There are some limitations, like PWR, XTAL1/2, etc. but still very flexible.
And, as you say, 'it can be a blessing or a curse'. So, Infineon created a tool called DAvE (Digital Application Engineer) to help create the code for all of that flexibility. DAvE has many, many features, but helping to sort out the flexible I/O mapping and making that feature be a blessing and not a curse is definitely one of them... :-)
Duane Benson 6/5/2012 12:43:47 AM User Rank Blogger
Re: A crucial point
Brian - now that you mention it, I recall an MCU from Silicon Labs that has what they call a "Dual Crossbar" allowing just about any peripheral on just about any pin. That would add a lot of flexibility with your PCB layout. Still, unlike an FPGA, the functions are fixed. They can just be rearranged. If you need five PWM outputs and the chip only has four, you can't just add one like you can with an FPGA.
Duane Benson 6/7/2012 4:29:06 PM User Rank Blogger
Re: A crucial point
These crossbar implementations must be more common than I had thought. I just ran across a number of the Microchip PIC24F family MCUs that have remappable peripherals via a crossbar. The PIC24FJ16MC101, for example, has ten peripheral pins that can be remapped around. Again, it's not FPGA, but it does add PC board layout flexibility similar to what you get with an FPGA.
Max Maxfield 6/4/2012 11:05:31 AM User Rank Blogger
FPGA design engineer vs. PCB layout designer
Re my previous comment – the fact that the design engineer can decide which physical pins on the FPGA are going to be associated with which signals in the design... may be a blessing or a curse... The thing is that a lot of FPGA design engineers don't really think about the world outside their FPGA (at least, the young and/or inexperienced don't). So they may make physical pin assignment based on what looks "nice" to them, without any thought for how the printed circuit board (PCB) layout designer is going to route the tracks on the board. This can lead to endless problems. It's not uncommon for the board designer to perform the layout, only to discover at the last moment that the FPGA designer has swapped some of the pins. Alternatively, it's also not uncommon for the board designer (knowing that FPGA pins may be swapped) to swap pins "willy-nilly" without (a) realizing that different pins are assigned to different banks that have been programmed to use different I/O standards and (b) without informing the FPGA designer of the change. This used to be more of a problem in the past when there was little if any communication between the different groups. More recently, the tools have evolved to keep track of this sort of thing ... but it's still possible for mix-ups to occur.
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.
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.
Adam Taylor 6/4/2012 11:47:08 AM User Rank Blogger
Re: FPGA design engineer vs. PCB layout designer
Of course the flexability of FPGA Io means if you do get something mis wired than all might not be lost I have seem it a few times when a footprint error on a RAM which is connected to a FPGA has crept through checking.
Max Maxfield 6/4/2012 11:11:28 AM User Rank Blogger
The world as your lobster
Duane, in your article you say "Considering the complexity of FPGA design relative to the microcontrollers I'm used to..."
Don't forget that this might just be the fact that you are so used to MCUs .... an FPGA designer might see things completely the other way round. Hang in there, because I know that once you have mastered the FPGA you will be amazed at all of the things you can do. The world will truly be your lobster (or any crustacean of your choice).
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?
Duane Benson 6/4/2012 11:57:56 AM User Rank Blogger
Re: Pin mapping "Huh?"
It's not you. It is very confusing. First, there's the identifier used in the HDL and identified in the .UCF file. Then there's the label inside the chip, the pin designator, the PC board net name and the LED reference designator on the PCB.
Here's part of the issue:
The identifier used in the HDL and .UCF file is set by the FPGA code designer
The label inside the chip is created when the silicon is designed
The pin number is set when the silicon is put in the chip package
The PC board net name is set by the schematic designer
The LED reference designator is set by whomever is doing the PCB layout
It's a lot to wrap one's head around and I'll cover it in more detail in my next blog.
This is definitely one of those blogs where reading all of the comments is important. I learned as much reading your Q&A and discussions as I did the article. (Sorry, Duane- not trying to take anything away from the blog, but I thought these comment discussions deserve special credit :-)
Duane Benson 6/4/2012 12:38:33 PM User Rank Blogger
Re: Comments...
Brian - no need to apologize. The comments make this a collaborative learning environment and in my book, that's always going to be better than just me writing something up. Sometimes I'm not even sure what questions to ask, let alone answer and having a number of extremely talented people chiming in like we do makes this all much more valuable.
My Spartan-6 MicroBoard should be here soon! I too am a software developer looking to figure out what FPGA's are all about. I've got the RSS feed bookmarked and will be following along. Hope to share my own insights as I learn from your posts!
Suggestion: As the IDE and HDL work gets more complex, consider making a screencast of how you're coding, building, and loading the MicroBoard.
Duane Benson 6/4/2012 2:23:33 PM User Rank Blogger
Re: Great blog!
Mbarclay - That's great. I look forward to hearing your insights as well.
The FPGA world is a fascinating one. In some ways it's very different from software and in some ways similar. I hope you enjoy the exploration as much as I am.
Max Maxfield 6/4/2012 1:56:58 PM User Rank Blogger
More on "Compile" and "Load"
@Duane: Re your questions about "Compile" and "Load" -- I would like to elaborate on Adam's reply a little.
Since you come from a microcontroller / software background, you are familiar with the classic definition of "compile" (in a programming sense), which is to use a computer program to translate source code written in a particular programming language into computer-readable machine code that can be executed.
One point I would like to make here is that "newbies" tend to assume that it's the compiler that generates the machine code. In reality, there are things happening "under the hood". Hidden from the user, the compiler usually generates a file in Assembly Code (or Pseudo Code), then an Assembler (or whatever you call the tool that processes the Pseudo Code) takes things the final step and generates the machine code.
The reason I'm explaining this is that there is also a multi-step process when it comes to FPGAs. As Adam says, the way things work today is that the Synthesis tool reads in your HDL and generates a corresponding netlist that maps things to the resources inside the FPGA, such as the LUTs, DSP functions, RAM blocks, and so on. The Synthesis engine does have knowledge of the FPGA's architecture and it will assign inputs and output, but it does this with no knowledge of placement inside the FPGA (by which I mean assigning items like LUTs in the netlist to specific resources the FPGA. So the netlist at this stage is just a "rat's nest" of routes between resources.
Next, a "Mapper-and-Packer" tool will further refine the assignment of resources based on any constraints provided by the user (you will be learning about constraints later). And then the Place-and-Route tool will further refine the netlist based on these constraints. So while it's true that the Synthesis engine will map the design into LUTs etc., this is not very useful from an end design perspective until Map-and-Pack and Place-and-Route are complete.
The output from this whole process in known as the Configuration File. When we talk about loading the FPGA, we really mean reading the contents of this file and loading what is known as the Configuration Bitstream into the FPGA. When this bitstream is loaded into the FPGA, it configures the LUTs, DSP functions, RAM blocks, interconnect, etc. to perform the desired functions. (Note that we're assuming an SRAM-based FPGA in these discussions).
Max Maxfield 6/4/2012 1:57:26 PM User Rank Blogger
A bit more about the UCF file
@Duane: As you noted in your column, the User Constraints File allows the user to associate signals in the RTL with physical pins on the FPGA.
The UCF is also used to set timing between pins, clocking, IO offsets, and Digital Clock Module (DCM) attributes. This file can also be used to establish the initial data stored in the block of RAM in the FPGA.
Designers should get in the habit of creating the UCF as early as possible, first to make IO assignments, also to provide the necessary timing.
If they don't create one, the tool will make assignments on its own, these will likely need to be changed for board layout and to assure various attributes are set etc.
Duane Benson 6/5/2012 11:37:34 AM User Rank Blogger
Re: A bit more about the UCF file
Max - "If they don't create one, the tool will make assignments on its own," This is interesting. I had thought the .UCF file was required. Without a universal constraints file, how does the tool set decide where to put pins and things? Does is just start at the first pin and assign them sequentially? Or is there some rhyme or reason?
Max Maxfield 6/7/2012 5:29:04 PM User Rank Blogger
More information about the .UCF file
I realized that I was a little confused about some aspects of the .UCF file, so I asked the folks at Xilinx. They replied as follows:
ISE does create a file, unfortunately it is not called an .UCF file; it is a .PCF (program constraints file).
If ISE doesn't find a .UCF file, then it will default to the .PCF file. This explains your confusion. As to the algorithm for assignments in this file... it is a simple ordered assignment of resources in order, no real magic.
The recommendation is to create the UCF file as early as possible to assure all constraints are captured and all pin assignments are made.
However, you should also note that out new Vivado design environment solves all of this by eliminating the Xilinx proprietary UCF entirely; instead it uses the open standard XDC (Synopsys Design Constraints derivative) only, which is created prior to synthesis and which can be changed at any step in the flow. This gives more control over results, not only in terms of QoR but also runtime and analysis.
Duane Benson 6/10/2012 2:28:31 AM User Rank Blogger
Re: More information about the .UCF file
Max - That explains a lot. When trying to get the ISE going, it would seem to include the UCF, but it didn't seem to care too much if there wasn't a UCF.
Did they say if the .PCF can be edited? Or is that set only by ISE and if you want your own pin assignments, a UCF is required?
Adam Taylor 6/10/2012 6:45:22 PM User Rank Blogger
Re: More information about the .UCF file
Once you have placed and routed your design if you did not specify a UCF you can create one using the back annotate pin locations option under the Place and Route stage.
You can also use plan ahead to place pins pre and post synthesis this is under the user constraints option in the design tab window.
many engineers often allow the device to place the pins where it wants first time to try and get optimal timing unless specific pins likes clocks etc are locked.They then generate the UCF file and use that one for future builds. This is where a tool like IO Designer are useful to tie up the FPGA design and the hardware schematic and ensure they are in step.
Duane Benson 6/11/2012 11:14:54 AM User Rank Blogger
Re: More information about the .UCF file
Adam - I hadn't thought of it from this perspective. I had just been thinking about making things easier for whomever is doing the PC board layout. But after reading your comment, it makes sense that the timing and optimization inside the chip might be far more important. I can certainly see some back and forth between board layout and chip internal optimization, but I would guess that the chip internal is likely to have a much greater impact on overall system performance.
Max Maxfield 6/11/2012 9:30:43 AM User Rank Blogger
Re: More information about the .UCF file
@Duane: I'm guessing that the .PCF can be edited, but why would you want to? My understanding is that it's just a "failsafe" to make sure that there are some pin assignments, even if they don;t make much sense.
If you want your own pin assignments (which you really do) then the .UCF is the way to go. And remember that in the latest version of the tool suite -- Vivado -- even the .UCF file goes away ... but we will worry about that on another day :-)
So, i'm in a similar boat. I've been an analog sensor engineer for a long time (mostly camera heads), and I wanted to start learning the digital side of things a little better.
Several years ago, I bought an Opal Kelly XEM3005 board and the associated breakout board. Similar to what you're using, with some differences.
I saw your posts, and so have decided to try to follow along a bit. I've taken a VHDL class several years ago, but with nothing to immediately apply it, ... well...
So, I've downloaded the newest Xilinx Webpack, and plugged in my board.
My "hello world" is a bit different than yours to start, but mainly based on the hardware being used. Videos are here:
Right now, I've done the implementation using schematics, as that's my fastest way forward. I'm looking for some good refeences to self-learn the vhdl, but I'm not real good at learning from books. I guess we'll see.
I have in mind a goal to push towards - a project, that is. It will be a camera controller and data buffer for some various projects I have in mind where I've yet to find a MCU fast enough to do the job.
Duane Benson 1/20/2013 6:12:54 PM User Rank Blogger
Re: Following along
Tomii - I'm going back in time to see what I can learn about VHDL. It certainly make sense to spend some time implementing designs schematic first too. Part of my problem though is that most of my hardware experience is decades old. The MCU boards I design seem pretty simple compared to what I'm trying to do now.
Yeah, I agree. Most of what I've done is pretty simple by comparison. Would you believe I'm already 20-some-odd blogs in? The schematics have been an excellent tool for learning some of the stuff, especially the code that's not horriblky obvious to me. I'm still Verilogging along, though.
I've been given an opinion from a friend, and so far I tend to agree - that is that Verilog is much easier and flexible, due to it's more programming-like nature, whereas VHDL is much more inflexible, yet also more powerful, as it's much more descriptive of actual hardware.
...
Sort of like a comparison between, say, C++ and Assebly.
Yeah schematic design is a nice step. Currently working on a project initiated through Schematic design then generated its test_filename_bench, once done simulation task will be done. Although, i am designing in VHDL but have done Verilog projects before.
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
