New FPGAs from Renesas

[asmi]

That's my point.  If you only compare package size you aren't doing a fair comparison.  The entire area around the BGA used for breakout routing needs to be considered.  The BGA ends up being a big road block to other routing while the QFP has room under it for vias, etc.

Of course I am doing a fair comparison. Typical BGA-64 only requires one or two signal layers for a full breakout, as the rest of the balls (which typically are in the middle) only connect to the power/ground planes, heck 1 mm 196 ball BGA can be fully routed on 2 signal layers even with generous 0.1 mm tolerances (see a project in my signature for example of that), and entire breakout almost always fits underneath BGA so it's more compact (nevermind other advantages like SI) than QFP/QFN (especially the latter as it typically has an exposed pad underneath leaving no space for any routing, which leads to more wasted space outside part's perimeter for signal vias to internal layers). On a 6 layer board that leaves two more signal layers for any "thru" routing. Practically I can't think of a case when I had routing issues with BGA system controllers - the part I mentioned (STM32H723VGH6) is a 100 ball 0.8 mm pitch BGA part, which can be fully routed on just two signal layers without requiring any advanced tolerances.

[ataradov]

I figured out the test bench situation. At least the Linux version simply calls iverilog for simulation. And they don't even package it with the IDE, it just calls the system one. My minimal dummy VM did not have one installed, so it failed to do anything. As soon as I installed it, it worked. It produces VCD file and automatically launched GTKWave on it. Again, the system GTKWave.

It also needed VCD file to be located in the default directory.

All of this starts to look more and more like amateur hour put together with sticks and sticky tape. If you are going to use OSS tools, just do it right.

[Bassman59]

Tools are the expensive part of selling FPGAs.  Only the big suppliers write their own tools.  Everyone else licenses synthesis software which costs them for every copy they supply.  Now you know why many companies don't want to support no-profit hobbyists. 

Has anyone looked at simulation?  I'm not familiar with Yosys, but I assume that is just synthesis.  Are they also supplying open source simulation or are you on your own to figure that out?  When using Gowin they punted on the simulation.

You can use GHDL which works OK. I did run into funny effects though when assigning a clock to a different signal; in that case GHDL likes to delay the new signal as well as if it is registered by the clock. But this could be a bug in an older version.

Not sure what you mean by "assigning a clock to a different signal".  If you mean literally just writing

Code: [Select]

clk1 <= clk2;
in VHDL that will create a delta delay which will in essence be a new clock domain slightly out of sync with the first.  So register outputs will be updated on clk2 before clk1 gets it's edge and cause unexpected results.

This is not a bug, it's a feature... really!

This is entirely correct.

You will get the same thing in Verilog.

[nctnico]

But it still sucks that it behaves differently when synthesized (absorbed into a single net) versus being simulated.

[gnuarm]

That makes no sense.  You are saying the test bench file is not stored as text?  Or that all of the source files are not stored as text?

Nothing is stored as text. The whole project is just one file that contains everything. I think this supports their business model where you do the design, send it to them and they ship you the programmed devices.

There is no way to edit text files. You get the IDE and that's it.

Again, this feels more like Arduino that any other FPGA IDE. This is designed for very simple things.

So, yes, the whole thing makes less and less sense. Hopefully this device will just be supported by open source tools to make it usable.

I would not compare this to any other IDE tool.  I've never heard of one that did not store the source code as separate text files.  The only exception is generators that use graphical input.  That is no longer text by definition. 

I don't recall ever hearing that the Arduino didn't store source code as text files.

[ataradov]

I don't recall ever hearing that the Arduino didn't store source code as text files.

I compare it to Arduino in a sense of capabilities of the IDE itself. It is essentially a text editor with a few extra buttons to generate binary files.

Storage of the files inside the project files makes no sense to me, but I don't think this is going to change.

Basically, unless those devices are <~$1.5 / 100pcs, then it is easier to ignore them and just use Lattice.

