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

>   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:
>>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

> 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:
> > 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

> 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.

bart schrieb:

> Chris wrote:
> > Nope won't work.  I talked to Lattice today.  There is no internal osc to
> > use, and they did not recommend using a bunch of gates.  Moreover there is
> > no extra flash space either - zip.  This is not the first time.  Overall I
> > am very disappointed with what they put out in their MachXO and XP  NV
> > families.  They lack a lot of little features that would make them so much
> > more powerful.  I guess they have heard that from others too, he told me
> > that they were coming out with a 'revised' new XP line next year.  XP-II I
> > think he said.
> >
> > Chris.
>
> Hello Chris,
>
> I spoke with our Director of Applications, Bertrand Leigh on this topic
> and confirmed that the application will work.
>
> 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.
>
> For Flash write back both options are available -- PERSISTENT=ON for
> sysConfig port and through JTAG.
>
> We will follow up with the person you spoke to on our technical support
> line and let them know about this application. Sorry if they caused any
> confusion.
>
> Hope this helps.
> Bart Borosky, Lattice Semiconductor

thanks Bart,

there are many ways to make a ring-oscillator, depends on the needs I
have one version that I call fgpa_safe  it is basd on 4 FF that use
only set  reset pins. This thing always delivers an "useable" clock for
given FPGA and works any synthesis tool, eg does not get optimized
away.

there can different other methods, which may be better but may require
special trick to fool the optimizer and may require LOC contraints to
get better repeated frequency. invertor chain may run too high
simetimes, as example for V4 special care has to be taken to get the
inverter chain frequency to be low enough to be useable.

in most cases the fgpa_safe oscillator is sufficient, is sure has large
difference in frequency as it will be routed by different paths each
time.

Antti

Chris wrote:
> Nope won't work.  I talked to Lattice today.  There is no internal osc to
> use, and they did not recommend using a bunch of gates.  Moreover there is
> no extra flash space either - zip.  This is not the first time.  Overall I
> am very disappointed with what they put out in their MachXO and XP  NV
> families.  They lack a lot of little features that would make them so much
> more powerful.  I guess they have heard that from others too, he told me
> that they were coming out with a 'revised' new XP line next year.  XP-II I
> think he said.
>
> Chris.

Hello Chris,

I spoke with our Director of Applications, Bertrand Leigh on this topic
and confirmed that the application will work.

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.

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

We will follow up with the person you spoke to on our technical support
line and let them know about this application. Sorry if they caused any
confusion.

Hope this helps.
Bart Borosky, Lattice Semiconductor

Chris wrote:
> I am evaluating using the Altera Cyclone with Quartus SOPC vs. Xilinx
> Spartan3E and PicoBlaze.  I need a soft core processor and I think PicoBlaze
> would be enough.  SOPC and Nios-II is very powerful but the learning curve
> looks like a potential nightmare to me.  In order to use SOPC I might have
> to get involved writing custom components to do the job and then one has to
> master the Avalon interface.  That looks like a lot of potential debugging
> time.
> 
> The Xilinx solution seems more direct, and under my control, since PicoBlaze
> is stand alone and does not depend on so many bus interrelated components
> and SOPC infrastructure.  Easier and quicker to write direct interfaces.
> Nios seems to need much more of the SOPC (RAM,ROM,Avalon,etc) around it to
> work.
> 
> Also, it seems like the Nios/SOPC solution is likely to require far more
> gates than a Xilinx/PicoBlaze implementation.
> 
> I would be curious to know any of your experiences with SOPC/Nios-II.  I
> have very limited R&D time for this project.
> 
> Thanks,  Chris.
> 

If you don't need very tight integration between the processor and the 
FPGA, you might save yourself a great deal of time and effort by using 
an external small microcontroller.  Choose the right part, and things 
like I2C are a no-brainer.

Nope won't work.  I talked to Lattice today.  There is no internal osc to
use, and they did not recommend using a bunch of gates.  Moreover there is
no extra flash space either - zip.  This is not the first time.  Overall I
am very disappointed with what they put out in their MachXO and XP  NV
families.  They lack a lot of little features that would make them so much
more powerful.  I guess they have heard that from others too, he told me
that they were coming out with a 'revised' new XP line next year.  XP-II I
think he said.

Chris.