New FPGAs from Renesas

[asmi]

That is your punishment for trying to derail the thread into another VHDL versus Verilog debate 

Using VHDL is an alright punishment for stubbornness and arrogance that VHDLers tend to demonstrate.

Besides that, creating a Verilog module definition is pretty much the same work as for VHDL.

Not even close. Creating a module in Verilog/SV is not a work at all. It's a single line of code. While in VHDL it's a real work writing a wall of useless text. Again, yet another punishment for stubbornness.

[gnuarm]

That is your punishment for trying to derail the thread into another VHDL versus Verilog debate 

Using VHDL is an alright punishment for stubbornness and arrogance that VHDLers tend to demonstrate.

Besides that, creating a Verilog module definition is pretty much the same work as for VHDL.

Not even close. Creating a module in Verilog/SV is not a work at all. It's a single line of code. While in VHDL it's a real work writing a wall of useless text. Again, yet another punishment for stubbornness.

I think he meant the total amount of work including debugging the inevitable mismatched items in the positional parameter list.  If you are a masochist you can do that in VHDL, but they typically use the form with names that have to match the names in the interface definition (I can't recall the terminology). 

Oh, crap!  I'm in the debate mode.  Sorry.

[gnuarm]

In SystemVerilog, the 'assign' has no delta/order delays where as logic implemented inside the 'always_comb' will follow the order it is written in.  At least, this is how Modelsim seems to treat the logic in a procedural always_comb decoding loop in my DDR3 multi-port selection decoder which requires the recognition of A before B to operate properly.  Quartus seems to interpret the code properly as function matches my simulations while altering the order of my code in this instance will prevent cycling of my multi-port priority selection decoder.

Writing such combinational logic out of order does generate 'Warnings' in Modelsim and the simulation may take values out of order in such circumstances.  This does not happen with 'assigns'.

Sorry, I don't recall my Verilog well enough to debate this.  The issue is not the statements within a process (module).  It's the ordering of the execution of the clocked logic in different modules. 

Consider module A assigns output X on the clock edge CLK.  Module B assigns output Y on clock edge CLK.  If X depends on Y and Y depends on X, you get different results depending on which process is executed first. 

I don't recall how this is resolved in Verilog, but it isn't through delta delays and I've been warned how to prevent being caught by it, I just don't recall how. 

[asmi]

I think he meant the total amount of work including debugging the inevitable mismatched items in the positional parameter list.  If you are a masochist you can do that in VHDL, but they typically use the form with names that have to match the names in the interface definition (I can't recall the terminology). 

Being a masochist is pretty much a requirement for using VHDL.

[SiliconWizard]

But it is totally besides the point. If you copy & paste some code between projects, test benches, etc, the (clock) signal names may not match. This will work for synthesis, but not for simulation.

I don't follow.  What is different about simulation?

I think you guys can run in circles forever discussing this. We don't know anything about nctnico's bad experience here, but I'm willing to bet it was an ill-done test bench with assignments instead of just properly instantiating entities and passing them signals (which does not suffer from the same issue obviously), which is the right way of doing it. Maybe they just inserted some of the code under test directly in a test bench code without encapsulating in separate entities. And so needed to assign signals to make it "compile" for simulation (but not work obviously). (But yeah they could have used aliases in this case, even if this is the bad way of tackling it.)

After which, the experience lingered on in nctnico's head because it was apparently traumatizing. But instead of being "traumatized" by assignments, we could wish it was an opportunity for encapsulating code in entities properly, which is neater, easier to test and easier to reuse. We can hope that's what happened, but I'm not sure.

Ofcourse you can encapsulate but I usually only simulate very small pieces of VHDL. Hardly worth putting into an entity due to the amount of typing involved.

Any piece of code not worth making a component out of is not worth using, at least in any serious project and environment. (Except for just "glue" code, of course.)

Not doing it means using copy-and-paste, and not only not having something reusable, but not having something really testable in the true sense. If what you test is not the same code as what is used in production, then something is wrong. As soon as you start copy and pasting, you have no guarantee they are in sync, then one modification requires modifying in the test bench as well... Awful. I really advise against doing things this way.

And don't talk about the amount of typing. I find this 100% irrelevant in most cases. It's not like you're asked to write a 1000-page book for every project you do. It's just a few more lines of code to make things tidy - and the time you'll spend is never while typing. It's designing stuff and... debugging it when you didn't design properly in the first place. That's something that applies to software as well and that is discussed every once in a while. If you care about the amount of "typing", and it's actually significant enough, relative to the time you spend on a project, then something is probably wrong.

And if, on top of that, you waste significant time "debugging" because you wanted to save a few minutes in the first place, while making things less maintainable, yeah. I don't think we'll ever agree on the process.

And I wouldn't call it traumatized; it is just something to be aware off. When it bit me I quickly realized that it had to be related to how simulation of VHDL works. I'm just used to synthesizers absorbing the signals into a single net. I agree that using aliases would make things even more messy.

Knowing the differences between simulation and synthesis when using HDLs (whatever they are) is very important. No doubt about it and not something to be taken lightly.

[Bassman59]

Sorry, I don't recall my Verilog well enough to debate this.  The issue is not the statements within a process (module).  It's the ordering of the execution of the clocked logic in different modules. 

Consider module A assigns output X on the clock edge CLK.  Module B assigns output Y on clock edge CLK. If X depends on Y and Y depends on X, you get different results depending on which process is executed first. 

That is not true, in either language (assuming non-blocking assignments in Verilog).

Remember how assignments work:

On the event that triggers the process -- the rising edge of the clock -- all right-hand-sides of assignments are captured. Remember a "right-hand-side" also includes the conditions in if statements, the expressions in case statements, and the like. Then each line in all of the processes sensitive to the clock are evaluated. In a given process the lines are evaluated in order. After each evaluation, the result of that evaluation is scheduled to be assigned to the target on the left-hand-side. Only after all assignments are evaluated and scheduled do the left-hand-sides actually update.

Let's look at a simple example:

Code: [Select]

Swap1 : process (clk, rst_l) is
begin
    if rst_l = '0' then
        X <= '1';
        Y <= '0';
    elsif rising_edge(clk) then
        X <= Y;
        Y <= X;
    end if;
end process Swap1;
Now the same process but with the assignments after the clock edge test reversed:

Code: [Select]

Swap2 : process (clk, rst_l) is
begin
    if rst_l = '0' then
        X <= '1';
        Y <= '0';
    elsif rising_edge(clk) then
        Y <= X;
        X <= Y;
    end if;
end process Swap2;
If the assertion, "you get different results depending on which process is executed first" was true, then you'd get different results with these two processes.

But you don't. They are identical. Which is as you would expect.

And that is because at the clock edge, the current values on X and Y are both captured. Then (since the evaluation is trivial) we simply assign the current value of X to Y, and the current value of Y to X. On the next clock edge, you have new current values on X and Y. And so forth.

Simulate the two examples. Prove to yourself that what I say here is correct. And yes, I realize that the example is trivial.

If you are using VHDL variables, then yes, the order in which the statements in the process are written absolutely matters, because a variable updates immediately after evaluation, instead of having the evaluation result scheduled for assignment. For example:

Code: [Select]

Swap3 : process (clk, rst_l) is
    variable v_foo : std_logic;
begin
    if rst_l = '0' then
        v_foo := '0';
        X <= '0';
        Y <= '0';
    elsif rising_edge(clk) then
        X <= v_foo;
        v_foo := BAR or BLETCH;
        Y <= v_foo;
    end if;
end process Swap3;
versus:

Code: [Select]

Swap4 : process (clk, rst_l) is
    variable v_foo : std_logic;
begin
    if rst_l = '0' then
        v_foo := '0';
        X <= '0';
        Y <= '0';
    elsif rising_edge(clk) then
        v_foo := BAR or BLETCH;
        X <= v_foo;
        Y <= v_foo;
    end if;
end process Swap4;
In Swap3, the current value of v_foo is assigned to X, then v_foo gets a new value, and that new value is assigned to Y. On the next clock, the value we assigned to Y -- the current value of v_foo -- on the previous clock is assigned to X, and then again v_foo gets a new value which we assign to Y.

In Swap4, v_foo is assigned a new value on the clock edge, and that value is assigned to both X and Y.

So for variables the order of evaluation in the process matters.

As for Verilog: the assignment semantics are identical to what I describe above if you use non-blocking assignments in your always block. If you use blocking assignments, then the evaluation and updating are the same as for VHDL variables, which means the order in which assignments are evaluated matters and you will get different results depending on how you write the block.

Hope this helps.

[gnuarm]

Bassman, you don't seem to have understood what I wrote.

First, this is not at all about the order of assignments within a process.  So please don't continue to discuss that.  The swap examples are not relevant.  That is about blocking vs. non-blocking assignments (signals vs. variables in VHDL, not respectively).  This is about the ordering of processes.

I am saying Verilog can have a problem, not VHDL.  This is exactly the reason why VHDL uses delta delays.  Delta delays are just like time delays, except they add zero time.  They just provide ordering.  Events that are scheduled from a rising edge of a clock at time 20 ns are all evaluated.  Then once all evaluations are complete in all processes, the updated values are assigned to the respective signals. 

If these changed signal values trigger other events through assignments with zero time delay, these events are scheduled for time 20 ns plus 1 delta delay.  Now the time is advanced to 20 ns + 1d and the processing continues.  So the assignments from all clocked processes are scheduled for 1 delta delay after the time of the clock and so the assignments can not affect any clocked processes at time 20 ns. 

In Verilog, there is no delta delay.  So when a clocked process is run the results of the assignments are updated at time 20 ns.  When another process is run subsequently, those assignments are evaluated and if one of the variables assigned in the prior process is an input, the assignment uses the updated value, not the value prior to the clock time.  This can result in different assignment values depending on the sequence of execution of the processes which may or may not be related to the order they appear in the source code.

I am sure there is something in Verilog to prevent this from being a problem.  I was told about this a long time ago.  But the point is this is why delta delays are used and why assignments should not be made for clocked signals unless you are careful to mitigate the impacts.

I'm very rusty in both Verilog and VHDL, so I may not be using the terminology correctly.  I think this is one of the technical issues where it can be important to use terminology precisely, so I apologize for any confusion I create.

[Cerebus]

I am saying Verilog can have a problem, not VHDL. 

Why are you arguing about something that, by your own admission, you are largely ignorant?

Sorry, I don't recall my Verilog well enough to debate this.

And for evidence that you are correct in that assertion:

I think he meant the total amount of work including debugging the inevitable mismatched items in the positional parameter list.

Verilog hasn't relied on positional parameters since before the 2001 version of the standard.

By all means make definitive statements about what VHDL does and doesn't do, can and can't do, if that is your area of expertise. But making statements about what Verilog does and doesn't do, can and can't do, when you're twenty years out of date and you admit to poor recall of the subject matter seems a bit like skating on thin ice.

Vis:

...
In Verilog, there is no delta delay.

An explicit zero delay (#0) requires that the process be suspended and added as an inactive event for the current time so that the process is resumed in the next simulation cycle in the current time.

[SiliconWizard]

You'll find a more detailed answer here: https://electronics.stackexchange.com/questions/99223/relation-between-delta-cycle-and-event-scheduling-in-verilog-simulation

[gnuarm]

I am saying Verilog can have a problem, not VHDL. 

Why are you arguing about something that, by your own admission, you are largely ignorant?

Sorry, I don't recall my Verilog well enough to debate this.

And for evidence that you are correct in that assertion:

I think he meant the total amount of work including debugging the inevitable mismatched items in the positional parameter list.

Verilog hasn't relied on positional parameters since before the 2001 version of the standard.

When you say "hasn't relied on" I think you are playing word games.  Every bit of Verilog code I've ever seen used positional parameters.  There is also frequently very little white space used to facilitate organization of the code for easy reading.  Yeah, not part of the language, but common use.  That equals more time debugging.

By all means make definitive statements about what VHDL does and doesn't do, can and can't do, if that is your area of expertise. But making statements about what Verilog does and doesn't do, can and can't do, when you're twenty years out of date and you admit to poor recall of the subject matter seems a bit like skating on thin ice.

Vis:

...
In Verilog, there is no delta delay.

An explicit zero delay (#0) requires that the process be suspended and added as an inactive event for the current time so that the process is resumed in the next simulation cycle in the current time.

I'm not clear on what that statement implies.  Are you saying Verilog does include the delta delay concept?  If so, I suppose my information preceded the 2005 standard.  I did start using HDL in the 1990s.  The important aspect of this is that the variable values are not updated until all assignments have been evaluated.  That's the part that prevents using a new value in a current assignment.

[gnuarm]

You'll find a more detailed answer here: https://electronics.stackexchange.com/questions/99223/relation-between-delta-cycle-and-event-scheduling-in-verilog-simulation

Thanks for that info.  Looks like Verilog accomplishes the same thing in a very different way.  I hope the user doesn't need to know any of this.

[Cerebus]

When you say "hasn't relied on" I think you are playing word games.  Every bit of Verilog code I've ever seen used positional parameters.  There is also frequently very little white space used to facilitate organization of the code for easy reading.  Yeah, not part of the language, but common use.  That equals more time debugging.

No, I'm not playing word games. That you haven't seen a well written bit of contemporary Verilog, but have only ever seen stuff that uses a style that went out years ago underlines how poorly qualified you are to comment on how Verilog is actually used.

I'm not clear on what that statement implies.  Are you saying Verilog does include the delta delay concept?  If so, I suppose my information preceded the 2005 standard.  I did start using HDL in the 1990s.  The important aspect of this is that the variable values are not updated until all assignments have been evaluated.  That's the part that prevents using a new value in a current assignment.

Well it's probably not clear for three reasons: (1) that's an isolated quote from a standard , (2) "delta delay" is from the VHDL lexicon, not a general term, (3) that you don't understand basic Verilog - standard Verilog behaviour for non-blocking assignments has always been that prior evaluation of all right hand sides that happen in the same simulation "event" happens before any assignments are made . Vis:

Code: [Select]

`timescale 1ns / 100ps

module example;

    reg A, B, C, D;

    initial begin
        $dumpfile ("example.lxt");
        $dumpvars (0, example);
        A <= 1;
        B <= 0;
        #30 $finish();
    end
   
   
    initial begin
         // The initial delay is just to make a clear timing diagram
         #10 B <= A;        // assignment happens at time 10, using value of A from just before time 10
             A <= #10 B;    // assignment happens at time 20, using value of B from just before time 10
    end

endmodule

Yields:

[gnuarm]

When you say "hasn't relied on" I think you are playing word games.  Every bit of Verilog code I've ever seen used positional parameters.  There is also frequently very little white space used to facilitate organization of the code for easy reading.  Yeah, not part of the language, but common use.  That equals more time debugging.

No, I'm not playing word games. That you haven't seen a well written bit of contemporary Verilog, but have only ever seen stuff that uses a style that went out years ago underlines how poorly qualified you are to comment on how Verilog is actually used.

This is getting old fast.  Ok, fine.  I know nothing about Verilog.  But if you don't use positional notation, you get the same typing as VHDL. 

I'm not clear on what that statement implies.  Are you saying Verilog does include the delta delay concept?  If so, I suppose my information preceded the 2005 standard.  I did start using HDL in the 1990s.  The important aspect of this is that the variable values are not updated until all assignments have been evaluated.  That's the part that prevents using a new value in a current assignment.

Well it's probably not clear for three reasons: (1) that's an isolated quote from a standard , (2) "delta delay" is from the VHDL lexicon, not a general term, (3) that you don't understand basic Verilog - standard Verilog behaviour for non-blocking assignments has always been that prior evaluation of all right hand sides that happen in the same simulation "event" happens before any assignments are made .

Delta delays (regardless of what you call them) are a good way to order assignments preserving causality.  Verilog seems to make this very complex.  To the best of my knowledge a simulation event is exactly one assignment.  But that's VHDL, don't know what you are referring to in Verilog.

SiliconWizard posted some good info that addresses the appropriate subject.

[ataradov]

There are no parts, not going to be for a long time. It is not even clear with their business model if the blank parts will be available.

[Cerebus]

When you say "hasn't relied on" I think you are playing word games.  Every bit of Verilog code I've ever seen used positional parameters.  There is also frequently very little white space used to facilitate organization of the code for easy reading.  Yeah, not part of the language, but common use.  That equals more time debugging.

No, I'm not playing word games. That you haven't seen a well written bit of contemporary Verilog, but have only ever seen stuff that uses a style that went out years ago underlines how poorly qualified you are to comment on how Verilog is actually used.

This is getting old fast.  Ok, fine.  I know nothing about Verilog.  But if you don't use positional notation, you get the same typing as VHDL. 

I don't think that it has dawned on your yet that the "typing thing" was a joke!

I'm not clear on what that statement implies.  Are you saying Verilog does include the delta delay concept?  If so, I suppose my information preceded the 2005 standard.  I did start using HDL in the 1990s.  The important aspect of this is that the variable values are not updated until all assignments have been evaluated.  That's the part that prevents using a new value in a current assignment.

Well it's probably not clear for three reasons: (1) that's an isolated quote from a standard , (2) "delta delay" is from the VHDL lexicon, not a general term, (3) that you don't understand basic Verilog - standard Verilog behaviour for non-blocking assignments has always been that prior evaluation of all right hand sides that happen in the same simulation "event" happens before any assignments are made .

Delta delays (regardless of what you call them) are a good way to order assignments preserving causality.  Verilog seems to make this very complex.  To the best of my knowledge a simulation event is exactly one assignment.  But that's VHDL, don't know what you are referring to in Verilog.

That's the whole point. You quite clearly don't know Verilog, but you seem to qualified to hold forth on the matter and make definitive statements about Verilog. Surely you must realise that's not the way to generate light on the subject. Verilog makes it quite easy to order assignments, should one want to make one's design reliant on that; whether that's a good design choice is another discussion entirely.

[Cerebus]

There are no parts, not going to be for a long time. It is not even clear with their business model if the blank parts will be available.

Given that currently one can only get parts that have been extant for several years only if you're prepared to wait until next year I don't hold out much hope for seeing these new parts available next year, possibly even the one after. That does have the upside that it gives a bit of time for feedback on issues like tooling to filter through, and perhaps when one can get parts to play with the toolchain will also have been made more to the liking of folks here that have expressed discontent.

[gnuarm]

There are no parts, not going to be for a long time. It is not even clear with their business model if the blank parts will be available.

Like virtually every company, they will release info in due time as they see fit. 

[SiliconWizard]

And due to the fab congestion these days, releasing a brand new line of ICs is likely to take longer than usual.

[mark03]

Given that currently one can only get parts that have been extant for several years only if you're prepared to wait until next year I don't hold out much hope for seeing these new parts available next year, possibly even the one after.

Crosslink-NX parts are sort-of available now (at least last time I checked at DK/Mouser), and they are new.  I have been wondering if the really new parts might be *more* available than the sort-of new, because they haven't been designed into as many products yet.  Especially if they are just entering production and only available in hobbyist quantities to begin with.

[SiliconWizard]

Given that currently one can only get parts that have been extant for several years only if you're prepared to wait until next year I don't hold out much hope for seeing these new parts available next year, possibly even the one after.

Crosslink-NX parts are sort-of available now (at least last time I checked at DK/Mouser), and they are new.

Yeah, but not nearly as "new". Crosslink-NX was announced in very early 2020, so, that's almost 2 years ago. =)

[gnuarm]

Given that currently one can only get parts that have been extant for several years only if you're prepared to wait until next year I don't hold out much hope for seeing these new parts available next year, possibly even the one after.

Crosslink-NX parts are sort-of available now (at least last time I checked at DK/Mouser), and they are new.  I have been wondering if the really new parts might be *more* available than the sort-of new, because they haven't been designed into as many products yet.  Especially if they are just entering production and only available in hobbyist quantities to begin with.

I don't think it works quite that way.  When new parts are being introduced they already have users lined up... large volume users.  They have a schedule they want to meet, so unless they are lucky and are ahead of schedule, there are no extra parts waiting for someone to buy them.  I'm not saying Digikey won't have parts.  I'm saying Digikey will have ordered them previously and when they come in will be uncertain. 

[LostTime77]

I work for a very big name in the industry and I can say I am very excited about these chips. I have already contacted my FAE about them and have gotten some initial information. However, I am under NDA and cannot share much.

What I will share is that my company has been using a CPLD (Max series) in our designs for many years now. There are several reasons for it, but power consumption, NVM, and <$1.00 cost are a part of it. We recently tried to start a fresh design and use something modern only to find the current market laughable for any comparable device, thus we were forced back to using a Max V. The Lattice ice40 series was the closest match, but Lattice's treatment of the device when we were interested, was laughable.

A word on Lattice. When we started searching for a new PLD (CPLD / FPGA / whatever) for this project, Lattice's name obviously came up so we contacted them. I have PLD experience from previous jobs, so I am very up to date with what devices every major manufacturer provides - packages, logic, power, etc.. I specifically keyed in to the ice40 to our rep, saying that was the only device even close to what we might want. What I got in response was that the ice40 devices are red headed step child's in Lattice's view. They are a design that they bought around 2010 and it's just kind of there. They have decided to not spend many resources on expanding the series or making them better in terms of packages and cost for the last decade. I suspect it was a huge marketing stunt, just so that they could say they are the leader in low power devices. Basically our reps told us "Yeah... those are old. We don't want you using those as we kind of don't support them. How about this Mach XO class device over here? We are willing to work with you on the price." I basically laughed at my rep and told him: "I don't care how you work with us on the price. I have been in this industry awhile and know about price breaks and "special" pricing, because I have been involved in those dealings before. Unless you are willing to take a massive cost hit, which we will still be expecting to have in 5 or 10 years on these devices, there is no other way you are going to cut your cheapest device price from like $4 to less than $1, which is what we get now."

The ice40 series is a tale of something that could have been great for Lattice, but like many companies, such as Intel, Lattice decided to sit on their laurels for the last 10 years doing nothing with it, even going as far to tell customers not to use it. "Nobody can ever dethrone this market segment from us". After hearing the announcement from Dialog of the new devices and seeing some of the information on what they can do first hand, we get to see the joke play out in real time. Dialog will be eating a large portion of Lattice's lunch in this segment. Again, Lattice has been trying to get in the pants of my company, because it is a huge name. I will be talking to my reps in the next months and am going to tell them to tell Lattice to shove it. Seriously. They lost the battle before it even began, by having Intel mentality. I have to tell you, it grinds my gears when corporate tom foolery screws up something like the ice40 series, which had tons of potential. They had a decade to do something with the series. Does not compute. Gross negligence. Instead, they still want to claim "lowest in class power", yet no new devices and are focusing on this high power NX crap.

The ice40 series is kind of laughable in terms of logic and package. You either get these tiny packages with like 5 I/O pins that cost $1.25 or you get these bigger packages where the price balloons into the >$2.5 range. Nothing in between. Our application calls for a good number of I/O and not so much logic at all.

As others have alluded to, I have seen the pinout and some of the specs for the QFN24. It exists. As I have a huge part in part selection at my job, the amount of I/O in this device fits our application like a glove. Even if we need more I/O, we can just slap more of these devices in there with how cheap they are supposed to be. I do hope Dialog will be providing larger package devices in the future though. I don't have full roadmap information yet. However, I believe these first entries are going to blow the flood gates open for many possibilities now and in the future. I mainly look at Lattice devices for low power devices and when I need something like a "real" device, I look to xilinx for something like a Spartan 7. I have a feeling that Lattice will be wiped from my vocabulary in the near future as there will really be nothing left for me to look at them for.

Next up: Me making a very similar angry, time squandering forum post on the Saleae logic forum, likening Saleae to Lattice. No new devices in 8 years. No USB C connector, even though its a 5 minute hardware change. Instead, we get a doubling of price because their 10 engineers can't figure out a crypto handshake to their software due to Chinese knock offs. In 2014, when we bought the PRO16s, they cost $399 or $499 IIRC. Anyhow, that's a story for another time.

[gnuarm]

It's Not Invented Here syndrome. Lattice spent $65 million acquiring SiliconBlue years ago and forgot (intentionally, I suspect) to allocate any capital for new R&D. They made a few stupidly tiny chips - the UltraLite, LitePlus, whatever - but they refuse to port them to a newer process, add better features, or anything like that. Claire Wolf's contribution of icestorm+etc was the best thing that ever happened to Lattice and they did nothing in response to it. Now they're being blatantly ripped off by GOWIN.

That's always a specious statement that Gowin is copying the iCE40 line.  They have virtually nothing in common other than being LUT based FPGAs.  The Gowin parts are more like the other Lattice parts.

They have added products to the line which you just mentioned.  You call them "stupidly tiny", but that is the target market for those parts, small devices to fill cracks in designs omitted by the ASICs.

Now they can't even keep their chips in proper production - try to buy a reel of any iCE40 other than the <2k LUT joke series.

In spite of that, I'm blown away by their stock price and valuation. They barely make any money, and yet they've gone from $5 when I bought and sold a couple shares in 2018 to $75 today. Seems like slightly growing revenue and the M&A factor are why they're priced so high.

I can't find the reference, but there's an old economic story or historical analysis of corporations that were notable in the 1920s or 1930s. All of the big performers tended not to stay successful for more than 3-4 years before fading back into mediocrity.

You mean like Intel?  I bought Xilinx stock since they are merging with AMD at a 1.7 to one stock swap.  Both stocks have gone up nearly 100% and Xilinx will get another 20% boost from the merger.  Meanwhile Intel has been sucking wind for 3 years now.  Who would have thought Intel would stumble on process technology and end up at least a year behind!?  I wonder how this will impact the Altera FPGA products.  Did they ever port to the Intel process or are they still using Taiwanese fabs?

[LostTime77]

I just poked my FAE again last night to get more information. Again, under NDA, so I can't reveal much. However, the roadmap looks extremely interesting. The LUT implementation is also very interesting. Yes, they will be eating all of Lattice's lunch with regards to the ice40 series in the near future. Very excited.

[nctnico]

I just poked my FAE again last night to get more information. Again, under NDA, so I can't reveal much. However, the roadmap looks extremely interesting. The LUT implementation is also very interesting. Yes, they will be eating all of Lattice's lunch with regards to the ice40 series in the near future. Very excited.

How about tooling? Any indication they are going to add support for VHDL?