Skip navigation

FPGA Group

9 Posts authored by: pjclarke

So after so many weeks we have come to the end and I have got the whole project working. If you have been following then in Part One we came up with the idea of making a temperature display using a LED matrix (5x8). This would be driven by a FPGA and would get its temperature from a MAX31855 SPI temperature sensor. We then looked at the blocks of code and function blocks that would go into this project.

 

100_4458.JPG


Then in Part Two I designed and generated the separate code blocks for the function blocks in Part One. Then in Part Three I connected the blocks together. However up till then I’d not used the SPI sensor. So in Part Four I designed a SPI interface that could interface to the chip. This used a small state machine that kept the interface running and updating a interface. So now its time to get this interface working.

 

100_4459.JPG


I think this is a very important point to say that this went very easy. The reason for that is Part Four. I had spent a lot of time designing the SPI separately and also testing it. This did not appear in the blog but simulating your design is critical. So that in this part, ‘just’ placing the code in the full project worked really well because it was well tested. Testing on a live system in FPGA without the right tools can be very hard.

So let see it working then... I placed the SPI unit into the rest of the project and changed one line of code:

--bcd(11 downto 0) <= to_bcd(cnt_r(29 downto 22));
bcd(11 downto 0) <= to_bcd(SPI_Data(28 downto 21));

Here I commented out the original line that took the counter as our data input via the BCD converter. This was replaced with data from the SPI interface.

Once compiled this just run and was even surprised myself! So below here are a few pictures of the display. Sorry images are not clear but wanted the LEDs to show up clear on the camera.

 

100_4462.JPG

 

100_4463.JPG



So that's it. I’ve once again copied in the full design files for people to look at and hopefully learn from. I hope that you have enjoyed reading these blog posts and have been inspired to go do some FPGA programming yourself.

If you want to follow my other blogs then please feel free to follow me on Twitter, Facebook or Google+.

Thanks for reading and if you do any projects yourself, write them up and post them here. We all want to hear how you get on.

Paul
(aka @monpjc)

So now that I have a working display I guess I had better get started on the SPI temperature sensor. The design process here is a little different as we are not just passing data or signals from one block to the next. What we need is a sub block that can process a few instruction to pull in the data from the SPI device.


max31855-breakout-board-onl.jpg


 

Now in some cases you may consider a state machine, but no. we first need to look at and think about what the SPI device delivers. The device I’ll be using is one I got from TAUTIChttp://store.tautic.com/ and uses a MAX31855http://datasheets.maxim-ic.com/en/ds/MAX31855.pdf. On page 5 we can the data pattern used that comes out of the device. It’s actually a very basic device to interface to. The chip select line goes low (CS) and then as the clock line is driven one bit of data comes out the device. There is a total of 32 bits (31 to 0) that need clocking out.


 

So the design can be done using a counter that counts out a number steps and during each step a different action takes place. We will need a few clock cycles to drive the CS line high, reseting the SPI device back to the start. Lets say we need 36 steps, that 32 for the data and a extra 4 for setting up and CS line etc. That’s more than enough.


 

So the code we write is going to need two sections, one that is a counter from 0 to 35 and another to drive the CS line and store data. It also needs to push the data out at the very end into a 32 bit wide signal what we can use. The counter is easy but what about the other sections?


 

Well we can start by just looking at the counter. When the counter has a value of 0 or 1 we can set the CS line high.  At count 2 we can drive the CS line low knowing that on the next clock we will get our first bit out. So thats count value 3 to 34 that will have valid data in them. These can be placed into a buffer that is shifted one bit every time too. hence data in collected one bit at a time. Once we get to count 34 we can ‘register’ the buffer into our 32 bit output. Registering it means its gets locked in so the buffer can be used again without effecting the output. It's actually nothing more that a big 32 bit latch. Also on count 34 and also during count 35 we will drive the CS line high and because our counter resets itself back to 0 when it sees 35, the whole thing starts all over again with no outside help. This is useful as we want a continuous flow of data from the temperature device.


 

Now this so far has all sounded quite a lot to do but as you will now see is not very much code at all.


 

 

 

 

 

entity SPI_Temp_Master is

    Port ( clk_i : in  STD_LOGIC;

            SPI_clk : out STD_LOGIC;

           SPI_cs : out  STD_LOGIC;

           SPI_Data_In : in  STD_LOGIC;

           SPI_Data_Out : out  STD_LOGIC_VECTOR (31 downto 0));

