Some tutorials I'd love to see

Post your suggestions for new tutorials or anything here!
Post Reply
pdp8
Posts: 4
Joined: July 5th, 2014, 10:31 pm

Some tutorials I'd love to see

Post by pdp8 » July 5th, 2014, 11:01 pm

First, the tutorials are awesome - thank you! They were enough to get me going back on the right path. I love how you focused on the bite-sized chunks. Teaching digital design and Verilog is not easy.

Some more tutorials I'd love to see:

1) SD card! I'm working on this for my PDP-8 project, but am suspecting I'm a few days off from completion, probably with some justification at the end of the day to buy a low cost logic analyzer. I'm hoping I modified the SPI code properly to be mode 0 (I think all I have to do is remove a negation on the clock, but I haven't tested this yet). There's a ton of documentation online about interfacing an SD card to a micro, but just about nothing on interfacing it in Verilog. Even better would be an SD card interface shield, although I certainly understand the cost of producing a potentially low volume item.

2) I'm still struggling with hazards/metastability issues in my design occasionally. Certainly I can add flip flops and fix most of that, but I'm curious why the Xilinx ISE isn't warning me of these hazards - I would think it could detect these, but clearly not. It's mostly when I decide to take a shortcut and implement combinational logic on outputs, which I take it is a bad thing, but I'd love to know what the rules about that actually are. I'm sure Xilinx tells me in the docs, but that sure is a lot of documentation!

3) Making the Spartan 6 talk to an XBee is fairly easy (if you can do serial communication) - either basic serial or even more basic with the pin-signal-level relaying these devices can do. Anyone needing simpler-to-implement wireless communication would be well served looking into those. Again, an XBee shield would be cool. Maybe combined with the SD-Card? :)

4) Something that tells me what all the files created in my project directory are! I.E. what is a .wdb? What is a .prj? What is a a .drc? Etc.

5) A "Getting started using Xilinx documentation" tutorial! They write a lot of reference material, so it's a bit intimidating to know where to find useful things. I know I have a ton of questions that are certainly answered in this documentation, but finding the answer is sometimes difficult for someone without a strong EE background.

otzen42
Posts: 46
Joined: March 1st, 2014, 2:37 pm

Re: Some tutorials I'd love to see

Post by otzen42 » July 13th, 2014, 4:29 pm

1) Agreed, SD cards are super useful. I have been experimenting a bit with a core from Open Cores for an SD card, but havent' had a chance to get it working yet.

2) Metastability is tricky, and can be a nasty issue in FPGAs. It is a bit technical in spots, but there is a really good White Paper on Metastability and Clock Domain Crossing (CDC): http://sunburst-design.com/papers/Cummi ... on_CDC.pdf It does a good job going through the pitfalls of CDC, and shows examples of how to properly cross signals from one clock domain to another.

The simples solution is of course to reduce the number of clock domains in your design. Try to get as much of your design as possible synchronized to a single clock domain so that you don't have to worry about CDC. The other thing is to make NO assumptions that 2 clocks will have any sort of relation unless you are 100% sure they will. Treat different clocks (say your core clock and a external data bus clock) as 2 completely different clocks, and treat the interactions between the 2 clocks appropriately.

Not sure what you mean by "take a shortcut and implement combinational logic on outputs" but in general the biggest metastability issue with combination logic is when all of the inputs to your logic cloud are not on the same clock domain. Make sure all of your signals are properly synchronized to the same clock domain before you do any combinational logic.

4) Yeah, ISE likes to make files. A lot of them aren't very helpful, but a few of them are. I tend to do all of my builds at the command line (Just something about ISE that I can't stand). Here is a list of a few of the files I see when I run a build that are either important or useful (not 100% sure they will all be there when you use the GUI):

- *.xise: This is the ISE project file that saves all of your source code files and settings if you are running in the GUI. Don't delete this one :)
- *.ucf: This contains the user constraints for things like Pinouts and clock constraints. Don't delete this one either.
- *.prj: The .prj appears to be a list of source files for XST to use. I really don't understand the need for this file when all of the information in it is contained in the .xise file. The tools should regenerate it each time you build (I know I have my Makefile regenerate it each time).
- *.ngc: During synthesis, XST transforms your code into basic fundamental logic which represents your design. This logical representation of the code is stored as a "netlist" in the .ngc file.
- *.pcf: This is a lot like the .ucf except it is generated by the tools every time you build. It is possible to have multiple .ucf files and to end up with some constraints generated by the tools (like timing constraints for PLL outputs). The during Translate the tools condense all of these constraints sources into a single file (the .pcf) which is used for the rest of the build.
- *.ngd: During Translate the tools also merge all of the design netlists (for example if you use Coregen sometimes it outputs a pre-synthesized netlist for the core) and create a single unified netlist for the design (the .ngd). This file still contains the design as basic logic.
- *_map.ncd: During MAP the tool converts the basic logic in the .ngd into actual digital components (primitives) within the target device (xc6slx9-tqg144-2 for a Mojo). The _map.ncd is the netlist containing the design as a "circuit" made of these primitives. If you have timing constraints in your design (like the 50MHz clock frequency constraint) then MAP also runs place (for some strange reason...) and the _map.ncd will contain the physical placement of each primitive on the Silicon die of the FPGA.
- *.ncd: During PAR the tools route all of the signals between the primitives. The .ncd file contains the final routed design. This file represents the final design.
- *.bit / *.bin: The .bit (or .bin) files are generated by Bitgen. They contain the actually binary data which is stored in the FPGA SRAM which causes the silicon primitives to be configured and routed into your design. The .bin is a Microcontroller friendly version of the .bit (few headers etc.).
- *.syr: ASCII text log from Synthesis
- *.bld: ASCII text log from Translate
- *_map.mrp: ASCII text log from MAP
- *.par: ASCII text log from PAR
- *_pad.csv: Standard .csv file containing information about all of the IO used such as their directionality and IO standard. There is also a .pad with the same info in a different format.
- *.twr / *.twx: Logs from timing analysis. The .twx is an XML (I believe) version of the .twr which is ASCII text. The .twx is used by PlanAhead to allow you to look at each timing path in the device floorplan.
- *.pwr / *.xpe: ASCII text log from power analysis. The .xpe is used by the Xilinx power analysis spreadsheet, the .pwr is an ASCII text log.
- *.drc: Logs from Bitgen Design Rule Check which is performed on the .ncd before generating a .bit file.
- *.bgn: ASCII text log from Bitgen run.

5) I wish Xilinx would read this :) They do indeed have a TON of documentation, and finding what you need can be a bit of an art form. Unless you are explicitly instantiation fabric primitives in your design a lot of it is more advanced than you probably need. I would assume that most beginners will be allowing synthesis to infer things like IO buffers and Block RAMs in which case most of the documentation is not as useful.

I posted to this board a while back with a list of some of the more useful Spartan 6 documentation. The Family overview has some good general info, and the Primitives Guide can be nice if you want to start explicitly defining the primitives for your design.

embmicro
Site Admin
Posts: 834
Joined: March 24th, 2013, 12:45 pm

Re: Some tutorials I'd love to see

Post by embmicro » July 14th, 2014, 8:38 am

Thanks for the suggestions!

1) I'm currently investing in some equipment to allow for more lower volume runs (more shields!). Right now I have to make around 500 boards for it to be economical since we're not currently assembling them. That can make it too expensive to make a lot of different shields. However, With some of the new equipment, boards that can have their parts manually placed (ie, not too many parts) will be doable. This Summer is being devoted mostly to better tools, but once those are released I'll probably start cranking out a lot more shields. Hopefully come Spring, I'll be able to buy a pick and place and really get rolling.

2) The rule of thumb here is your outputs should come from a flipflop, and your inputs should pass through at least two flipflops before being used. There are some exceptions like if you know your inputs are synchronized to the clock then you don't need multiple flipflops (you should still have one to help with timing). Hazards are very hard to predict and aren't really an issue internally to your FPGA (thanks to flipflops).

3) Likely to happen after Summer/early next year.

4) I just ignore pretty much all those files but otzen42 did a good job documenting them. You can typically delete the entire syn folder and when you implement your design again all the files will be regenerated.

5) Agreed, I'll try to get something about this up.

pdp8
Posts: 4
Joined: July 5th, 2014, 10:31 pm

Re: Some tutorials I'd love to see

Post by pdp8 » July 16th, 2014, 11:52 am

Thanks, both of you!

As for the metastability issue, I'm having issues internal to the FPGA with a single clock domain - I.E. <FF> -- <COMB. LOGIC> -- <FF> where I believe the combinatorial logic is changing too soon after the rising edge of the clock, causing the "final" FF to have instability - certainly, adding a FF in the middle of a long computational logic chain seems to resolve this (FWIW, I'm not dealing with any external signals in this path). I'll have to see if I can make a simple example of what I'm seeing, and I'll post it up here in the appropriate forum. I'm sure I'm doing something dumb, and I probably need to figure out what it is.

Again, very cool board and I ended up buying a second one (going to make a speaker count-down clock for a conference. It's a rather expensive clock, so I have other plans for the board and LED matrix after the conference. :)

otzen42
Posts: 46
Joined: March 1st, 2014, 2:37 pm

Re: Some tutorials I'd love to see

Post by otzen42 » July 20th, 2014, 11:38 am

@pdp8
Very strange, internal to the device on a single clock domain the tools should be ensuring that the timing is correct. Do you have an accurate period constraint for the clock that is driving those FFs?

NET "clk" TNM_NET = clk;
TIMESPEC TS_clk = PERIOD "clk" 50 MHz HIGH 50%;

Also, when you build the design, are you seeing any timing violations? Simplest solution is to check near the bottom of the .par file for the line "All constraints were met." and the end of the .twr file for the line "Timing errors: 0 Score: 0 (Setup/Max: 0, Hold: 0)". If the .twr reports errors and the .par doesn't then it means that you have unconstrained paths somewhere in your design which aren't meeting timing. This means that the tools aren't trying to optimize the path length inside the chip for those paths, so they may take far longer than one clock cycle to get from A to B. The .par only reports failure of your constraints (the ones the tools used when routing your design), the .twr looks at all paths, including those that were routed without constraints (at least I believe the GUI checks unconstrained paths by default, you may want to check the options for the Post Placement Static Timing Analysis {I think thats what it calls it...}).

As long as you have an accurate period constraint and there were no timing violations then the tools should be ensuring that the signals will make it from one FF, through the Combo Logic, and into the next FF in time to meet all timing requirements for the destination FF. If you are still seeing odd behavior I would verify your logic and make sure it is synthesizing like you intended it to.

@embmicro
The only thing I would add to your Metastability rule of thumb is to remember that two FFs only works for single bit signals. If you have a bus of signals you must use a different technique (like a pulse sync or an AFIFO) in order to synchronize the data. If you double register each bit of the bus there is no guarantee that all of the bits will come through at the same time and you can end up with one or more bits out of alignment with the reset of your data. For example if your input was 0's and then 0x49 followed by 0x2A, you might see something on the output of your double registers like 0's followed by 0x09 followed by 0x6A. In this case Bit 6 happened to have a slightly longer path to the first Flop, and therefore is one cycle behind the others.

Post Reply