We’ve always found the Cypress PSoC an interesting beast. It’s a CPU with functional blocks that you can configure to build various I/O devices, including incorporating FPGA logic using Verilog. [MiguelVP] has an excellent multi-part project that produces VGA output from a PSoC. So far it just generates a fixed pattern, but a frame buffer is in the works, and there is plenty of detail about how to configure the PSoC for the task.
Although the PSoC has some analog capability, [MiguelVP] uses a cheap R2R DAC and VGA connector to interface to the VGA monitor. You can get the same PSoC board the project uses for about $10. The software, unfortunately, is Windows-only, so be prepared to fire up a virtual machine if you run Linux or Mac. Our own [Bil Herd] did a video introduction to PSoC that you can watch after the break.
The post mostly focuses on the configuration of the chip (with plenty of screenshots). However, the Verilog has enough comments and there is enough theory of operation that if you are more interested in how the VGA logic works, you’ll still find the post worthwhile.
Driving a VGA isn’t all that difficult, and we’ve seen it done by small CPUs and even 7400 TTL logic. However, the point isn’t the VGA driving as much as it is something flashy and non-trivial to help you get started with PSoC.
YAY!
Awesome!
Do the universal data blocks have latches or flip flops?
I’m reading the datasheet and TRM and I’m not sure if I’m missing something obvious.
It is supposed to be in the macrocell labeled as “MC1” to “MC4” in Figure 7-3. “PLD 12C4 Structure”.
They show the macrocell in their PSoC4 datasheet quote below:
>Figure 16-4 shows the macrocell architecture. The output drives the routing array and can be registered or combinational. The registered modes are D Flip-Flop (DFF) with true or inverted input and Toggle Flip-Flop (TFF) on input high or low.
So looks like the PSoC5LP have some nice features over their early PSoC4: USB, DMA and finally large enough array of 12C4 to be useful – up to 24 * 8 = 196 macrocells. Also they finally realized the need to put in a SWD debugger in a low cost tool as their IDE doesn’t support the usual 3rd party debuggers.
FYI on Creator you can export the project once you have all the data blobs ready into keil uVision, Eclipse, IAR and CMSIS (in beta at the moment)
http://www.eevblog.com/forum/microcontrollers/psoc-examples/msg529947/#msg529947
Ful debug as well, but I have not tried it on the PSoC 5LP but worked great on the PSoC 4.
BTW Al, thank you. Still a work in progress and tons of things to do.
I’m not saying either that this chip is anything close to a CPLD or an FPGA but for $10 is a good entry way to Verilog at a low power cost.
Does this schematic from the Verilog UDB Application Note help? http://www.datasheet.net/snippet/567fff12e33754500baa3d79/7e3244d4c662195a4a70dcc26cfe6e0b
Thanks tekkieneet and Oli, that helps.
Or have a ready made, to spec, full featured HDMI on a £3.30 RPI 0
Or, you know, actually learn something.
How does this drive a VGA screen?
Did somebody compare to the VGA project from MIT (2013): http://web.mit.edu/6.115/www/document/psoc_vga_design.pdf Looks nice too, includes DMA.
Their analog stuff is something that is not easily done otherwise., but IMHO not sure if their approach for the digital side make sense. You can get high ended ARM cortex chips in their price range with very sophisticated on-chip peripherals that’ll serve most applications.
Their chips comes with the building blocks and none of the usual peripherals. Even very simple peripherals can use up the PLD resources quickly. While it is a more flexible approach, to make a custom peripheral requires a hell lot of complexity that very few (outside of Cypress) could/would program. You’ll need to not only learn to use PLD (which is the easy part), but also their complex data path blocks to integrate a peripheral and write your own driver to talk to a custom block. In the end, the users have to rely on Cypress pre-built blocks which makes the whole point of programmable hardware moot.
I take your point. One thing to think about, though. With the old 8051-based parts (and I’m sure these too) you could reconfigure on the fly which was an interesting use case. So I could have the CPU configured differently for different tasks. Granted, that’s a pretty limited use case where that makes sense. It would imply you are chock full on some resource so that you can’t just have idle devices sitting around.
I have long suspected that many more FPGAs, though, get programmed with off the shelf IP, so the fact that this is probbaly similar wouldn’t surprise me. And, as you point out, the analog blocks are pretty cool.
On ARM Cortex and others, you can mux to a few different peripherals to a set of pins on the fly too. There are some restrictions on what get mapped to where and that is something you need to plan out in the design stage. Most of the time, you only need a small number of those.
Their datapath stuff (essentially bit slice ALU) while powerful isn’t quite as easy to use as the more generic finer grain configurable blocks that you find on FPGA/CPLD.
No, it’s not moot.
Sometimes its difficult to get a micro that has an array of serial ports, or multiple I2C buses, or really fast I/O that can operate while the CPU is asleep. These are special cases not easily met with most micros. If I need 5 UARTs, my options are limited.
Every single PSoC can drive LCD glass directly and not tie up the CPU doing it.
My only complaint with these parts is their relatively small memory size.
Building your own custom elements is not easy, however you can take an existing predefined “block” and modify it either at the low level API or the higher level API, or the verilog code directly.
Just to let everyone know that I implemented the frame buffer and the DMA transfers, did hit some problems, like not being able to use the internal oscillator to meet timings, but I will address that at a later date.
I still have to add the EEPROM character set and a color buffer for each character. Also I might need to add a UDB and Datapath implementation in Verilog to help on the timings since as someone already posted there is not a lot of information about that, but it’s really not that complicated since we are talking about pretty basic ALUs.
More to come. The project itself would take no time at all, but documenting all the steps and at least clarifying the issues takes a lot of time, so it’s a slow process.
Latest update is here:
http://www.eevblog.com/forum/projects/no-bitbanging-necessary-or-how-to-drive-a-vga-monitor-on-a-psoc-5lp-programmabl/msg825368/#msg825368
Also on the 3rd post I added a second part to that post on how to add a Digital Signal clock using a precise 26MHz OCXO.
I got some dual ported DIP video memory, not sure if I will add them any time soon.
Anyway, the purpose was really on demystifying Verilog on a PSoC since there are not many examples about that, now I’m just running with it because I also want to impart some of my knowledge on this chip and exposing what it can do might trigger someone to do something really cool with it, specially since this part doesn’t consume too much power.
As the project is right now, it wouldn’t be hard to use it as is to do a simple pong game or space invaders perhaps, controlled via PSoC capsense maybe.
Anyways, I’m just posting as I go, instead of when it’s all done. maybe is not the best approach but that’s what I did.
Part 5 (EEPROM character set) is done
http://www.eevblog.com/forum/projects/no-bitbanging-necessary-or-how-to-drive-a-vga-monitor-on-a-psoc-5lp-programmabl/msg825369/#msg825369
I still want to add more to that post as in adding a 2nd DMA to copy the CPU frame buffer to the video DMA controlled one, so that the CPU doesn’t have to do the memory copy 60 times per second, and also changing the DMA clock to be synced to the dma adjust value so we don’t crop half of the 1st character.
After that on post 6 I’ll optimizing the Verilog code to make use of the UDBs and the Datapaths so we optimize our resources.
Don’t know if anyone is following here but I did implemented the 2nd DMA for the copying of the CPU frame buffer to the video DMA one.
It means that we can change the CPU buffer at 60 fps
Still plenty of time for a lot of things since that is 666,666.7 clock ticks per frame at 40MHz CPU clock and 60Hz frame rate.
The refresh fits during the vertical retrace (28 lines out of 628 lines total) so we have 636,942.7 CPU cycles left @ 40MHz when it’s not refreshing
So far it’s at 800×600@60Hz with 60fps update time from the CPU on a small Cortex M3 MCU on a $10 and the CPU is free for 95.5% of the time which is plenty of time to do anything you need to the CPU frame buffer.