end SPI_Temp_Master;


 

Starting with the entity for this block we can see we have a incoming clock. We then have the interface to the SPI device which is a SPI_clk (clock output), SPI_cs (chip select) and SPI_Data_In which is the serial data from the device. Then we have the 32 bit output from the block which is called SPI_Data_Out.


 

signal SPI_rx_buff: std_logic_vector(31 downto 0);

signal SPI_cnt    : std_logic_vector(5 downto 0) := B"000000";

signal SPI_cs_sig : std_logic := '0';


 

The above signals will be used internally to the block as consist of the 32 bit buffer, our 6 bit counter (note its std_logic_vector) and then a chip select signal thats internal.


 

I then do a  bit of quick driving of the CS and clock line by having the following two lines.


 

SPI_cs <= SPI_cs_sig;

SPI_clk <= clk_i;


 

Next we need our counter noting that it resets when it sees a value of 35, back to 0. I have used the counter as a std_logic_vector as it fits with the rest of the design we have seen. Keeping consistent. People will be critical of me using the IEEE.STD_LOGIC_UNSIGNED.ALL library but for now this is about keeping it simple so I don't have to start explaining the whole which library debate. Just for now except that IEEE.STD_LOGIC_UNSIGNED.ALL is not great, but I’m using it anyway for now.

 

So our counter will look like this.


 

if SPI_cnt = 35 then

SPI_cnt <= (others => '0');

else

    SPI_cnt <= SPI_cnt + 1;

end if;


 

Notice that I’ve not included the process around this as yet, that because I’ll be wrapping the counter and the SPI block inside one process. This other block is as follows and should be easy to read.


 

if SPI_cnt < 2 then

    SPI_cs_sig <= '0';

    SPI_rx_buff <= (others => '0');

elsif SPI_cnt < 34 then

    SPI_rx_buff(31 downto 1) <= SPI_rx_buff(30 downto 0);

    SPI_rx_buff(0) <= SPI_Data_In;

    SPI_cs_sig <= '0';

elsif SPI_cnt = 34 then

    SPI_Data_Out(31 downto 0) <= SPI_rx_buff(31 downto 0);

    SPI_cs_sig <= '1';

else

    SPI_cs_sig <= '1';

end if;


 

So as you can see this block of code is lot shorter than my explanation.! The full file is included at the end of this post.

 

So we now have a working SPI unit that reads data out of our SPI device and pushes the result out once every 35 clock cycles, that’s quick. Our next stage is to plug this SPI block into our display logic we have done so far to get the final project working. That however will have to wait till next time.


 

Thanks

Paul (@monpjc)

pjclarke

FPGA Design Guide Pt3

Posted by pjclarke Mar 11, 2012

So over the last few months if you have been following my FPGA Design guide you will see that I have first blocked out the chucks of logic I needed, then last time I showed you the code used to get my first part of the temperature display working. However I said last time that having all the code in one block of VHDL makes it hard to read and is not a good idea. So this time lets look at the structure of VHDL and using separate files, ‘components’ and get our heads round the ‘entity’ and ‘architecture’ of VHDL.

So starting with the ‘entity’ statement as this is our top level for any design or sub unit. Its easy to forget when writing VHDL that its hardware, so lets think about this as if we were wiring up real chips on a bread board. The ‘entity’ therefore for the purpose of this example is going to be your chips pin out.

entity counter_30bit is
    Port ( clk_i : in  STD_LOGIC;
           count : out  STD_LOGIC_VECTOR (29 downto 0));
end counter_30bit;

Above is the entity for just our counter.

Counter_30.png

As you can see the entity lists the names of the pins and if its a input or output. All or pins and signals so far have been listed as STD_LOGIC, this is a single wire that can be logic level ‘1’ or ‘0’. When you see a reference to STD_LOGIC_VECTOR then we are talking about a number of wires like a data bus. The statement that follows explains the width and designations of the wires. Here you can see we have 30 wires labeled bit 0 to 29. The reason for the downto keyword explains that its bit 29 that is the MSB.

So next is the architecture and again we look at our counter as a separate unit.

architecture Behavioral of counter_30bit is
signal cnt_r : std_logic_vector(29 downto 0) := (others=>'0');
begin
process(clk_i) is
begin
  if rising_edge(clk_i) then
   cnt_r <= cnt_r + 1;
  end if;
