some questions for section 3

some questions for section 3

by Jakob Wilhelm Svedling -
Number of replies: 3

hi, we have some questions about  section 3 of this lab:

* logic analyzer

we plugged the analyzer to 4 extreme pins on the on each side of the gpio zero and generated a periodic signal on the pins via our custom parallel port but nothing showed up on the logic analyzer.

how do we write to pins through the parallel port and to which pins on the board do we write?

* IRQ recovery and response time

we followed the instructions for manipulation 3 and 4 and got a response time of around 0x294 clock cycles and a recovery time of around 0x6aa clock cycles but this seems suspiciously high and the values are suspiciously different. should we assume we did something wrong or is this an acceptable result?

* memory configurations

how do we try the different memory configurations (cache enabled/disabled)?




In reply to Jakob Wilhelm Svedling

Re: some questions for section 3

by Alexandre Chau -

Hi,

I will ask you a few questions to try to pinpoint the issue.

  • Did you export your parallel port signals in Qsys?
  • Did you then connect them to the GPIO_0_D port in the top-level DE1_SoC_top_level.vhd file?
  • Did you set this file as top-level entity in Quartus?
  • Did you run the TCL script for pin assignment?
  • Did you plug at least one GND wire of the logic analyzer to one of the GND pins of GPIO_0?
  • Is the bit ordering consistent (i.e. bit 0 of your exported VHDL signals from your custom parallel port matches GPIO_0_D(0))?
  • Are you sure you're using and measuring from GPIO0, and not GPIO1?
About the IRQ recovery and response time: if I understood correctly you have around 13200ns of response time and 34120ns of recovery time. Depending on your config, the first measurement seems reasonable, while the latter seems a bit high. Make sure to run many measurements and average them together, as you will for sure encounter outliers with cache misses.

For the memory configurations, you can enable/disable caches by editing the Nios II processor component in your Qsys system. There's a "Caches and Memory interfaces" tab in which you can select which caches to keep (instruction/data) and their sizes.

Let us know how it goes and if you need more info,

Best,
The TAs team
In reply to Alexandre Chau

Re: some questions for section 3

by Filip Slezák -

Hi, 

We went over your suggestions yesterday and we got it to work (more or less), thanks. A few general questions since then:

1) The DE1-SoC board takes about 2h to setup. It is incredibly inconsistent, sometimes just plugging it in works within the minute, sometimes never. I am on mac using the provided VirtualBox, the problem is doesn't seem to be the VirtualBox. Any ideas how to resolve this or what to pay attention to?

2) We have an internal error 82 with the jtag server not found; fixes proposed on the internet and various restarts of everything do not work.

3) We managed to measure the time it takes to IORD and IOWR to correct our future measures, IORD was measured using the counter values and we get 0.7us and IOWR using the logic analyzer, we get 20us. The former seems extremely fast, or isn't it? 

We'd like to go over the important tasks with you on Monday but if we spend that time solving the above issues we won't have time for it, therefore we would highly appreciate even guesses as to how to solve these issues. So far we feel like we've spent 20% of our time working on the lab and 80% debugging these useless issues.

Thanks in advance, 

Filip & Jakob


PS: for those of you stuck as we are, here is our troubleshooting list since we started with these labs:

// offset in macros is offset in bytes - just don't

// one-hot coding for values, key/led 0 is lsb

// led=1 means active, button pressed is 0

// use 16bit i/o just for safety as there are 10leds

// elf file to find by browsing files, "locate .elf" in terminal

// javalange exception -> restart eclipse

// recipe for target public.mk failed, right click lab1_bsp, nios 2, generate & should be ok

// binary not found -> do elf file not found step and it magically works even if nothing really changes

In reply to Filip Slezák

Re: some questions for section 3

by Alexandre Chau -

Hi,

1) This seems very weird indeed. You don't have any microSD card inserted into the board by any chance? Or some switches on the board that aren't set to default values? It may be that your board is trying to boot another sequence, is misconfigured or simply defective. If this doesn't resolve, you could try switching to another board that you can grab at the LAP.

2) jtagserver should launch with Eclipse Nios II. If everything else fail, you can try to close everything, "killall jtagserver" and "killall gdbserver", and then restart Eclipse. Also, if you have ran code on the Nios II CPU and it failed to stop the debugging properly (for instance if you are unable to stop the debugging session) then the JTAG connection will become unresponsive, and you'll need to reset the power on the board (and reprogram the FPGA).

3) It really depends on your code. For a read to take 0.7 us = 700ns ~ 35 clock cycles is not necessarily surprising. It really depends on which bus accesses you perform at what point in time, for instance you also need  to consider that the read / writes to your peripherals (timer, GPIO) also take some time, and caches and memory types may also affect your timings if you use load / stores from memory. I can't really say in the general case, if you want to take these in consideration you would need to do it on a per-project basis.

I understand that it may be frustrating to fight against the tools (and I cannot argue with the fact that the Quartus suite is not very developer-friendly) however in some sense we also consider this to be part of the assignment and, more generally, engineering work. The unfortunate truth is that many systems are complex, not necessarily well-designed and may also have crappy documentation; Quartus and Nios II are used in industrial projects, and it is also part of the role of engineers to learn the tools of the trade or find / create better alternatives.

I hope this helps and do not hesitate to let us know if you have questions,

Best,

The TAs Team