Survey on Quartus SOPC/Nios-II

> Antti is correct, you CAN build an internal ring oscillator based on
> stacked inverters for a coarse frequency oscillator inside the XP or
> EC/ECP type devices.  This is a proven method that has worked at
> Lattice and at other users. XO and ECP2/M device families have built-in
> oscillator based on the configuration oscillator that is accessable
> from the FPGA fabric after configuration.

Yes I saw that the XO does have an internal osc.  That is good.  But the
XO2280 has 1/3 the RAM as the 3E-100.   Not sure the XO2280 has enough to do
what I need.  I need 32bit wide True Dual Port.  That burns up 2 banks.  The
3E-100 only needs one bank.  Not sure I can get the instruc space that I
need using a Micro8 on the XO2280.  I can run 3 PicoBlaze on the 3E-100 no
problem.

> For Flash write back both options are available -- PERSISTENT=ON for
> sysConfig port and through JTAG.

Yes that is what I thought too, but what good is it since the local FAE told
me there is no spare flash space.  If there is spare flash area for user
data, please let me know.  The datasheet gives little info on this.

Thanks,  Chris.

Chris wrote:
> > For Flash write back both options are available -- PERSISTENT=ON for
> > sysConfig port and through JTAG.
>
> Yes that is what I thought too, but what good is it since the local FAE told
> me there is no spare flash space.  If there is spare flash area for user
> data, please let me know.  The datasheet gives little info on this.

sorry i'm not that technical, but i think for applications that would
require less than 1,000 writes, you could use the flash.

here's how: the JTAG verify command reads out the flash data without
changing the configuration in the SRAM. you just need to use JTAG to
write to the flash for the user data you need and use the JTAG verify
command to get the data back out.

not that useful, since you want to turn off the part and reconfigure?

well, i think you should be able to write some data (let's say version
1, version 2, version 3, etc...) into the flash that wouldn't alter the
configuration of the FPGA except for a few memory bits. you would just
need to figure out which configuration bits to change in the flash to
give you your ROM in the SRAM array. that way, each time you turned the
part on, you would get the new ROM information along with your regular
FPGA configuration.

if your application doesn't require using the flash more than 1,000
times, i would suggest you talk to Lattice technical support.

hope this helps.
rgds,
bart

> require less than 1,000 writes, you could use the flash.

It's not a matter of the number of writes.  It is a matter of where to
write.  I don't need to change the flash bits that control the FPGA, I need
other flash area that is unused by the FPGA.  They tell me that in the XO
and XP all of the flash bits are used to config the FPGA.  There is no extra
space.  If I write in that, then the FPGA logic will be messed up.

>  since you want to turn off the part and reconfigure?

No, I don't want to recofigure the FPGA.  I need to store serial numbers and
calibration data on the product somewhere.  The FPGA code itself is not
going to change.

The point is this:  Lattice thinks that it's a big advantage having built-in
flash that you don't need an external memory part like the Altera or Xlinix.
Well that's only true if you don't need to store some other stuff in NV
memory also.  If you do, then the advantage is lost because you have to add
an external memory anyway.  Whether the external mem chip is $0.40 (8K
EEPROM) or $0.75 (1M-SPI) is no big deal.  It doesn't save much, and no
board space at all.  Lattice would have been miles ahead if they would have
left some extra space besides what the FPGA uses in their onboard flash.

They now know that all too well, and in the XP-II parts coming out next
quarter there will be extra flash space.

The big advantage Lattice has right now is single supply.  That may make the
difference between a 4 layer board and double sided board in my case, and
that difference pays for the entire FPGA.  That is a real big deal.  Single
supply is probably the most cost saving feature in these cases where a
multilayer board is not needed for much else than the FPGA.

Thanks,  Chris.

Chris wrote:
>>require less than 1,000 writes, you could use the flash.
> 
> 
> It's not a matter of the number of writes.  It is a matter of where to
> write.  I don't need to change the flash bits that control the FPGA, I need
> other flash area that is unused by the FPGA.  They tell me that in the XO
> and XP all of the flash bits are used to config the FPGA.  There is no extra
> space.  If I write in that, then the FPGA logic will be messed up.
> 
> 
>> since you want to turn off the part and reconfigure?
> 
> 
> No, I don't want to recofigure the FPGA.  I need to store serial numbers and
> calibration data on the product somewhere.  The FPGA code itself is not
> going to change.

  Lattice offer Soft CPUs like the Mico8 and they need to store the 
Opcodes in ROM. That means there must be an Opcode-> ROM pathway, for
their parts ( ie using BRAM as ROM ).
  Why not look at the Mico8 flows for that, and put your 
Serial#/Calibration infos into the psuedo ROM space ?

-jg

>   Lattice offer Soft CPUs like the Mico8 and they need to store the
> Opcodes in ROM. That means there must be an Opcode-> ROM pathway, for
> their parts ( ie using BRAM as ROM ).
>   Why not look at the Mico8 flows for that, and put your
> Serial#/Calibration infos into the psuedo ROM space ?

No where close to enough space.  The largest XO2280 has only 3 block rams.
I have to burn two of those just for my 32 bit dual port ram.  The 3rd one
gets used to hold 512 instructions for the CPU, and that may not even be
enough instructions.  I need 16k bits more for my other app data storage.
No where to put it.

Chris.

Chris wrote:
>>  Lattice offer Soft CPUs like the Mico8 and they need to store the
>>Opcodes in ROM. That means there must be an Opcode-> ROM pathway, for
>>their parts ( ie using BRAM as ROM ).
>>  Why not look at the Mico8 flows for that, and put your
>>Serial#/Calibration infos into the psuedo ROM space ?
> 
> 
> No where close to enough space.  The largest XO2280 has only 3 block rams.
> I have to burn two of those just for my 32 bit dual port ram.  The 3rd one
> gets used to hold 512 instructions for the CPU, and that may not even be
> enough instructions.  I need 16k bits more for my other app data storage.
> No where to put it.

  Hmm, 16k is quite a lot more than I expected for the statement
"need to store serial numbers and calibration data on the product 
somewhere."

  It's also likely to be more than a CPLD vendor will put in the
corner "for free", so at that level you will have to use an
off chip EE (SOT23?) solution, or a small uC as a "smarter EE"

-jg