end process;
count <= cnt_r;
end Behavioral;

This section as we have said before is the functanl bit of the VHDL. If this was a chip then its the bit that explains how the device works. Anything in here is completely separate from the outside world and hardware that connects to the block via the port entity can only see the connected signals.

So the next question is how do you connect this counter or ‘chip’ to others to make up your full circuit. Well this we can do via the ‘component’ keyword. From a chip and hardware point of view we would need a Bill of Materials (BOM) and also a Net list so we know what to connect where. In VHDL we will do the same sort of thing.

So if we want to use our counter in our design we first must tell VHDL what it is. This component deceleration is just like our BOM list.

component counter_30bit
port (
   clk_i : in STD_LOGIC;
   count : out STD_LOGIC_VECTOR (29 downto 0)
);
end component;

This looks a lot like the entity and that's because we are just listing the interface. This delectation will appear inside the architecture of the VHDL code before the ‘begin’ statement. After the begin statement in the functionally bit we need to create our Net list connections to other logic.

counter : component counter_30bit
          port map ( clk_i => clk_i,
                          count => cnt_r );

Here we list the component we want to use and then use the ‘port map’ keyword to generate the Net connections. I always think of this as ‘map-ing’ the pins of the chip to the signals. Here we list inside the port map first the pin (clk_i and count are the names used in the component) that then map to the signals in my design ( clk_i and cnt_r are local signals).

Improving on the original design and VHDL below I have attached all the new files. Here I have broken out each sub block and made it into a component. My top level design then only has to connect up the components, bit like wiring up chips on  a bread board.

The advantage of all this is that the blocks are easier to understand and also can be tested alone. Also means that you can use them as many times as you like in a design or in other designs.

pjclarke

FPGA Design Guide Pt2

Posted by pjclarke Feb 20, 2012

In Part 1 of my Design Guide I looked at the outline of a new project, a temperature meter, and the blocks I’d need to get started. This time I will look at the code used to display the digits on the display and examine a little of what is going on. However I want to first thank people for the questions - that's what this is all about - and address the hardware questions. I will be making a effort to generate the circuits in Eagle so that you can see the full circuits used. However I want to focus on the FPGA design first, so it will all come in the final part of this Design Guide.

I’m going to look first not at things like structure, the Entity or Architecture but the raw code used. I’ll also start out by not writing this code very well and use poor structure. The reason is I want to show you the code and ignore ‘some’ of that to start with. Later on in my next post when I explain structure, I’ll place this code in that structure.

Now referring back to the last article you will see we had blocks of functions that do things, so I’ll first start with the counter.

-- generate counter
process(clk_i) is
begin
if rising_edge(clk_i) then
  cnt_r <= cnt_r + 1;
end if;
end process;

You will see that its quite a small block of code and uses two varibles that in VHDL we would call signal’s (think signal wires) called clik_i and cnt_r. Now we cant see the size of these but don't worry for now. What you will see is that the code is wrapped up in something called a process. This is were the hardware is getting defined and you will see the process lists clk_i at the start. The process needs to know what signals will effect the output. In our case clk_i is the clock input. We then see a ‘if’ statement that looks at the rising edge of the clock and then you can see that our signal cnt_r gets changed if this is true. Now this is not like a programming language like C, you cant say X equals Y here, you have to say that X is ‘assigned’ with Y. So in our code we are ‘assigning’ cnt_r to the value of cnt_r plus one. And because the rising edge is a event the values increases each clock cycle. Its important to point out that we need to do this stuff on the rising edge, not when the clock signal is high. That's because ‘high’ is a state not a event and our little counter would run as fast as it can in a race condtion effect clicking up very fast. I’ll come back to the size of the signals later on.

The next block of code is our binary to BCD convertor.


function to_bcd ( bin : std_logic_vector(7 downto 0) ) return std_logic_vector is
          variable i : integer:=0;
          variable bcd : std_logic_vector(11 downto 0) := (others => '0');
          variable bint : std_logic_vector(7 downto 0) := bin;
          begin
                    for i in 0 to 7 loop  -- repeating 8 times.
                              bcd(11 downto 1) := bcd(10 downto 0);  --shifting the bits.
                              bcd(0) := bint(7);
                              bint(7 downto 1) := bint(6 downto 0);
                              bint(0) :='0';
                              if(i < 7 and bcd(3 downto 0) > "0100") then --add 3 if BCD digit is greater than 4.
                                        bcd(3 downto 0) := bcd(3 downto 0) + "0011";
                              end if;
                              if(i < 7 and bcd(7 downto 4) > "0100") then --add 3 if BCD digit is greater than 4.
                                        bcd(7 downto 4) := bcd(7 downto 4) + "0011";
                              end if;
                              if(i < 7 and bcd(11 downto 8) > "0100") then  --add 3 if BCD digit is greater than 4.
                                        bcd(11 downto 8) := bcd(11 downto 8) + "0011";
                              end if;
                    end loop;
          return bcd;
