Archive for March, 2014

Cyclone II-Exp.5

Posted in Cyclone II Experiments on March 31, 2014 by asteriondaedalus

Straight forward. No crashing tonight.  Glass of stale cab sav – I wonder if that’s what makes the difference??

module KEY_AND_LED ( A, B, F );

input A,B; output F; assign F = A & B;

endmodule

Nothing exciting here, no buttons then no lit LED, any or all buttons then LED lights.

So I bumped the inputs and played around with views.

module KEY_AND_LED ( A, B,C, F );

input A,B,C; output F; assign F = A & B & C;

endmodule

Becomes, in the RTL view:

RTL view

RTL view

As you might expect, it thence becomes in the technology map view:

Raw technology map view

Raw technology map view

More interesting is:

viewsd

Double click and hover over technology map view

And finally, voila! it becomes:

The raw gate from the chip planner view

The raw gate from the chip planner view

Of course, you can chase down the input/output pins as well:

PIN_40 or input C

PIN_40 or input C

The output pin

The output pin

To close the loop:

The "assignment"

The “assignment”

Cyclone II-Exp.4

Posted in Cyclone II Experiments on March 30, 2014 by asteriondaedalus

Gag!

Code was simple enough:

module KEY_OR_LED ( A, B, F );

input A, B;
output F;
assign F = A||B;

endmodule

But the pin assignments in the default example project didn’t make sense, they were set to:

wrong

wrong

 

I went with it, just in case I was missing something, but compiled, bombed and no LED lit.

Changed to:

right

right

Got:

again

again

 

But held my breath and restarted and got a circuit that worked counter intuitively until I dusted off me logical thinking.  No LED lit if either of the buttons weren’t pressed.

No LED lit if one of the buttons pressed and … finally … LED lit when both buttons pressed.

Basically both inputs are held high by a 4.7K ohm resistor and you need to drive both low to drive the LED low because of the OR function (either input high then high at output then LED sees same voltage at each of it’s pins – 3.3V).

All good.

Cyclone II-Exp.3

Posted in Cyclone II Experiments on March 30, 2014 by asteriondaedalus

Gag!

quartus error

Bugger!

Now I am actually known for finding bugs in things.  I even got a contract letter from L3 to the company I was working for in Canada that requested I be taken off testing BECAUSE I was holding up the project BECAUSE I was finding bugs – I was so proud, regretted keeping a copy of the letter for my CV LOL.

So, how did I get this error.  Well, straight forward really. I took the next example, which was the Verilog rather than schematic example of the switch plus the LED and modified it.  It worked alright unmodified but I wanted to extend it to use an array of switches inputs.

Unmodified it started out as:

module KEY1_NOT_LED ( A, F );

input A ;
output F;
assign F =~A;

endmodule

Now it turned out setting up the array wasn’t that straight forward.

I just did something as kooky as the following:

module KEY1_NOT_LED ( A, F );

input [3:0] A ;
output [3:0] F;
assign F[0] =~A[0];
assign F[1] =~A[1];
assign F[2] =~A[2];
assign F[3] =~A[3];

endmodule

Now this didn’t work, of course, when I went to assign the pins to ports as the pin assignment would want to assign them as an IObank it would appear.  No problem.  I decided to compile anyway – expecting I would have to go for another approach anyway and voila! the crash bang boom!

Now restarting the Quartus tool and no crash.  Compiles and I can bomb chip.  A single LED lights but we know that isn’t right.  This points to a quirk in the project that sees the pin assign balk when trying to assign pin 43 – the software feels this is already assigned??  This seems to suggest database in some kooky state.  Why you ask?  Well pin 43 was assigned as input in the unadulterated code prior to the mod and the crash.  All good, read on.

Of course, the resultant code that I should have written in first place included creating a module that would be instanced:

module KEY2LED (input K, output L);

assign L =~K;

endmodule

 And then simply calling it four times:

module KEY1_NOT_LED ( input K1,K2,K3,K4, output L1, L2, L3, L4 );

KEY2LED (K1,L1);
KEY2LED (K2,L2);
KEY2LED (K3,L3);
KEY2LED (K4,L4);

endmodule

Assigning keys and LEDS:

K1 INPUT PIN_43
K2 INPUT PIN_48
K3 INPUT PIN_40
K4 INPUT PIN_45
D30 OUTPUT PIN_65
D31 OUTPUT PIN_69
D32 OUTPUT PIN_70
D33 OUTPUT PIN_71

So, upshot voila! it recompile, seemed to clear up database and:

 

Look closely, only 3 LED glowing ... no really ... look harder

Look closely, only 3 LED glowing … no really … look harder

Cyclone II-Exp.2

Posted in Cyclone II Experiments on March 29, 2014 by asteriondaedalus

No red wine this time.  Some stout instead.

So experiment 2 – adding a switch to turn the led on and off.  Gripping stuff!

So, the board comes with switches connected to inputs on the FPGA so just jumping in and going for it.

Altera Cyclone II

In fact:

K1 INPUT PIN_43
D30 OUTPUT PIN_65

So closed Exp.1 file and opened Exp.2.

Something new.  Compiling the file is fine.  When I open the “Programming” window for the first time it balks with “Cannot add target device EPCS4 when in current programming mode” – something to chase down sometime but lets push on.

