Planet FPGA brings all the FPGA Blogs from around the web under one roof. So instead of visiting multiple blogs/portal to find updates on the blogs, just visit Planet FPGA and see all the updates together. You can visit the original blog post by clicking on the title of the blog post.
Don't see the blog that you author or read here? Submit the blog to us for addition using our contact form.
Just sitting with a glass of red and sorting out final bug of VHDL for Altera Lab Digital Logic part II port for the Master 21EDA board. Looking like the multiplexers are not passing through signals for some dang blasted reason. Will sort and post full details as soon as it is cracked.
The overall carnage and woe in the chip sector in the first quarter is spreading to the second quarter, and the casualties are starting to add up. Micron Technology was absolutely blasted when it missed, and the AMD warning knocked the stock down at one point Tuesday almost 20%.
A new report from the SunTrust Robinson Humphrey team notes that while the personal computer issues are pretty well figured in, their work indicates that further demand drag in wireless infrastructure and what they call the “broad-based” industrial markets are factoring into weakness. They even think it could spread to the automotive sectors usage, which has been very strong over the past couple of years.
The SunTrust team focused on three specific stocks could have negative price reactions ala Micron, and they also could see downward earnings revisions. Combined with the fact that the companies have not really sold off big and have higher price-to-earnings multiples than some stocks, they could face a swift reaction when they report if the data is negative.
This stock has had a big run and just recently started to roll over. Analog Devices Inc. (NASDAQ: ADI) designs, manufactures and markets analog, mixed-signal and digital signal processing integrated circuits (ICs) for use in industrial, automotive, consumer and communication markets worldwide. It offers signal processing products that convert, condition and process real-world phenomena, such as temperature, pressure, sound, light, speed and motion into electrical signals.
ALSO READ: 4 Jefferies Top Value Stocks to Buy Now
The company may have been awarded a nice a product slot in the next iPhone, according to some reports, but those revenues may not be reported anytime soon, and Apple has been known to award and then pull big design awards. Overall, Analog Devices has a bright future, the near term is what investors may need to be wary of. The company is expected to report earnings in August.
Analog Devices investors are paid a 2.57% dividend. SunTrust has the stock rated at Neutral, with a $68 price target. The Thomson/First call consensus price target is $67.32. Shares closed Tuesday at $63.38.
Maxim Integrated Products
This company supplies some chips to Samsung for the Galaxy S6. Maxim Integrated Products Inc. (NASDAQ: MXIM) designs, develops, manufactures and markets various linear and mixed-signal ICs worldwide. The company also provides a range of high-frequency process technologies and capabilities for use in custom designs. It primarily serves automotive, communications and data center, computing, consumer and industrial markets.
The stock jumped in May when chatter about a buyout from Avago started to hit the tape. Avago ultimately bought Broadcom in a massive $37 billion deal that should cool that speculation at least for the near term. While Maxim’s current business seems steady, an earnings miss and revisions talked down could take a toll in the near term. The company is expected to report on July 23.
ALSO READ: 4 Top Merrill Lynch Internet Picks for the Second Half of 2015
Maxim shareholders are paid a 3.36% dividend. SunTrust rates the stock Neural, with a $33 price target. The consensus is posted at $35.80. Shares closed Tuesday at $33.72.
This is another company that has had a nice run and looks to have rolled over on the chart. Xilinx Inc. (NASDAQ: XLNX) designs and develops programmable devices and associated technologies worldwide. Its programmable devices include ICs in the form of programmable logic devices (PLDs), such as programmable system on chips and three-dimensional ICs; software design tools to program the PLDs; targeted reference designs; printed circuit boards; and intellectual property (IP), which consists of Xilinx and various third-party verification and IP cores.
Again, with a solid portfolio of products, and the distinct possibility of it being considered as a takeover candidate, what the SunTrust team views is on a very short-term basis. That means second-quarter results, which are scheduled to be reported on July 22.
Xilinx shareholders are paid a 2.87% dividend. The SunTrust team rates the stock Neutral with a $44 price target. The consensus target is at $45.04. The shares closed most recently at $43.62.
ALSO READ: Deutsche Bank’s 3 Top Networking Stocks to Buy Now
Again, these are three top-notch companies, and the play for those that own them and want to keep them would be to hedge by either selling short against the box or putting on a costless collar. That would require selling the calls, and taking the proceeds to buy the puts on the stocks. Now if the market takes a huge swift downturn, everything will get sold, these included.
I’ve been reading up as much VHDL as possible these last few days as I’ve recently found out that the majority of my summer is going to consist of writing it! After seeing loads of implementations for HD44780 16×2 character based LCDs, I couldn’t find any examples for the easy to get LCDs (by easy, I of course mean off eBay), SSD1306 based OLEDs, Nokia 5110 PCD8544 LCDs etc…
So, instead of cursing to myself why none exist, I decided to jump right in and get it done myself! The design process itself is quite simple when split into separate blocks and the first block I wrote was the SPI block because this was the easiest. SPI as I’ve mentioned before is a brilliant protocol consisting of a clock, a data out and data in line (named MISO and MOSI – Master In Slave Out, Master Out Slave In, in the industry), along with a chip select line. In my version, I have an SPI peripheral declared as a master, with a permanently low CS (a variable in the code selects whether CS toggles after every byte). The SPI peripheral I designed allows for CPHA and CPOL to be changed (though I’ve not really tested the other modes), along with a variable size data width and clock prescaler. A word of warning: The prescaler is an integer between 0 and 7. The actual amount of prescaling is equal to 2^(Presc+1) so if the prescaler is set to 1, the SPI clock out will be 4x slower than the master clock (or thereabouts). This allows for correct clocking of slower devices. The SPI peripheral has a parallel data load bus, along with a BUSY output signal and TRIG (trigger) input signal. On the falling edge of the TRIG signal, the parallel data is loaded into the shift register and the BUSY output is set high. Once the BUSY output goes high, the host can set the TRIG low again. Upon completion of the data shifting, the BUSY output goes low and the host controller should detect this falling edge and know the SPI peripheral is now free for more data transmission. As this application is only half duplex, the SPI MISO and parallel data out ports aren’t used.
The second block is the actual LCD controller. This block sends the correct SPI commands, along with reading the internal ROM and sending the graphic data to the LCD. This block controls the SPI peripheral and initializes the LCD before sending the graphic data, along with controlling the CD line on the LCD. This is where most of the magic happens!
The final block is the ROM itself. As I have an Altera FPGA, I’ll be using a single port RAM block. I’ve also designed the system using the block diagram method within Quartus and my simulations are done using the university vector waveform method.
Testing the SPI module
SPI driven LCDs generally support not having to use the CS pin during data transmission, allowing a continuous stream of data into the LCD without the host having to worry about toggling the chip select pin as theoretically, the chips already selected! For certain devices however, where the SPI input is merely a shift register without a data counter, the CS pin is needed to latch the data and indicate the end of a transmission.
Running a prescaler of 2, along with CS toggling being disabled.
The same prescaler however, CS is set after the transfer is complete.
The fastest prescaler. Four clock cycles are required per SPI clock cycle giving a maximum clock speed of 12.5MHz with a 50MHz system clock.
Zoomed out view of the above.
Obviously, it can be seen above that the SPI interface is working. on the falling edge of the TRG input (trigger), the SPI transaction is initiated and data is shifted out as expected. During this, the BSY (busy) line is set high, indicating an SPI transaction is currently happening.
Adding in the LCD controller
The LCD controller sends data and controls the SPI peripheral through the BSY and TRIG lines. Inside the LCD controller is an array containing all the instructions required to initialize the LCD, along with the code required to interface the internal ROM and write the pixel data to the LCD. The image (as ever!) was dithered and scaled in Matlab, the bits packed and written into a .MIF file (all within Matlab actually…), which can be ready directly by the Altera compiler. The image is of my landscape test scene as ever and from far away, looks… acceptable!
Attaching the LCD controller and shifting data out! As CPHA = CPOL = 0, the clock idles low and the data is valid on the rising edge.
As can be seen in the image above, the first command is 0xA8, shifted out of the SPI peripheral, as controlled by the LCD controller, wahoo!
For simulation purposes, the clock has been increased and the prescaler decreased. The initialization phase and graphics data write phases can easily be seen by the CD transition.
And just to prove it works…
Displaying my dithered test landscape scene on an SSD1306 OLED display!
I’m not cheating! It really is connected to my FPGA.
Thankfully, my FPGA development board features an easily interfaced IDC connector socket.
I’ve got the whole project up on Github for those who want to pick through my poor commentless VHDL…
There are a few development boards entered in this year’s Hackaday Prize, and most of them cover well-tread ground with their own unique spin. There are not many FPGA dev boards entered. Whether this is because programmable logic is somehow still a dark art for solder jockeys or because the commercial offerings are ‘good enough’ is a matter of contention. [antti lukats] is doing something that no FPGA manufacturer would do, and he’s very good at it. Meet DIPSY, the FPGA that fits in the same space as an 8-pin DIP.
FPGAs are usually stuffed into huge packages – an FPGA with 100 or more pins is very common. [antti] found the world’s smallest FPGA. It’s just 1.4 x 1.4mm on a wafer-scale 16-pin BGA package. The biggest problem [antti] is going to have with this project is finding a board and assembly house that will be able to help him.
The iCE40 UltraLite isn’t a complex FPGA; there are just 1280 logic cells and 7kByte of RAM in this tiny square of programmable logic. That’s still enough for a lot of interesting stuff, and putting this into a convenient package is very interesting. The BOM for this project comes out under $5, making it ideal for experiments in programmable logic and education.
A $5 FPGA is great news, and this board might even work with the recent open source toolchain for iCE40 FPGAs. That would be amazing for anyone wanting to dip their toes into the world of programmable logic.The 2015 Hackaday Prize is sponsored by:
This breakout board helps me to interface my FPGA with the DAC900E from Texas Instruments.
The DAC has 165 MSPS and 10 bits which is quite some speed.
The combination FPGA and DAC opens up for experiments with digital signal processing, like making a direct digital synthesizer (DDS), digital modulation and many more. The DAC is fast enough to use it in the TX part for a shortwave radio without any analog mixer required.
A detailed description can be found:
[Daniel Bailey] built himself a scaled-down clone of a very early computer in an FPGA. Specifically, he wrote some VHDL code to describe the machine in question, a scaled-down clone of the Manchester Small-Scale Experimental Machine with an 8-bit processor and a whopping 8 bytes of RAM, all of which are displayed on an LED screen. Too cool.
That he can get it to do anything at all with such constraints amazes us. Watch him program it and put it through its paces in the video below the break.
The coolest thing about the original “Manchester Baby” is that it retains memory in a Williams tube, which is essentially a CRT with an electrical pickup plate covering up the screen. You know how you get a static charge on the face of an old CRT where the electron beam hit? Well, it turns out that you can read this electric field for a while, and use it as a short-term memory element.
The builders of the SSEM included a second CRT screen so that you could visualize the entire 32×32 bits of memory on a screen, like you would. Naturally, [Daniel] had to replicate this feature on his Manchester Baby clone, but with an 8×8 LED matrix. Now we want one of those for our laptop.
Thanks [Ed] for the tip.
After managing to get my graphics controller working at a mediocre resolution of 100×75, I wanted to squeeze as much performance out of this chip as possible! Unfortunately, due to memory constraints, this meant rewriting the VGA controller to work at a different resolution. The original controller was running at a resolution of 800×600, which when divided by 8 gives us the 100×75 pixel resolution with each 100×75 macropixel consisting of 8x 800×600 pixels. I’m using power of two resolution divisions as this allows me to calculate the memory addresses through only two shifts and a multiply, as opposed to 2 shifts and 3 multiplies (along with much more logic space…). Therefore, the next logical size up will be 4x sized macropixels, meaning a total resolution of 200×150. All seemed great after I changed the memory widths and hit compile. Disaster! Turns out, my FPGA only contains 30x M9K memory blocks whereas for a resolution of 200×150 (at 8bpp), would’ve required 32x M9K blocks! I can’t help but feel a little gutted that only two M9K blocks were holding me back from the prime resolution of 200×150 pixels.
I then reattached my thinking hat and thought of other methods of squeezing out the best performance I could from this chip. If 200×150 was the next step from 100×75 for a master resolution of 800×600, why not change to a different master resolution and subdivide that? And so that is what I did. I’ve now rewritten the VGA controller to work at 640×480 though I need to test how temperamental it is in the long term. Since my master clock is 48MHz, the best I can achieve with the PLL is a pixel clock of either 25.2MHz (supposed to be 25.175MHz) or 31.5MHz. Of these two, the 25.175MHz clock is the industry standard, however since I can actually properly synthesize the 31.5MHz clock, I’ll be using this. This will give a refresh rate of either 73Hz in VGA mode of 75Hz in VESA mode.
Now that I’m running my monitor at 640×480, I can group the pixels into 4×4 macropixels (640×480/4 = 160×120) while also storing the whole framebuffer in my onboard dual port SRAM! This is pretty much the best resolution that I can achieve in my setup without the use of external RAM though even this small increase in resolution (1.6:1.33..), video playback has reduced to a sloooooow 6.6fps.
Oh yeh, it turns out I had a small error in my original block diagram file where the memory clock is meant to be the same as the shift register clock. This was causing erratic pixel errors at high write rates.
Rerouting the memory clock
Using the same test pic of me and Kim, the quality is much better than with the previous 100×75 version.
Nothing like a close up, still got those random cyan artifacts on our noses…
Testing the display with my landscape test image
…And a closeup! The macropixels being smaller really adds to increased quality.
Keep tuned for more updates!
Well, this week so far has been very productive with regards to electronics! This is a project I’ve been wanted to do for ages just haven’t got round to doing. I’ve previously designed VGA controllers on both my CPLD and my FPGA board but I’ve not actually done anything useful other than design a bouncing box and display a few colour bars so I finally thought: why not actually try developing a full graphics controller, how hard can it be?!
The answer to that is actually “not very hard”, I managed to get it working relatively well in one evening of coding, displaying text, images and (unsynchronised) video!
While I love my STM32F0, and wouldn’t swap it for any other platform, it is limited when it comes to precision timing events (or more so, I’m limited in my assembly knowledge!) so all I’m essentially doing is outsourcing all of the precision timing events to the FPGA and shifting data to the FPGA from my STM32F0.
The FPGA side of things is essentially just a super dumb half duplex unidirectional memory interface. The FPGA expects a 24bit SPI transfer consisting of the memory address and pixel data.
Block diagram file for the FPGA VGA Controller
Yes, I know that the block diagram method of Altera is for lazy people but I am lazy and don’t see the point in port mapping (for this application) when everything is so much easier to visualise in the block diagram format! Regardless, each section has a different use and I’ll go through what those uses are.
“SR” (Inst4, bottom left):
This is the main interface to the world! Its pretty much a 24bit SIPO shift register where it accepts 24bits in serial form and outputs 24 bits in parallel form (to the busses PDO and MADDR), along with controlling the WR input of the dual port SRAM. To ensure the system is kept stable, the incoming clock, data and latch inputs are synchronised to the the c1 clock, running at 192MHz. The reason this clock is so fast is to ensure the FPGA can capture every edge of the SPI clock/latch from the STM32F0. I’m clocking the STM32F0 SPI at 24MHz and without a drastic amount of oversampling, data from the STM32F0 to the FPGA was getting corrupted.
Upon the latch input going from high to low (falling edge), the WR pin is set low and the two outputs PDO and MADDR are both set to zero. The system then clocks in 24 bits on the rising edge of the clock input (from the STM32F0). If more than 24 bits are clocked in, like a FIFO, all the original bits will get shifted out of the top and will be lost. On the next rising edge of the latch input (low to high), the WR pin is set high, along with the shifted data being written to the two output ports, PDO (Port data output) and MADDR (Memory address). On the next rising edge of c1, this data will be written to the dual port SRAM
PLL (Inst8, farthest left):
This block does pretty much what it says in the name, it PLLs! For those who don’t know, PLLs are effective methods of creating fractional multiples of an input square wave, such as clocks, variable duty cycle pulse waves or phase shifted square waves. The reason I’m using a PLL is to provide two system clocks. One for the VGA controller and memory interface and the other for the shift register. The two output clocks, c0 and c1 have output frequencies of 48MHz and 144MHz, respectively.
VGA Controller (Inst, top right):
This is where all the timing magic happens! This block generated the VSync, HSync, and colour output signals, along with the memory address of the current pixel. The memory address is generated from the horizontal and vertical counters. The actual timings used, give a resolution of 800×600 pixels which if you divide both by 8, gives the chosen resolution of 100×75, nifty huh! Fortunately, division by 8 is as simple as shifting down by 3 bits by using the srl keyword. The VGA controller section actually outputs a 16bit word per pixel as this is what the DACs on my FPGA board support. My controller however only has an 8bit video interface (256 colours). To essentially “upscale” from 8bit colour to 16bit colour, some of the most significant bits are assigned to the lower bits, on the red channel for example:
Red(4 downto 2) <= MemDI(2 downto 0);
Red(1 downto 0) <= MemDI(2 downto 1);
Where MemDI is the data into the controller from the memory module. This upscaling allows the controller to display full red, green and blue, as opposed to only displaying the top few bits. The controller also ensures that the colour outputs are zero during synchronisation phases (required for some monitors).
The VGA controller outputs a memory address to one side of the dual port SRAM and reads the data from the same side on the next clock edge, displaying it pixel by pixel to the screen.
Dual port SRAM memory (Inst7, bottom right):
Dual port SRAM is by far the easiest method of allowing both read and write operations at the same time giving a layer of separation between the shift register interface and the VGA controller. This drastically simplifies potential synchronisation problems that may become present when trying to read and write a single port SRAM at the same time. The problem here however comes with larger occupied space and increased complexity in manufacture. Fortunately for me, the FPGA I’m using (Altera Cyclone IV EP4CE6E22C8) features onboard memory blocks, allowing me to store the whole frame buffer for a 100×75, 8bit pixel screen on the FPGA. If more memory was available, I would be able to store the whole 800×600 pixel frame buffer but the amount of space increases dramatically with increasing screen sizes! I need 7,500 bytes to store a 100×75 8 bit frame buffer whereas I need 480,000 bytes to store a 800×600 8bit frame buffer! In the future, I might replace this for an SDRAM interface for my onboard SDRAM, allowing me to store the full frame buffer.
As the interface is so simple, I can shift data from the STM32F0 to the FPGA pretty fast. As the STM32F0 series features a variable length SPI interface, I can send a pixel over in two 11bit SPI writes (8 bits for the pixel colour and 13bits for the address). I have however made the shift register 24bits long, for systems that don’t support a variable length SPI interface, instead requiring 3x 8bit SPI writes. As it doesn’t take that long for the STM32F0 to send a pixel over, it actually allows relatively complex tasks such as video playback to be realisable at a relatively good frame rate. Reading my proprietary video format off a bog standard SD card, through the SPI protocol on the STM32F0 gave an unsynchronised frame rate of ~17fps. By proprietary video format, I merely mean packing every pixel, one after another into a data file and streaming that off the SD card and into the graphics controller. No decoding/decompression takes place on the STM32F0.
The video conversion is done in Matlab where the scaling factors for the original video to the 100×75 pixel screen are first calculated, the video is then scaled and converted to RGB332 format (SLOW SLOW SLOWWWWWW) and finally written to the output data file. This process is unbelievably slow, most probably because Matlab isn’t really meant to be used for relatively heavy video processing. I’ve been meaning to get around to creating a C/C++ program to do my video processing needs but haven’t got round to it just yet… This same process is used for displaying images on the screen. The image is first scaled, then packed into RGB332 format and stored in a data file, to then be read on my STM32F0 and each pixel pushed into the screen buffer. One very fortunate thing however is the fact that as the screen is interfaced with a single function: WritePix(X, Y, Col), my previously written “GFXC” library can be used to write data to the screen! This allows me to do things like write text, draw circles, ellipses, squares and so on.
Displaying a test image of mine, a colourful “landscape” image I got off google!
That same image, up close. You can now see every macropixel.
A picture of me and my girlfriend! It looks better from afar…
…Then you see the close up and we look like we’ve been cross-stitched! I don’t know why there are random green artifacts chilling in the image.
Using my GFXC library to write some text to the screen. Believe it or not, thats the smallest font…
One of the cooler things, displaying the colour dependent mandlebrot set! Who doesn’t love good ol’ fractals.
I will at some point in the future be uploading code for this project but I wouldn’t as of yet consider it complete enough to release to the general public as there are still a few niggles that I need to iron out. Until then, keep tuned for more updates!
Oh and also, here is a quick vlog demonstrating the video playback capabilities:
Besides the cost difference, there is a huge advantage by using N25Q128 or N25Q064. Their packages are both SOIC-8 whereas EPCQ64 and EPCQ128 are only available in SOIC-16 packages as of today. This could save you some board space!
I personally had tested N25Q128A13ESE40E and N25Q256A13EF840E on hardware to configure Altera FPGAs in both Active Serial x4 and Active Serial x1 modes. It works fine. No issue for the Quartus II software programmer to program the POF files into these N25Q devices, too.
If you’ve been keeping up with the hobbyist FPGA community, you’ll recognize the DE0 Nano as “that small form-factor FPGA” with a deep history of projects from Oldland cpu cores to synthesizable Parallax Propeller processors. After more than four years in the field though, it’s about time for a reboot.
Its successor, the DE0 Nano SoC, is a complete redesign from multiples perspectives while doing it’s best to preserve the bite-size form factor and price that made the first model so appealing. First, the dev board boasts a Cyclone V with 40,000 logical elements (up from the DE0’s 22K) and an integrated dual-core Arm Cortex A9 Processor. The PCB layout also brings us 3.3V Arduino shield compatibility via female headers, 1 Gig of external DDR3 SDRAM and gigabit ethernet support via two onboard ASICs to handle the protocol. The folks at Terasic also seem to be tipping their hats towards the “Duino-Pi” hobbyist community, given that they’ve kindly provided both Linux and Arduino images to get you started a few steps above your classic finite-state machines and everyday combinational logic.
And while the new SoC model sports a slightly larger form factor at 68.59mm x 96mm (as opposed to the original’s 49mm x 75.2mm), we’d say it’s a small price to pay in footprint for a whirlwind of new possibilities on the logic level. The board hits online shelves now at a respectable $100.
Next, as a heads-up, the aforementioned Arduino Zero finally makes it’s release on June 15. If you’ve ever considered taking the leap from an 8-bit to a 32-bit processor without having to hassle through the setup of an ARM toolchain, now might be a great time to get started.
via [the Arduino Blog]