end to_bcd;

VHDL is as you know a way of describing hardware. To this there is a way of thinking, that the code is about thinking hardware, NOT software or sequential. However there ways of writing in VHDL that looks and feels just like normal C code. These are called ‘functions’ in VHDL and sit in a special place in the code structure which we will see later. They then get called by the normal VHDL a bit like a subroutine in normal code but its all really happening in logic, there is no processor running this code. Functions like C code can be passed signals (values) and return them too. Inside you can generate variables and write your code. Here I have taken code written in true C to do the conversions. I have had to tweak it because in VHDL you use the ‘:=’ operator not the normal ‘=’ operator for passing values between variables (not these are NOT signals).

To use this above function in our VHDL code we simply use:

bcd(11 downto 0) <= to_bcd(cnt_r(29 downto 22));

Just like C code, VHDL pops off and takes in some signals, and processes the function and gives us a answer back (well think of it this way for now). Its again all in signals so the value of the ‘bcd’ signal is assigned with the result of our function.

The next part of my code is the look up table. Here its shown in summary only:

process (clk_i) is
begin
          if rising_edge(clk_i) then
                    case bcd(3 downto 0) is
                              when B"0000" =>
                                        col_data_1(4 downto 1) <= B"1000";
                                        col_data_2(4 downto 1) <= B"1010";
                                        col_data_3(4 downto 1) <= B"1010";
                                        col_data_4(4 downto 1) <= B"1010";
                                        col_data_5(4 downto 1) <= B"1000";
                              when B"0001" =>
                                        col_data_1(4 downto 1) <= B"1101";
                                        col_data_2(4 downto 1) <= B"1001";
                                        col_data_3(4 downto 1) <= B"1101";
                                        col_data_4(4 downto 1) <= B"1101";
                                        col_data_5(4 downto 1) <= B"1000";
:
:
                              when others =>
                                        col_data_1(4 downto 1) <= B"1111";
                                        col_data_2(4 downto 1) <= B"1111";
                                        col_data_3(4 downto 1) <= B"1000";
                                        col_data_4(4 downto 1) <= B"1111";
                                        col_data_5(4 downto 1) <= B"1111";
                    end case;
                    case bcd(7 downto 4) is
                              when B"0000" =>
                                        col_data_1(8 downto 5) <= B"1111";
                                        col_data_2(8 downto 5) <= B"1111";
                                        col_data_3(8 downto 5) <= B"1111";
                                        col_data_4(8 downto 5) <= B"1111";
                                        col_data_5(8 downto 5) <= B"1111";
                              when B"0001" =>
                                        col_data_1(8 downto 5) <= B"1101";
                                        col_data_2(8 downto 5) <= B"1001";
                                        col_data_3(8 downto 5) <= B"1101";
                                        col_data_4(8 downto 5) <= B"1101";
                                        col_data_5(8 downto 5) <= B"1000";
:
:
                              when others =>
                                        col_data_1(8 downto 5) <= B"1111";
                                        col_data_2(8 downto 5) <= B"1111";
                                        col_data_3(8 downto 5) <= B"1000";
                                        col_data_4(8 downto 5) <= B"1111";
                                        col_data_5(8 downto 5) <= B"1111";
                    end case;
          end if;
end process;

Even so this is a big chuck of code! Once again we see the ‘Process’ being sensitive to the clock in our system and once again only doing anything when there is a rising clock edge. For my look up table I’m using a ‘case’ statement. Its a lot like the ‘switch - case’ statement you see in C code. However the ‘case’ statement here defines what your looking at and then it uses a ‘where’ statement  to instruct what happens. So here I have used the top ‘case’ to look at only one of the BCD digits (4 bits). The ‘where’ looks at the BCD value and can then generate or assert values onto 5 signals. These signals that are set are the LED pattens that will be used on the display. Look closely at the 1’s and 0’s and you can see that shape of the numbers to be displayed. You will also see that for the first bcd digit, when the value is zero I don't display anything. That's so we don't get a leading zero (01 for example). We can also use the ‘others’ keyword at the end of each case to cover unexpected results, like a value other than in the range 0 to 9.

