Ive been recently using an M74HC590 binary counter to capture some data from an opto-encoder and thought that since I'd modelled a basic binary counter into the FPGA, why don't I go the whole hog and model this real world component into it too and make a final blog post in this series.
Here's the front page and the pinout in the datasheet for the M74HC590 that I'll be modelling:
So we know what the inputs and outputs are of the device are but what about the way it functions internally? Well I looked through the datasheet and found a truth table that I could work things out from.
Using this data, I made up the following Verilog file:
As you can see Ive copied the pin labels etc.. and used nested if's to do most of the logic.
Once were happy with the Verilog file, we generate the board symbol shown here. Theres the corresponding input pins and the output pins QA throught to QG are shown as a single wire representing the 8bit output bus.
In the following schematic, Ive added the symbol for the Verilog file and made some connections to it:
The CCKEN and G pins have been connected to an internal Ground and CCLR has been connecting to an internal voltage source (VCC). These could have been broken out to real pins on the DE0-NANO P0082 board and connected manually but I did it this way for simplicity.
The RCK and CCK pins have both been connected to a push button on the development board.
The QA - QG outputs have all been connected to the LED's on the development board and the RCO pin has been left unconnected for the time being. This output would be connected to another 8-bit counter if they were being cascaded into a 16-bit counter.
From here it was just a case of assigning the LED's and pushbutton to the correct pins and the device is ready to test. The video at the bottom of this shows the final programmed development board. Because the CCK and RCK pins were attached to a push button, simply pressing that button causes the device to count up press by press.
Heres the compiler summary for the above component, very few of the actual resources were used (in most cases less than 1%):
Hopefully this gives an insight into how fpga's can be utilised by modelling existing components that we already know, this is the final blog post in this mini-series but I will be posting occasional updates of my progress on an rgb led matrix driver that Im working towards with the DE0-NANO. I intend to cheat a little bit to start with and initialise some registers with a test pattern while I work out how to drive the signal properly. Once that's done I can work backwards into a more complex design.
Top Comments