Altera FPGA weirdness

"John Larkin" wrote in message news: snipped-for-privacy@4ax.com...

Missing pull up/down ? I would suspect some Jtag interference with a new device. Do you have the latest Quartus 10 ? Or even the latest usb blaster driver?

Cheers

Do you have TCK daisy chained with other devices? It's possible that you have a signal integrity problem on it. This is a fast-edge clock like any other and needs to be treated as such.

Can you tell if the other bits in the stream are correct? If you can read them, it would be good to compare them to the BSDL file to see if it's a bit error or if the device is really providing the unexpected value. You can get the BSDL file on the Altera website.

Bob

--
== All google group posts are automatically deleted due to spam ==

The latest one is 11.0sp1, update Your software if You didn't do this already.

Have you checked these few signals mentioned in the manual. I had this problem once in the past.

"If the device is in reset state, when the nCONFIG or nSTATUS signal is low, the device IDCODE might not be read correctly. To read the device IDCODE correctly, you must issue the IDCODE JTAG instruction only when the nSTATUS signal is high."

--Kim

Kim,

When you posted that, my reaction was "no, nobody could make the jtag handshake that stupid"... but they did!

We wrote a stub program for our ARM processor to just pull up nCONFIG, and now the chip id's itself as a GX45.

Thanks!

If you're ever in San Francisco, expect free beer.

John

Me too! I'm doing a Stratix V design now. I already have pullups on nConfig and nStatus, but it's great to know about this...ahhh...feature.

Thanks, Kim!

Bob

--
== All google group posts are automatically deleted due to spam ==

Isn't it possible to load the FPGA using an SPI like interface? I avoid using JTAG whenever I can. A JTAG interface is not something that is required for a device to function properly so it gets very little attention to get it right.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

The ARM processor will load the FPGA through its SPI port in real life, but we're using JTAG to test the PCI Express interface parts first, because it's quick and easy. When it works.

The production system has the ARM boot its code off a serial flash chip. Then it reads more of that flash chip and configures the FPGA. We'll probably compress the config data, because it's something insane like 30 megabits, mostly zeroes.

John

I thought Quartus will compress for you ??? Do you need all 30 Mbits ???

You don't really get a choice. Every config bit and every RAM bit is in the config file. The vendor's compression usually doesn't help a lot. Since most of the config data is 0's, simple bytewise RLL compression on zeroes helps a lot, 2:1 to as much as 5:1.

John

Methinks, you should try Altera's compression first. You wouldn't get

5:1, but for low-utilization design with mostly uninitialized internal memories you will certainly get 2.5:1 and sometimes even 3:1. Besides, unlike vendor's compression, your own compression will not make boot process any faster.

In a current Altera design with a GX45, low logic density, the Altera compression is about 2:1, which isn't bad, 30M bits down to about 15.

The Xilinx compression, at least for Spartans, is much less effective.

I the case where a uP is bit-banging the config into the FPGA, home-made compression can speed up configuration significantly, because the bang-out-the-zeroes loop can be very fast.

Not that any of that matters much. Huge serial flash chips are cheap, and the difference between 3 seconds of config and 8 isn't going to affect the world much.

John

.

ane

???

at least for xilinx you wouldn't even have to get the data through the uP, you could just wire the DO and clock on the flash to both the fpga and the uP spi interface and do enough reads from the flash to get through the whole configuration. Theres a sync word in the stream so the fpga knows when the config stream starts

Just saw Xilinx came out with some mega fpga with stacked dies or something, I think it is 450Mbits of configuration

-Lasse

You assume the sync word only occurs once in the stream.

Knowing Xilinx, probably $1/bit.

Why don't you use the SPI interface? In an older design I used an 8MHz MSP430 (Texas Instruments). With extra and gates I could 'route' the MISO and clock line into the Din and CLK line of a chain of xilinx FPGA's. All the uC has to do is read the SPI interface as fast as it can. It configured the FPGAs pretty fast.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

l

ts

sh

PGA.

insane

ts ???

s l

not really, you should start reading data at the start of the config it is just that the extra bits and clocks that the fpga will see when you send a read command etc. to the flash will be ignored because they come before the sync word

if it worries you you could just pulse /prog when you are ready to read the right data

it is obviously not cheap, but at 6.8 billion transistors...

-Lasse

insane

???

...and if there is more than one sync word? I've seen more than one gigged by this amateur's mistake.

Kinda defeats the purpose, no? Why not just read the bits that need to be read?

Nothing 'X' does is cheap, much absurdly expensive. There's always the government to buy them, of course, using OPM.

.

ane

???

I got following ratios: Arria2GX 125, logic utilization=3D8%, part of the memories initialized =3D> 2.5 Arria2GX 125, logic utilization=3D19%, almost no memories initialized =3D>

2.6 Cyclone3 25,logic utilization=3D42%, almost no memories initialized =3D> 2.43 Stratix2 90,logic utilization=3D23%, almost no memories initialized =3D> 2.53 Stratix2 90,logic utilization=3D69%, almost no memories initialized =3D> 1.91 etc.

So I'm a little surprised by your result. I expected better.

Depends on specific ARM uC. For slow Cortex-M3 what you said sounds about right. For fast Cortex-R4 and may be even Cortex-M4 the internal core processing would be close to free and the configuration time would be roughly proportional to number of peripheral accesses, which, assuming that DCLK and DATA are mapped to the same GPIO register, should be independent of your compression.

Well, 3 or 8 sec is not important for you. For one of the our clients it was mighty important whether FPGA configuration takes 0.7s or 0.9s. And that with A2GX-125 which in uncompressed form takes not 30 Mbit, but more like 50 Mbit.

real

parts

flash

e FPGA.

ng insane

Mbits ???

t is

p a

get

rnal

t

ra

2. >

ve.

p,

e e

gged by

what? you clock a few bytes into the flash start a read, then you read how ever many bytes needed for the whole configuration the sync word that counts is the first one

be

that point was that if you put the fpga config data and clock on the same pins as the flash spi interface you don't have to read the data and then clock it out through another set of pins, can just read and discard the data as fast your uP can clocking the data out of the flash and into the fpga at the same time

-Lasse