Zorro III Bus Specifications wanted

[FrenchShark]

Originally Posted by tnt23

At the top left corner of the board, right under the JTAG connector, an SO-8 EP1C configuration flash will be soldered. It cannot be programmed via JTAG directly as it is not on the chain, but there is a way of programming it through FPGA. I've again got an appnote on that somewhere.

Good !
This it what I do also.

I personnaly do not use the EPCS chips they are too expensive.
Actually, they are ST/Numonyx chips with a different marking. The Spansion chips work too. Get a 16Mbit part (just $2), that will give you plenty of room for storing software after the serial configuration (extra Kickstart, autoboot ROM ).

Regards,

Frederic

[tnt23]

Originally Posted by Shadowfire

You've glossed over the lack of series resistors on the proto board.

The series resistors are almost certainly there to reduce the slew rate (and therefore, the the over- and under-shoot) of the I/O lines. You want to be real careful about this, since the Cyclone devices have very specific tolerances about how much over and undershoot they can take without degrading/dying, discussed in the data sheets.

Directly related to this, is the fact that Zorro 2/3 was never conceived with operating with the kinds of slew rates these FPGAs will put out. So, you may wish to check on over/undershoot on the Zorro bus as well, even though you have quickswitches there.

Wow. I will have to look up the slew rate topic in datasheets. Didn't think about anything at all except voltage levels conversion. The resistors I was speaking were related to SDRAM lines (CLK and such).

Not sure what are the overshoots and undershoots, could you please tell more?

[tnt23]

Originally Posted by FrenchShark

Good !
This it what I do also.

I personnaly do not use the EPCS chips they are too expensive.
Actually, they are ST/Numonyx chips with a different marking. The Spansion chips work too. Get a 16Mbit part (just $2), that will give you plenty of room for storing software after the serial configuration (extra Kickstart, autoboot ROM ).

I'll check these. Just grabbed whatever there was in my local electronics shop that would suit.

Would be nice if they have the same pinout as EPCS.

[FrenchShark]

Originally Posted by tnt23

I'll check these. Just grabbed whatever there was in my local electronics shop that would suit.

Would be nice if they have the same pinout as EPCS.

All the SPI Flashes I looked at have the same pinout.
Two footprints are available (not counting the QFN) : SOIC-8 and SOIC-16. The SOIC-8 footprint fits inside the SOIC-16 footprint by rotating it 90 degree.
This is what I do on my layout so I can support any flash size from 1Mbit to 128Mbit.

What is important to look at are the flash commands and especially the format of the flash identification command. This is what Quartus checks first when you program a flash with the .JIC file.
For example, the Atmel and SST flashes are not compatible with Quartus but if you design your own flash loader, you can use them.

Regards,

Frederic

[FrenchShark]

Originally Posted by tnt23

Wow. I will have to look up the slew rate topic in datasheets. Didn't think about anything at all except voltage levels conversion. The resistors I was speaking were related to SDRAM lines (CLK and such).

Not sure what are the overshoots and undershoots, could you please tell more?

Overshoots and undershoots are overvoltages or undervoltages you see after a rising or falling edge on the signals. They destroy the I/O cells over time.

They are due to wrong impedance matching that creates reflections on the propagation lines.
The serie resistor is here to match the impedance. It has to be located close to the source on a unidirectional line (i.e address) and in the middle on a bidirectional line (i.e. data).
On short distance, they are most of the time not necessary and can create more problems.

At least, I put always a resistor on the clock lines, usually 22 ohms.
If you have drive current settings on the pins of your Cyclone II, by reducing the current, you decrease the slew rate and the risk of overshoot and undershoot.

You can check that with a high speed oscilloscope but keep in mind that the 20pF of a standard oscilloscope probe changes the characteristics of your line. You need a FET probe. You can also make an adapter using one of you quickswitch which is certainly FET based.

Hope it helps.

Regards,

Frederic

[Shadowfire]