Next block to look at is the shift register that drives the rows of the display:

process (cnt_r(12)) is
begin
          if rising_edge(cnt_r(12)) then
                    row_shift(3 downto 0) <= row_shift( 4 downto 1);
                    row_shift(4) <= row_shift(0);
          end if;
end process;

Once again we see the process but its not looking at the clock this time. We said in the last article that we need a slower speed for the shift register as too fast and we get problems on the LED matrix. So here I have used, for now, the 12th bit of the counter we generated. There are a few ways of making a shift register but this is my way of making it so you can see whats happening. Here we simply assign the top 4 bits to the lower bits and then wrap around the last bit.

-- drive row's on LED matrix
LED_row <= row_shift(4 downto 0);

Once we have the shift register its a simple line of VHDL to push these line out to the LED matrix.

So driving the rows was easy, and we have gone from counter via BCD to look-up table. Now we have generated the columns we need to drive them out for each row.

-- for each row, drive the col data into matrix
process (clk_i, row_shift(4 downto 0)) is
begin
          if rising_edge(clk_i) then
                    case row_shift(4 downto 0) is
                              when B"11110" =>
                                        LED_col <= col_data_1;
                              when B"11101" =>
                                        LED_col <= col_data_2;
                              when B"11011" =>
                                        LED_col <= col_data_3;
                              when B"10111" =>
                                        LED_col <= col_data_4;
                              when B"01111" =>
                                        LED_col <= col_data_5;
                              when others =>
                                        LED_col <= B"11111111";
                    end case;
          end if;
end process;

Again the ‘case’ comes in and we look at the row (shift register) signal to decide which colum of signals need to be pushed out to the LED matrix.

So now you have seen the chunks of code, below I have a link to the one file with it all in. This is not best practice but hopefully you will from the explain above be able to read it and understand it. Next time I’ll go deeper and explain the links between the blocks of code, talk about the larger structure of the code and more.

As always your feedback is welcome.

Thanks
Paul (@monpjc)

pjclarke

FPGA Design Guide Pt1

Posted by pjclarke Jan 30, 2012
Last month I looked at three different FPGA dev kits. You will have seen that I have selected the XuLA FPGA board from XESS that uses a Xilinx chip at its core. This month I want to go though the initial design process I use when designing a FPGA project. Then over the following posts you will see my progress, see the code I write and hopefully start to understand FPGA’s and my chosen language of VHDL.

Outline: So I want to know what the temperature is? I want to display this on a different type of display than normal, something a little fun looking. I’m only interested in seeing the temperature in ‘C and pulse or minus one on the display is fine.

The Hardware: So as I have said I’m using the XuLA FPGA board. As a display I have decided to use the LED 5x8 Matrix that's available from Tautic.com. I’m also going to use one of the pnp driver boards from Tautic also to help with the line driving of the LED’s. I also found while I was on the site a great and low cost temperature sensor. Its the MAX31855 K-type thermocouple that I can plug straight into a bread board. So no soldering required for this project then!

The circuit for the external hardware is as follows - in its basic form:
img1.png
Above you can see that I will use 8 lines from the FPGA to drive the pnp driver board. This then allows me to switch current to a row of 5 LEDs. The other side of the LEDs can then be pulled low to 0 volts by 5 other outputs from the FPGA. You should note here that to turn on the pnp transistor I need to send it a zero (low) and also a zero (low) to one of the five pins that pull the LEDs to 0 volts to get the LED to light. So we need a 0 and a 0 to turn on a LED.

 

Because the LED matrix is 5 by 8 I’m going to use it on its side. That way I can get two digits on it that are 4 by 5 in size. Its actually 3 by 5 as I need a space between them.
img2.png

 

As for the Thermocouple, I’ll come back to that in a later post. This is because I want the split the project up into two parts. So first I’ll work on getting the display working, then feeding it with temperature data.

 

So now you can see the external display hardware lets look at what we need to drive this internally with logic from a block point of view. I’m going to start were the XuLA demo leaves off which is with a clock input driving a counter (23 bit) and blinks a LED. This I’ll use as my data input for now and as a clock divider while I play around with the display update rates (will fix this up later).
img3.png

 

