ECP5 support in Latest Diamond 3.2 IDE from Lattice ( 64-bit Linux version) ?

I have downloaded latest Diamond and installed it on my Gentoo OS.

It works normally except that I can't choose ECP5 part, because program lists none. I can see MachXO3L series, but no ECP5.

BTW, I do have 1year subscription license that is still current and program obviously can find and read it, since it lists it and enabled options ("Help->Debug License")

Has anyone tried this ?

Reply to
Brane2
Loading thread data ...

Why not ask Lattice? Shouldn't be hard to submit a ticket.

Reply to
KJ

Dne petek, 04. julij 2014 01:53:57 UTC je oseba KJ napisala:

I did. Still waiting for an answer. Just thought to check here also, if anyone else had tried it.

Reply to
Brane2

I wouldn't use the online support, they normally aren't very good at actually answering your questions. Try your local FAE, they usually know what is going on and can give you a real answer to the questions you will ask next.

--

Rick
Reply to
rickman

BTW, I've got an anser that ECP is not covered by my current 1yr subscription license file and that the'll check if I am entitled to upgrade.

Bummer. First they silently deleted whole XO3-H part of the series and now they want $$$ for a licence for ECP5 that is in absence of XO3-H my next choice.

And there are no visible discounts this time- full price is EURO$1k. ;o/

Reply to
Brane2

I'm confused. I thought that was the point of the paid license, you get the capability of supporting their full range of parts. If not, why bother paying for a license? Just what are you buying over the free edition of the tools?

--

Rick
Reply to
rickman

There's a "Request ECP5 support" form under ECP5 section on the website.

formatting link

Looks to me as if they are just going to give you an add on but keeping tabs on who gets it (while the ECP5 is still virtual ? :-)

Michael Kellett

Reply to
MK

Dne sobota, 05. julij 2014 08:24:29 UTC je oseba MK napisala:

Great ! Thanks, you were faster than their support :o)

Hehe- good one. ECP5- "Breaking The Rules" - meet first VFPGA - Virtual FPGA.

First, you buy ECP3 as physical machine and then install ECP5 on top of it ;o)

Honestly, this licensing stuff is annoying.

I would understand it if I wanted some advenced sh** full of IP blocks etcetc.

But they are charging serious $$$ for utility that basically configures merchandise they plan to sell. It's kind of utility equipment.

Not to mention that for stuff I do, and at those densities, I'd be quite happy with lower level stuff.

If someone gave me something like PCB editor for FPGA, where I could access and set basic structures and manipulate them as one would elements on PCB, I'd probably toss verilog in a second.

Reply to
Brane2

That's your problem - switch to VHDL and everything will be rosy !

For what it's worth I use Aldec HDL (paid for $$$ but worth it) and only use the Lattice tools for some IP modules and synthesis. You get the Aldec tool (cut down but still quite good) in with the Lattice toolset.

The stuff I do got way too big to want to think about gates a long while ago - latest project uses some 96 and some 128 bit arithmetic - I wouldn't fancy placing the flip-flops for that by hand !

Michael Kellett

Reply to
MK

I remember when the HDLs were still not mainstream with the FPGA users and the FPGA vendors were pushing to get everyone converted. One of the expert users Ray Andraka had a full set of schematic modules which he could use hierarchically with place and route constraints which gave him tons of control over the actual design, much like what Brane is asking for. So Ray was a serious hold out for schematics.