Slew rate of signal determines the "frequency" of the signal (... using the good old sine wave formula, Voltage=Amplitude*sin(2*pi*frequency*time).
You take the derivative of the above formula, with respect to time:
dVoltage/dTime = A*2*pi*F*cos(2*pi*F*T)
Then, the frequency is where the change is greatest, i.e. where cos(xxxx...) is 1, and get
dV/dT=A*2*pi*F.
Substitute in your slew rate for dV/dT, your signal amplitude, and solve for frequency.
Take the reciprocal of the frequency to get your period, then take 1/4 of your period. This is your "transmission line" cutoff time.
Multiply the cutoff time by the speed that electricity travels in the copper medium, to get the "transmission line" cutoff distance.
If the length of the trace from your driver to your receiver is more than the cutoff distance, your trace acts like a transmission line, and you will get over/undershoot, and possibly ringing.
I've seen 40% overshoot on my board, and just today I say a 75% overshoot on an RS422 (4V signal, shooting up to 7V) driver line.

[tnt23]

Originally Posted by FrenchShark

Overshoots and undershoots are overvoltages or undervoltages you see after a rising or falling edge on the signals. They destroy the I/O cells over time.

They are due to wrong impedance matching that creates reflections on the propagation lines.
The serie resistor is here to match the impedance. It has to be located close to the source on a unidirectional line (i.e address) and in the middle on a bidirectional line (i.e. data).
On short distance, they are most of the time not necessary and can create more problems.

At least, I put always a resistor on the clock lines, usually 22 ohms.
If you have drive current settings on the pins of your Cyclone II, by reducing the current, you decrease the slew rate and the risk of overshoot and undershoot.

Thank you, now I understand the topic better.
Here's what Cyclone II datasheet says on series termination:

-----------------------------
I/O Driver Impedance Matching (RS) and Series Termination (RS)

Cyclone II devices support driver impedance matching to the impedance of the transmission line, typically 25 or 50 Ω. When used with the output drivers, on-chip termination (OCT) sets the output driver impedance to 25 or 50 Ω by choosing the driver strength. Once matching impedance is selected, driver current can not be changed. Table 10–7 provides a list of output standards that support impedance matching. All I/O banks and I/O pins support impedance matching and series termination. Dedicated configuration pins and JTAG pins do not support impedance matching or series termination.

Table 10–7. Selectable I/O Drivers with Impedance Matching and Series Termination
I/O Standard === Target RS (Ω)
3.3-V LVTTL/CMOS === 25
-----------------------------

So I guess I can use these on-chip termination resistors just to be on the safe side. Also, limited Current Strength Setting is available for LVTTL/LVCMOS, can be turned on also.

You can check that with a high speed oscilloscope but keep in mind that the 20pF of a standard oscilloscope probe changes the characteristics of your line. You need a FET probe. You can also make an adapter using one of you quickswitch which is certainly FET based.

Hmm, that is going to be tricky. Perhaps a small piece of proto board with edge connector will be required to arrange for probing.

[tnt23]

Cyclone II manual says on-chip termination (OCT) is available on all I/O banks. However, I cannot activate it for all pins. Some can be OCT'd, some can not. This can be either me or Quartus II software, or both. So if I fail to resolve the termination issue, I will let it as it is, hoping the thing will survive.

(Oh, and the EPCS1 turned out to be too small to accomodate both firmware and SFL loader. Gotta get a bigger one next week).

[FrenchShark]

Originally Posted by tnt23

Cyclone II says on-chip termination (OCT) is available on all I/O banks. However, I cannot activate it for all pins. Some can be OCT'd, some can not. This can be either me or Quartus II software, or both. So if I fail to resolve the termination issue, I will let it as it is, hoping the thing will survive.

(Oh, and the EPCS1 turned out to be too small to accomodate both firmware and SFL loader. Gotta get a bigger one next week).

Did you compress the SOF ? There is a hidden option in the "Convert Programming Files" window : select the .sof file under "SOF Data" then hit the button "Properties".

The compatible SPI brands seems to be ST/Numonyx, EON Silicon Solutions, Spansion and Macronix. So far, I used Spansion and ST without any issue.

Regards,

Frederic

[tnt23]

Originally Posted by FrenchShark

Did you compress the SOF ? There is a hidden option in the "Convert Programming Files" window : select the .sof file under "SOF Data" then hit the button "Properties".

Good point! Will check this tomorrow.

The compatible SPI brands seems to be ST/Numonyx, EON Silicon Solutions, Spansion and Macronix. So far, I used Spansion and ST without any issue.

Can you give any certain part numbers, SO-8 compatible?

[FrenchShark]

Originally Posted by tnt23

Good point! Will check this tomorrow.



Can you give any certain part numbers, SO-8 compatible?

For SO-8 200mil (there is a 150mil package too) :

Macronix 16Mb : MX25L1605D-M2
ST/Numonyx 16Mb : M25P16-VMW
Eon 16Mb : EN25F16-100H
AMIC 16Mb : A25L016M-F
Spansion 16Mb : S25FL016A0LMFI01

Today, it is hard to get something under 16Mb. Even 16Mb is getting phased out by Spansion.

Regards,

Frederic

[tnt23]

Indeed, turning the compression option on allowed to program the EPCS1.

Soldered the Quickswitches in place, put the board in A4000. Did not observe any magic smoke. The Amiga boots OK, but the board is not seen in the system. Obviously my Autoconfig code is not working.

[FrenchShark]

Originally Posted by tnt23

Indeed, turning the compression option on allowed to program the EPCS1.

Soldered the Quickswitches in place, put the board in A4000. Did not observe any magic smoke. The Amiga boots OK, but the board is not seen in the system. Obviously my Autoconfig code is not working.

I am glad the compression trick worked. Are you sure that the FPGA correctly configures itself ? I guess you have a config done LED, right ?

Anyway, it is time to use Signaltap . Now, you have at least a Zorro III logic analyzer .
What kind of JTAG interface are you using ?
It looks bigger than a USB Blaster. Is it a homemade clone ?

Regards,

Frederic

[tnt23]

Originally Posted by FrenchShark

I am glad the compression trick worked. Are you sure that the FPGA correctly configures itself ? I guess you have a config done LED, right ?

Anyway, it is time to use Signaltap . Now, you have at least a Zorro III logic analyzer .
What kind of JTAG interface are you using ?
It looks bigger than a USB Blaster. Is it a homemade clone ?

The LEDs are just plain I/O pins. The top green LED is blinking to indicate the FPGA is up and running. The other green LED should be blinking if the card is unconfigured, lit constantly when configured and blank when shut up.
I don't use the CONFIG_DONE pin, I believe the FPGA is configured OK as I also can access the EPCS through the SPL megafunction.

Going to introduce myself to Signaltap My Rigol digital scope has a built-in cheap logic analyzer (8/16 TTL channels) which is going to be very handy.
I will also pass the Zorro signals like /CONFIGn, /CFGOUTn, /FCS and /SLAVEn through to the debug I/O pins for some live performance. A serial output can also be implemented to help debugging.

Right, the grey box at the front is homemade USB blaster clone I borrowed from another friend

[tnt23]

FrenchShark, your Signaltap hint was very helpful. Spent a day fiddling with it, and guess what The Autoconfig now works more or less!



Still no memory on the board, it is configured as an I/O PIC, but at least we know full cycles work for Autoconfig.

[DarrenHD]

Originally Posted by tnt23

FrenchShark, your Signaltap hint was very helpful. Spent a day fiddling with it, and guess what The Autoconfig now works more or less!



Still no memory on the board, it is configured as an I/O PIC, but at least we know full cycles work for Autoconfig.

Wow, awesome!!!

[Brosol]

Wow Indeed! I'm hoping for an alternative to rare & insanely high priced cards like DKB 3128 for my A3000D.

[Minuous]

And of course the Zorro ]I[ spec is in the RKRM Hardware Manual. Sorry if anyone has already pointed this out.

[tnt23]

Originally Posted by Minuous

And of course the Zorro ]I[ spec is in the RKRM Hardware Manual. Sorry if anyone has already pointed this out.

I didn't know that The AmigaHardRefManual.pdf from The Zone covers Autoconfig only for Zorro II. Do you happen to have a link to latest RKRM somewhere?

[alexh]

http://amigadev.elowar.com/read/ADCD.../node028B.html