The Blinky LED flashes at bit more than once per second so is running at a good speed for us to test with. So the first thing I’ll do is to add 7 bits to this counter and use these top 8 bits as my data input to the display (bits 22 to 29).

 

Now that I have 8 bit data I need to consider how I will turn this into data to display. I could get a number as large as “255” from the 8 bits but as I’m only using two digits on the display I actually only care about “00” to “99”. If you have written software you may know about BDC (binary-coded decimal). This allows you to code a number into 4 bit blocks. So one 8 bit byte can store between 00 and 99, just want we want. If we wanted the full reading of “255” then we would need a extra 4 bits making it a 12 bit byte.

 

After breaking our data down so that we have each 4 bits holding a digit or value from 0 to 9 we then need to display them. Looking back at the LED graphic above you can see that to display the number “42” you just need a sequence of 1’s and 0’s. Noting that we need 0’s to turn a LED on, then the digit “2” would be coded as (from top to bottom as);

 

1000

1110

1000

1011

1000


So what we will need is a lookup table that will convert our signal digit from one of the 4 bits into a bit patten as show above.

 

As suggested already we need to drive each line one at a time. So the FPGA will power one row at a time and then drive the right patten for the row, from the bit patten above. Don’t worry, it will all make sense!

 

So having a look-up table generating our bit patten is one thing. As I have said we now need to drive each row in turn. This we can do with a simple shift register holding the value “11110”. One bit for each row, the zero pulling that row of LEDs to 0 volts. This patten or output from the shift register can be driven directly to the LEDs. The speed at which the shift register rotates will be our scan rate. As I said at first I’ll use a output from the counter as its quick and dirty way of changing the speed and testing - in my view anyway.

 

The last thing we need is a block that takes in the bit patten and then drives out the line of data biased on the value, or state of the shift register. So this means the shift register not only drives the LEDs 0 volt line but selects or gates out the right patten at the right time. Below is the block drawing for this.

img4.png

So having got our top level design we will design each block in turn. And that will be the subject of the next blog where I will look at the code for each block.
Thanks
Paul (@monpjc)
pjclarke

FPGA Dev Kits

Posted by pjclarke Dec 20, 2011

FPGA.jpgSo if you have been following my series of post on what a FPGA is and which is better VHDL or Verilog then you should by now be thinking about the next step - actually buying a development kit. In this post I will talk about the three kits I think you should consider and why one, in my view wins over the rest for starting out.

 

Before I get too deep let’s consider what you want from a dev kit. You will need an FPGA that will allow you to do stuff. Sounds silly but what I mean is not a chip that’s crippled on gates and features to keep the price down, but a device you can grow into. Your dev kit also needs features, what extra things will it bring that makes it usable to you? Are you looking to perform some certain task, has the board got that? Can it expand? You also need to consider that once you have done the basics, how will it grow with you. There is no point in buying a whizz board that's only good for one job. And the important thing to me (and to you) is how easy is it to use and is it well documented?

 

Over the last year I reviewed a number of low-cost, entry level FPGA boards and there are three that really stand out to me; The Nano-DE0 from Terasic, the Papilio one and lastly the XuLa from XESS. Each of these board has different merits and restrictions as well as usability, so let’s look and see what they are like.

 

The Terasic Nano-DEo is possibly the best looking, feature rich of all the boards available. At only $79 the board features the largest of the FPGAs considered, an Altera Cyclone IV with up to 22,320 LEs. On chip features of the EP4CE22F17C6N also include 594Kbis of memory, 66 multipliers and 4 PLLs as well as 153 I/O pins. The dev board itself provides 72 I/O lines that come out on 40-way headers as well as one 26-pin header providing 16 digital I/O pins and 8 analog input pins to connect to analog sensors, etc. . Analog is handled by an ADC chip (8-Channel, 12-bit)  with a high speed serial interface. This sits alongside other chips like a 3-axis accelerometer, I2C EEPROM, 32MB SRAM and other, standard dev kit stuff like LEDs and push buttons.

IMG_4604.jpg

Documentation-wise it’s good at getting you started and getting your first example done, however it quickly moves onto embedded micro using the licenced Altera core. Great if you have a licence but not if you want to make a stand-alone design. Your option then is to use an open core that you can download but may need tweaking to fit and get working. The 40-way connectors are not the easiest things to connect to for expansion and the other issue for me is that it is an Altera part. Not that Altera is bad, but the IDE provided is not the best and simulation does not have a nice work flow to it.

 

