Lattice diamond / MachXO2

I've recently discovered that Lattice MachXO2 is quite a nice family of
low-end FPGAs.  I like especially the built-in oscillator (but +/- 5.5% is
not good enough for async serial- +/- 1% would be better) and the built-in
1.2V core linear regulator which allows operation of the chip with 3.3V only
(next generation they should work on an integrated switching regulator).  I
can also wish for more analog peripherals (ADC, comparators, anything I can
find on PIC microcontrollers...).

Anyway, they certainly make the system cost lower when compared with Altera
or Xilinx.

Also nice is the MachXO2 breakout board.  The feature I like is that the
built-in USB programmer chip from FTDI is a dual-function device.  It has
both the JTAG programmer, but also has a USB-to-RS-232 converter which shows
up as a separate USB device in Windows.  I can have a console serial
connection with PuTTY and at the same time have the Lattice Programmer. 
Very nice.

It's been an interesting experience using Lattice Diamond.  I think just a
few minor tweeks would make it a lot more usable:

Dump the whole multiple-implementation within one design concept.  Most
projects are only going to have single implementaton, and I think it's
reasonable to create a new project for a new implementaion (the new project
could use the same source files an existing one to get the same effect as
multiple implementations).  Anyway, this would reduce clutter.

I got confused when trying to change the PULLMODE using the spreadsheet
view.  The problem is that spreadsheet view does not consider the .lpf file
as changed until you actually move off of the cell you just modified.  I
think this is a straight bug.

There is a run-manager which lets you select an implementation and has its
own button for "Run".  When you run this way, the Export Files (like JEDEC
or bitstream files) process is not automatically run.

But then there is the "Process" pulldown on the main menu bar.  This also
has "Run" and "Run All", but they are disabled unless you select something
from the Process pane.  "Run All" does actually run the Export Files
process.

Anyway, it's pointless that there are multiple ways to run.  Again, dump the
multi-implementation stuff and have a single run-all button.

I tried the Reveal logic analyzer, but no luck first time.  After insertion
I can no longer place and route the design with the only error shown as
"Done: error 1".  Even after disabling Reveal (also not obvious how this is
done), the error remains.

-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

On 29/09/2013 06:24, Joseph H Allen wrote:
> I've recently discovered that Lattice MachXO2 is quite a nice family of
> low-end FPGAs.  I like especially the built-in oscillator (but +/- 5.5% is
> not good enough for async serial- +/- 1% would be better) and the built-in
> 1.2V core linear regulator which allows operation of the chip with 3.3V only
> (next generation they should work on an integrated switching regulator).  I
> can also wish for more analog peripherals (ADC, comparators, anything I can
> find on PIC microcontrollers...).
>
> Anyway, they certainly make the system cost lower when compared with Altera
> or Xilinx.
>
> Also nice is the MachXO2 breakout board.  The feature I like is that the
> built-in USB programmer chip from FTDI is a dual-function device.  It has
> both the JTAG programmer, but also has a USB-to-RS-232 converter which shows
> up as a separate USB device in Windows.  I can have a console serial
> connection with PuTTY and at the same time have the Lattice Programmer.
> Very nice.
>
> It's been an interesting experience using Lattice Diamond.  I think just a
> few minor tweeks would make it a lot more usable:
>
> Dump the whole multiple-implementation within one design concept.  Most
> projects are only going to have single implementaton, and I think it's
> reasonable to create a new project for a new implementaion (the new project
> could use the same source files an existing one to get the same effect as
> multiple implementations).  Anyway, this would reduce clutter.
>
> I got confused when trying to change the PULLMODE using the spreadsheet
> view.  The problem is that spreadsheet view does not consider the .lpf file
> as changed until you actually move off of the cell you just modified.  I
> think this is a straight bug.
>
> There is a run-manager which lets you select an implementation and has its
> own button for "Run".  When you run this way, the Export Files (like JEDEC
> or bitstream files) process is not automatically run.
>
> But then there is the "Process" pulldown on the main menu bar.  This also
> has "Run" and "Run All", but they are disabled unless you select something
> from the Process pane.  "Run All" does actually run the Export Files
> process.
>
> Anyway, it's pointless that there are multiple ways to run.  Again, dump the
> multi-implementation stuff and have a single run-all button.
>
> I tried the Reveal logic analyzer, but no luck first time.  After insertion
> I can no longer place and route the design with the only error shown as
> "Done: error 1".  Even after disabling Reveal (also not obvious how this is
> done), the error remains.
>
While Diamond is not perfect you should remember that it is intended to 
support the whole range of Lattice FPGAs which includes devices much 
bigger devices than the XO2.
The multiple ways of running get useful when it takes a significant 
amount of time to complete the whole process and you just want to run a 
bit of it.
I haven't had much joy with Reveal.
Don't hold your breath for ADCs - the XO3 (just announced and not 
available for some time) doesn't have any.

