@COBRA

Quote:

So from this you would think that you could get away with re-programming the flash of the Lattice XP in-circuit via the CPU, while the old gate configuration is still in place and functioning. However according to ACube this is not the case, the chip cannot operate in its current configuration, while its flash is being programmed.

I posted this from lattice in the other thread before reading this comment:

"
Real Time Reprogramming
LatticeXP FPGA devices have flexible reprogramming / re-configuration modes. Even when the LatticeXP FPGA device is operational, the internal configuration FLASH memory can be reprogrammed in the background via 1149.1 port. When desired the SRAM configuration memory can be reconfigured on the fly (less than 1 mS) from the FLASH memory by toggling a pin or issuing the correct commands through the device configuration ports. In addition, the internal configuration SRAM can also be reprogrammed from sysCONFIG parallel port within tens of milliseconds.
"

This seems to go against your information from ACube. But I realise that there are always exceptions or limitations on these type of things.
I would be interested to know why it wouldn't work in the SAM440 case.

Also note this:
"
Leave Alone I/O
This optional feature provides flexibility for implementing systems where reprogramming occurs on-the-fly. LatticeXP FPGA devices provide flexibility in specifying I/Os as high, low, tristated, or held at current value during non-volatile memory (1532 mode only) programming or during a command to refresh the SRAM memory from FLASH.
"

Last edited by Bit7 on 25-Sep-2008 at 03:45 AM.

@Bit7

That assumes that the 1149.1 (JTAG) port is connected to the CPU which I doubt is the case.

regards,
Stefan

@Bit7

You might want to contact ACube directly for the details.

@Yabba

Quote:

That assumes that the 1149.1 (JTAG) port is connected to the CPU which I doubt is the case.

As I pointed out in the other thread. The SAM does have GPIOs (general purpose IO) on a connector. So all you would need is a cable that goes between the GPIO connector and the header for the JTAG interface.

@Bit7

Oh, I didn't say that this wasn't possible, I was just saying that it is unlikely that the JTAG port is wired to the CPU directly. I would suggest to get 2 SAM boards first thought and connect the JTAG cable from one board to the other until you have a working programmer. Then you should be able to loop back the cable on the same board.

Emulating JTAG over GPIO however.... Sounds kind of slow to me
How large is the bit file for the FPGA? Maybe this is not so bad after all.

Cheers,
Stefan

About the lack of gfx card on the flex:
Wouldn't we loose the small and nice formfactor if we were required to add a large standing PCI gfx card to the machine??!

I like the idea of integrated gfx because that way the board can be used in its default small formfactor. If a large standing PCI card needs to be added, the case would have to turn into an ugly cube instead of a small flat box. Or did I miss something?

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

Quote:

About the lack of gfx card on the flex: Wouldn't we loose the small and nice formfactor if we were required to add a large standing PCI gfx card to the machine??!

If you want the small form factor and integrated gfx, then you buy a Sam440 and not a Sam440-Flex, as easy as that ;)

@Yabba

Quote:

Emulating JTAG over GPIO however.... Sounds kind of slow to me How large is the bit file for the FPGA? Maybe this is not so bad after all.

bit files are small.
The most simple JTAG programming hardware are no more than cables connected directly to a bit banged parallel port (with a buffer to handle the different voltage levels).

The GPIOs will have no trouble at all driving JTAG well past its top operating speed.