By contract the Papilio One is a Xilinx part and the Xilinx IDE and work flow is far better in my view that that of Altera. The hardware of the Papilio uses a Spartan 3E and comes in one of two sizes of FPGA at $49.99 and $74.99, so it is competitive on price. The dev board itself is limited in features, including only a power supply input and regulators, an interface chip for programming and a SPI Flash chip to store your configurations (FPGA code). Despite this the board is possibly more open than the Terasic in having its 48 I/O pins all easy to access along the side of the board, Arduino style. In fact these are laid out as wings and Papilio offers lots of add on extra wings you can buy and use that fit these connectors. You may end up spending more but you get what you want.

Copy of 100_4189.JPG

The other nice thing about the Papilio is its Arduino compatibility. You can in fact program and use the Papilio One just like an Arduino part (less the analog side). This makes it attractive as a stepping stone while you learn extra VHDL or Verilog to strap on the AVR core that's downloaded. There is quite a bit of documentation but you may find yourself hunting around on the site to find examples and answer you want.

 

The last of my three is the XuLa from XESS. This, like the Papilio carries a Xilinx chip meaning you can use the better IDE for programming and simulation. The board is the lowest cost at $55 carrying the XC3S200A device but unlike the Papilio brings with it a 8Mbyte SDRAM (16bit data ). You will find an on board Microchip PIC that is used to interface between the USB port and JTAG. You have an SPI Flash for storing the FPGA configuration (programmable via the PIC) and that’s about it. The layout is, however, mbed style in that it’s a 40 DIL making it perfect for fitting in a bread board. This then give you access to 34 I/O pins that are not shared with the SDRAM.

100_4153_small.jpg

Documentation for this kit surpasses any of the others and will guide you through what an FPGA is, how it works, your first design, errors and then even debugging via the USB on your PC. In fact it’s so good I’m wondering if I should have just posted the link in place of me writing these blogs! That aside you will also find on the site a large number of examples not only from Xess but from some customers, too.

 

So for me the clear choice is the XuLa and I will feature it in all of my posts next year showing examples of FPGAs doing their stuff. But the choice is yours as to what you would buy and what you want to get from the experience of learning about FPGAs. Remember, when designing something you need the right tool for the right job.

 

So until next time I want to wish you all a happy Christmas and New Year wherever you are and whatever you are  doing - have a geeky time.

This interview was put together to talk about the new ErP2015 changes that are effecting not only manufactures of fans but motors in general. Geoff Lockwood is the Technical Director at ebm-papst but also the Chairman of the EVIAs Fan Working Group.

 

100_4152.JPG

Over  the last few months I’ve been looking at a number of low cost entry  level FPGA development boards. The XuLa from XESS is one of those and  also one that comes well recommended by other engineers. So in this blog  post I will review how I think it compares to others in the sub $100  price range.

 

FPGAs  tend to fall into one of two main manufactures, that being Altera and  Xilinx. I’ve always been a Altera and Quartus person writing in VHDL -  that's my background so was also interested to see what its was like to  play on the other side with a Xilinx chip. The board that I have tested  is the larger XuLA-200 which comes with the Spartan-3A (XC3S200A).  Comparing this to Altera it’s similar to say a Cyclone II, both having  around 4,000 logic cells. Not the biggest chips going, good starting  point but some say these are not quite big enough. I’m a little  undecided myself.

 

 

100_4153.JPG

 

The  board is supplied as a plan PCB with no extras. So that’s just the PCB,  no connectors, cables or CD. I guess in a way the biggest issue I found  was not having the two 20way connectors down the side. This meant I  can’t ‘just’ plug it into a bread board or adaptor. I guess it gives you  the choice but from the point of view of a new hobbyist means the  soldering iron will have to come out before you can start to play. If  you want the connectors and also jumpers you can buy these for a extra  $9.

 

I’m  normally also critical of not having a CD with files on them. Its again  avalible for a extra $2 from Xess however I found the Xess web site far  and above one of the best for support and finding downloads. Under  thire product page you can find the manual as well as a ‘Learning FPGA’  guide that I’ll come back to. You will also find all the circuits as  well as all the source code build details etc. These boards are supplied  as open source and personally found that the level of detail way out  weighted the lack of not having a CD with it all on.

 