Michael Kellett

On 9/29/2013 1:24 AM, Joseph H Allen wrote:
> I've recently discovered that Lattice MachXO2 is quite a nice family of
> low-end FPGAs.  I like especially the built-in oscillator (but +/- 5.5% is
> not good enough for async serial- +/- 1% would be better) ...
>

I've used a much worse built-in oscillator (from Spartan 6) for async
serial communication.  It turns out that most of the tolerance is due
to process, which won't change for any given device.  So in my
application I made an auto-baud detect FSM and required the host
side to send a capital "U" character with minimum 10 ms gap before
and after it.  This sets (or changes) the baud rate simply due to the
sequence of 1's and 0's.  I've found that even after significant warm
up the link still operates within tolerance.  Requiring the protocol
to occasionally update the baud rate would allow for changes in
temperature if necessary.

-- 
Gabor

In article <PKqdnUrbYqd0Q9rPnZ2dnUVZ7sydnZ2d@bt.com>,
MK  <mk@nospam.co.uk> wrote:

>While Diamond is not perfect you should remember that it is intended to 
>support the whole range of Lattice FPGAs which includes devices much 
>bigger devices than the XO2.
>The multiple ways of running get useful when it takes a significant 
>amount of time to complete the whole process and you just want to run a 
>bit of it.

I'm spoiled by Quartus-II: it has "revisions", but the feature is completely
hidden unless you select Project=>Revisions.  I use a source code control
system, so having this feature in the FPGA is less necessary for me.

>I haven't had much joy with Reveal.

I'll keep trying it :-)

>Don't hold your breath for ADCs - the
>XO3 (just announced and not available for some time) doesn't have any.

The field is wide open for these features.  Logic is logic, so this could be
something new to compete over.

-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

In article <l29lbh$6qh$1@dont-email.me>, Gabor  <gabor@szakacs.org> wrote:
>On 9/29/2013 1:24 AM, Joseph H Allen wrote:
>> I've recently discovered that Lattice MachXO2 is quite a nice family of
>> low-end FPGAs.  I like especially the built-in oscillator (but +/- 5.5% is
>> not good enough for async serial- +/- 1% would be better) ...
>>
>
>I've used a much worse built-in oscillator (from Spartan 6) for async
>serial communication.  It turns out that most of the tolerance is due
>to process, which won't change for any given device.  So in my
>application I made an auto-baud detect FSM and required the host
>side to send a capital "U" character with minimum 10 ms gap before
>and after it.  This sets (or changes) the baud rate simply due to the
>sequence of 1's and 0's.  I've found that even after significant warm
>up the link still operates within tolerance.  Requiring the protocol
>to occasionally update the baud rate would allow for changes in
>temperature if necessary.

Are you using CFGMCLK? Interesting..  +/- 55%! This seems to be available
starting Virtex-4.

Well I guess you get auto baud rate detection as a side benefit.

-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

On Monday, September 30, 2013 12:15:08 PM UTC+12, Joseph H Allen wrote:
> 
> >Don't hold your breath for ADCs - the
> >XO3 (just announced and not available for some time) doesn't have any.
> 
> The field is wide open for these features.  Logic is logic, so this could be
> something new to compete over.

ADCs are not quite Logic. Harder to get right, and more costly to test.
 
However what they could include, which is just logic, is support for the isolated/separate Sigma-Delta ADC front ends from ADi / Maxim etc.

Joseph H Allen wrote:
> In article <l29lbh$6qh$1@dont-email.me>, Gabor  <gabor@szakacs.org> wrote:
>> On 9/29/2013 1:24 AM, Joseph H Allen wrote:
>>> I've recently discovered that Lattice MachXO2 is quite a nice family of
>>> low-end FPGAs.  I like especially the built-in oscillator (but +/- 5.5% is
>>> not good enough for async serial- +/- 1% would be better) ...
>>>
>> I've used a much worse built-in oscillator (from Spartan 6) for async
>> serial communication.  It turns out that most of the tolerance is due
>> to process, which won't change for any given device.  So in my
>> application I made an auto-baud detect FSM and required the host
>> side to send a capital "U" character with minimum 10 ms gap before
>> and after it.  This sets (or changes) the baud rate simply due to the
>> sequence of 1's and 0's.  I've found that even after significant warm
>> up the link still operates within tolerance.  Requiring the protocol
>> to occasionally update the baud rate would allow for changes in
>> temperature if necessary.
> 
> Are you using CFGMCLK? Interesting..  +/- 55%! This seems to be available
> starting Virtex-4.