[gnuarm]

That's my point.  If you only compare package size you aren't doing a fair comparison.  The entire area around the BGA used for breakout routing needs to be considered.  The BGA ends up being a big road block to other routing while the QFP has room under it for vias, etc.

Of course I am doing a fair comparison. Typical BGA-64 only requires one or two signal layers for a full breakout, as the rest of the balls (which typically are in the middle) only connect to the power/ground planes, heck 1 mm 196 ball BGA can be fully routed on 2 signal layers even with generous 0.1 mm tolerances (see a project in my signature for example of that), and entire breakout almost always fits underneath BGA so it's more compact (nevermind other advantages like SI) than QFP/QFN (especially the latter as it typically has an exposed pad underneath leaving no space for any routing, which leads to more wasted space outside part's perimeter for signal vias to internal layers). On a 6 layer board that leaves two more signal layers for any "thru" routing. Practically I can't think of a case when I had routing issues with BGA system controllers - the part I mentioned (STM32H723VGH6) is a 100 ball 0.8 mm pitch BGA part, which can be fully routed on just two signal layers without requiring any advanced tolerances.

I think we are going to go around in circles all day about this.  You say the BGA can break out by putting vias all around under the chip and I'm saying these vias create a road block, which you aren't hearing or seeing.  The QFP doesn't do that.  There is room under the package to route other signals than the FPGA signals, so it doesn't use the entire space you are counting as "used". 

The board I'm shipping now uses a 100QFP which fits on the board with a few mm to spare.  Signals need to route under it to get past.  By using vias under the package, layers can be changed and still have room to route the signals that need to get past.  With the BGA, it might be slightly smaller (a 256BGA just fits, the 196BGA is a bit smaller), but it requires vias densely packed under the part creating a traffic jam that other signals have to route around.  Sure, you can use more layers, but that's the point, you have to use other layers and increase the cost of the PWB.

With the 100 QFP there's enough room that I put three 8 element resistor packs on the other side of the board from the FPGA as well as the decoupling caps, about 8 I think.  I've never seen a BGA used without significant space left open around it and nothing on the side opposite other than perhaps decoupling caps.  The thermal tab of QFN packages causes the same sort of routing restrictions.

[asmi]

I think we are going to go around in circles all day about this.  You say the BGA can break out by putting vias all around under the chip and I'm saying these vias create a road block, which you aren't hearing or seeing.  The QFP doesn't do that.  There is room under the package to route other signals than the FPGA signals, so it doesn't use the entire space you are counting as "used". 

There is no road block just from vias as they leave plenty of space between them for 1 mm pitch (enough to route two 0.1 mm traces), unless you have enough signals to fill entire area, but in that case QFP would take more than triple the area of equivalent BGA (BGA-256 is 17x17 vs QFP-208 is 30.6x30.6, or even more if you count entire footprint, and not just the chip itself).

The board I'm shipping now uses a 100QFP which fits on the board with a few mm to spare.  Signals need to route under it to get past.  By using vias under the package, layers can be changed and still have room to route the signals that need to get past.  With the BGA, it might be slightly smaller (a 256BGA just fits, the 196BGA is a bit smaller), but it requires vias densely packed under the part creating a traffic jam that other signals have to route around.  Sure, you can use more layers, but that's the point, you have to use other layers and increase the cost of the PWB.

With the 100 QFP there's enough room that I put three 8 element resistor packs on the other side of the board from the FPGA as well as the decoupling caps, about 8 I think. 

LOL - QFP 100 is going to have about half the amount of IO compared to BGA-196, and yet still take more area than that BGA. So if you would only route out about half of IO balls of BGA-196, you will have a lot of space under the chip to place all kinds of stuff. AND still end up with using less PCB space.

I've never seen a BGA used without significant space left open around it and nothing on the side opposite other than perhaps decoupling caps.