Then the FPGA folks showed him how to apply the same constraints to VHDL with the same hierarchy (I'm sure it works the same with Verilog) as well as the advantages of text files for development and archival... he was sold! I believe he never looked back.

Who am I to argue with Ray Andraka?

--

Rick
Reply to
rickman

Dne sobota, 05. julij 2014 18:24:20 UTC je oseba rickman napisala:

  1. AFAIK he was working for XIlinx. His focus might have been more toward h igh end of application spectrum.
  2. I'm not arguing for schematics but for something much closer to pcb part .

Substantial difference is that PCB substrat by itself is homegenous- non pa tterned. So you need several step approach, first you choose elements and t hen wire them symbolically and in second step you map those symbols to "mea t" ( element housings etc), place them and shape copper between them

With FPGA, you don't have those degrees of freedom. Everything is already p re patterned and placed on LEGO landscape and all you need to do is flip th e right subset of switches on.

If i could click on PFU and enter simple equation and system would configur e FLASH for its ROM table, that'd be great. Same with output flip-flop, gat es etc tidbits. Seeing actual wires could also help with autorouting. I cou ld plan in advance which wires to use for what etc.

Once I would complete say 4-bit counter, I could make a group, which could move around as a whole. Simple SW logic might take care of tidbits. Like if I move group somewhere that violates some wiring demands, that it would si mply erase those wires and show me fresh ratsnest etc.

HDL for me is just another layer of obfuscation that fogs things and demand s whole new learning curve etc.

After all, our brain evolved so that we have visual "accelerators", not rel ational ones. If visual data is presented right, brain can filter interesti ng patterns and edges out ouf vast array of pixels and details.

Reply to
Brane2

I HAVE used tools like that, for parts much smaller than we have today. One of the first PLD configuration tools I used had a mode which brought up the full fuse map so you could configure your 16 FF PLD letting you choose from the logic modes of the logic block and configure the routing matrix for the and/or/xor input block. It was much preferable to enter in the equations and let the compiler figure all this out. Looking at the map might help if you were getting "too complex" errors to let you see what was the problem. And by letting you try to do it yourself you could actually convince yourself it was too complicated, or let you figure out how to express it directly so the compiler could work it out (This normally due to tweaking "don't care" conditions).

Later, when we had real FPGA's, the tools would have a mode where you could see each of the individual LE as a little box that you could assign your logic elements as defined by equations or schematic, and see the "rats nest" of connections, and an indication of how stressed the routing matrix was in that area. A printout of this sort of layout could take a good part of a wall for a whole chip.

Sometimes, for a small complicated circuit, you could sit down and pre-fit pieces to help the fitter. More often often you could help some by assigning chunks of the design to regions of the device. The one spot where this ability really helped was if you had to place pins to start the board layout before you finished the FPGA design. You could enter basic designs for the things driving the outputs and see what were natural placements for them and what pins they could directly drive.

I am much happier not to need to get down to that level most of the time. Being able to see things at the HDL level give a much better understanding of the over all function. It would be somewhat like deciding to work on a large software package by throwing out the compiler and saying it obfuscates what really happens, you REALLY need to design that system at low level assembly.

This doesn't say that in some special cases there won't be a need to dig in and look at the raw results generated to solve a performance issues, but that is the exception, and normally for just a small piece of the system.

Note, that even though they are HDLs, there normally IS a way to force low level effects, this signal WILL be the output of a logic element, this signal WILL use the carry change, to allow you to define things exactly as you want the compiler to generate the logic.

Reply to
Richard Damon

ure

es

d

'Simple' is the keyword in all of that. You would only be able to create ' simple' designs, nothing complex, nothing that could be easily maintained. Good luck being productive, others will pass you right by. You would take forever to create a design...or be let go before you complete it.

d

if I

ply

But there is not much call for 4-bit counters. Move them around all you li ke and let us know if you can create a video coder/decoder or some other fu nctionality that has usefulness. Even your statement "Once I would complet e say 4-bit counter", shows the lack of being productive. Most anyone skil led in HDL would probably have trouble even quantifying the amount of time required to 'complete a 4-bit counter' it would be so small.

nds

Maybe you should work your up way up the learning curve and see if that fog s clears up. For most, that is what happens.

Kevin Jennings

Reply to
KJ

I believe Ray used Xilinx parts almost exclusively but he did not work

*for* Xilinx. I'm not sure he even worked at the "high end" per se. He did utilize the parts to their maximum capabilities, both in speed and density. He did a lot of work in the days when what you want would have been practical in the way you picture it.

What you are talking about would be direct instantiation of hard features in the FPGAs. I believe you can instantiate PFUs and then assign logic to them from the HDL. It may not be portable across vendors, but that's no surprise.

Yes, we are more visual, but when using text based design entry we can get the computer to do things for us more easily and some functions like version control work better.

If you are willing to use an HDL you can do what you are talking about. It is the graphical interface that is not going to happen.

--

Rick
Reply to
rickman

Dne nedelja, 06. julij 2014 20:56:01 UTC je oseba Tim napisala:

Look at their website. After all fanfares, they revealed XO3 that was functionally on paper nothing like what was promised.

Then, they hastily added in the XO3 family introduction that this is only low end of the family and that high end XO3H is yet to come.

And now that sentence has dissapeared. If you click on XO3 family intro on latticesemi.com, there is nothing about XO3H. Crap.

Reply to
Brane2

Dne nedelja, 06. julij 2014 19:03:56 UTC je oseba KJ napisala:

like and let us know if you can create a video coder/decoder or some other functionality that has usefulness.

You are comparing apples to helicopters. I used 4-bit counter just as an si mple example. Just as you can use symbollics to describe more complex struc tures in HDL, there is nothing preventing that in graphically oriented appr oach.

Really ? Examples around me say exactle the opposite. FPGA is relatively ex pensive. It's not a peanut like some ARM. And it carries quite a few additi onal considerations.

At least in my price and volume ranges, chip utilisation counts. My extra w ork less so.

And quite frequently I can find people trying to see through the "fog" and to aqueeze extra performance. Then all those symbolic levels start working against the designer.

But this is theme for another dilemme.

I'v got renewed license. It supports a couple of ECP5-U and ECP5-UM, probab ly those models that they have in productions already.

If anyone is inteerseted in details, as of this moment, I can select:

LFE5U, LFE5UM and LAE5UM in 25F,45F and 85F densities.

Reply to
Brane2

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.