Artix-7 only has three different die sizes?

[hamster_nz]

I just saw a tweet that linked to this thread:

https://forums.xilinx.com/t5/7-Series-FPGAs/Vivado-Artix-7-XC7A15T-BRAM-site-75/td-p/670657

It seems that there are only three different dies for the six members of the family:

1) 15T, 35T 50T are the same
2) 75T & 100T are the same
3) 200T

and it is an arbitrary restriction imposed by the tools that enforces the resource usage limits.

 

[ataradov]

and it is an arbitrary restriction imposed by the tools that enforces the resource usage limits.

It is highly likely that it is not a simple arbitrary restriction. Lower grade devices may have manufacturing problems that render them unusable as high grade devices.

[mikeselectricstuff]

and it is an arbitrary restriction imposed by the tools that enforces the resource usage limits.

It is highly likely that it is not a simple arbitrary restriction. Lower grade devices may have manufacturing problems that render them unusable as high grade devices.

That may well be true, however it seems like you can use any <x> of <y> BRAMs present, and the limit is only on the tool.
So what happens if you try loading a bitstream from a bigger device into a cheaper one...
I'm guessing there's a part number marker in the bitstream - I wonder how hard that would be to alter,,,,

[SeanB]

Lower grade might have bad blocks of logic, so they get mapped out in a set of internal flash cells with only a die pad, not a package pin. That makes the yield higher, so lowering cost.  You might get lucky and have a few of the better units marked as low grade if they were short on the order, but it would be on a device by device basis, and you would basically have only a small chance of the higher number of cells being present. Might overwrite some already programmed cells, or might simply do the end block over and over. Might even work fine, at least till you order a new set of parts and they were correctly marked.

Kind of like how the reject PIC controllers are used anyway, just whatever is not working on the chip is marked, so that if you do not need it you are fine, and get a cheaper chip. Do not need ADC, get one with failed ADC, or with failed pin drivers selecting ADC.

[Rigby]

Or, maybe it isn't a binning process and the lower end device can be coaxed into loading the bitstream of a higher end device.

Why talk yourself out of trying?

[mikeselectricstuff]

Remember the tool doesn't know about bad areas in a particular device, and selection of which BRAMs to use has to be done by the tool as it determines routing.
It may be the case that there may be some local rerouting/patching, but it's hard to see how an "only allow <x> of <y>" limit could be anything other than artificial crippleware.
Of course they could have something in hardware that counts BRAMs instantiated as the bitstream is loaded, but seems unlikely that they would add extra hardware to do something like this.
So the question is how robust is the mechanism that prevents the cheaper devices loading a bitstream compiled for the more expensive one. It could be a simple as patching the device ID and fixing up any checksum/CRC.

And maybe the tool limits are buried in a config file somewhere.

Maybe the guys who rev-enged the ICE40 bitstream should take a look.... An toolchain that allowed more logic in cheaper devices would be more practical use than an OSS replacement for an existing freely available toolchain.

[Chipguy]

According to the datasheet the 7A15T, 7A35T and 7A50T also got the same JTAG ID.
So, what happens if you just set the tool to 7A50T and shoot the stream on a 7A15T device?
I bet there are "safety" measures in place so the bitstream won't work right away.

I would search for something like a "certain marker" and just make a small design, lets say a 2 input AND gate. Very elaborate 
Then constrain the logic to a fixed cell, routing etc. and the I/O's to fixed pins.
Then compile the design for all 3 devices and see where the differences in the bitstreams are 

That's gonna be interesting 

[hamster_nz]

I've been thinking about this... I don't really mind paying less for a larger die, giving the tools more freedom during the place and routing process,

Guessed downsides:
- Static power higher than a smaller die.
- Larger chip gives longer paths

Guessed upsides:
- Even when close to 100% of resource usage, the 15T and 35T  designs will have higher performance, due to extra routing resources available on the lager die
- You have the ability to use lower or higher capacity device with zero change in design performance (e.g. engineer for a 50T part, then if your design fits in the smaller part you can use a 35T instead, with zero impact).


I've also implemented the same design on the Artix-7 15T, 35T and 50T, and the resulting floor plan looks exactly the same...

At the bit-file file level between the 35T and 50T implementation, the Device type and build date have changed in the file's  header, a byte at offset 235, and a four byte word at the very end of the file (maybe a CRC-32 checksum?).

[hamster_nz]

and it is an arbitrary restriction imposed by the tools that enforces the resource usage limits.

It is highly likely that it is not a simple arbitrary restriction. Lower grade devices may have manufacturing problems that render them unusable as high grade devices.

I was thinking that as well as speed, maybe the devices are binned based on a power specification, maybe so the dynamic power usage is the same.

However, I can't see any indication of this in the "Artix-7 FPGAs Data Sheet: DC and AC Switching Characteristics" User Guide.... the 15T, 35T and 50T parts have all the same power specifications. 

[Chipguy]

...
I've also implemented the same design on the Artix-7 15T, 35T and 50T, and the resulting floor plan looks exactly the same...

At the bit-file file level between the 35T and 50T implementation, the Device type and build date have changed in the file's  header, a byte at offset 235, and a four byte word at the very end of the file (maybe a CRC-32 checksum?).

Byte at offset 245 eh 
Sounds to me you already found it.

The simplest way to ensure that bitstreams only work for a given device would be to implement a comparator that, if set wrong would not load the rest of the data or prevent the FPGA start after it is finished loading.
As a second measure they could try to keep the checksum calculation method a secret. But that's just a wild guess. I rather think that you are right with it being a common CRC32 checksum.
I think the info in the header is redundant.

Would be interesting to see what happens when you got a bitstream for a 50T device (with complexity >35T) and you change the header, byte 235 and recalculate the checksum (which I believe is a plain CRC32) to load it into a 15T device 

[marshallh]

This has been suspected for a long time and then proven by die shots. By the way, Altera did the same thing. They also do the same thing with selling FPGAs with faulty transceivers as non-transceiver models. Some Altera parts do not seem to have any faulty rows/cols fused off - the logic would work, which would not be true of these Artix-7 parts - they are probably doing basic row/col substitution with a pool of spares like is done when NOR flash is built

If you could get the bigger bitstream to work on the smaller device, great. But it won't have been tested and qualified to the larger functionality. When I asked Altera about this, I got a vague sorta-answer than implied that do not perform full testing coverage in production for the binned smaller devices.
So while it's something you could play around with for hobby, it's not possible to trust when shipping a product. And honestly, when wasting 2 weeks debugging a design problem, do you want to have that nagging suspicion in your mind that goes "Maybe it's the chip itself, and not my code?"

[mikeselectricstuff]

If you could get the bigger bitstream to work on the smaller device, great. But it won't have been tested and qualified to the larger functionality.

I think that depends a lot on the details of any testing and defect handling.
From the original thread it seems that the tool can map any <x> of <y> BRAMs. I'd have though that something as big as a BRAM would be hard to switch over by fuse options, except maybe if they are done as local pairs.
Of course there may be other resources that are mapped in a way that allows a limit on quantity, but it's hard to see how this could be done with BRAM.

[nctnico]

In general I'm not convinced by stories where parts of bad chips get disabled to increase the yield especially when resources can be used freely. If the yield is poor and the demand for large chips is big then they have to throw a lot of chips in the bin. It makes more sense to create one design and sell it at various price points.
Relocating BRAMs on the fly seems impossible to me because the vast amount of connections usually going to a BRAM and the asociated timing constraints. My best guess would be that the devices have fuses or some other (one time?) programmable area which has the chip ID. Maybe it is combined with matching the device ID from the bitstream but it wouldn't surprise me if it is possible to load a bigger design into a smaller device with some clever hacking.

[hamster_nz]

I've just successfully used 50% more BRAM than my Artix-7 35T has. I've got a design with 75 BRAMs loaded into an FPGA with 50 and it is still working.

Doesn't seem to be any fuses or counting of resources used during configuration - I was wondering how that would work with partial reconfiguration, and decided it wouldn't be easy. Strangely enough, most of the answer was the same as reverse engineering the protocol for beyondhelp's pyrotechnic controller that ataradov and I helped with a while back.

Grrrr. One more way that cheap 'knock-off' products can substitute cheaper parts and undercut those using the official ones.

PS. Don't want to publish the code - it is rude to bite the hand that feeds.

[marshallh]

Yeah, the last thing anyone needs is chinese counterfakers remarking FPGAs. One of the few types of devices that there aren't fakes for, yet.

[amyk]

Yeah, the last thing anyone needs is chinese counterfakers remarking FPGAs. One of the few types of devices that there aren't fakes for, yet.

You really think they haven't noticed already...? They probably figured it out ages ago, but this sort of thing tends to stay on the Chinese part of the internet.

If what's been posted so far is true, the ones ripping you off here are the manufacturers. These are otherwise perfect devices with all the BRAMs working, since they wouldn't let you arbitrarily use them if some of them were defective.

Looking at it overall, it makes sense that the checks are minimal - the cost of adding extra logic to the die to count/lock out features is more, since FPGAs are extremely regular in structure and any deviance from that would mean additional non-uniformity that needs to be custom.

[coppice]

If what's been posted so far is true, the ones ripping you off here are the manufacturers. These are otherwise perfect devices with all the BRAMs working, since they wouldn't let you arbitrarily use them if some of them were defective.

How exactly are people being ripped off? If they sell all devices at the price of the entry level part they will go out of business. If they sell at an average price they will sell less, as the entry level will be too high for many applications. This will, in turn, bias the average price upwards. Nobody really wins. Even the buyers of the highest specified parts would be sourcing from a weakened supplier, less able to service them.

Most dies these days are spun into multiple sellable products. Its the only way the industry has so far devised to balance the market need for a wide range of products with the huge cost to develop each mask set.

[frogmaster]

How probable is it that other chips, eg. ZYNQ 7010 & 7020 are actually the same die?

[aventuri]

How probable is it that other chips, eg. ZYNQ 7010 & 7020 are actually the same die?

me too same thought! but had just a look at UG585 (IIRC) where firmware sizes are showed and they are different.

only Zynq7035 and Zynq7045 do have same size.. pretty interesting uhuh :-)

[Someone]

To delight some and disappoint others I will present the outline of hacking a Xilinx bitstream for such a purpose. I don't have enough 7 series parts on hand to make a go of it with them but I do have plenty of spartan series parts and an easy target is the S6LX4 and S6LX9 which both show the same quiescent supply currents and have the same number of PLLs available.




The smaller device is missing several rows of slices, half the DSP sites, and most of the RAMs. They are possibly untested but for hacking its all up in the air.

Comparative analysis of .bin files generated for the same placed design in the two parts showed very simple changes, one key is the ability to turn off CRC checking of the design when generating the programming file by unchecking "Enable Cyclic Redundancy Checking (CRC)". Similarly the .mcs output prom file had the same changes between the two parts and can be programmed directly to an SPI flash for configuration. Ignoring this:

INFO:iMPACT - A CFI file is not detected. To ensure correct and safe configuration,
 Please make sure a CFI file is present in the same directory as the PROM file,
 or, regenerate the PROM file with the latest software.

The part programs fine and can run the larger designs, as a quick test:

Specific Feature Utilization:
  Number of RAMB16BWERs: 27 out of 32 84%

The done pin goes high and data merrily flows through the rams without error, more testing would be needed on any design you try this with as there may be some gotchas or untested silicon being utilised.