Home    Bloggers    Messages    Webinars    Resources   
Tw  |  Fb  |  In  |  Rss
Paul Clarke

Why PicoBlaze? Implementing a UART

Paul Clarke

I'm sure you've heard the old saying "Things come in threes." Well, this is one of those occasions. I'll be covering my progress with the PicoBlaze as usual, but I also want to cover three big step changes with you.

As the title of this column suggests, we will be looking at adding a UART (universal asynchronous receiver/transmitter) to our PicoBlaze. That will take up most of this post. But there's more. As you can see from the following photograph, I have a new development board.

There is no doubt the PicoBlaze in the Spartan 3A FPGA-based development board I have been using works very well. However, despite our love for this device, progress moves on, and the Spartan 6 FPGA is becoming more and more common as the entry-level Xilinx device in development boards.

This board, the Drigmorn3 from Enterpoint, comes from the UK and is worth checking out. Moving to this development board will let me take full advantage of the newer features available in both the PicoBlaze and the Spartan 6 FPGA.

Next, I want to cover how this project is structured. As engineers, we should be used to this, but you may not have thought about it as being applicable inside a FPGA. In reality, for any design, it's important to partition your project into functional blocks. The block diagram below illustrates how I have separated the PicoBlaze core from its ports and the UART.

Partitioning the design in this way means you can test each part separately. Also, it helps to make your code more reusable, because you can use these blocks in future projects. It's also going to help you, as the engineer, see what's going on. It can be hard to make sense of VHDL or Verilog files as they get very deep in code. Breaking things up like this makes everything much easier to handle.

When designing FPGAs, I like to think of each block as a small chip on a breadboard. The blocks/chips work on their own, and we need only to wire them together to make them function as a system. This is also why all I do at the top level of my FPGA design is wire the signals between each device or block.

Another thing I like to do is to organize my code into different folders, as illustrated below. As this project moves forward, you will see this structure grow, and you will understand why it's so important to keep track of your files.

Now that you have seen my changes, let's consider the UART, and I'll comment more on these changes as needed.

Next page >

Page 1 / 2 Next >
Page 1 / 2   >   >>
Myplanet
Myplanet
8/22/2012 3:15:12 AM
User Rank Guru
Re: Keeping track of things.
Thanks, Ken for your clarification. After creating the post, I had a thought in similar direction and found that your logics are correct.

100%
0%
Ken_Chapman
Ken_Chapman
8/17/2012 4:38:03 AM
User Rank Expert
Re: Keeping track of things.
 

54.25347222 is the precise result of 100,000,000 / (16 x 115,200) but clearly a clock enable pulse must be synchronous with the clock so we have to work in whole clock cycles and that typically means the nearest integer division. As it happens the most common little mistake people make is to forget that a binary counter/divider has a zero state.

By the way, if you've ever wondered why you come across a crystal with what appears to be a very strange frequency (i.e. when  ripping apart that old gadget before  you finally commit it to the rubbish bin) then it was probably there to make integer division work perfectly. For example a 31.3344MHz crystal is exactly 288 times 115,200 baud and of course 115,200 is precisely 12 times 9,600 baud.

When working with evaluation boards you have to work the best we can with the oscillator provided. For UART this is rarely an issue but for more challenging situations there are the delights of the DCM (Digital Clock Manager) and PLL (Phase Locked Loop) blocks in the Xilinx device but that really would be another Blog.

50%
50%
Myplanet
Myplanet
8/17/2012 3:34:01 AM
User Rank Guru
Re: Keeping track of things.
Ken, it seems like another blog inside the main blog. Thanks for the explanation. Ok, in your example you had mentioned that instead of 54 clock cycles, it requires 54.253 cycles. Why you had added some extra fraction of cycle? Is it something like a delay between the last cycle and reset?

100%
0%
Karl
Karl
8/16/2012 12:31:08 PM
User Rank Guru
Re: Block Diagram Partitioning
@Paul:  Those 74xx devices were really nice.  Then PROMS were very interesting because using arrays to do logic is so powerful.  The power of the big LUTS today is even better.

Now alu's that do and, or, xor, add, subtract, can be done using 1 LUT per bit of data width.  Looks like synthesis really does a good job with this approach.

I recently discovered that the memory blocks access time is so fast that 3 levels can be cascaded with a LUT level inbetween and still run at about the typical clock rate.

Now the idea is to design so the logic "flows" through the arrays.  I have seen papers recently about using chains of adders to reduce power and now I begin to see how.

50%
50%
Max Maxfield
Max Maxfield
8/15/2012 8:03:04 PM
User Rank Blogger
Re: Block Diagram Partitioning
@Paul: "we could at some point generate nice looking block images from HDL code"

