Wale
1/20/2013 7:46:24 PM
User Rank Beginner
Re: Following along
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.
tomii
1/20/2013 6:32:42 PM
User Rank Blogger
Re: Following along
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.
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.
tomii
11/16/2012 10:21:14 AM
User Rank Blogger
Following along
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.
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.
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 :-)
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.
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?
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.
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.
|
|
To celebrate Geek Pride Day, Sylvie Barak has created a mega-cool infographic that depicts how geeks have been building the Internet since 1832.
When traversing serial links with optics or backplanes, high-speed signals are degraded by impairments in the link, such as insertion loss, reflections, crosstalk, and optical dispersion.
Can statistical or heuristic verification really work for FPGA designs?
One of the things I've been wondering is whether or not the "okWireOR" module is really just a giant OR, or if the order in which things are attached matters.
I am shocked and horrified. It appears that those little scamps at Planet Analog are writing blogs pertaining to field-programmable issues.
|
Tweet This