Exactly.  I was pleasantly surprised at the low temperature drift in the
Spartan 6, especially given the huge range over PVT.  As I said it
appears that Process gives the lion's share of the 55%.

> 
> Well I guess you get auto baud rate detection as a side benefit.
> 

In my case this came by necessity.  I was using an external SiLabs
clock generator that needed to be programmed via I2C in order to get
any clocks to the FPGA.  Once that is up and running, I've got some
very precise clocks to use.  Unfortunately the settings for the
SiLabs chip get uploaded from a COM port, so I needed to have some
way to bootstrap the system.  The internal clock, bad as it is, saved me
the expense of an additional clock oscillator.  It also gives me
a way to operate I2C, even when I already have the settings uploaded.
The SiLabs chip stops outputting clocks while it is re-preogrammed.
Of course an I2C master does not need a precise clock.

-- 
Gabor

On 9/30/2013 10:36 AM, GaborSzakacs wrote:
>
> In my case this came by necessity. I was using an external SiLabs
> clock generator that needed to be programmed via I2C in order to get
> any clocks to the FPGA. Once that is up and running, I've got some
> very precise clocks to use. Unfortunately the settings for the
> SiLabs chip get uploaded from a COM port, so I needed to have some
> way to bootstrap the system. The internal clock, bad as it is, saved me
> the expense of an additional clock oscillator. It also gives me
> a way to operate I2C, even when I already have the settings uploaded.
> The SiLabs chip stops outputting clocks while it is re-preogrammed.
> Of course an I2C master does not need a precise clock.

Couldn't you have just used some default settings for the clock chip 
which would give you a workable baud rate, then update the settings from 
the com port?

-- 

Rick

In article <l2afqc$679$1@pcls7.std.com>,
Joseph H Allen <jhallen@TheWorld.com> wrote:
>In article <PKqdnUrbYqd0Q9rPnZ2dnUVZ7sydnZ2d@bt.com>,
>MK  <mk@nospam.co.uk> wrote:

>>I haven't had much joy with Reveal.

>I'll keep trying it :-)

I did get it to work.  One gotcha is that your clock (the sample clock for
reveal) must be faster than the JTAG clock.  I'm not really sure what
frequency the JTAG clock is, but faster than 7 MHz but slower than 66.5 MHz.

Second is the error return mystery from par.  Par completed, but GUI said it
had an error.  Even with the error return the GUI proceded with bitgen if I
asked it to.  The GUI is definitely rough..  I also experienced some more
glitches with the spreadsheet view.
-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

rickman wrote:
> On 9/30/2013 10:36 AM, GaborSzakacs wrote:
>>
>> In my case this came by necessity. I was using an external SiLabs
>> clock generator that needed to be programmed via I2C in order to get
>> any clocks to the FPGA. Once that is up and running, I've got some
>> very precise clocks to use. Unfortunately the settings for the
>> SiLabs chip get uploaded from a COM port, so I needed to have some
>> way to bootstrap the system. The internal clock, bad as it is, saved me
>> the expense of an additional clock oscillator. It also gives me
>> a way to operate I2C, even when I already have the settings uploaded.
>> The SiLabs chip stops outputting clocks while it is re-preogrammed.
>> Of course an I2C master does not need a precise clock.
> 
> Couldn't you have just used some default settings for the clock chip 
> which would give you a workable baud rate, then update the settings from 
> the com port?
> 

I could, but the settings for this particular chip would eat up a block
RAM if I stored them internal to the FPGA.  So I placed them in the
attached SPI flash along with other general device settings.  I could
also pre-program the SPI flash but it's generally easier for
manufactufing to upload everything starting from blank parts.  Once
the unit has settings uploaded, it can come up running on the next
power cycle.  I still keep the communication port working from the
internal oscillator because it's easier than switching clocks, though.
I do have code that calibrates the baud divisor when the external clocks
are running.  Still it wasn't too much of a hardship to require the
auto-baud startup in the protocol from the PC host.

At one time I was generating MCS files for the device that contained
both the FPGA bitstream and the settings, but it turns out that Impact
is very slow and stupid about programming the SPI flash when there
are big gaps between individual files, so the self-programming with
upload from a 115,200 baud COM port was actually faster.  Now we only
use JTAG for the initial FPGA bitstream, and all subsequent updates
are done via the COM port, including FPGA bitstream updates.

-- 
Gabor