system console, external memory, multiple masters

Hey Dave

i measured bit period on signal tap to be around 52us. thats 104us period... 9600 baud

same baud rate from putty->signaltap (rx) and nios->signaltap (tx)

this is with putty set to 24000 and the qsys uart set at 9600. i did email ftdi and they want me to update drivers. Ill do that tomorrow.

i put the 50MHz clock into signal tap as well and it looks like it has correct period

If qsys thinks its got a 50MHz clock and generates a 9600 baud off that, and that 9600 is closer to 24000, then that would mean the 50MHz clock is 125MHz. Ill double check the board and system builder.

well, look at this straight from terasic manual...

Table 3-6 Clock Source, Signal Name, Default Frequency, Pin Assignments and Functions

Source

Schematic

Signal Name

Default

Frequency

I/O Standard

Cyclone V GX

Pin Number

Application

U20 CLOCK_125_p 125.0 MHz LVDS PIN_U12

U20 CLOCK_125_n 125.0 MHz LVDS PIN_V12

X2

CLOCK_50_B5B 50.0 MHz 3.3-V PIN_R20

CLOCK_50_B6A 50.0 MHz 3.3-V PIN_N20

U20 CLOCK_50_B7A 50.0 MHz 2.5-V PIN_H12

U20 CLOCK_50_B8A 50.0 MHz 2.5-V PIN_M10

U20 REFCLK_p0 125.0 MHz 1.5-V PCML PIN_V6

U20 REFCLK_n0 125.0 MHz 1.5-V PCML PIN_W6

U20 REFCLK_p1 156.25 MHz1.5-V PCML PIN_N7

U20 REFCLK_n1 156.25 MHz1.5-V PCML PIN_P6

So my top level .v does use CLOCK_125_p. I seem to remember doing that from a "my first nios" tutorial.

To use a 50MHz clock instead of that 125MHz, is it as simple as replacing CLOCK_125_p in my top level instantiation with say CLOCK_50_B5B? Will the FPGA know to just jump over and use that pin as my clock?

See, i told you im very green...

thanks Dave!

im learning a lot

So, my suspicion is that the qsys clock parameter is up to me to define. if i say its 50, and i actually give it 125MHz, then its still going to assume its 50MHz?

if thats the case, everything coming out of qsys will be 2.5 times faster. so 9600 baud will become 24000 baud

Im still confused why my signal tap says 9600 baud. im tapping right at the uart TX/RX pins. thats outside the qsys realm. so you would think that the rate would already be skewed by the time it gets to the TX pin.

yet, the data on the TX pin is at 9600 baud.

thoughts?

--- Quote Start ---

So, my suspicion is that the qsys clock parameter is up to me to define. if i say its 50, and i actually give it 125MHz, then its still going to assume its 50MHz?

--- Quote End ---

There is no assuming anywhere. Double-click on the clock in your Qsys system and change it from its default value of 50000000 to 125000000.

--- Quote Start ---

Im still confused why my signal tap says 9600 baud. im tapping right at the uart TX/RX pins. thats outside the qsys realm. so you would think that the rate would already be skewed by the time it gets to the TX pin.

yet, the data on the TX pin is at 9600 baud.

thoughts?

--- Quote End ---

It depends on what clock you have connected to your SignalTap II instance.

You need to confirm what clock is going to SignalTap II.

Cheers,

Dave

Hi Dave,

So it works. baud rates are what is expected.

thank you for all your help on that!!!

my problem now is that im using fgets to read in strings from uart, but i must enter the max number of characters to get the fgets to return.

i thought that fgets will return fewer chars if desired..

ie :

char myString [11];

fgets(myString, 10, fp);

printf("i only get here if myString entered is 10 or more chars");

if myString is less than 10, fprintf never gets executed.

Any ideas?

thanks man!

--- Quote Start ---

Hmmm. works in "cool term" just fine, but not putty. ill have to check the putty config....

--- Quote End ---

You'll have to look at the source for fgets to see whether it determines a "line" to be terminated with \n or \r or \r\n.

Look at your SignalTap II traces of a short string sent via Putty, eg., type in HI and hit enter, and see if four characters are transmitted HI\r\n or three HI\n.

Cheers,

Dave

--- Quote Start ---

baud rates are what is expected.

--- Quote End ---

And what was the solution?

I assume it was realizing that you were using a 125MHz clock for everything, but performing your calculations assuming it was 50MHz, and the FTDI baud rate was correct all along?

Cheers,

Dave