It kind of seems to me that you haven't actually ever routed BGAs. They are very easy for routing compared to any other package with similar amount of pins/balls, again, taking into account the amount of area those other packages would take.
Oh, and will haven't touched an elephant in the room - namely, horrible SI of QFP packages. That's the reason there are no DDR2 and above memory chips in non-BGA packages. So for anything more complex that LED blinkers you will have to use BGAs, which kind of makes the whole discussion moot.

[gnuarm]

But it still sucks that it behaves differently when synthesized (absorbed into a single net) versus being simulated.

Yes, but you just stated the distinction.  The simulation has two nets and the real design has but one.  This does not happen with signals passed into processes or functions, etc.  This only happens when you have a signal assignment of a clock.  So that should be avoided same as in the real world.  An assignment should be thought of as a buffer which could cause similar problems in an actual design. 

I have not verified this, but if all the inputs to the same registers are also buffer delayed, you should not see this problem.  The register outputs will have an extra delta delay, but that should not be a problem.  That's why delta delays are there, to prevent the outputs that change from a clock from impacting any of the inputs captured by the same clock.  More delta delay in an output is fine, it's the inputs you have to worry about.

[nctnico]

But it still sucks that it behaves differently when synthesized (absorbed into a single net) versus being simulated.

Yes, but you just stated the distinction.  The simulation has two nets and the real design has but one.  This does not happen with signals passed into processes or functions, etc.  This only happens when you have a signal assignment of a clock.  So that should be avoided same as in the real world.  An assignment should be thought of as a buffer which could cause similar problems in an actual design. 

That is all nice and dandy, however in some cases you have a different name for a clock in a test bench and assigning it to basically rename it doesn't work in simulation. It is just something to be aware off when creating test benches.

[Someone]

But it still sucks that it behaves differently when synthesized (absorbed into a single net) versus being simulated.

Yes, but you just stated the distinction.  The simulation has two nets and the real design has but one.  This does not happen with signals passed into processes or functions, etc.  This only happens when you have a signal assignment of a clock.  So that should be avoided same as in the real world.  An assignment should be thought of as a buffer which could cause similar problems in an actual design. 

That is all nice and dandy, however in some cases you have a different name for a clock in a test bench and assigning it to basically rename it doesn't work in simulation. It is just something to be aware off when creating test benches.