The  only thing I did have to source is the Xilinx ISE development  environment. I can’t blame Xess for not supplying this on CD as they  only make the Dev Kit. I would have however suggested to customer that  while they are waiting for the XuLA board to turn up that they start  downloading the IDE, not that its big or anything and took me me nearly  two hours to install.

 

The  rest of the XuLA hardware contains a Microchip PIC18 that handles USB  to FPGA JTAG programming. The board also contains a EEPROM that you can  store your configuration in and a SDRAM. The FPGA is clocked via the PIC  at 12Mhz which may not be the 50Mhz some supply but fast enough in my  view for 99% of applications. Anyway you can always use the internal PLL  to pump this up in speed.

 

Using  the PIC means that programming of the FPGA is not done via the IDE and  the configuration is uploaded via a GXSLOAD program available from the  website or on the CD. This was really easy to use compared to some I  have seen. Just drag and drop the output file to the utility and this  then allows programming directly to the FPGA and or to the EEPROM  allowing the board to run standalone.

 

The  PIC also adds other benefits other than just programming that you would  get with say a FTDI chip. This is because Xess have supplied as I said  all the code and also a really good example program that allows you to  talk to your FPGA, via the PIC and JTAG interface to your PC. They even  show you how to write and compile your own programmes on the PC side -  nice touch. This takes allot of the headache away from figuring out how  to do this - if you wanted to that is. The site also contains lots of  other example code as well as one supplied by customers.

 

Now  I said I wanted to come back and talk about the guides on programming  and using the FPGA board. These are second to none as I found as I  followed them word for word. There are no errors and the documents even  throw in some errors for you to fix with guidance from the documents.  This was very educational and extremely well explained. Everything from  downloading licence files to the most complex examples was very well  written and easy to follow.

 

I  would have said that for $69 the XuLA is a little high on cost for it’s  raw on the board features but as someone who has not used Xilinx before  the support of the site and documents make up for this.

 

I  also like the fact that this design plugs into a bread board and out of  the others I have seen is the only one that will. Its just really easy  to use and other than not coming with connectors, I would certainly  follow other engineers in recommending. It’s a board for beginners and  for the more advanced engineers that ‘just’ want a plug in solution.

 

If  you would like to see the reviews of the other boards I have done then  please follow the links below. In the coming weeks I’ll also be  reviewing the Papilio One.

 

Links:

FTDI Morph-IC-II FPGA Development Module - Review

DE0-NANO FPGA Development Kit Review - Terasic

 

Many Thanks

Paul (aka @monpjc)

pjclarke

Hello element14 -!

Posted by pjclarke Feb 20, 2011

1218115_99865682.jpgHello to element14 and  all you guys. I have finally got round to writing my first blog for this  site and rather than posting a blog about anyone subject I have decided  to introduce myself.

 

I live in the UK and have been doing electronics since  I was about 10years old. Electronics was not my first choice of  career however I followed what was my hobby into becoming a full time  job. I’ve worked at a number of places in my time but now work at ebm-papst UK Ltd. Most people have  never heard of them but they are a massive suppliers of fans and Farnell  are just one of thier distributors. I work as an electronics design  engineer designing controllers for our products and get involved in  fully product life cycle. That means everything from writing the  specification, circuit design, PCB layout, Prototyping, Validation  testing and all the way to seeing the first product off the production  line and into the end customer. Its a lot of work and paperwork which I  hate - hay I’m an engineer after all. I want to tinker!

 

The other big part of  my engineering life now includes a online life. How before I start I’m  going to point out that I’m going to comment on and link to other  communities other than element14. We as engineers all know about them so  I’m not going to hide that fact they exist and hopefully element14 will  not censor my blog for linking to them. OK back to my online life. This  started around a year ago when I was invited to Beta test the new RS  Electronics website called DesignSpark. Here I have written a  large number of blogs and reviews on  products. More importantly I have been using my Twitter account

and connecting to  other engineers and making new and exciting contacts like Jeri Ellsworth and more. However I  have now started to spread my wings and followed the advice of others  and decided to not just blog in one place. So in the last month I have  set up my own blog website. I’ve also  had the opportunity to blog on EngineerBlogs which is a collection  of great engineers and again is still new but getting great numbers of  hits.

 

Well that's it for my  first blog an hope you will be back to check out what I have to say. I  hope to post once a month but if you want to follow this and my other  blogs please feel free to follow me on Twitter !

Filter Blog

By date: By tag: