Lattice diamond / MachXO2

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

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.

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'll keep trying it :-)

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

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.

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.

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

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

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.

MachXO2 fans may be interested in this stuff:

The pif board is an XO2 FPGA that plugs onto a Raspberry Pi.

The tif board is an XO2 FPGA on a HID USB connection. HID is used so there is no need for software drivers.

Both boards include all the software you need to download Lattice Diamond JEDEC to the board, plus example designs and an example of web control of a design inside the FPGA.

Tim

So when does the XO3 version come out?

As far as I can tell the XO3 will slot in above the XO2 and include stuff such as SERDES. Eventually something will replace the XO2 (only a couple of years old) but the XO3 parts that are being hinted at are not the ones.

I could very easily be completely wrong.

I dunno. A few weeks ago I sent an email asking about the new line in the Flash series and I was asked how I knew it existed... I guess they are trying to keep a tight lid on it. Now they have some info they will share, but I guess you need approval from someone. I sent in a request and haven't heard anything back yet.

Hi All I am athar kaludi (skype lailajamil) I NEED to Download LATTICE Semi Conductors Software for training fpga and other iCE stick - the link on page to download are all broken - I sent email to LATTICE no reply yet - PLEASE SOME HELP ME how to download software for lattice products . my Skype lailajamil regards snipped-for-privacy@gmail.com