Just to derail this thread some more, when VHDL delta cycles are making pain: get yourself an alias! (and then watch all your colleagues complain they don't like it).

[gnuarm]

But it still sucks that it behaves differently when synthesized (absorbed into a single net) versus being simulated.

Yes, but you just stated the distinction.  The simulation has two nets and the real design has but one.  This does not happen with signals passed into processes or functions, etc.  This only happens when you have a signal assignment of a clock.  So that should be avoided same as in the real world.  An assignment should be thought of as a buffer which could cause similar problems in an actual design. 

That is all nice and dandy, however in some cases you have a different name for a clock in a test bench and assigning it to basically rename it doesn't work in simulation. It is just something to be aware off when creating test benches.

I don't think that is the same thing.  Using a name in a test bench that is different from the name in the UUT does not create a delta delay if the connection is made at the instantiation.  One name on one side and another name on the other side does not constitute an assignment, so no delta delay.  It's only in assignments that delta delays are created.  So they are explicitly created and easily avoided.

[nctnico]

But it still sucks that it behaves differently when synthesized (absorbed into a single net) versus being simulated.

Yes, but you just stated the distinction.  The simulation has two nets and the real design has but one.  This does not happen with signals passed into processes or functions, etc.  This only happens when you have a signal assignment of a clock.  So that should be avoided same as in the real world.  An assignment should be thought of as a buffer which could cause similar problems in an actual design. 

That is all nice and dandy, however in some cases you have a different name for a clock in a test bench and assigning it to basically rename it doesn't work in simulation. It is just something to be aware off when creating test benches.

I don't think that is the same thing.  Using a name in a test bench that is different from the name in the UUT does not create a delta delay if the connection is made at the instantiation.  One name on one side and another name on the other side does not constitute an assignment, so no delta delay.

That is not the case if you want to mix & match some VHDL code quickly.

[Bassman59]

But it still sucks that it behaves differently when synthesized (absorbed into a single net) versus being simulated.

Yes, but you just stated the distinction.  The simulation has two nets and the real design has but one.  This does not happen with signals passed into processes or functions, etc.  This only happens when you have a signal assignment of a clock.  So that should be avoided same as in the real world.  An assignment should be thought of as a buffer which could cause similar problems in an actual design. 

That is all nice and dandy, however in some cases you have a different name for a clock in a test bench and assigning it to basically rename it doesn't work in simulation. It is just something to be aware off when creating test benches.

I don't think that is the same thing.  Using a name in a test bench that is different from the name in the UUT does not create a delta delay if the connection is made at the instantiation.  One name on one side and another name on the other side does not constitute an assignment, so no delta delay.

That is not the case if you want to mix & match some VHDL code quickly.

Huh? I don't understand what you mean. What gnuarm says about port formals and actuals is correct.

[nctnico]

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.

[gnuarm]

But it still sucks that it behaves differently when synthesized (absorbed into a single net) versus being simulated.

Yes, but you just stated the distinction.  The simulation has two nets and the real design has but one.  This does not happen with signals passed into processes or functions, etc.  This only happens when you have a signal assignment of a clock.  So that should be avoided same as in the real world.  An assignment should be thought of as a buffer which could cause similar problems in an actual design. 

That is all nice and dandy, however in some cases you have a different name for a clock in a test bench and assigning it to basically rename it doesn't work in simulation. It is just something to be aware off when creating test benches.

I don't think that is the same thing.  Using a name in a test bench that is different from the name in the UUT does not create a delta delay if the connection is made at the instantiation.  One name on one side and another name on the other side does not constitute an assignment, so no delta delay.

That is not the case if you to mix & match some VHDL code quickly.

Sorry, I don't know what "mix and match" means in VHDL. 

It is simple.  Assignments create delta delays.  Signal connections through instantiation or procedure calls do not.  Don't assign clock signals to other clock signals unless every use of clock signals has the same number of assignments in the path.  That's pretty simple, no?

Maybe you are talking about using existing code that you don't look at.  Yeah, that can cause all sorts of trouble.  A lack of attention to detail when reusing code was what brought down an Ariane rocket if I recall. 

[gnuarm]

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? 

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

[nctnico]

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

Sorry, I don't know what "mix and match" means in VHDL. 

Mix & match = throw some pieces together and make something out of it that works.

[Cerebus]

Hardly worth putting into an entity due to the amount of typing involved.

Us Verilog types don't have that problem, or get repetitive strain injury from coding up a little bit of logic. 

[gnuarm]

Hardly worth putting into an entity due to the amount of typing involved.

Us Verilog types don't have that problem, or get repetitive strain injury from coding up a little bit of logic. 

Perhaps you are not aware that VHDL has delta delays (the cause of this issue) to prevent another problem which is much worse, the logical result of clocked assignments depending on the arbitrary order of execution of the assignments.  I believe Verilog doesn't use delta delays and so can have issues regarding this.  Or maybe they've done something to resolve this problem? 

[BrianHG]

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

[Cerebus]

Hardly worth putting into an entity due to the amount of typing involved.

Us Verilog types don't have that problem, or get repetitive strain injury from coding up a little bit of logic. 

Perhaps you are not aware that VHDL has delta delays (the cause of this issue) to prevent another problem which is much worse, the logical result of clocked assignments depending on the arbitrary order of execution of the assignments.  I believe Verilog doesn't use delta delays and so can have issues regarding this.  Or maybe they've done something to resolve this problem?

I made no comment on that, read what I quoted to comment on and read the smiley afterward. 

[nctnico]

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

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

[Cerebus]

Ha! May a thousand mismatched entity and architecture statements plague your code!