When using the “Auto Detect” function in the “Programmer” window it adds an EP2C5 device to the chain – which I suspect is sitting in the USB Blaster.

Once the x.sof file for the project is added, the target device is chained with the EP2C5.  The EP2C5 selected in the window and can be deleted from the chain.

Once programmed the LED on PIN_65 is lit and it is unlit when you press the switch on PIN_43.

Changing it up

So, simple enough change is to tie four LED to four switches.

Except…

… first up, what is not intuitive is that when you are in Pin Assignment tool, you can manually set direction.  This wasn’t a problem in the end once you go and compile but when you first make the assignment it won’t allow you to set it.  Turns out, if you are using the schematic it was set when you created an input pin type.  The problem, it doesn’t get reflected into the pin assignment when you make it initially.

However, the steps outlined in the training material seem to reflect this anyway – you need to compile so the Pin Assignment tool picks up the pin directions.

Second problem.  For what ever reason simply adding 3 extra circuits seems to simply light up all LEDS on board, including 7-segment displays … and buzzer … hmm.

Started new project with only only switch and one LED – mirroring the one in the example library that comes with the board, still the same thing.

Next morning, after a long bike ride and a brunch …

Usual Microsoft-like problem.  I deleted the project, unzipped it again from the archive, got one LED responding to each of the 4 keys in turn (reassigned and recompiled each single connection).  So there wasn’t a problem with the switches.

Added a second circuit to the schematic of the refreshed project and voila! it is okay this second time around.  No obvious reason for not working the first few times.

Thus, all four switches finally included.

So:

K1 INPUT PIN_43
K2 INPUT PIN_48
K3 INPUT PIN_40
K4 INPUT PIN_45
D30 OUTPUT PIN_65
D31 OUTPUT PIN_69
D32 OUTPUT PIN_70
D33 OUTPUT PIN_71

On our way again.

POST SCRIPT

Now I thought I would add a glyph and, of course, I opened the project again to screen capture the schematic.  Go figure, only two circuits were in the schematic (the picture below has been corrected).

When I looked at the pin assignment all the pins were there, the components for the second two circuits were “missing” from the schematic.  I compiled the schematic and voila! software crashed and bailed out to operating system.  I had to go back in and re-add the components damn it!

Any old way, not that exiting but why does it have to be so niggly.  Seems the Quartus software is quite buggy at version 10.1.  Can’t, upgrade as I need 10.1 for the chips I have in my development boards.

Won’t be a problem once I have gone through the pain of learning FPGA design as I will move to updated chips.  Better not be.  I still have my Xilinx boards to tackle once the Altera exercises are done, so we’ll see if there is a different in the quality of the software tools then

 

Just block copy right ... well ... er ... things do come amiss

Just block copy right … well … er … things do come amiss

Cyclone II-Exp.1 – followup

Posted in Cyclone II Experiments on March 29, 2014 by asteriondaedalus

Coming back to the board I half expected when it started that it would simply light up the LED from the previous experiment.

However, it jumped back up into counting up seconds on the 7-Segment displays.

!a light bulb moment!

In fact, I now recall from the training is that the FPGA can be booted from from EEPROM and, voila! looking a the schematic there is an AT24C04 on the board.

But wait, there is more!  Serial configuration via EPCS4.  So, a little more to the board than the manual alludes.  So, the FPGA will always boot up to counting up seconds as the CMOS SRAM elements of the FPGA will be needing instruction.  Subsequent programming via JTAG by the USB Blaster will obviously clear that sucker out with the new code.

The purpose of the EEPROM needs some investigation but I suspect it might be programmable and itself to provide a cold boot other than the counting up in seconds.

In any event, fiddling with the pin layout to light different LED is straight forward – but requires re-compile each time.

 

Cyclone II-Exp.1

Posted in Cyclone II Experiments on March 26, 2014 by asteriondaedalus

Little Baby Steps

 

So, not much to report.  Re-reading final Master’s coursework assignment (four years of UGHHHHH!) and so dusted off the FPGA training board to bomb something onto it to buzz it out.

Went for the “Hello World” of FPGA and chose a Verilog example for lighting an LED.

Mostly an exercise to get used to the Quartus II software; set up USB Blaster drivers, work out which of two sockets the JTAG cable goes into; final steps setting up programming from Quartus etc.

Nice glass of CabSav with the red glow of the LED also helpful.

 

Phew

Posted in Development on March 23, 2014 by asteriondaedalus

So, last assignment for Master’s done save for re-reading and touching up references.  Two weeks ahead of when it has to be handed in so plenty of study time before exam.

In the meantime, some dusting off of projects in order I think.

So many, so which ones?

Might just dabble a bit with PROFETA.

I am going for a Samsung Galaxy S4 for my phone account upgrade so I can through the S2 back into the place I wanted it for – robotics experiments workhorse.

I might also get back into the FPGA bits and pieces as a couple of other toys have long turned up and waiting play:

Of course I also ordered the LOGIBONE with camera for FPGA vision experiments.  It hasn’t turned up yet since the chore of Kickstarter is getting in too early isn’t it.

Still I still have the other hack boards and now course is over with, and Telstra is sorted (so far) I can get back to the Altera video training etc.