Archive for the Cyclone II Experiments Category

Part V of Lab 2

Posted in Altera Labs, Cyclone II Experiments on June 13, 2016 by asteriondaedalus

So a few things need sorting before I could program my Cyclone II board again.  The problem it appears was actually that the USB ports on the back of my PC had died.

So, what about the Quartus v OS story.

Same, same.

Quartus does not yet support Windoze 10.

So, what I had discovered still holds, that you cannot install the drivers as Windoze 10 disallows it.  Might be a way around it on a new install (I think you can turn driver signatures off in the BIOS).  In fact, on the Altera site, people are saying they are staying with Windoze 7 until their machines die.  The chap who designs the boards that I am using also is running a Windoze 7 box.  Seems unrealistic on Altera’s part to cause such a problem by not keeping up, at least with drivers.  A lot of this is likely “grey” market anyway.  Many manufacturers treat customers who have “grey” goods unfairly or even unethically – especially when you consider that the original manufacturer would have made their profits on the goods when they were moved into the “grey” market.

However, the quirk was as I had already installed the USB Blaster on the PC under Windoze 7 it has gotten around the block Windoze 10 places on unsigned drivers.  So, after a bit of swearing at myself for not catching the dead USB ports in the first place, all seems well.  I simply moved the blaster to the front USB ports on my PC.

I will still need look at setting up a Linux based version for my FPGA design as my PC is old and could go kaput at any time.

Even so, certainly was an interesting couple of days as I had to re-learn a few things.

So, without further adieu then, DL-L2.

So, for the Part VI of LAB 2 we need to read into “Double Dabble“.  The Part VI story doesn’t give the hint as to how but its a safe bet Double-Dabble will do.  Again we are missing buttons on our board.  We’ll take a 8 bit example and recode for 6 bit.

Perhaps, something like this first cut from wikipedia VHDL example.

Advertisements

God I am so rusty with my math

Posted in Altera Labs, Cyclone II Experiments on March 8, 2016 by asteriondaedalus

Not to mention the twists when doing math in VHDL.

Okay, I will mention it.

So dusting off the FPGA Labs from Altera University pack, recall we are working through Digitial Lab 2, in VHDL, to port it from DE0 or DE1 to  MASTER 21EDA BASIC CYCLONE II EXPERIMENTER’S BOARD!

I am currently up to Part V of Digital LAB 2 … what? … lay off!  I have been distracted somewhat … get over it.

Any old how, the math thing.

Here is the problem.

fpga math

The deal is that previously we were building a bcd adder by the numbers, using logic.  Now we are to build it algorithmically.  It is, however, more or less what the logic did.

Can’t be hard right.  Just like programming.  BUT it isn’t. Remember we are predominantly defining and wiring blocks of logic together.  In places, many many  places, we get what you might call in programming terms “concurrency” or “parallelism” because once things are wired together they can and will all send signals simultaneously if the layout permits.  All part of the problem of building logic circuits in VHDL or in Verilog.

The other thing is, being as we are building logic circuits, bits and vectors of bits rule Man!

So, it took a little work because we needed, firstly, to read into casting.  Some quirks came out, of course.

Short cut is the following VHDL code.  It compiles but I am still to debug so don’t get too excited.  However, worth taking a pause.

fpga math2

So a few things first.  Many authors of *cough* VHDL help will likely baulk.  There are some fashionable rules about how NOT to use STD_LOGIC_VECTOR, and adding is one of them.  The mantra is it’s for bits and other “types” are for math.  Never mind we also have a STD_LOGIC type in the carry flags!  (Well, we’ll mind don’t you worry about that.)

The thing though, we are learning and this brings out useful nuances to get your head around.  It did take a little time to click as one did have to read things once or twice … or thrice.

The other side, I am trying to get re-use out of the infrastructure already built in earlier parts of the lab so the inputs out outputs are STD_LOGIC_VECTOR and STD_LOGIC … so there.

The types for a_in, b_in and c_in are:

a_in : IN STD_LOGIC_VECTOR (3 DOWNTO 0);
b_in : IN STD_LOGIC_VECTOR (3 DOWNTO 0);
c_in : IN STD_LOGIC;