There are tools available to do this (I don't know their names off-hand) but they are generically referred to as "schematic synthesis".

50%
50%
Paul Clarke
Paul Clarke
8/15/2012 9:51:18 AM
User Rank Blogger
Re: Block Diagram Partitioning
The same can be done in Xilinx's ISE.

This is how I started out many years ago, just dropping in 74xx chips and wiring them up. I too have created symbles for blocks of code too however have sort of dropped away from it as i now tend to see the blocks.

However it is a good way of 'seeing' the design. If the RTL tools were better I cetain we could at some point generate nice looking block images from HDL code.

50%
50%
Karl
Karl
8/15/2012 9:41:03 AM
User Rank Guru
Block Diagram Partitioning
Paul I think partitioning into functional blocks is the most important design step.  At some point a good block diagram is going to be needed for documentation, so start there and build on it.

I use Altera Quartus and cannot speak for Xilinx tools.  A key feature is to create blocks from HDL and use the schematic editor to connect the blocks graphically.  That way the design and block diagram evolve together and it is easier to visualize.

Many think of schematics as spaghetti, but it is not necessary to actually draw all nets and busses so the .bdf does not become as messy as one might fear.

Since the source for the blocks is HDL the design is portable.  Some files generated by the tools are IP but the HDL source is as portable, just the tool generated graphics.

I think this is a way to relieve some of the emotion of HDL zealots.

50%
50%
Ken_Chapman
Ken_Chapman
8/15/2012 7:09:07 AM
User Rank Expert
Re: Keeping track of things.
As Paul indicated the documentation provided with the UART macros in the PicoBlaze package explains how to set the baud rate but quite simply you just have to supply clock enable pulses to the 'en_16_x_baud' inputs. Unsurprisingly these pulses should be should be at a rate that is 16 times that of the intended baud rate.  For example, for 115,200 baud the enable pulse rate should be 1.8432MHz. So if you have a 100MHz system clock you can use a simple counter to generate a pulse every 54 clock cycles (i.e. count 0 to 53 and then synchronously reset back to zero to achieve 54 states). In a perfect world you would need to divide 54.253 cycles but clearly the error resulting from the integer division is less than 0.5% (assuming a perfect clock frequency in the first place) so no problem there or with any of the typical baud rates and clock frequencies.

Baud rate accuracy only becomes a challenge when the target baud rate is high relative to the clock frequency and you get unlucky with the division ratio. I agree that 5% is pushing the limits a bit because we should take into account the combined inaccuracy associated with both ends of the link as well as the signal propagation itself. In the worst case, a transmitter might be too fast and a receiver too slow or vice versa.

However (and again as Paul previously indicated), it is the average rate of the enable pulses that really matters. What we need to avoid is the accumulation of error that results in position 'creep' of the last bit. You can 'dither' the timing of the 16 pulses to obtain a more accurate time per bit. If you were really desperate you could even play with the timing of the 160 pulses associated with the transfer of a whole character (start bit + 8 data bits + stop bit).

So take an interesting example in which the baud rate required was 3Mbps (yes, I really mean 3MHz) and the system clock was 100MHz. Ideally the 'en_16_x_baud' pulse rate would be 48MHz and implies a clock division of 2.0833. Whilst it sounds like a simple divide by 2 would be adequate that would result in a baud rate of 3.125MHz which is over 4% too high and that could be marginal especially at this the bit rate. The key to the solution is to recognise that 0.833 is 1/12 so rather than thinking in terms of generating 1 enable pulse every 2 clock cycles we just need to think about generating 12 enable pulses every 25 clock cycles. In practice,  that means 11 pulses generated at 2 clock cycle intervals followed by the 12th after 3 clock cycles. In that way the average enable pulse rate is exactly 48MHz and the baud rate will be perfect. With programmable logic, implementing that is easy...

signal   baud_count : std_logic_vector(4 downto 0) := "0000";
signal en_16_x_baud : std_logic := '0';

baud_rate: process(clk)
begin
  if clk'event and clk = '1' then

    if baud_count = "11000" then
      baud_count <= "00000";
     else
      baud_count <= baud_count + 1;
    end if;

    en_16_x_baud <= baud_count(0);

  end if;
end process baud_rate;

 

100%
0%
William Murray
William Murray
8/15/2012 6:53:03 AM
User Rank Blogger
Re: Keeping track of things.
One should be able to take what the ppm's of error of the system clock does to the baud clock error, and then factor in the ratio to get to the baud rate(divider) and come close to an uppper/lower limit for an FPGA/uC board - Not forgetting to leave in a budget for temperature shift in addition to the base tollerance error budget.

50%
50%
hamster
hamster
8/15/2012 4:02:49 AM
User Rank Blogger
Re: Keeping track of things.
5% is a bit generous - you might miss the last bit if the either end is off by 5% in different directions... :-) 

I've done some high(ish)-speed rate matching for S/PDIF signals, and found it useful to generate 'trimable' enable pulses to cope with the tiny variations in clocking between the FPGA and audio source.

It hurts to work at that accuracy!

Side qn.. How do GPS receivers calculate time with greater accuracy than the local system clock, so they can acurately judge the frequency of the incoming signal... that makes my head hurt too!

I understand how they sync to the Gold codes, but they all suffer from dopler shifts too, but it must be hard to not trust the accuracy of the local clock.

From what I've read they just use an iterative solution where accuracy gets better once the receiver makes assumptions about where it is...

50%
50%
Page 1 / 2   >   >>
More Blogs from Paul Clarke
Now it's time to look at the memory interface that will supply the information required by our PicoBlaze 8-bit soft processor core.
We've now reached the point where we are ready to start debugging a PicoBlaze-based design using the ISim software simulation tool.
For some reason, my simulation never loads my memory with any contents. Instead, it's left containing undefined ('UUUU...') states. Can you help?
The PicoBlaze does not come with the ability to single step, set breakpoints, and monitor registers and memory, so we need a way to get around these limitations.
As opposed to rebuilding the entire design every time we "tweak" the code we wish to run on the PicoBlaze soft microcontroller core, we can simply use a JTAG tool to load our executable code directly into the FPGA's on-chip memory.
flash poll
information resources
sponsored content by Xilinx
All resources
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