One thing to note, in all the scribbling out there, is that signed and unsigned are vectors so they can be cast to/from STD_LOGIC_VECTOR.  A good explanation is at bitweenie.

So, end result is that the following worked:

t <= STD_LOGIC_VECTOR(unsigned(a_in) + unsigned(b_in));

The following did not work:

t <= STD_LOGIC_VECTOR(unsigned(a_in) + unsigned(b_in) + unsigned(c_in));

Similarly the following did not work:

t <= STD_LOGIC_VECTOR(unsigned(a_in) + unsigned(b_in) + c_in);

It took some head scratching but the line that worked was:

t <= STD_LOGIC_VECTOR(unsigned(a_in) + unsigned(b_in) + (c_in & ""));

The gem, of course, was the (c_in & “”).  The ampersand or & is a concatenation operator in VHDL.  So, you are building a vector of one or, say {c_in} as opposed to c_in.  That is the “” is an empty vector so an empty vector plus an entry is a non-empty vector of one entry.  Think of vector then as array.  A good explanation, with examples, is on page 41 of a tutorial on VHDL by Peter Ashenden.

 The line I am dubious about is:

s_out <= STD_LOGIC_VECTOR(unsigned(t) - unsigned(z));

I actually curious whether I need to use signed instead, so a little thinking still to do.

Not to mention the idea that if I make z (4 DOWNTO 0), instead of (3 DOWNTO 0), I naturally get a carry bit without having to have the extra signal and so I likely can do something like this:

c_out <= z[4];

Meaning I can get rid of some of the intermediate signals.  We’ll see.

Still poking around.

Oh yeah.  It is in a process block because it has to be sequential, like a program, and not a bunch of wired up logic.  That is that other twist you need to remember.

Part IV of Lab 2

Posted in Altera Labs, Cyclone II Experiments, FPGA on September 1, 2015 by asteriondaedalus

Here is were I am up to with Digital Lab 2, having sorted out what I thought was an issue with Part IV.  Turns out I opted to invert inputs into the seven segment display code of an earlier part, but had to re-code for un-inverted inputs.

DL-L2

Part III of Lab 2

Posted in Altera Labs, Cyclone II Experiments, FPGA on August 29, 2015 by asteriondaedalus

Here is were I am up to with Digital Lab 2, having sorted out what I thought was an issue with Part III.  Turned out I was muddled by my use of 4 bit LPM constants so I just opted for 4×1-bit constants so as not to confound.

DL-L2

Hmmmmm

Posted in Altera Labs, Cyclone II Experiments, FPGA on August 20, 2015 by asteriondaedalus

When testing Part III of Lab 2 there were some anomalies. Here is where I am at – DL-L2.

I have double checked the 1-bit adder so I am thinking it is in the wiring up.  I think also I have forgotten, as usual, that the input pins need inversion before use (since they are pulled UP).  Still, when I pulled them up, I still got weird results so that points back to the wiring up.

Stay tuned for corrections.

VHDL DIGITAL LOGIC LAB 2 Interim

Posted in Altera Labs, Cyclone II Experiments, FPGA on July 12, 2015 by asteriondaedalus

LAB 2 in work, here are parts 1 and 2 at DL-L2.

No such thing as a Ghost

Posted in Altera Labs, Cyclone II Experiments, FPGA on July 12, 2015 by asteriondaedalus

Well, not anymore.

You may or may not recall during the LAB I work that we knocked up a module to allow our Master 21EDA board to behave somewhat like a Altera DE1 board with respect to the way the displays worked.

While the original code worked it had a bug where a ghost of the preceding digit would show on the current digit display.

The problem was sorted thus:

no ghost

Now it turns out if the signal M is 2bit then this doesn’t work.  There is still a hangover were the enable moves to the next digit before the digit value changes.  The fix was then to set M to a 3bit counter and then set the unused cycles to all ‘1’ – so all blank led segments when HEX=”1111111″, and setting all display enables to disabled when DISPn=”1111″.

NOTE

This is still clunky.  It may be fine for the display problem but it is likely not the best for signal problems (there may still be glitches in timing but the LED isn’t bright enough now to notice).  Will need some investigation still and some playing with registering via coding patterns.  The likely way we want to fix it properly is to set the enables high, select the digit, then set the enable low each time.